[Bug middle-end/27733] [4.1 Regression] Large compile time regression
--- Comment #20 from soete dot joel at tiscali dot be 2006-06-13 15:43 --- (In reply to comment #19) > Fixed, but we may want the patch on 4.0 too. > Curious I didn't notice this pb gcc-4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1 Regression] Large compile time regression
--- Comment #17 from soete dot joel at tiscali dot be 2006-06-11 13:56 --- Yes, it does the drill: I back port this patch against debian gcc-4.1 stock sources (gcc version 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)) and got this excellent improvement of the real case (kernel parisc linux page_alloc.c) # time sh ../TstPageAlloc + hppa64-linux-gnu-gcc-4.1 -Wp,-MD,mm/.page_alloc.o.d -nostdinc -isystem /usr/li b/gcc/hppa64-linux-gnu/4.1.2/include -D__KERNEL__ -Iinclude -Iinclude2 -I/CAD/li nux-2.6.17-rc5-pa3/include -include include/linux/autoconf.h -I/CAD/linux-2.6.17 -rc5-pa3/mm -Imm -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-al iasing -fno-common -O2 -fomit-frame-pointer -pipe -mno-space-regs -mfast-indirec t-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000 -Wdeclar ation-after-statement -Wno-pointer-sign '-DKBUILD_STR(s)=#s' '-DKBUILD_BASENAME= KBUILD_STR(page_alloc)' '-DKBUILD_MODNAME=KBUILD_STR(page_alloc)' -c -o mm/.tmp_ page_alloc.o /CAD/linux-2.6.17-rc5-pa3/mm/page_alloc.c with the debian stock 64bit xcompiler: real92m41.950s user88m4.628s sys 0m2.520s with patch applied: real2m32.845s user2m24.835s sys 0m0.229s Thanks a lot, J. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug target/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc
--- Comment #5 from soete dot joel at tiscali dot be 2006-05-17 08:56
---
Created an attachment (id=11481)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11481&action=view)
just another similar test case regarding double equivalent pb
compile with -O2 the Nan3.s is:
.LEVEL 1.1
.section .rodata.str1.4,"aMS",@progbits,1
.align 4
.LC1:
.stringz"__builtin_nan(): 0x%llx.\n"
.section .rodata.cst8,"aM",@progbits,8
.align 8
.LC0:
.word 2146959360
.word 0
.text
.align 4
.globl main
.type main, @function
main:
.PROC
.CALLINFO FRAME=0,CALLS,SAVE_RP
.ENTRY
stw %r2,-20(%r30)
ldil LR'.LC0,%r28
ldil LR'.LC1,%r26
ldw RR'.LC0(%r28),%r23
ldw RR'.LC0+4(%r28),%r24
ldo RR'.LC1(%r26),%r26
ldw -20(%r30),%r2
bl printf,%r0
nop
nop
.EXIT
.PROCEND
.size main, .-main
.ident "GCC: (GNU) 4.1.1 20060511 (prerelease) (Debian 4.1.0-4)"
and print out:
__builtin_nan(): 0x7ff8.
or bin form of 1 32bit word: 0000
i.e.
- the first bit being the sign == 0
- next 11 being the exponenent all == 1
- next 52 one being fraction have the first bit == 1, making this NAN a
signaling NAN.
And according to this thread (I don't have access to C99 std ;-( ):
<http://gcc.gnu.org/ml/libstdc++/2002-09/msg00030.html>
as well as gcc info
/quote
-- Built-in Function: double __builtin_nan (const char *str)
This is an implementation of the ISO C99 function `nan'.
Since ISO C99 defines this function in terms of `strtod', which we
do not implement, a description of the parsing is in order. The
string is parsed as by `strtol'; that is, the base is recognized by
leading `0' or `0x' prefixes. The number parsed is placed in the
significand such that the least significant bit of the number is
at the least significant bit of the significand. The number is
truncated to fit the significand field provided. The significand
is forced to be a quiet NaN.
This function, if given a string literal, is evaluated early enough
that it is considered a compile-time constant.
/quote
__builtin_nan[f](""); should return a quiet NAN. To do so, the parisc2.0 doc,
says that the fraction part have to be <> 0 but with first bit == 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
[Bug c/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc
--- Comment #2 from soete dot joel at tiscali dot be 2006-05-16 15:58 --- Created an attachment (id=11477) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11477&action=view) a very simpler test case afaik don't need precompile (just rebuild) (e.g. gcc -o nan2 Nan2.c; ./nan2) -- soete dot joel at tiscali dot be changed: What|Removed |Added Attachment #11476|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
[Bug c/27627] __builtin_nanf("") doesn't return a _quiet_ nan on parisc
--- Comment #1 from soete dot joel at tiscali dot be 2006-05-16 11:51 --- Created an attachment (id=11476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11476&action=view) precompile nan test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
[Bug c/27627] New: __builtin_nanf("") doesn't return a _quiet_ nan on parisc
ld-tree/hppa-libc/math
..
../libio
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc
../sysdeps/hppa/elf
../libidn/sysdeps/unix
../linuxthreads/sysdeps/unix/sysv/linux/hppa
../linuxthreads/sysdeps/unix/sysv/linux
../linuxthreads/sysdeps/pthread
../sysdeps/pthread
../linuxthreads/sysdeps/unix/sysv
../linuxthreads/sysdeps/unix
../linuxthreads/sysdeps/hppa
../sysdeps/unix/sysv/linux/hppa
../sysdeps/unix/sysv/linux
../sysdeps/gnu
../sysdeps/unix/common
../sysdeps/unix/mman
../sysdeps/unix/inet
../sysdeps/unix/sysv
../sysdeps/unix
../sysdeps/posix
../sysdeps/hppa/hppa1.1
../sysdeps/wordsize-32
../sysdeps/ieee754/flt-32
../sysdeps/ieee754/dbl-64
../sysdeps/hppa/fpu
../sysdeps/hppa
../sysdeps/ieee754
../sysdeps/generic/elf
../sysdeps/generic
/usr/lib/gcc/hppa-linux-gnu/4.1.1/include
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/debian/include
End of search list.
/usr/lib/gcc/hppa-linux-gnu/4.1.1/cc1 -fpreprocessed Nan.i -quiet -dumpbase
Nan.c -auxbase-strip
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc/math/Nan.o
-g -O2 -
Wall -Winline -Wstrict-prototypes -Wwrite-strings -Wno-uninitialized
-std=gnu99 -version -fstrict-aliasing -fno-inline -ffloat-store -fno-builtin
-o Nan.s
GNU C version 4.1.1 20060511 (prerelease) (Debian 4.1.0-4) (hppa-linux-gnu)
compiled by GNU C version 4.1.1 20060511 (prerelease) (Debian 4.1.0-4).
GGC heuristics: --param ggc-min-expand=46 --param ggc-min-heapsize=31137
Compiler executable checksum: e86175deb88d866b27528eee26dfa969
as --traditional-format -V -o
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc/math/Nan.o
Nan.s
GNU assembler version 2.16.91 (hppa-linux-gnu) using BFD version 2.16.91
20060413 Debian GNU/Linux
--
Summary: __builtin_nanf("") doesn't return a _quiet_ nan on
parisc
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: soete dot joel at tiscali dot be
GCC build triplet: hppa-unknown-linux-gnu
GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
[Bug target/17471] glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux
--- Additional Comments From soete dot joel at tiscali dot be 2005-09-04 19:42 --- Subject: Re: glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux Hello pinskia, mmm I don't know very accurately how are manage outdated br? In fact the pr doesn't exist anymore to build glibc-2.3.5 with gcc-4.0. Ok not related to the mentioned pr (completely different releases) but they are, since recently, the new operational toolchain in debian unstable :^), though. I so suspect that there is any more interest to fix that old pb? What's your opinion if you close it? Thanks, Joel pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-04 > 19:06 --- > No feedback in 3 months. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17471
[Bug target/17471] glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux
--- Additional Comments From soete dot joel at tiscali dot be 2004-12-19 20:54 --- Subject: Re: glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 > 03:43 --- > Does this happen in 3.4.3? > Sorry no progress :-( CPP='/usr/bin/gcc-3.4 -E -x c-header' /Develop/parisc-linux/build/glibc/elf/ld.so.1 --library-path /Develop/parisc-linux/build/glibc:/Develop/parisc-linux/build/glibc/math:/Develop/parisc-linux/build/glibc/elf:/Develop/parisc-linux/build/glibc/dlfcn:/Develop/parisc-linux/build/glibc/nss:/Develop/parisc-linux/build/glibc/nis:/Develop/parisc-linux/build/glibc/rt:/Develop/parisc-linux/build/glibc/resolv:/Develop/parisc-linux/build/glibc/crypt:/Develop/parisc-linux/build/glibc/linuxthreads /Develop/parisc-linux/build/glibc/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.T make[2]: *** [/Develop/parisc-linux/build/glibc/sunrpc/xbootparam_prot.stmp] Segmentation fault make[2]: Leaving directory `/Develop/parisc-linux/sources/glibc-2.3.3-hppa-20041011/sunrpc' make[1]: *** [sunrpc/others] Error 2 make[1]: Leaving directory `/Develop/parisc-linux/sources/glibc-2.3.3-hppa-20041011' make: *** [all] Error 2 ### Sat Dec 18 21:10:57 2004 ### # dpkg -l gcc-3.4 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gcc-3.43.4.3-2The GNU C compiler Sorry far beyond my skill to help more. Thanks for your attention, Joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17471
[Bug target/17471] glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux
--- Additional Comments From soete dot joel at tiscali dot be 2004-12-18 11:32 --- Subject: Re: glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 > 03:43 --- > Does this happen in 3.4.3? > Have to check; will advise Joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17471
