Expr::isIntegerConstantExpr() seems to return bogus results with the sizeof() operator.
For example, for input "21-2*2+4", it returns 21 as expected
but with sizeof:
So it seems that sizeof() is being computed in bits, but then the operations aren't consistent. (in fact it should be computed in bytes, as that's the value of that operator in C/C++)
Should the fix instead go in the body of getTypeSize() instead of within isConstantExpr()? Should getTypeSize() ever return the number of bits instead of the number of bytes? Does this have something to do with bitfields?
So it seems that sizeof() is being computed in bits, but then the
operations aren't consistent. (in fact it should be computed in bytes,
as that's the value of that operator in C/C++)
Yep, you're right, applied, thanks!
-Chris
Should the fix instead go in the body of getTypeSize() instead of within isConstantExpr()? Should getTypeSize() ever return the number of bits instead of the number of bytes? Does this have something to do with bitfields?
This is the right solution. We want getTypeSize to be unambiguous as to units, and bits are the most constant thing there are. Various strange things like bitfields, non-8-bit-bytes, and datatypes that are not even multiples of byte sizes all conspire to wanting to have a simple and unambiguous unit to represent things in, bits is the right way to go.
sizeof, on the other hand, is determined in units of sizeof(char). To be fully general, it shouldn't divide by 8, it should divide by TargetInfo.getCharSize().
So it seems that sizeof() is being computed in bits, but then the
operations aren't consistent. (in fact it should be computed in bytes,
as that's the value of that operator in C/C++)
Yep, you're right, applied, thanks!
-Chris
Should the fix instead go in the body of getTypeSize() instead of within isConstantExpr()? Should getTypeSize() ever return the number of bits instead of the number of bytes? Does this have something to do with bitfields?
This is the right solution. We want getTypeSize to be unambiguous as to units, and bits are the most constant thing there are. Various strange things like bitfields, non-8-bit-bytes, and datatypes that are not even multiples of byte sizes all conspire to wanting to have a simple and unambiguous unit to represent things in, bits is the right way to go.
Okay. Seems like a valid reason to me.
sizeof, on the other hand, is determined in units of sizeof(char). To be fully general, it shouldn't divide by 8, it should divide by TargetInfo.getCharSize().
I am not sure this is the right forum for reporting LLVM build problems. But here it is. After a recent update, I get this build error building llvm:
llvm[2]: Compiling Lexer.cpp for Debug build
/Volumes/sandbox/llvm/lib/AsmParser/Lexer.l: In function ‘int llvmAsmlex()’:
/Volumes/sandbox/llvm/lib/AsmParser/Lexer.l:278: error: ‘PURE’ was not declared in this scope
/Volumes/sandbox/llvm/lib/AsmParser/Lexer.l:279: error: ‘CONST’ was not declared in this scope
Lexer.cpp: In function ‘int yy_get_next_buffer()’:
Lexer.cpp:2543: warning: comparison between signed and unsigned integer expressions
make[2]: *** [/Volumes/sandbox/llvm/lib/AsmParser/Debug/Lexer.o] Error 1
make[1]: *** [AsmParser/.makeall] Error 2
make: *** [all] Error 1
sizeof, on the other hand, is determined in units of sizeof(char). To be fully general, it shouldn't divide by 8, it should divide by TargetInfo.getCharSize().