This decision was intentional, as documented in
https://sourceforge.net/p/mspgcc/bugs/118/. My recollection is that the
choice of how to make things consistent was informed by similar behavior in
the contemporaneous gcc for x86 or at least one other target architecture.
As you say, the behavior is undefined. Anybody who expects any particular
behavior for this situation is confused about how C works and should take
the issue up with JTC1/SC22/WG14.
Peter
On Sun, Apr 21, 2013 at 2:35 PM, Paul Sokolovsky <pmis...@gmail.com> 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.
>
>
> --
> Best regards,
> Paul mailto:pmis...@gmail.com
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
