On Thu, Oct 13, 2005 at 11:05:01PM +0100, Stephen Gran wrote: > I think you are misunderstanding him, Steve, or I am misunderstanding > the whole thing (which is not unlikely). I think Aurelian is saying > that the same source code that you supplied builds and runs fine with > gcc-3.4, but not with gcc-4.0:
Well, while that's true, I don't believe that's what he was saying at the time; the 3.4 vs. 4.0 generated code he cited corresponded to the assembly from libm, not to the test case I provided. > [EMAIL PROTECTED]:~$ gcc-3.4 -lm test.c -o test.3.4 > [EMAIL PROTECTED]:~$ gcc-4.0 -lm test.c -o test.4 > [EMAIL PROTECTED]:~$ ./test.3.4 > [EMAIL PROTECTED]:~$ ./test.4 > Bus error > This certainly smells more like a compiler bug than anything. The same > library and the same header files, 2 different compiler versions, 2 > results. To say that this is a compiler bug, you would have to show that gcc-4.0 is *wrong* to 32-bit align the fenv_t struct instead of 64-bit aligning it. You'd have to check with the compiler folks to be sure, but I don't think this is a correct assertion for a struct of 32-bit unsigned ints. At any rate, knowing that gcc-3.4 does this alignment differently gives us a viable workaround for qt; since qt is already building with g++-3.4 on hppa (et al.), it's no trouble to also make it build-depend on and use gcc-3.4. On Fri, Oct 14, 2005 at 12:20:50AM +0200, Aurelien Jarno wrote: > Well we've discussed a bit of that on IRC with Steve, I think we have > two problems (maybe linked): > - gcc-3.4 and gcc-4.0 changed the way they align the code. > Have a look at your test.c file. There is nothing in it, and moreover > gdb show the problem appears in libm, which has been compiled with > gcc-3.4. > - gcc-4.0 generates wrong code > For that see my attached file. It's the file from the glibc, with the > code from Steve pasted at the end. It works with gcc-3.4, but fails > with gcc-4.0. I suspect that compiling this portion of glibc with gcc-4.0 will give the same behavior: building test.c with gcc-4.0 will fail, building test.c with gcc-3.4 will succeed. Either that, or both will fail if this is one of the cases where gcc-4.0 breaks glibc horribly, but I didn't see any reason to think this was the case. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
