Am Sonntag, den 21.09.2014, 17:34 +0200 schrieb Szabolcs Nagy:
> * Jens Gustedt <Jens.Gustedt@inria.fr> [2014-09-21 16:39:34 +0200]:
> > 
> > This fixes a bug found by Nadav Har'El, who observed that musl was giving
> > different prn sequences than other systems, even if seeded with the same
> > value.
> > 
> > The problem with something like
> > 
> > a = lc[0] | lc[1]<<16 | lc[2]+0ULL<<32;
> > 
> > where lc[1] is an unsigned short and int is 32bit is the following
> > 
> > (1) lc[1] is promoted to int
> > (2) the left shift 16 is performed on int
> > 
> 
> the fix looks ok, but i'm not clear on why it breaks in practice

I was curious, too. The assembler looks a bit different, so it is not
so easy to tell. But it looks to me that the problem comes from a cltq
instruction that is inserted in the faulty code. It probably sets the
high bits of %rax to 1 before the or-ing of the different parts takes
place.

I think the cltq instruction comes handy to zero out the the high
order bits of the %rax register in the defined case.

> (i know it's ub, but gcc used to handle such shifts "as expected"
> the linux kernel is full of them and c++14 allows this and there
> is a dr to change the semantics for c too
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_463.htm
> )

right, so this here can serve as an example why this ain't so easy to
define that behavior.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::