[Bug c/32865] New: glibc ICE's gcc-4.3.0 SSA corruption [4.3 Regression]
c/powerpc32
../sysdeps/unix/sysv/linux/powerpc/powerpc32
../nptl/sysdeps/unix/sysv/linux/powerpc
../ports/sysdeps/unix/sysv/linux/powerpc
../sysdeps/unix/sysv/linux/powerpc
../sysdeps/ieee754/ldbl-128ibm
../sysdeps/ieee754/ldbl-opt
../nptl/sysdeps/unix/sysv/linux
../nptl/sysdeps/pthread
../sysdeps/pthread
../ports/sysdeps/unix/sysv/linux
../sysdeps/unix/sysv/linux
../sysdeps/gnu
../sysdeps/unix/common
../sysdeps/unix/mman
../sysdeps/unix/inet
../nptl/sysdeps/unix/sysv
../ports/sysdeps/unix/sysv
../sysdeps/unix/sysv
../sysdeps/unix/powerpc
../nptl/sysdeps/unix
../ports/sysdeps/unix
../sysdeps/unix
../sysdeps/posix
../sysdeps/powerpc/powerpc32
../sysdeps/wordsize-32
../sysdeps/powerpc/fpu
../nptl/sysdeps/powerpc
../ports/sysdeps/powerpc
../sysdeps/powerpc
../sysdeps/ieee754/dbl-64
../sysdeps/ieee754/flt-32
../sysdeps/ieee754
../sysdeps/generic/elf
../sysdeps/generic
../nptl
../ports
..
../libio
.
/usr/include/libffi
/usr/include
End of search list.
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -fpreprocessed vfprintf.i
-quiet -dumpbase vfprintf.c -mcpu=G4 -mnew-mnemonics -mlong-double-128
-auxbase-strip
/var/tmp/portage/sys-libs/glibc-2.6/work/build-default-powerpc-unknown-linux-gnu-nptl/stdio-common/vfprintf.o
-O2 -Wall -Winline -Wwrite-strings -Wstrict-prototypes -Wno-uninitialized
-std=gnu99 -version -fgnu89-inline -fmerge-all-constants -fno-strict-aliasing
-freorder-blocks -o vfprintf.s
GNU C version 4.3.0 20070723 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070723 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96556
Compiler executable checksum: 5d5139bad2f5d41bdb4959a445c33bb0
vfprintf.c: In function '_IO_vfprintf_internal':
vfprintf.c:1301: warning: pointer targets in passing argument 1 of
'__find_specmb' differ in signedness
Unable to coalesce ssa_names 1221 and 144 which are marked as MUST COALESCE.
is_long_double_1221(ab) and is_long_double_144(ab)
vfprintf.c:184: internal compiler error: SSA corruption
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: glibc ICE's gcc-4.3.0 SSA corruption [4.3 Regression]
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michelin60 at gmail dot com
GCC build triplet: rs6000
GCC host triplet: rs6000
GCC target triplet: rs6000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug c/32865] glibc ICE's gcc-4.3.0 SSA corruption [4.3 Regression]
--- Comment #1 from michelin60 at gmail dot com 2007-07-23 13:48 --- Created an attachment (id=13952) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13952&action=view) preprocessed vprintf.c from glibc-2.6 vprintf.c from glibc-2.6, glibc2.6.90, and glibc-2.5 differ in minor ways but cause the same SSA-Corruption -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug c/32865] glibc ICE's gcc-4.3.0 SSA corruption [4.3 Regression]
--- Comment #2 from michelin60 at gmail dot com 2007-07-23 13:51 --- Created an attachment (id=13953) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13953&action=view) Partial *.s output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #4 from michelin60 at gmail dot com 2007-07-23 18:03 --- (In reply to comment #3) > Stop changing the CC for this bug, the issue is a generic issue and most > likely > unrelated to any of the CC you added. This is more likely to be a PRE issue > than anything else. When I get into work, I will look into it further to > double check. > The three person CC'd are listed per MAINTAINERS as follows: rs600o portDavid Edelsohn c++ runtime libs Ulrich Drepper (also glibc) tree-ssa Andrew Macloed while spu port Andre Pinski (spu ?= playsation.sony.???) Doing a search of PR's filed I came up, surprise, with no remotely equivalent report and I chose people that matched what I reported. As the author of the report I think that I have the right to choose peple that match as provided by the MAINTAINER's list -- michelin60 at gmail dot com changed: What|Removed |Added CC||dje at watson dot ibm dot ||com, amacleod at redhat dot ||com, drepper at redhat dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #6 from michelin60 at gmail dot com 2007-07-23 18:33 --- (In reply to comment #5) > Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption > > No, you do not. You submitted the bug. Let the GCC developers > decide how best to triage and analyse the bug. > > David Well David here is an interesting quote: IMO the most notorious case is how the gcc development is held hostage by Edelsohn and maybe IBM as a whole by requesting that everything always works perfectly well on AIX. How often has one seen "this patch breaks AIX, back it out". It cannot reasonably be expected that everybody tests on AIX. It is an proprietary OS running on proprietary and expensive hardware which not many people have access to. The overall development speed could be significantly improved by dropping the AIX requirement which, in some form or another, has been agreed upon by the steering committee. AIX is irrelevant in general today, i.e., the situation changed. And the people in the steering committee are too nice to just tell the very small minority causing the problem to take a hike. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #11 from michelin60 at gmail dot com 2007-07-23 23:17 --- Very interesting Using a colleague's i686 machine vfprintf.c did not fail with recent gcc-4.3. This led to further research prompting not only the CC's but also the quote. Dr. Edelsohn metioned triage but there are no triage officers in the MAINTERNER list. Also it might be useful to spell out the rights of submitters. It might discourage submissions which are quite onerous to conform to the already stated requirements. >From his webpage Mr. Berlin is a lawyer specializing in intellectual property and is also an author. He might want to provide some legal advice on conflicts of interest. The quote is specific to glibc and AIX. Potentially the AIX contortions forced upon glibc by Dr. Edelsohn could have caused the specific problem reported, not affecting i686. As an aside the officers of kernel.org (Torvalds, Morton) spell out quite clearly how they are not liable to any interpretation of conflict of interest. -- michelin60 at gmail dot com changed: What|Removed |Added CC||dje at watson dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32873] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #3 from michelin60 at gmail dot com 2007-07-28 00:00 --- Somewhat irritated by this plagiarizing the following come from my earlier PR32865 Unable to coalesce ssa_names 1221 and 144 which are marked as MUST COALESCE. is_long_double_1221(ab) and is_long_double_144(ab) vfprintf.c:184: internal compiler error: SSA corruption Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. --- Comment #1 From [EMAIL PROTECTED] 2007-07-23 13:48 [reply] --- Created an attachment (id=13952) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13952&action=view) [edit] preprocessed vprintf.c from glibc-2.6 vprintf.c from glibc-2.6, glibc2.6.90, and glibc-2.5 differ in minor ways but cause the same SSA-Corruption --- Comment #2 From [EMAIL PROTECTED] 2007-07-23 13:51 [reply] --- Created an attachment (id=13953) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13953&action=view) [edit] Partial *.s output --- Comment #3 From Andrew Pinski 2007-07-23 17:22 [reply] --- Stop changing the CC for this bug, the issue is a generic issue and most likely unrelated to any of the CC you added. This is more likely to be a PRE issue than anything else. When I get into work, I will look into it further to double check. --- Comment #4 From [EMAIL PROTECTED] 2007-07-23 18:03 [reply] --- (In reply to comment #3) > Stop changing the CC for this bug, the issue is a generic issue and most > likely > unrelated to any of the CC you added. This is more likely to be a PRE issue > than anything else. When I get into work, I will look into it further to > double check. > The three person CC'd are listed per MAINTAINERS as follows: rs600o portDavid Edelsohn c++ runtime libs Ulrich Drepper (also glibc) tree-ssa Andrew Macloed while spu port Andre Pinski (spu ?= playsation.sony.???) Doing a search of PR's filed I came up, surprise, with no remotely equivalent report and I chose people that matched what I reported. As the author of the report I think that I have the right to choose peple that match as provided by the MAINTAINER's list --- Comment #5 From David Edelsohn 2007-07-23 18:05 [reply] --- Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption >>>>> michelin60 at gmail dot com writes: michelin60> Doing a search of PR's filed I came up, surprise, with no remotely equivalent michelin60> report and I chose people that matched what I reported. As the author of the michelin60> report I think that I have the right to choose peple that match as provided by michelin60> the MAINTAINER's list No, you do not. You submitted the bug. Let the GCC developers decide how best to triage and analyse the bug. David --- Comment #6 From [EMAIL PROTECTED] 2007-07-23 18:33 [reply] --- (In reply to comment #5) > Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption > > No, you do not. You submitted the bug. Let the GCC developers > decide how best to triage and analyse the bug. > > David Well David here is an interesting quote: IMO the most notorious case is how the gcc development is held hostage by Edelsohn and maybe IBM as a whole by requesting that everything always works perfectly well on AIX. How often has one seen "this patch breaks AIX, back it out". It cannot reasonably be expected that everybody tests on AIX. It is an proprietary OS running on proprietary and expensive hardware which not many people have access to. The overall development speed could be significantly improved by dropping the AIX requirement which, in some form or another, has been agreed upon by the steering committee. AIX is irrelevant in general today, i.e., the situation changed. And the people in the steering committee are too nice to just tell the very small minority causing the problem to take a hike. --- Comment #7 From Andrew Pinski 2007-07-23 18:42 [reply] --- (In reply to comment #6) > Well David here is an interesting quote: Lets put it this way, this quote is true but it is held hostage in a good way. You don't want broken code in your compiler do you? This is what David and AIX does for GCC, they prevent bad code from being in GCC. Have you looked into what has been found via compiling on AIX? Lots of bugs. Who wants bugs in their compiler? Anyways as I have mentioned before, I am 99% sure this is ___NOT___ related to the powerpc back-end at all. And next time please don't CC anyone unless you are sure at what patch caused the issue. Also don't you can't expect a response within 24 hours, GCC developers are busy with their day jobs. --- Comment #8 From Andrew Pinski 2007-07-23 18:56 [reply] --- Working on a reduced testcase but when I quickly looked into it, PRE
[Bug c/32988] New: [4.3.0 Regression] ICE in build2_stat, at tree.c:3081
-implicit-function-declaration -Wdeclaration-after-statement -Wno-pointer-sign -version -fno-strict-aliasing -fno-common -ffixed-r2 -funit-at-a-time -fomit-frame-pointer -fno-stack-protector -o page_alloc.s GNU C version 4.2.2 20070731 (prerelease) (powerpc-unknown-linux-gnu) compiled by GNU C version 4.2.2 20070731 (prerelease). GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96556 Compiler executable checksum: 3dcdab03fd037d389f4b01296a9801b5 /usr/lib/gcc/powerpc-unknown-linux-gnu/4.2.2/../../../../powerpc-unknown-linux-gnu/bin/as -mppc -many -V -Qy -maltivec -o mm/page_alloc.o page_alloc.s GNU assembler version 2.17.50.0.16 (powerpc-unknown-linux-gnu) using BFD version (Linux/GNU Binutils) 2.17.50.0.16.20070511 -- Summary: [4.3.0 Regression] ICE in build2_stat, at tree.c:3081 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michelin60 at gmail dot com GCC build triplet: rs600 GCC host triplet: rs600 GCC target triplet: rs600 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32988
[Bug c/32988] [4.3.0 Regression] ICE in build2_stat, at tree.c:3081
--- Comment #1 from michelin60 at gmail dot com 2007-08-04 16:09 --- Created an attachment (id=14022) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14022&action=view) failing *.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32988
[Bug c/32988] [4.3.0 Regression] ICE in build2_stat, at tree.c:3081
--- Comment #2 from michelin60 at gmail dot com 2007-08-04 16:10 --- Created an attachment (id=14023) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14023&action=view) OK *.I -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32988
[Bug c/32988] [4.3.0 Regression] ICE in build2_stat, at tree.c:3081
--- Comment #3 from michelin60 at gmail dot com 2007-08-04 16:11 --- Created an attachment (id=14024) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14024&action=view) Failing *.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32988
[Bug c/33125] New: ICE during boot
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michelin60 at gmail dot com
GCC build triplet: rs000
GCC host triplet: rs6000
GCC target triplet: rs6000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33125
[Bug c/33125] ICE during boot
--- Comment #1 from michelin60 at gmail dot com 2007-08-20 19:07 --- Created an attachment (id=14083) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14083&action=view) preprocessed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33125
[Bug c/33125] ICE during boot
--- Comment #2 from michelin60 at gmail dot com 2007-08-21 00:48 --- This failure to boot perdures since since about 11.00 am. The extensive changes submitted by Chao-ying Fu did not change anything. Per telephone inquiry the same ICE occurs on a pentium3 but does not occur on a pentium2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33125
[Bug c/33125] ICE during boot
--- Comment #3 from michelin60 at gmail dot com 2007-08-21 01:01 --- Pr 33126 by torsten.debian.org seems to confirm this, even as that build was for a cross-boot. -- michelin60 at gmail dot com changed: What|Removed |Added CC||torsten at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33125
[Bug libstdc++/33168] New: GCC Boot failure, building libstc++
This time __please__ follow standard procedures instead of doing it like
PR33125/PR33126 where the earlier submission was made a duplicate of a later
one . Which then was left unconfirmed for a lengthy period (6+ hours) and
never formally closed as resolved leaving the parties hanging.
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,c++,fortran --enable-altivec --disable-libssp
--disable-decimal-float --disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070823 (experimental) (GCC)
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1plus -E -quiet -nostdinc++
-v
-I/var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include/powerpc-unknown-linux-gnu
-I/var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include
-I/var/tmp/43/gcc-4.3.0/libstdc++-v3/libsupc++ -iprefix
/var/tmp/43/build-140/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/
-D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux
-D__linux -Asystem=linux -Asystem=unix -Asystem=posix -D_GNU_SOURCE -isystem
/usr/powerpc-unknown-linux-gnu/include -isystem
/usr/powerpc-unknown-linux-gnu/sys-include
../gcc-4.3.0/libstdc++-v3/src/system_error.cc -mcpu=G4 -std=gnu++0x -Wall
-Wextra -Wwrite-strings -Wcast-qual -fno-implicit-templates
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-fworking-directory -O2 -fpch-preprocess -o system_error.ii
ignoring nonexistent directory "/usr/powerpc-unknown-linux-gnu/include"
ignoring nonexistent directory "/usr/powerpc-unknown-linux-gnu/sys-include"
ignoring nonexistent directory
"/var/tmp/43/build-140/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/var/tmp/43/build-140/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/var/tmp/43/build-140/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
ignoring nonexistent directory
"/var/tmp/43/build-140/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/var/tmp/43/build-140/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/var/tmp/43/build-140/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include/powerpc-unknown-linux-gnu
/var/tmp/43/build-140/powerpc-unknown-linux-gnu/libstdc++-v3/include
/var/tmp/43/gcc-4.3.0/libstdc++-v3/libsupc++
/usr/include/libffi
/usr/local/include
/usr/include
End of search list.
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1plus -fpreprocessed
system_error.ii -quiet -dumpbase system_error.cc -mcpu=G4 -auxbase-strip
system_error.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -std=gnu++0x
-version -fno-implicit-templates -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -o system_error.s
GNU C++ (GCC) version 4.3.0 20070823 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070823 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 91efee225a5243299b9fb0dada305fe7
../gcc-4.3.0/libstdc++-v3/src/system_error.cc:67: error: std::system_category
causes a section type conflict
--
Summary: GCC Boot failure, building libstc++
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michelin60 at gmail dot com
GCC build triplet: rs600
GCC host triplet: rs6000
GCC target triplet: rs6000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug libstdc++/33168] GCC Boot failure, building libstc++
--- Comment #1 from michelin60 at gmail dot com 2007-08-23 22:28 --- Created an attachment (id=14097) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14097&action=view) preprocessed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug fortran/33252] New: GCC-4.3.0 Bootstrap testsuite error increase
Attached will be an unaltered log of : nice --adjustment=18 make -j2 -i check 2>&1 |tee .Check done on : 127924 svn://gcc.gnu.org/svn/gcc/trunk svn://gcc.gnu.org/svn/gcc Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix --enable-shared --enable-clocale=gnu --enable-bootstrap --enable-languages=c,fortran,c++ --enable-altivec --disable-libssp --disable-decimal-float --disable-libmudflap --disable-nls --disable-werror --disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu --with-system-zlib Thread model: posix gcc version 4.3.0 20070830 (experimental) (GCC) The significant increase concerns gfortran; but, others appear high. This ist to amplify the result reported in PR33247. -- Summary: GCC-4.3.0 Bootstrap testsuite error increase Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michelin60 at gmail dot com GCC build triplet: powerpc GCC host triplet: powerpc GCC target triplet: powerpc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #1 from michelin60 at gmail dot com 2007-08-30 18:23 ---
Did not work as attachment with the following message:
GCC Bugzilla has suffered an internal error. Please save this page and send it
to [EMAIL PROTECTED] with details of what you were doing at the time this
message appeared.
URL: http://gcc.gnu.org/bugzilla/attachment.cgi
undef error - Undefined subroutine Fh::slice at
data/template/template/en/default/global/hidden-fields.html.tmpl line 58
Sending the make log below:
make[1]: Entering directory `/var/tmp/43/build-156'
make[2]: Entering directory `/var/tmp/43/build-156/fixincludes'
autogen -T ../../gcc-4.3.0/fixincludes/check.tpl
../../gcc-4.3.0/fixincludes/inclhack.def
autogen: symbol lookup error: autogen: undefined symbol: gh_enter
make[2]: [check] Error 127 (ignored)
/bin/sh ./check.sh ../../gcc-4.3.0/fixincludes/tests/base
/bin/sh: ./check.sh: No such file or directory
make[2]: [check] Error 127 (ignored)
make[2]: Leaving directory `/var/tmp/43/build-156/fixincludes'
make[2]: Entering directory `/var/tmp/43/build-156/intl'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/var/tmp/43/build-156/intl'
make[2]: Entering directory `/var/tmp/43/build-156/libcpp'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/var/tmp/43/build-156/libcpp'
make[2]: Entering directory `/var/tmp/43/build-156/libdecnumber'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory `/var/tmp/43/build-156/libdecnumber'
make[2]: Entering directory `/var/tmp/43/build-156/libiberty'
make[3]: Entering directory `/var/tmp/43/build-156/libiberty/testsuite'
powerpc-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.3.0/libiberty/testsuite/../../include -o test-demangle \
../../../gcc-4.3.0/libiberty/testsuite/test-demangle.c
../libiberty.a
make[2]: Entering directory `/var/tmp/43/build-156/gcc'
Making a new config file...
echo "set tmpdir /var/tmp/43/build-156/gcc/testsuite" >> ./tmp0
test -d testsuite || mkdir testsuite
test -d testsuite/gcc || mkdir testsuite/gcc
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc-4.3.0/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite/gcc; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=expect ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ;
\
export TCL_LIBRARY ; fi ; \
GCC_EXEC_PREFIX="/usr/lib/gcc/" ; export GCC_EXEC_PREFIX ; \
runtest --tool gcc )
WARNING: Couldn't find the global config file.
Test Run By root on Thu Aug 30 10:13:23 2007
Native configuration is powerpc-unknown-linux-gnu
=== gcc tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /var/tmp/43/gcc-4.3.0/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gcc.c-torture/compile/compile.exp
...
powerpc-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.3.0/libiberty/testsuite/../../include -DHAVE_CONFIG_H -I.. -o
test-pexecute \
../../../gcc-4.3.0/libiberty/testsuite/test-pexecute.c
../libiberty.a
powerpc-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.3.0/libiberty/testsuite/../../include -DHAVE_CONFIG_H -I.. -o
test-expandargv \
../../../gcc-4.3.0/libiberty/testsuite/test-expandargv.c
../libiberty.a
./test-demangle < ../../../gcc-4.3.0/libiberty/testsuite/demangle-expected
./test-demangle: 765 tests, 0 failures
./test-pexecute
./test-expandargv
PASS: test-expandargv-0.
PASS: test-expandargv-1.
PASS: test-expandargv-2.
PASS: test-expandargv-3.
make[3]: Leaving directory `/var/tmp/43/build-156/libiberty/testsuite'
make[2]: Leaving directory `/var/tmp/43/build-156/libiberty'
make[2]: Entering directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3'
Making check in include
make[3]: Entering directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3/include'
if [ ! -d "./powerpc-unknown-linux-gnu/bits/stdc++.h.gch" ]; then \
mkdir -p ./powerpc-unknown-linux-gnu/bits/stdc++.h.gch; \
fi; \
/var/tmp/43/build-156/./gcc/xgcc -shared-libgcc
-B/var/tmp/43/build-156/./gcc -nostdinc++
-L/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3/src
-L/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/powerpc-unknown-linux-gnu/bin/ -
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #4 from michelin60 at gmail dot com 2007-08-31 00:47 --- (> Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase > > > /var/tmp/43/gcc-4.3.0/libstdc++-v3/testsuite/libstdc++-abi/abi.exp. > > ERROR: could not compile testsuite_abi.cc > > This was fixed by: > 2007-08-30 Jakub Jelinek <[EMAIL PROTECTED]> > > PR target/33168 > * config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Return > true if any of the compare_section_name calls returned true, > rather than if any returned false. I am really confused now. I thought that PR33168 was fix by the patch from Dr. Edelsohn. It seems that Mr. Jelinek reversed the sense of the test. In any case PR33168 referred to libstdc++ and not gfortran. In any case I re-bootstrapped and got Mr Jelinek patch the results, still concerning gfortan are as follows: === gfortran tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /var/tmp/43/gcc-4.3.0/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/fmt_p_1.f90 -O0 execution test FAIL: gfortran.dg/fmt_p_1.f90 -O1 execution test FAIL: gfortran.dg/fmt_p_1.f90 -O2 execution test FAIL: gfortran.dg/fmt_p_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/fmt_p_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/fmt_p_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/fmt_p_1.f90 -O3 -g execution test FAIL: gfortran.dg/fmt_p_1.f90 -Os execution test Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp ... FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O0 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O1 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O2 execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -O3 -g execution test FAIL: gfortran.dg/large_real_kind_form_io_1.f90 -Os execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O0 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O1 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O2 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -O3 -g execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 -Os execution test Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gcc.c-torture/execute/execute.exp ... FAIL: gfortran.dg/nint_2.f90 -O0 execution test FAIL: gfortran.dg/output_exponents_1.f90 -O0 execution test FAIL: gfortran.dg/output_exponents_1.f90 -O1 execution test FAIL: gfortran.dg/output_exponents_1.f90 -O2 execution test FAIL: gfortran.dg/output_exponents_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/output_exponents_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/output_exponents_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/output_exponents_1.f90 -O3 -g execution test FAIL: gfortran.dg/output_exponents_1.f90 -Os execution test Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/gomp/gomp.exp ... Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/vect/vect.exp ... Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp ... Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp ... FAIL: gcc.c-torture/execute/mayalias-2.c compilation, -O3 -g (internal compiler error) FAIL: gcc.c-torture/execute/mayalias-3.c compilation, -O3 -g (internal compiler error) Running /var/tmp/43/gcc-4.3.0/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp ... === gfortran Summary === # of expected passes20768 # of unexpected failures33 # of expected failures 8 # of unsupported tests 36 Please bring this to the attention of the appropriate gfortran people. As a chemical engineer I am distressed that the gfortran people are not allowe
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #6 from michelin60 at gmail dot com 2007-08-31 01:43 --- (In reply to comment #5) > First off don't CC anyone unless there is a real reason to like you know they > caused the issue. Second most of the rest of the failures are PR 33225 > anyways. > First of all I CC'd Dr. Edelsohn because I mentioned him and he was the acting on PR33168, you chimed in about 24 hours later. Even you mention somebody involved by name it is common curtesy to make that person aware of that mention. Second I mentioned Mark Mitchell because he, as relesae manager, put a stop to backporting definitely aggravating productive use of GCC. Third you mentioning PR33168 out of context instead of PR33225 was just plain dumb so I CC'd Burnus because he seems to be working pretty hard to make gfortran usable. Last but not least, there are even two ICE's (mayalias) in the test results that I did not feel making an issue of. Result, do not force me to contact these people directly when you do not take the pain of even reading submissions. -- michelin60 at gmail dot com changed: What|Removed |Added CC||dje at watson dot ibm dot ||com, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #10 from michelin60 at gmail dot com 2007-08-31 04:33 --- (In reply to comment #7) > Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase > > > Second I mentioned Mark Mitchell because he, as relesae manager, put a stop > > to backporting definitely aggravating productive use of GCC. > This is the trunk we are talking about, I am seriously thinking you > need to understand what that means. There is no backporting, it is > And again, this is the trunk we are talking about, not some release > branch and we are not even in stage 3 yet so there will be issues. > It was just fixed so update and try again. > > Yes we know about those, if did a quick search, you would find that I > filed the bug about those before I added those testcase. Regarding the last quote I am led to believe that Mr. Pinski is taking undue credit. PR30758 (marked as a duplicate) is the first addressing the re-appearance of mayalias. there are another 5 PR, all appearing before Mr. Pinski's filing. This reminds me of what happened regarding PR33125 (filed by myself) and PR33126. Neither made to the bug list; neither has been officially closed. Anyhow the patch submitted seems to have resolved the issue. I updated, and I am now bootstrapping with check. I am sure Mr Delisle patch originally worked and passed tests; but, that some other later patch gave rise to what I, and seemingly others, saw in PR33252. I took issue with Mr. Pinski's confusing PR32225 with PR33125 not Mr Delisle volunteer work. Now to the more confusing issue of backporting. I managed to find the following: > IMO, for the Fortran front end, "regressions-only" is an inappropriate > criterion for this sort of mode, given that the front end does not have > a long history for the wrong-code and ICE-on-valid bugs to be > regressions against. I think that's less true than it used to be. It's true that gfortran is new-ish, and I've given the Fortran team a lot of flexibility in past release cycles. But, congratulations are in order: gfortran is now a real Fortran compiler and people really are using it! But, "regressions, wrong-code, and ICEs" isn't a bad criteria for this intermediate lockdown. I do expect Fortran to honor the regressions-only rule once the 4.3 release branch has been made. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] Mr Kargl explains what happened from an maintainer's and release manager's view but does not provide a paliative to the user. G77 relative to g90 is relatively much more out of date than C1989 to C1994. Anyhow, if memory serves, there was significant back-porting from 4.3 to 4.2.x to to solve some memory usage problems. Michelin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #14 from michelin60 at gmail dot com 2007-08-31 14:52 ---
>
> > FAIL: gfortran.dg/nint_2.f90 -O0 execution test
>
This one is annoying, I think I had it fixed (I saw it on numerous targets, and
fixed it on most... I believed it was fixed on all targets). If you are willing
> to get this fixed, please open a PR specifically for this problem, adding the
> relevant output from ${builddir}/gcc/testsuite/gfortran/gfortran.log.
> Additionally, you might want to compile and run the testcase outside of the
> testsuite framework, see what happens and put that into the bugreport.
> Hopefully, I can work on fixing that with you (asking you to perform any
> further inquiries).
>
> PS: most developers of gfortran are also end-users of the compiler, and
> volunteers. Most of us are academic or private researchers. Writing this long
> explanation took 30 minutes of my working day, and thus impacted my own
> resarch, so please consider it seriously. (I also am a working in physical
> chemistry, have a few friends working with Michelin.)
>
Thank you for your detailed and informative response. Glad to work with sombody
in the physical sciences. I was/am not smart enough to get into physical
chemistry. My family background is Northern Italy and any connection to the
French branch must have occurred centuries ago.
Let us start with the easiest one for me as this is the last working day of my
vacation, I cannot give access to to my dual G4 machine as my Internet
connection does not allow outside initiated connection. I will immediately
gather data on nint_2.f90 and open an PR.
Thanks again
Armando
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33271] New: nint_2.f90 abort compiled with -O0
section.note.GNU-stack,"",@progbits
The resulting executable came up with Abort.
I recompile with -O1 and execution was OK:
At your disposal for any further requests.
--
Summary: nint_2.f90 abort compiled with -O0
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michelin60 at gmail dot com
GCC build triplet: powerpc
GCC host triplet: powerpc
GCC target triplet: powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #1 from michelin60 at gmail dot com 2007-08-31 15:36 --- While I am properly logged in I did not even try using the attachment ptocess given the difficulties Torsten and myself had with PR33126 and PR33252 -- michelin60 at gmail dot com changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase
--- Comment #15 from michelin60 at gmail dot com 2007-08-31 15:52 --- > > Regarding the last quote I am led to believe that Mr. Pinski is taking undue > > credit. PR30758 (marked as a duplicate) is the first addressing the > > re-appearance of mayalias. there are another 5 PR, all appearing before Mr. > > Pinski's filing. > > Wait one minute, did you read PR 28834 (note how the number is lower)? > Also read comment #1: > >Note this is the testcase for > > 28807 which I was using for testing so the testcase might be added to the > > testsuite by the time someone gets around to looking into the bug. > What confused me (and I take full blame for it) was the following: --- Comment #7 From Andrew Pinski 2006-08-24 15:16 [reply] --- Mine, all mine. --- Comment #8 From [EMAIL PROTECTED] 2006-08-24 15:18 [reply] --- Subject: Bug number PR 28807 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00878.html --- Comment #9 From Andrew Pinski 2006-08-25 07:14 [reply] --- Fixed. Any further discussion with Mr Pinski and Mr. Kargl seems pointless as thanks to Mr. Coudert I am engaged in doing something constructive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #3 from michelin60 at gmail dot com 2007-08-31 17:24 ---
> Could you compile with "-O0 -fdump-tree-original" and attach the
> nint_3.f90.003t.original file (or similarly named)? Could you also run with
> "-O1 -fdump-tree-optimized" and attach nint_3.f90.115t.optimized (or similarly
> named)?
No problem but some questions:
A) I see that you and others put a number of patches and regenerations. Do you
want me to rebootstrap and then do it? If an earlier version is acceptable do
you want using the test command as amended per above can I do outside of the
gcc tree?
If outside the tree I can do it right now. I also hope that the attachment
process works again. personally I had no problems until PR33252. I presume you
are in Europe with a 6 hour time difference.
I will do it on nint_2.f90 right now to try the attachment nint_3.f90 migh have
been a slip on your part. They are small thus not attached.
Original:
MAIN__ ()
{
real8 a;
int4 j2;
int8 i2;
int8 i1;
real4 b;
int4 j1;
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options (7, (void *) &options.0);
a = 4.99944488848768742172978818416595459e-1;
i2 = 0;
i1 = (int8) __builtin_lround (a);
if (i1 != 0 || i2 != 0)
{
_gfortran_abort ();
}
a = 5.0e-1;
i2 = 1;
i1 = (int8) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
{
_gfortran_abort ();
}
a = 5.00111022302462515654042363166809082e-1;
i2 = 1;
i1 = (int8) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
{
_gfortran_abort ();
}
b = 4.99701976776123046875e-1;
j2 = 0;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 0 || j2 != 0)
{
_gfortran_abort ();
}
b = 5.0e-1;
j2 = 1;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
{
_gfortran_abort ();
}
b = 5.0059604644775390625e-1;
j2 = 1;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
{
_gfortran_abort ();
}
a = 4.503599627370497e+15;
i1 = __builtin_llround (a);
i2 = 4503599627370497;
if (i1 != i2 || i1 != 4503599627370497)
{
_gfortran_abort ();
}
a = -4.503599627370497e+15;
i1 = __builtin_llround (a);
i2 = -4503599627370497;
if (i1 != i2 || i1 != -4503599627370497)
{
_gfortran_abort ();
}
}
Optimized: ?
;; Function MAIN__ (MAIN__)
Analyzing Edge Insertions.
MAIN__ ()
{
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
:
_gfortran_set_options (7, &options.0);
return;
}
Invalid sum of incoming frequencies 1, should be 9053
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug c++/33126] gimplification failed during stdc++ translation
--- Comment #4 from michelin60 at gmail dot com 2007-08-31 20:29 --- What is the official status of this bug? Mr Jelenik's patch made into the trunk and libstdc++ now at least compiles. Is that patch just a stop-gap measure and is final solution still outstanding? A status report or closure seem in order. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33126
[Bug c/33277] New: [4.3.0 Regression] Bootstrap check failures ICE's
The summary results are pretty obvious:
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O1 (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O2 (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
(internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
-funroll-loops (internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions (internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -g (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -Os (internal compiler
error)
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
This are __not__ the mayalias failures which continue to fail with 4.3.0 and
are __not__
marked XFAIL
There is only on category, namely rs6000, both in the config tree and in the
MAINTAINERS LIST, so do expect the submitters to devine any other name dujour.
Also if the supposedly scarce manpower available can process hundreds of
pretty irrelevant GPL3 and whitespace elimination patches ( even for an already
released 4.2.x series) then submitters should not be harassed about submitting
superfluous details.
GPL3 has been dismissed by the world. Just look at the trade press, slashdot,
dig, and others.
There is neither adequate management for the steering committee down nor other
than lip-service to quality control. This and recent submissions by the
Debian-gcc-team prove the point.
Just to gild the lily here goes:
#include
f (x)
unsigned x;
{
return (unsigned) (((unsigned long long) x * 0xAAAB) >> 32) >> 1;
}
main ()
{
unsigned i;
for (i = 0; i < 1; i++)
if (f (i) != i / 3)
abort ();
exit (0);
}
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,fortran,c++ --enable-altivec --disable-libssp
--disable-decimal-float --disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070901 (experimental) (GCC)
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -quiet -v -D__unix__
-D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux
-Asystem=unix -Asystem=posix 930921-1.c -quiet -dumpbase 930921-1.c -mcpu=G4
-auxbase 930921-1 -O1 -version -o /tmp/ccCd2Hre.s
ignoring nonexistent directory
"/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/libffi
/usr/local/include
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.3.0 20070901 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070901 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fe13efd375927cd9d7414827707b954b
930921-1.c: In function 'f':
930921-1.c:6: error: could not split insn
(insn 6 3 31 930921-1.c:4 (set (reg:SI 0 0 [123])
(const_int 2863311531 [0xaaab])) 265 {*movsi_internal1}
(expr_list:REG_EQUIV (const_int 2863311531 [0xaaab])
(nil)))
930921-1.c:6: internal compiler error: in final_scan_insn, at final.c:2564
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.3.0 Regression] Bootstrap check failures ICE's
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michelin60 at gmail dot com
GCC build triplet: rs600
GCC host triplet: rs600
GCC target triplet: rs600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33277] [4.3 Regression] Bootstrap check failures ICE's
--- Comment #5 from michelin60 at gmail dot com 2007-09-02 15:23 --- I am beginning to enjoy this: There are about 34 hours between the first indication of failure on regress an my report. There are about 8 hours between my report and the first acknowledgment by GCC. This came by master of obfuscation and arbitrariness: Mr Pinski. The management motto at GCC seems to be: "Do as I say, do not do as I do" There is one person on the steering committee, who has real experience in building and managing a grou of professionals. His name is Mark Mitchell of Codesourcery. There is another member, acting as chairman, who is decidedly mis-using GCC for the interest of one company. His name is Dr. Edelsohn of IBM. This is not my statement I posted, acknowledged by GGC, proof in an earlier posting PR3316. That posting caused Mr. Pinski to flaunt a few more rules of comity, ownership of intellectual property (the posting), etc. There is ample confirmation provided for this misuse of GCC by using Google to for "Scott Handy IBM". Mr Handy is pretty far up in IBM management. Well as long as my name appears as poster of reporter I reserve the right to say whatever I please within the rules governing defamation and avoidance of foul language like used habitually by Mr. Pinski. -- michelin60 at gmail dot com changed: What|Removed |Added CC||dje at watson dot ibm dot ||com, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33277
[Bug middle-end/33283] [4.3 Regression] gcc.c-torture/execute/930921-1.c fails at -O1 and above now
--- Comment #3 from michelin60 at gmail dot com 2007-09-02 18:57 ---
Well here it is for interfering with Mr Guenther doing the reasonable thing.
This arbitrariness and unwarranted interference led me to do this.
It is also interesting to look a the GCC.mailing.list for June and July to
realize what is really going on within GCC
Mr. Mark Mitchell was overruled on his misgivings regarding the status of
gcc-4.2.0 . Hence gcc-4.2.0 is not really serviceable and can not even compile
glibc on some architectures. The linux distributors are staying away from
gcc-4.2.0 save for SUSE. However, SUSE made it impossible to find out
readily which gcc version compiled their executables and libraries. Thus a
statement that their latest available beta or release candidate compiler is
gcc-4.2.x is not verifiable.
What follows is a verbatim copy of PR33271 tentatively suppressed by Mr.
Pinski, who appears to be a protege of Dr. Edelsohn.
The summary results are pretty obvious:
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O1 (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O2 (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
(internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
-funroll-loops (internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions (internal compiler error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -O3 -g (internal compiler
error)
FAIL: gcc.c-torture/execute/930921-1.c compilation, -Os (internal compiler
error)
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
This are __not__ the mayalias failures which continue to fail with 4.3.0 and
are __not__
marked XFAIL
There is only on category, namely rs6000, both in the config tree and in the
MAINTAINERS LIST, so do expect the submitters to devine any other name dujour.
Also if the supposedly scarce manpower available can process hundreds of
pretty irrelevant GPL3 and whitespace elimination patches ( even for an already
released 4.2.x series) then submitters should not be harassed about submitting
superfluous details.
GPL3 has been dismissed by the world. Just look at the trade press, slashdot,
dig, and others.
There is neither adequate management for the steering committee down nor other
than lip-service to quality control. This and recent submissions by the
Debian-gcc-team prove the point.
Just to gild the lily here goes:
#include
f (x)
unsigned x;
{
return (unsigned) (((unsigned long long) x * 0xAAAB) >> 32) >> 1;
}
main ()
{
unsigned i;
for (i = 0; i < 1; i++)
if (f (i) != i / 3)
abort ();
exit (0);
}
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,fortran,c++ --enable-altivec --disable-libssp
--disable-decimal-float --disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070901 (experimental) (GCC)
/usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -quiet -v -D__unix__
-D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux
-Asystem=unix -Asystem=posix 930921-1.c -quiet -dumpbase 930921-1.c -mcpu=G4
-auxbase 930921-1 -O1 -version -o /tmp/ccCd2Hre.s
ignoring nonexistent directory
"/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/libffi
/usr/local/include
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.3.0 20070901 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070901 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fe13efd375927cd9d7414827707b954b
930921-1.c: In function 'f':
930921-1.c:6: error: could not split insn
(insn 6 3 31 930921-1.c:4 (set (reg:SI 0 0 [123])
(const_int 2863311531 [0xaaab])) 265 {*movsi_internal1}
(expr_list:REG_EQUIV (const_int 2863311531 [0xaaab])
(nil)))
930921-1.c:6: internal compiler error: in final_scan_insn, at final.c:2564
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #5 from michelin60 at gmail dot com 2007-09-03 13:49 ---
> (gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
> -O0).
>
> One last question: in your build tree, you should have a file named
> ${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
> macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
> and HAVE_LROUNDL?
>
Let me start off by saying that today is a holiday and that tomoorow I am back
at work and traveling, I am not allowed to use __any__ business assets for GCC
connected activity.
That last question seems beyond my ken. I am running glibc-2.6.1
(the latest official). The GCC tree is just the fairly current svn without any
changes by myself. I am a chemical engineer and computers, compilers are just
tools as far as I am concerned. I certainly do not use the latest for
production work (I have about a dozen compilers that I can make active at any
given time. This is my home machine and completely disconnected from my
company.
We just had an extensive power outage and we just recovering. I will try and
run that program today? the question is with which C compiler ( the latest
Trunk, gcc-4.3.0? 4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1) I am
not prepared to give you a choice of glibc as going back to earlier versions is
generally discouraged and rather risky.
Regarding the last question just look in your own current svn tree.
You might also look at PR33271 or PR33277 for my latest fiasco with Pinski. He
appears to owe his job to Dr. Edelsohn and was just hanging around a school
where a relative is a department head for several years. (this is documentable)
Do not try to recruit me as a maintainer because I would __never__ consider
working in an organization as politiized and poorly run as GCC. Mark Mitchel is
just not allowed to act as a real release manager.
The exception is the fortran group (minus Kargl). Where Paul Thomas has been
doing herculean work. I would love to see at least part of that work in 4.1.x
as 4.2.x and 4.3.x are completely messed up with things like decimal float
(major marketing tool of IBM). By the way the latest gcc on AIX is 3.3.1. Thus,
the IBM marketing types are pratically stating that they want to see gcc-4
hobbled.
Now if you do not want to work with me any more, just let me know. I am am
pretty hard boiled from the US corporate world and can spot the gcc
manipulations from a mile away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug c/32742] New: ICE vector(vuse_vec,base) index domain error
locker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michelin60 at gmail dot com
GCC build triplet: powerpc
GCC host triplet: powerpc
GCC target triplet: powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32742
[Bug c/32742] ICE vector(vuse_vec,base) index domain error
--- Comment #1 from michelin60 at gmail dot com 2007-07-12 19:39 --- Created an attachment (id=13904) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13904&action=view) standard *.i file *.i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32742
