This bug will depend on every gcc-3.3.3 related bug on the ppc platform Reproducible: Always Steps to Reproduce:
making it blocking #39041 since tethereal needs gcc-3.3.3 to be functional
Notice: gcc-3.3.3 has problems with the altivec code, the fixes for that issue are in the gcc-3.3.3-hammer branch
I made another snapshot from the hammer branch, same issues with openssl.
found the problem seems that -fstrict-aliasing may cause problems if the program (like openssl) uses type punning in the wrong way. appending -fno-strict-aliasing seems to solve the problem.
Just to be sure; is fstrict-aliasing what broke I/O operations in combination with the type thing? So, does the 20040215 snapshot work ok too if you specify -fnostrict-aliasing as option?
We cannot be sure if we don't try it. A good way check is using -Werror -Wstrict-aliasing and probably you get gcc pointing at some code segments or just grep the warning for the type-pun. I guess that this is the problem and I'm not sure if it will be solved by gcc or requires us to patch a _LOT_ of programs or to add -fno-strict-aliasing as default flag.
Seems that our problem is a side effect of a feature... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14725
the latest (0426 and 0505) snapshots have any sort of wierd problems, the 20040408-r1 should be the latest one stable enough to experimental use. I'm about to apply the stack fix to the gcc-3.4.0-r1 and start some tests.
I'll bump gcc-20040408-r1 to stable together with glibc-20040420-r1, unless somebody shouts. don't forget -fno-strict-aliasing :-)
removing ppc64 from this bug as we're no longer 3.3 based at all.
we can close it
