As you say, the reason for the undefined behaviour in the standard is
because different ISA (instruction set architectures) behave differently.
The underlying assumption here is that C is a 'bare metal' language, and
implements high level operations that map well to the machine language
facilities.
As a result, you should not expect any commonality in behaviour between
different ISA if there isn't commonality between their respective natural
binary operations. If the overall fastest generated code for a
standard-defined case is to mask out the shift count, it would be against
the spirit of C to do anything else.
This reminds me of the section of GCC manual that said something like
'because the behaviour in this case is undefined and left to the
implementer, our choice is to launch a game of life'.
On Sun, Apr 21, 2013 at 3: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
