Summary: | sys-freebsd/freebsd-lib-7.1: miscompilation with gcc 4.4 without -fno-strict-aliasing | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | FreeBSD | Assignee: | Gentoo/BSD Team <bsd+disabled> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | esigra, rhill, treecleaner |
Priority: | High | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Deadline: | 2019-10-11 |
Description
Diego Elio Pettenò (RETIRED)
2009-05-16 19:48:30 UTC
Fun, seems like the copy of gawk that I have on the same system behaves the same way. Not nice at all. Can somebody confirm/deny this? If it's only me I'd blame QEmu/KVM.. Seems like there is a miscompilation in the FreeBSD C library when using GCC 4.4, I'm marking GCC 4.4 -x86-fbsd for now, we can find the cause later maybe.. Reduced testcase to show where the problem is... gfbsd ~ # cat test.c #include <stdio.h> int main() { printf("%f\n", 11.0); } gfbsd ~ # gcc test.c -o test gfbsd ~ # ./test ;0.000000 [this causes strange effects on the original awk, gawk behaves slightly differently and outputs ;0 directly...] After looking around it seems like it's a variation of the problem reported to me by Alexander Patrakov before: http://blog.flameeyes.eu/2009/03/09/you-should-refuse-stable http://bugs.debian.org/518927 http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html I've appended -fno-strict-aliasing and rekeyworded gcc 4.4 so that we can move on. Let's keep this open until it's really fixed. I cannot reproduce this with sys-freebsd/freebsd-lib-9.0 and either GCC 4.6 or Clang 3.1. Are there any objections to removing -fno-strict-aliasing from the ebuild? We need to test this on x86. Right now, I only have amd64 setup. I will setup an x86 jail later to test this. sys-freebsd/* is now pmasked. sys-freebsd/* removed. |