[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free

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.

> sgran@paer:~$ gcc-3.4 -lm test.c -o test.3.4
> sgran@paer:~$ gcc-4.0 -lm test.c -o test.4
> sgran@paer:~$ ./test.3.4
> sgran@paer:~$ ./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.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: