[Openslp-announce] IMPORTANT: Openslp does not work on RH8.0

[Matt P. <ma...@sc...>]

OK.  I've finally figured out what is going on here:

It turns out that the newer versions of GCC use strict aliasing as part o=
f the=20
-O3 optimizations.  The ToUINTxx() macros are not "alias safe".  In other=
=20
words, they assume that differing pointer types can point to the same mem=
ory=20
location.  There is a simple work around that is now checked into CVS and=
=20
will be available in the next release of OpenSLP 1.0.11.  The fix involve=
s a=20
changing the ToUINTxx() macros to simple inline functions.

For those of you still compiling OpenSLP 1.0.10 you MUST modify CFLAGS to=
=20
include the -fno-strict-aliasing flag or compile without -O3.


On Thursday 13 February 2003 01:53 am, Christoph Bartoschek wrote:
> Hi,
>
> your attached programm was incomplete in regard to our problem. I've
> modified it such that it shows the FAILURE on my machine, with an outpu=
t of
>
> FAILURE: Your machine is busted
> 0x0
> 0x0
> 0x0
> 0x0
> 0xbb
> 0x0
> 0x2
> 0xaa
> 0xbb
> 0x0
>
> it is neccessary that you compile it with
> gcc -O3 htons_test.c
> because optimized code uses a macro htons while unoptimized code calls =
a
> function. The resulting binary fails on two other machines. A Athlon an=
d a
> Celeron. You should compile the program with -E to see the difference
> between RH8.0 and other machines.
>
> My machine is a
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 2
> model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
> stepping        : 4
> cpu MHz         : 2405.513
> cache size      : 512 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge =
mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> bogomips        : 4784.26
>
>
> The same error occurs in RH 8.1beta2. Therefore I conclude there is a e=
rror
> in the glibc.
>
> BTW, you should always include the header files you need.
>
> Am Donnerstag, 13. Februar 2003 01:03 schrieben Sie:
> > Christoph,
> >
> > I have checked this out on a Redhat 8.0 machine in our lab.
> >
> > $ cat /proc/cpuinfo
> >
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 6
> > model           : 8
> > model name      : Pentium III (Coppermine)
> > stepping        : 3
> > cpu MHz         : 937.597
> > cache size      : 256 KB
> > Physical processor ID   : 1631139384
> > Number of siblings      : 1
> > fdiv_bug        : no
> > hlt_bug         : no
> > f00f_bug        : no
> > coma_bug        : no
> > fpu             : yes
> > fpu_exception   : yes
> > cpuid level     : 2
> > wp              : yes
> > flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pg=
e
> > mca cmov pat pse36 mmx fxsr sse
> > bogomips        : 1859.14
> >
> > I do not see any problems.  I have attached a very short program that
> > runs a quick test.  If you can verify that the attached source identi=
fies
> > the problem on your pentium 4 then I will send it to RedHat as part o=
f a
> > bug report against RH8.0
> >
> > Thanks,
> >
> > Matt