Hi, When I compile the code you gave below (using gcc 4.6.3 from 20120406), I get:
warning: left shift count >= width of type [enabled by default] That is even without any sort of warning flags - and you should normally enable lots of warnings. So here you have undefined code, and the compiler tells you of the problem. You really cannot get better than that by trying to invent your own ideas about how you want to define this undefined behaviour. David On 21/04/13 21:35, Paul Sokolovsky wrote: > Hello, > > It's a known fact that shifting by more or equal bits as an integer > type contains is undefined behavior per C standard, > http://stackoverflow.com/questions/7214263/unexpected-behavior-of-bitwise-shifting-using-gcc > has relevant quotes and references. > > It's less known the rules of dealing with "undefined" values for > compiler writers, in this respect I find LLVM's description insightful: > http://llvm.org/docs/LangRef.html#undefined-values . Summing up, it > says that result of most of the expressions involving undefined value > is also undefined. > > Finally, it's known why C standard has it like that: because rules > various CPUs use for such shifts at *runtime* vary, so *runtime* code > should not rely on them. C also doesn't define separation between > compile-time and run-time evaluation strictly, so for it any shift by > too many bits is undefined. > > It's all nice and good. But there's difference between "undefined", > "any value" and "weird". Because "too many bits" shifts may be > undefined in C standard, but shifts by arbitrary number of bits are > very well defined in arithmetic - and by very definition of (unsigned) > shift, any value shifted by more bits than available in its > representation is 0. That's logical, that's what users know, that's > what they expect from compiler, and well, that's how x86-gcc behaves. > > Now mspgcc: > > int v = 5; > int main() > { > printf("%d\n", v + (1 << 16)); > } > > main: > mov r1, r4 > add #2, r4 > mov &v, r15 > add #1, r15 > push r15 > push #.LC0 > call #printf > add #4, r1 > > > So, msp430-gcc just masks out higher bits of shift count, and in this > case leaves original value intact. Which turns term ((1 << BITS) - 1), > which is common to do BITS-modular arithmetic, and would be expected to > just optimize out in case of a full type, into an expression killer with > infinite loops, etc. ensuing. > > ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
