[Bug middle-end/27909] emacs M-x is undefined
--- Comment #2 from happyarch at gmail dot com 2006-06-06 07:13 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561 " --- Comment #6 From Serge Belyshev 2006-03-08 12:46 --- This bug prevents emacs from working, it says "M-x is undefined". " -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27909
[Bug middle-end/27909] emacs M-x is undefined
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-06 07:19 --- (In reply to comment #2) > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561 That bug was fixed 3 months ago so that is not the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27909
[Bug java/27910] New: building fails due essentially to bad /bin/ksh on darwin
In order to build correctly in libjava and libjava/classpath, i had to:
1) in libjava/classpath/lib/Makefile.gcj, replace $(SHELL) by /bin/sh
2) in libjava/classpath/lib/gen-classlist.sh.in, replace the four occurrences
of "while read pkg file" with an appropriate awk sentence (eg for the first
one: awk '{ pkg=$1; file=$2; printf("%s %s %s/%s\n", pkg, dir, pkg, file); }'
[EMAIL PROTECTED]@ -)
3) in libjava/Makefile.in, replace "cat tmp-ilist | while read f; do" with "for
f in `cat tmp-ilist`; do"
It seems that the read built-in in darwin ksh does not read a line, but 4096
bytes.
--
Summary: building fails due essentially to bad /bin/ksh on darwin
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Denis dot Excoffier at airbus dot com
GCC build triplet: powerpc-apple-darwin8.2.2
GCC host triplet: powerpc-apple-darwin8.2.2
GCC target triplet: powerpc-apple-darwin8.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug libgcj/27910] building fails due essentially to bad /bin/ksh on darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-06 08:08 ---
Why are you trying to build with /bin/ksh? That is just wrong.
How is ${SHELL} is being set to /bin/ksh anyways, SHELL is set by MAKE to
/bin/sh by default unless someone else overrides it.
Did you set CONFIG_SHELL before building GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug libgcj/27910] building fails due essentially to bad /bin/ksh on darwin
--- Comment #2 from Denis dot Excoffier at airbus dot com 2006-06-06 08:33 --- Oops, i've found an unnoticed CONFIG_SHELL=/bin/ksh around the "configure" step in my build instructions. Sorry for that. Bug is not confirmed any longer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug libgcj/27910] building fails due essentially to bad /bin/ksh on darwin
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-06 08:37 --- Ok, closing as invalid, you might also want to report to Apple that ksh does not work correctly for POSIX cases. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27910
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-06-06 08:54
---
Based on David's descripion, a reduced testcase appears to be:
static short f[100];
int
bar (void)
{
return f[0];
}
void
foo (void)
{
int i;
for (i = 0; i < 100; i++)
f[i]++;
}
Looking at the assembly output of "-O2 -ftree-vectorize -maltivec
-mabi=altivec", it seems that "f" will only be guaranteed 2-byte
alignment with -fsection-anchors. Without -fno-section-anchors,
"f" gets the expected 16-byte alignment.
This is an ordering problem. gcc is compiling bar() first, and
generating code on the assumption that "f" has natural alignment.
The vectoriser then increases the alignment of "f", which throws
off any layout based on the original natural alignment.
If bar() is compiled first, then gcc really does need to be able to
place "f" at a fixed offset in its section, so that it can use section
anchors to access "f". So I think the possible fixes are:
(1) Don't use section anchors for "f" in bar()
(2) Don't increase the alignment of "f" in foo()
(3) Increase the alignment of "f" before compiling either foo() or bar()
(1) implies either (1a) not using section anchors for vectorisable variables
or (1b) disabling -fsection-anchors when -ftree-vectorize is in effect.
(2) implies either (2a) not increasing the alignment of variables that have
already been assigned a block offset or (2b) preventing -ftree-vectorize
from increasing alignment when -fsection-anchors is in effect.
(3) implies increasing the alignment of all vectorisable variables if
both -fsection-anchors and -ftree-vectorize are in effect.
Neither (2a) nor (2b) is acceptable IMO. (I don't think (2a) is
acceptable because the order of compilation is not guaranteed.)
(1) is a worst-case fall-back position, with (1a) obviously being
better than (1b). (3) seems more appealing, but only if we accept
that -fsection-anchors -ftree-vectorize may increase the alignment
of variables that do not in fact get vectorised. This is going to
be a data size hit. (Hopefully it will only be a small hit, and
I suppose -ftree-vectorize is already a "speed over size"
optimisation.)
If we choose (1) or (3), I suppose we should also add a gcc_assert()
that the vectoriser is not increasing the alignment of a variable
that has already been placed in a block (i.e. assert that (2a) would
then be a no-op).
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug rtl-optimization/27872] Internal compiler error in verify_loop_structure
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-06-06 09:02 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00284.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||06/msg00284.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27872
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #11 from pcarlini at suse dot de 2006-06-06 09:36 --- (In reply to comment #10) > In C90 strtod does not say anything specifically about "inf", etc. However, > it > does say: > > In other than the "C" locale, additional implementation-defined subject > sequence forms may be accepted. > > In any case, to me this is a quality of implementation issue. A good > implementation will accept "inf", "infinity" and "nan". Honestly, given also all the text in the C++03 standard I do not agree: currently we are not entitled to parse such strings, because they are not conforming to the grammar and to the text of Stage2. We must fail (as all the other implementations I'm aware of are doing). If you disagree, please file the issue as a DR, but... The fact that C99 > explicitly accepts them seems sufficient justification to me. Sure, that is a very meaninful enhancement, which falls in the C99-compatibility area (already very active, see all the material coming from TR1) and should (will) be discussed in the context of the next standard (C++0x). More exactly, I reported already that the issue is known by Martin at least (I trust him about this section of the standard), but at this stage the policy is that reporting DRs for new features is not the best way to proceed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-24 10:46:37 |2006-06-06 09:59:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Comment #12 from martin at mpa-garching dot mpg dot de 2006-06-06 10:10 --- This is now open since more than a year. Is there any hope of getting it fixed for gfortran 4.2? Correct "uninitialized" warnings are a very desirable feature IMO and have always been a stron point in gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Comment #13 from martin at mpa-garching dot mpg dot de 2006-06-06 10:11 --- (In reply to comment #12) > Correct "uninitialized" warnings are a very desirable feature IMO Sorry, I meant "unused" of course :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug fortran/25923] [gfortran] garbled diagnostics with -O -Wuninitialized
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-06-06 10:14 --- Is it possible to fix this before gcc 4.2? Whenever I see these garbled warnings I have a very bad feeling that something completely unintended is happening inside the compiler, and I guess that many users could feel the same way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25923
[Bug fortran/24168] Problems with SPREAD and/or scalarization
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-06 10:26 --- Created an attachment (id=11607) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11607&action=view) Patch and testcase for the PR The problem lay in simplification of the binary expression because the rank of the operands was not transferred. I will submit tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24168
[Bug bootstrap/27901] ICE: On second stage boostrap with -O3
--- Comment #3 from paulg at chiark dot greenend dot org dot uk 2006-06-06 11:16 --- Tried the following 1) Bootstrap GCC 4.1.1 using a GCC 3.4.4 host compiler without STAGE1_CFLAGS or BOOT_CFLAGS set. 2) Bootstrap another clean copy of GCC 4.1.1 using the GCC 4.1.1 from step (1) as the host compiler using "STAGE1_CFLAGS=-O3 -fomit-frame-pointer" "BOOT_CFLAGS=-O3 -fomit-frame-pointer". This fails in the same way which suggests that the bug causing this is still present in GCC 4.1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27901
[Bug rtl-optimization/21676] [4.0/4.1/4.2 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- Comment #3 from gcc at pdoerfler dot com 2006-06-06 11:22 --- I get the following with -O3 -march=pentium4 -fomit-frame-pointer on a pentium4 gentoo machine: gcc-3.4.6 gcc-4.0.2 gcc-4.1.1 2.69s 4.14s 3.26s These are all with gentoo's patches. Also, current mainline is the same as gcc-4.1.1 I can confirm that the difference without -fomit-frame-pointer is much smaller. In fact, 3.4.6 and 4.1.1 are almost the same without it. -- gcc at pdoerfler dot com changed: What|Removed |Added CC||gcc at pdoerfler dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-06-06 11:46 --- (In reply to comment #3) > This bug report is approaching its second anniversary. > Does anybody still watch it or take care? Yes, Harald. I have been looking these last days at a number of array initializer problems. I have not entirely decided how to do this one yet: (i) Blasting through and expanding the array setion is one way; or (ii) Doing as Erik Edelmann suggested in another PR; use a normal assignment for the initialization and a static flag to make sure that it only is done once. The first is consistent with the existing structure and the second can be used to simplify a lot but will be much more work. This is why I am looking at initializer PRs as a package. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/27916] New: Problem with allocatable arrays inside OpenMP do loop
I've stumbled on a gfortran "Fortran runtime error" when using allocatable
arrays inside OpenMP PARALLEL DO LOOPS
Consider the folowing reduced testcase.
>> cat allocate_in_loop.f90
program allocate_in_loop
use omp_lib, only: omp_get_num_threads,omp_get_thread_num
implicit none
integer :: numthreads,n,it,i
integer, dimension(:), allocatable :: int_array
!
!$OMP PARALLEL DEFAULT(shared) NUM_THREADS(4)
numthreads=omp_get_num_threads()
!$OMP DO PRIVATE(n,it,int_array,i) SCHEDULE(static)
do n=1,numthreads
it=omp_get_thread_num()
allocate(int_array(3))
do i=1,3
int_array(i)=(it)*100+i
write(*,'(a,i2,a,i1,a,i4)') 'thread :',it,' -->int_array(', &
i,')=',int_array(i)
end do
deallocate(int_array)
end do
!$OMP END DO
!
!$OMP END PARALLEL
end program allocate_in_loop
According to what I read in the OpenMP 2.5 Specification - in sections 2.8.3.3
page 75 - the usage of the allocatable array is correct since I allocate it and
deallocate inside the OMP loop and it is not allocated upon entering the OMP DO
loop.
Gfortran compile fine with
>> gfortran -fopenmp allocate_in_loop.f90
But fails on execution with: "Fortran runtime error: Attempting to allocate
already allocated array."
intel 9.1, pgi 6.1 and xl do fine, the output being for example...
>> ./a.out
thread : 0 --> int_array(1)= 1
thread : 0 --> int_array(2)= 2
thread : 0 --> int_array(3)= 3
thread : 1 --> int_array(1)= 101
thread : 1 --> int_array(2)= 102
thread : 1 --> int_array(3)= 103
thread : 2 --> int_array(1)= 201
thread : 2 --> int_array(2)= 202
thread : 2 --> int_array(3)= 203
thread : 3 --> int_array(1)= 301
thread : 3 --> int_array(2)= 302
thread : 3 --> int_array(3)= 303
Good bug squashing
Benjamin
--
Summary: Problem with allocatable arrays inside OpenMP do loop
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benjamin dot reveille at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27916
[Bug fortran/27916] Problem with allocatable arrays inside OpenMP do loop
--- Comment #1 from benjamin dot reveille at gmail dot com 2006-06-06 12:01 --- For the fortran mailing list thread on this bug see: http://gcc.gnu.org/ml/fortran/2006-06/msg00096.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27916
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #14 from bonzini at gnu dot org 2006-06-06 12:10 --- Patch pr27390-more.patch was bootstrapped/regtested and the approach was confirmed to be ok by Roger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug fortran/27885] FAIL: libgomp.fortran/vla[1-7].f90 -O0 (test for excess errors)
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-06 12:14 --- Subject: Re: FAIL: libgomp.fortran/vla[1-7].f90 -O0 (test for excess errors) > I wonder what outmode is in emit_library_call_value_1: > tfom = lang_hooks.types.type_for_mode (outmode, 0); > > I might have a look to later during the weekend if I my move goes smooth. If I recall correctly, it is TImode, and NULL_TREE is returned. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27885
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #13 from guerby at gcc dot gnu dot org 2006-06-06 12:37 --- Subject: Bug 27769 Author: guerby Date: Tue Jun 6 12:37:01 2006 New Revision: 114429 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114429 Log: 2006-06-06 Laurent GUERBY <[EMAIL PROTECTED]> PR ada/27769 mlib-utl.adb: Use Program_Name. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/mlib-utl.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #14 from guerby at gcc dot gnu dot org 2006-06-06 12:38 --- Subject: Bug 27769 Author: guerby Date: Tue Jun 6 12:37:36 2006 New Revision: 114430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114430 Log: 2006-06-06 Laurent GUERBY <[EMAIL PROTECTED]> PR ada/27769 mlib-utl.adb: Use Program_Name. Modified: branches/gcc-4_1-branch/gcc/ada/ChangeLog branches/gcc-4_1-branch/gcc/ada/mlib-utl.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug ada/27769] cross-gnatmake needs host gcc
--- Comment #15 from laurent at guerby dot net 2006-06-06 12:43 --- Should be fixed now. -- laurent at guerby dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27769
[Bug target/26051] [4.2 Regression] libgcc_s.so.1 causes SEGV on Solaris 10/x86
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-06-06 12:54 --- Subject: Re: [4.2 Regression] libgcc_s.so.1 causes SEGV on Solaris 10/x86 steven at gcc dot gnu dot org writes: > Rainer, there is no test case and no description for how to reproduce this. I couldn't find a smaller testcase, unfortunately. > But is this still an issue at all? You seem to be able to report Solaris 10 > test results, e.g. > http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00113.html, > for mainline. True: recent mainline bootstraps don't show this issue any longer. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26051
[Bug middle-end/27909] emacs M-x is undefined
--- Comment #4 from happyarch at gmail dot com 2006-06-06 13:02 --- Weird, it doesn't fixed. my gcc version is 4.2.0 20060603 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27909
[Bug bootstrap/27918] New: stage2 failed: broken linking / Relocations in generic ELF (EM: 62)
make boostrap (...) stage1/xgcc -Bstage1/ -B/local/devel/toolchain41/sparc-sun-solaris2.9/sparc-sun-solaris2.9/bin/ -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a /local/devel/toolchain41/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld: ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 62) /local/devel/toolchain41/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld: ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 62) /local/devel/toolchain41/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld: ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 62) /local/devel/toolchain41/sparc-sun-solaris2.9/bin/sparc-sun-solaris2.9-ld: ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o): Relocations in generic ELF (EM: 62) ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a: could not read symbols: File in wrong format note that `make all` works fine. -- Summary: stage2 failed: broken linking / Relocations in generic ELF (EM: 62) Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27918
[Bug fortran/23091] ICE in gfc_trans_auto_array_allocation
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-06-06 14:06 --- Created an attachment (id=11608) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11608&action=view) Patch for this and PR27583 This needs cleaning up and a testcase writing but it is nearly there. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23091
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #6 from fitzsim at redhat dot com 2006-06-06 14:07 --- On the JDK lib files are stored in $JAVA_HOME/jre/lib. I've recently moved some files, like libjawt.so, that would conflict for multiple, parallel libgcj installations to the same prefix, to $(libdir)/gcj-$(gcc_version). I think we should move all such files there, and that directory should be libgcj's equivalent to the JDK's $JAVA_HOME/jre/lib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug target/27918] stage2 failed: wrong compiler used for host genmodes.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-06 14:12 --- make boostrap This is invalid, you are trying to bootstrap a cross compiler which will never work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|bootstrap |target Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27918
[Bug c++/27722] [4.0 regression] ICE incrementing an array
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-06-06 14:21 --- Btw, the fix for PR27804 fixed the problem on mainline before Mark's patch went in. (This might be interesting for a backport to the 4.0 branch.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27722
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-06 14:26 --- What about instead of absolute numbers doing label subtraction for section anchors and then we can defer the decision for the layout of the section until after all functions are done compiling? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-06 14:26:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug testsuite/26614] make check fails during fixincludes testing.
--- Comment #2 from tomdkat at comcast dot net 2006-06-06 14:34 --- I do not get this problem with gcc 4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26614
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #13 from amacleod at redhat dot com 2006-06-06 14:43 --- Created an attachment (id=11609) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11609&action=view) assert to add if Jakub's idea is implemented. So do you want to fix it Jakub's way instead of hacking up the tree optimizer? or would you still prefer to simply apply my patch for now in 4.1 and 4.2? If/when Jakub's suggestion is implemented, I suggest adding the following assert so you will know you have actually fixed it. This assert will trigger whenever there is a duplicate DECL_UID on a variable. It triggers on testcases from both this PR and 26757. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #9 from richard at codesourcery dot com 2006-06-06 15:02
---
Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize
-maltivec
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> What about instead of absolute numbers doing label subtraction for
> section anchors and then we can defer the decision for the layout of
> the section until after all functions are done compiling?
I don't think symbolic offsets would work, if that's what you mean.
We need to know the constant offset so that (a) we can enforce
TARGET_{MIN,MAX}_ANCHOR_OFFSET (which is more important for other
targets than it is for PowerPC) and (b) we know for PowerPC-like
setups whether the offset needs an addis.
Richard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #10 from dje at gcc dot gnu dot org 2006-06-06 15:10 --- The auto-vectorizer is a Tree-SSA pass. The section anchors are an RTL pass. I do not understand why the alignment of the vectorized variables is not known at section anchor creation time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #11 from richard at codesourcery dot com 2006-06-06 15:16 --- Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec "dje at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > The auto-vectorizer is a Tree-SSA pass. The section anchors are an > RTL pass. I do not understand why the alignment of the vectorized > variables is not known at section anchor creation time. The rtl optimisations for bar() precede the tree optimisations for foo(). Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-06-06 15:18 --- (In reply to comment #10) > The auto-vectorizer is a Tree-SSA pass. The section anchors are an RTL pass. > I do not understand why the alignment of the vectorized variables is not known > at section anchor creation time. Because we decided while processing with the first function that the alignment for the variable is set. And we do tree and rtl intermixed when processing functions so we look at f's alignment during processing bar and then we change it during foo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #13 from dje at gcc dot gnu dot org 2006-06-06 15:22 --- We're performing the auto-vectorization in unit-at-a-time-mode, so maybe we need to recompile the other functions. It seems that we're going to encounter more problems along these lines with LTO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug c++/26965] [4.0/4.1/4.2 Regression] Unnecessary debug info for unused consts in C++
--- Comment #8 from ian at airs dot com 2006-06-06 15:42 --- As I mentioned in the original submission, I'm pretty sure it is caused by RTH's patch for PR 23190. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #14 from richard at codesourcery dot com 2006-06-06 15:53 --- Subject: Re: [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec "dje at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > We're performing the auto-vectorization in unit-at-a-time-mode, so > maybe we need to recompile the other functions. It seems that we're > going to encounter more problems along these lines with LTO. Well, I'm not convinced recompilation is the way to go. I can't imagine it scaling well in pathological cases. If we're talking about long-term fixes, I think we should just make sure that we vectorise all functions before applying rtl optimisations to any of them. But that's all moot anyway: either approach will take a long time to implement. (Note that, as things stand, we've already written out the asm code for bar() by the time we vectorise foo().) As far as 4.2 fixes go, does anyone disagree with my earlier comment? Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #7 from ayers at gcc dot gnu dot org 2006-06-06 16:05 ---
Subject: Bug 13946
Author: ayers
Date: Tue Jun 6 16:05:47 2006
New Revision: 114435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114435
Log:
2006-06-06 David Ayers <[EMAIL PROTECTED]>
PR libobjc/13946
* Makefile.def: Add dependencies for libobjc which boehm-gc.
* Makefile.in: Regenerate.
* configure.in: Add --enable-objc-gc at toplevel and have it
enable boehm-gc for Objective-C.
Remove target-boehm-gc from libgcj.
Add target-boehm-gc to target_libraries.
Add target-boehm-gc to noconfigdirs where ${libgcj}
is specified.
Assert that boehm-gc is supported when requested for Objective-C.
Only build boehm-gc if needed either for Java or Objective-C.
* configure: Regenerate.
Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/configure
trunk/configure.in
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-06-06 16:35 --- For other reasons it would be nice to be able to place "sync" points in the pass schedule where we re-start with going over all functions for the remaining passes. Per function SSA form is requires for this, though, and possibly more (like per function alias info). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #14 from mark at codesourcery dot com 2006-06-06 16:37 --- Subject: Re: [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong amacleod at redhat dot com wrote: > --- Comment #13 from amacleod at redhat dot com 2006-06-06 14:43 --- > Created an attachment (id=11609) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11609&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11609&action=view) > assert to add if Jakub's idea is implemented. > > So do you want to fix it Jakub's way instead of hacking up the tree optimizer? > or would you still prefer to simply apply my patch for now in 4.1 and 4.2? Please go ahead and apply your patch. (It's ready now, and Jakub's idea isn't.) > If/when Jakub's suggestion is implemented, I suggest adding the following > assert so you will know you have actually fixed it. This assert will trigger > whenever there is a duplicate DECL_UID on a variable. It triggers on > testcases from both this PR and 26757. Thanks!! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug libobjc/13946] ObjC configured --with-objc-gc needs external Boehm gc
--- Comment #8 from ayers at gcc dot gnu dot org 2006-06-06 16:57 --- Fixed for 4.2.0 -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13946
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-06-06 17:01
---
Subject: Bug 27842
Author: uweigand
Date: Tue Jun 6 17:01:27 2006
New Revision: 114438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114438
Log:
PR target/27842
* config/rs6000/altivec.md (UNSPEC_VSLW): Remove.
("altivec_vspltisw_v4sf", "altivec_vslw_v4sf"): Remove.
("mulv4sf3", "absv4sf3", "negv4sf3"): Adapt users to use
V4SImode temporaries and operations instead.
PR target/27842
* gcc.dg/vmx/pr27842.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/vmx/pr27842.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.md
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-06-06 17:05
---
Subject: Bug 27842
Author: uweigand
Date: Tue Jun 6 17:04:56 2006
New Revision: 114439
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114439
Log:
PR target/27842
* config/rs6000/altivec.md (UNSPEC_VSLW): Remove.
("altivec_vspltisw_v4sf", "altivec_vslw_v4sf"): Remove.
("mulv4sf3", "absv4sf3", "negv4sf3"): Adapt users to use
V4SImode temporaries and operations instead.
PR target/27842
* gcc.dg/vmx/pr27842.c: New test.
Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vmx/pr27842.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/altivec.md
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug target/27842] Miscompile of Altivec vec_abs (float) inside loop
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-06-06 17:10 --- Fixed on 4.1 branch and mainline. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-06-06 17:19 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00313.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||06/msg00313.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug libgcj/27797] win32.cc: FormatMessage fails on win98 for network messages
--- Comment #4 from r_ovidius at eml dot cc 2006-06-06 18:03 --- After reading more from http://tangentsoft.net/wskfaq/newbie.html [2.7], it seems MESSAGE_FROM_MODULE won't really work. A lookup table would be needed like in http://tangentsoft.net/wskfaq/examples/basics/ws-util.cpp for win98. But, the patch above still works for the time being to avoid the segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27797
[Bug c++/27894] "internal compiler error: Segmentation fault" with -O
--- Comment #5 from appfault at hotmail dot com 2006-06-06 18:20 --- Created an attachment (id=11611) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11611&action=view) test case Attaching relatively bare-bones test case. It could perhaps be whittled down a bit more, but this was as small as it got by way of a hacked-up perl script. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27894
[Bug libfortran/27919] New: dot_product should be removed from the library
In gfortran 4.2, the frontend always inlines dot_product. Hence it should be removed from the library. -- Summary: dot_product should be removed from the library Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: jb at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27919
[Bug c++/27894] [4.1/4.2 Regression] "internal compiler error: Segmentation fault" with -O
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-06-06 18:57:52 date|| Summary|"internal compiler error: |[4.1/4.2 Regression] |Segmentation fault" with -O |"internal compiler error: ||Segmentation fault" with -O Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27894
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-06-06 18:58
---
Can someone check to see if the proposed patch also fixes PR 27894, it is the
same issue as we have:
extern CBaseEntityList *g_pEntityList;
inline IHandleEntity* CBaseHandle::Get() const
{
extern CBaseEntityList *g_pEntityList;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27894
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug libgcj/27921] New: libgcj should support old 1.1-style JNI invocation API
I'm adding JNI 1.1 invocation API structures to classpath's jni.h so David Walluck can compile some existing java application. libgcj requires some runtime support to make this work properly. -- Summary: libgcj should support old 1.1-style JNI invocation API Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27921
[Bug testsuite/26813] Testsuite does not check for ICEs
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-06 19:30 --- Janis went for the second approach: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00324.html -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||janis187 at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26813
[Bug c++/27922] New: final link failed: Nonrepresentable section on output
Greetings, Using OpenEmbedded (crosscompilation environment) to port applications from x86 to sh3 (SuperH arch). GCC --- Using built-in specs. Target: sh3-linux Configured with: /work/jlime/dev/donkey/6xx/build/tmp/work/i686-linux/gcc-cross-4.1.1-r2/gcc-4.1.1/configure --build=i686-linux --host=i686-linux --target=sh3-linux --prefix=/work/jlime/dev/donkey/6xx/build/tmp/cross --exec_prefix=/work/jlime/dev/donkey/6xx/build/tmp/cross --bindir=/work/jlime/dev/donkey/6xx/build/tmp/cross/bin --sbindir=/work/jlime/dev/donkey/6xx/build/tmp/cross/bin --libexecdir=/work/jlime/dev/donkey/6xx/build/tmp/cross/libexec --datadir=/work/jlime/dev/donkey/6xx/build/tmp/cross/share --sysconfdir=/work/jlime/dev/donkey/6xx/build/tmp/cross/etc --sharedstatedir=/work/jlime/dev/donkey/6xx/build/tmp/cross/com --localstatedir=/work/jlime/dev/donkey/6xx/build/tmp/cross/var --libdir=/work/jlime/dev/donkey/6xx/build/tmp/cross/lib --includedir=/work/jlime/dev/donkey/6xx/build/tmp/cross/include --oldincludedir=/work/jlime/dev/donkey/6xx/build/tmp/cross/include --infodir=/work/jlime/dev/donkey/6xx/build/tmp/cross/share/info --mandir=/work/jlime/dev/donkey/6xx/build/tmp/cross/share/man --with-gnu-ld --enable-shared --enable-target-optspace --enable-languages=c,c++, --enable-threads=posix --enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=sh3-linux- --with-local-prefix=/work/jlime/dev/donkey/6xx/build/tmp/cross/sh3-linux --with-gxx-include-dir=/work/jlime/dev/donkey/6xx/build/tmp/cross/sh3-linux/include/c++ --enable-__cxa_atexit --disable-libssp --with-mpfr=/work/jlime/dev/donkey/6xx/build/tmp/staging/i686-linux Thread model: posix gcc version 4.1.1 ld Colossus bin # ./sh3-linux-ld -v GNU ld version 2.15.94.0.1 20041121 Compilation --- | sh3-linux-g++ -ml -m3 -isystem/work/jlime/dev/donkey/6xx/build/tmp/staging/sh3-linux/include -O2 -fpermissive -fno-exceptions -fno-rtti -nostdinc++ -fno-threadsafe-statics -Wl,-rpath-link -Wl,/work/jlime/dev/donkey/6xx/build/tmp/staging/sh3-linux/lib -Wl,-O1 -o kjs/.libs/testkjs testkjs.o cxx.o -L/work/jlime/dev/donkey/6xx/build/tmp/staging/sh3-linux/lib kjs/.libs/libjscore.so /work/jlime/dev/donkey/6xx/build/tmp/staging/sh3-linux/lib/libglib-2.0.so -lpthread | /work/jlime/dev/donkey/6xx/build/tmp/cross/lib/gcc/sh3-linux/4.1.1/../../../../sh3-linux/bin/ld: kjs/.libs/testkjs: hidden symbol `__udivsi3' in /work/jlime/dev/donkey/6xx/build/tmp/cross/lib/gcc/sh3-linux/4.1.1/libgcc.a(_udivsi3.o) is referenced by DSO | /work/jlime/dev/donkey/6xx/build/tmp/cross/lib/gcc/sh3-linux/4.1.1/../../../../sh3-linux/bin/ld: final link failed: Nonrepresentable section on output | collect2: ld returned 1 exit status | make[2]: *** [kjs/testkjs] Error 1 | make[2]: Leaving directory `/work/jlime/dev/donkey/6xx/build/tmp/work/sh3-linux/osb-jscore-0.5.0+cvs20060212-r0/JavaScriptCore' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/work/jlime/dev/donkey/6xx/build/tmp/work/sh3-linux/osb-jscore-0.5.0+cvs20060212-r0/JavaScriptCore' | make: *** [all] Error 2 | FATAL: oe_runmake failed NOTE: Task failed: /work/jlime/dev/donkey/6xx/build/tmp/work/sh3-linux/osb-jscore-0.5.0+cvs20060212-r0/temp/log.do_compile.32376 NOTE: package osb-jscore-0.5.0+cvs20060212-r0: task do_compile: failed ERROR: TaskFailed event exception, aborting NOTE: package osb-jscore-0.5.0+cvs20060212: failed ERROR: Build of osb-jscore failed -- Summary: final link failed: Nonrepresentable section on output Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kristoffer_e1 at hotmail dot com GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: sh3-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27922
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #16 from amacleod at redhat dot com 2006-06-06 19:41 --- yes, this appears to fix PR 27894 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug target/26223] [4.0 regression] ICE on long double with -mno-80387
--- Comment #12 from sayle at gcc dot gnu dot org 2006-06-06 19:43 --- Subject: Bug 26223 Author: sayle Date: Tue Jun 6 19:43:17 2006 New Revision: 114446 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114446 Log: PR target/26223 * config/i386/i386.c (construct_container): Split static issued_error flag into issued_sse_arg_error, issued_sse_ret_error and issued_x87_ret_error. Issue a daignostic if the x86-64 ABI requires the use of x87 registers and the user explicitly specified the -mno-80387 command line option. * gcc.target/i386/amd64-abi-2.c: New test case. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.target/i386/amd64-abi-2.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26223
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #6 from sje at cup dot hp dot com 2006-06-06 19:52 --- Created an attachment (id=11612) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11612&action=view) Cut down test case Here is a cutdown test case. I reproduced the problem on hppa64-hp-hpux11.11 with this cutdown testcase. When compiling with -O2 it compiles quickly (less than 1 second) when compiled with -O2 -mdisable-fpregs it took 17 minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #2 from csm at gnu dot org 2006-06-06 20:07 --- I don't see any pegged CPU usage with 4.2.0 20060606, on a dual AMD Athlon system, Linux 2.6.6, NPTL threads. The test case does seem to hang, however, after the seed is generated (it takes about a second for the result to be printed). There may be something going wrong with threads and the calls to Thread.yield(). Can you describe the systems you are running this test case on? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #3 from csm at gnu dot org 2006-06-06 20:14 --- Also, a good workaround (on Linux and other Unices) is to add this line to your classpath.security file: securerandom.source=file:/dev/random This is generally a good idea. If you have available some file or device that you can read random bytes out of, you should read that for PRNG seeds, instead of using the fallback implementation in VMSecureRandom. Note that you can even set that variable to an http URL, such as HotBits. You can also use the system property `java.security.egd'. It, too, takes a URL. For systems without /dev/random, you may have some luck with the entropy gathering daemon, http://egd.sourceforge.net/. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #4 from r_ovidius at eml dot cc 2006-06-06 20:20 --- Linux RH9 2.4.20 450Mhz WinXP 2Ghz I removed the call to VMSecureRandom from SecureRandom and just return length at the moment, and everything works again. The usage of /dev/random did work as well, but binaries would not be portable if target systems don't have it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #7 from sje at cup dot hp dot com 2006-06-06 20:48 ---
This seems to be identical to PR 23971 on alpha. The test case for that PR:
unsigned long long f(unsigned long long x) { return x *
5445825408751490200ULL;}
I changed long to 'long long' to make it 64 bits on hppa1.1 and hppa64. It
compiles fine on hppa1.1-*-* but takes forever on hppa64-*-* with "-O2
-mdisable-fpregs".
PR 23971 is closed as fixed, I don't know if alpha is having this problem
anymore or not.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-06 20:48:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug testsuite/26813] Testsuite does not check for ICEs
--- Comment #3 from janis at gcc dot gnu dot org 2006-06-06 20:48 --- Gosh, I don't remember ever seeing this stuff about new exit codes for ICEs. I can rethink how the testsuite detects them, now that we know where to look. Does the ICE message get translated for different locales? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26813
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #10 from sje at cup dot hp dot com 2006-06-06 21:02 --- Dave, in your last comment you said the patch didn't help but the failure you showed was for pr24626-2, not pr24626-1 (-2 vs. -1), which is what the original bug was about. Is pr24626-1 failing for you? It does not fail for me. pr24626-1 is failing but has been failing for a couple of months on hppa1.1-hp-hpux11.11. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #8 from falk at debian dot org 2006-06-06 21:04 --- (In reply to comment #7) > PR 23971 is closed as fixed, I don't know if alpha is having this problem > anymore or not. It takes 3.39s now, which while much faster than it used to be is still ridiculously slow (with 1 as constant, it takes 0.06s). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug testsuite/26813] Testsuite does not check for ICEs
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-06 21:04 --- > Does the ICE message get translated for different locales? Yes, see e.g. the results from the testcase from comment #3 of PR 26155 below. That shouldn't impact the testsuite AFAIK, because the dg-error markers require the C locale anyway. C: PR26155.cc:8: error: namespace alias 'N::M' not allowed here, assuming 'N' PR26155.cc:8: internal compiler error: in resume_scope, at cp/name-lookup.c:1379 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Dutch (nl_NL): PR26155.cc:8: fout: namespace alias 'N::M' not allowed here, assuming 'N' PR26155.cc:8: interne compilerfout: in resume_scope, at cp/name-lookup.c:1379 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. French (fr_FR): PR26155.cc:8: erreur: namespace alias 'N::M' not allowed here, assuming 'N' PR26155.cc:8: erreur interne du compilateur: dans resume_scope, à cp/name-lookup.c:1379 Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. Consultez http://gcc.gnu.org/bugs.html> pour plus de détail. German (de_DE): PR26155.cc:8: Fehler: Namensbereich-Alias »N::M« ist hier nicht erlaubt, »N« angenommen PR26155.cc:8: interner Compiler-Fehler: in resume_scope, bei cp/name-lookup.c:1379 Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein; bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es dienlich ist. Fehler in der deutschen Übersetzung sind an [EMAIL PROTECTED] zu melden. Gehen Sie gemäß den Hinweisen in http://gcc.gnu.org/bugs.html> vor. Spanish (es_ES): PR26155.cc:8: error: no se permite aquí el alias del espacio de nombres 'N::M', asumiendo que es 'N' PR26155.cc:8: error interno del compilador: en resume_scope, en cp/name-lookup.c:1379 Por favor envíe un reporte completo de bichos, con el código preprocesado si es apropiado. Vea http://gcc.gnu.org/bugs.html> para más instrucciones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26813
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #7 from gerald at pfeifer dot com 2006-06-06 21:04 --- That would be great. I'd really love to see us support parallel libgcj installations into the same $prefix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #5 from csm at gnu dot org 2006-06-06 21:29 --- On futher inspection, it is pegging my CPU as well. `top' was lying to me. It *looks* as though the test `while (running)' may have been optimized away, because the threads continue to run even after the `running' variable has been set to false. The attached test case seems to illustrate the problem, and it looks like a GCJ bug. This test case: - Fails to exit when compiled with GCJ 20060606. Command line: gcj -g -O2 -o PR27908 - Fails to run interpreted when compiled with 'gcj -C'. Error is 'java.lang.IllegalAccessError: PR27908: PR27908$run1.stop()V'. - Fails to run on Sun Java 1.5.0_03 on GNU/Linux x86 if compiled with 'gcj -C'. Error is 'java.lang.VerifyError: (class: PR27908, method: main signature: ([Ljava/lang/String;)V) Illegal use of nonvirtual function call'. - Fails to run on jamvm if compiled 'gcj -C'. Error is similar to that on gij: an IllegalAccessError. This test case runs fine if compiled with Sun's 'javac -source 1.4 -target 1.4' on both gij, java, and jamvm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #6 from csm at gnu dot org 2006-06-06 21:30 --- Created an attachment (id=11613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11613&action=view) Test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #9 from sje at cup dot hp dot com 2006-06-06 21:30 --- 3.39s is not ridiculously slow, 15+ minutes is ridiculously slow. 1.64 seconds using the constant 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #7 from csm at gnu dot org 2006-06-06 21:32 --- Also note that this test case works fine if compiled to a native binary (C++ ABI) with -O1. So there are likely two bugs here: an optimization issue, and a bytecode generation issue. -- csm at gnu dot org changed: What|Removed |Added Component|libgcj |java Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug c++/27177] [4.0/4.1/4.2 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-06 21:39 --- Subject: Bug 27177 Author: mmitchel Date: Tue Jun 6 21:38:54 2006 New Revision: 114448 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114448 Log: PR c++/27177 * call.c (standard_conversion): Require that the derived type be complete when performing a derived-to-base conversion. PR c++/27177 * g++.dg/expr/cast7.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/cast7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c++/27177] [4.0/4.1/4.2 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-06 21:39 --- Subject: Bug 27177 Author: mmitchel Date: Tue Jun 6 21:39:33 2006 New Revision: 114449 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114449 Log: PR c++/27177 * call.c (standard_conversion): Require that the derived type be complete when performing a derived-to-base conversion. PR c++/27177 * g++.dg/expr/cast7.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/expr/cast7.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/call.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-06 21:42 --- Subject: Re: [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors) > Dave, in your last comment you said the patch didn't help but the failure you > showed was for pr24626-2, not pr24626-1 (-2 vs. -1), which is what the > original > bug was about. Is pr24626-1 failing for you? It does not fail for me. > pr24626-1 is failing but has been failing for a couple of months on > hppa1.1-hp-hpux11.11. Oops, I didn't pay close enough attention. The patch may provide some improvement. Without the change, we have the following fails on 32-bit PA targets (same as reported by Joseph in comment #3): FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr24626-1.c -O3 -fomit-frame-pointer (test for excess err ors) FAIL: gcc.dg/torture/pr24626-1.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr24626-1.c -Os (test for excess errors) FAIL: gcc.dg/torture/pr24626-2.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr24626-2.c -O3 -fomit-frame-pointer (test for excess err ors) FAIL: gcc.dg/torture/pr24626-2.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr24626-3.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr24626-3.c -O3 -fomit-frame-pointer (test for excess err ors) FAIL: gcc.dg/torture/pr24626-3.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr24626-3.c -Os (test for excess errors) All ICEs occur at the same spot. I'd have to go back and retest but I'm fairly certain they were all introduced at the same time by r112128. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug c++/27177] [4.0 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-06 21:42 --- Fixed in 4.1.2, 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1/4.2 Regression] ICE|[4.0 Regression] ICE in |in build_simple_base_path, |build_simple_base_path, at |at cp/class.c:474 |cp/class.c:474 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-06 21:55 --- Subject: Re: [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors) > All ICEs occur at the same spot. I'd have to go back and retest > but I'm fairly certain they were all introduced at the same time > by r112128. Note, this isn't the change that introduced PARAM_MAX_SCHED_EXTEND_REGIONS_ITERS. That was r112126. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug fortran/23091] ICE in gfc_trans_auto_array_allocation
--- Comment #10 from patchapp at dberlin dot org 2006-06-06 22:00 --- Subject: Bug number PR23091 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-06/msg00332.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23091
[Bug c++/27666] [4.0/4.1/4.2 regression] ICE with volatile in conditional expression
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-06-06 22:04 --- The code is indeed invalid. (There's no copy constructor for A that accepts a volatile A as input, but the conceptual expression is an rvalue, so we have to (conceptually) create a temporary.) -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED Keywords|ice-on-valid-code |ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug c++/27666] [4.0/4.1/4.2 regression] ICE with volatile in conditional expression
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-06 22:12
---
The following code is accepted. Shouldn't it be rejected then?
===
struct A
{
A(int);
};
void foo(volatile A a) { 1 ? a : a; }
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #12 from ian at airs dot com 2006-06-06 22:18 --- At this web page: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm I see this: "The formatted input functions shall support the additional conversion specifications specified in C99 subclause 7.19.6.2." So if my understanding is correct, this facility is already in TR1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug c++/27666] [4.0/4.1/4.2 regression] ICE with volatile in conditional expression
--- Comment #4 from mark at codesourcery dot com 2006-06-06 22:35 ---
Subject: Re: [4.0/4.1/4.2 regression] ICE with volatile in
conditional expression
reichelt at gcc dot gnu dot org wrote:
> --- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-06 22:12
> ---
> The following code is accepted. Shouldn't it be rejected then?
>
> ===
> struct A
> {
> A(int);
> };
>
> void foo(volatile A a) { 1 ? a : a; }
> ===
No, in that case the expression is an lvalue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug libstdc++/27904] operator>> to floating point variable does not support "inf", "infinity", or "nan"
--- Comment #13 from pcarlini at suse dot de 2006-06-06 22:36 --- (In reply to comment #12) > At this web page: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm > > I see this: > > "The formatted input functions shall support the additional conversion > specifications specified in C99 subclause 7.19.6.2." Interesting, in particular the followint note. > So if my understanding is correct, this facility is already in TR1. Well, not really. The text in TR1 is about the facilities provided in and . The text in 22_locale should then be consistently updated, at minimum the specifications for Stage2 and the grammar made consistent. But probably the entire parsing must be heavily reworked, there are long standing and nasty defects proper. More generally, the entire C++0x standard will be more careful with NaNs, infinities and such, not mentioned at all in C++03 (similarly to C90). That is causing problems in other unrelated areas (while we are writing people are discussing on the reflector containers vs NaNs...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27904
[Bug target/26223] [4.0 regression] ICE on long double with -mno-80387
--- Comment #13 from roger at eyesopen dot com 2006-06-06 22:41 --- This should now be fixed on all active branches. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26223
[Bug middle-end/26622] [4.0 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #15 from Harmon dot Nine at gmail dot com 2006-06-06 22:52 --- Hello all. I notice the last comment for this bug was made on May 29th. Today is June 06 (06-06-06 ). I've *just* (i.e. yesterday) download the latest source from the 4_1 branch and compiled and installed it on my cygwin. An internal compiler error is incurred when compiling Gecode that looks very similar. Files containing the pre-processed source and the stdout of the gcc command used to generated it are attached. Here's the exact command used to generate the pre-processed source file: /usr/local/bin/g++ -v -save-temps -I. -I. -DNDEBUG -Wall -ggdb -O3 -fno-strict-aliasing -finline-limit=3000 -ffast-math -mthreads -DGECODE_BUILD_INT -c -o int/var/imp.o int/var/imp.cc -- Harmon dot Nine at gmail dot com changed: What|Removed |Added CC||Harmon dot Nine at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug middle-end/26622] [4.0 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #16 from Harmon dot Nine at gmail dot com 2006-06-06 22:54 --- Created an attachment (id=11614) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11614&action=view) Stdout and Stderr of gcc command to make pre-processed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug middle-end/26622] [4.0 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #17 from Harmon dot Nine at gmail dot com 2006-06-06 22:55 --- Created an attachment (id=11615) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11615&action=view) Pro-processed source that incurs internal compiler error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug middle-end/26622] [4.0 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-06-06 22:58 --- (In reply to comment #15) > Hello all. I notice the last comment for this bug was made on May 29th. > Today > is June 06 (06-06-06 ). I've *just* (i.e. yesterday) download the latest > source from the 4_1 branch and compiled and installed it on my cygwin. An > internal compiler error is incurred when compiling Gecode that looks very > similar. Files containing the pre-processed source and the stdout of the gcc > command used to generated it are attached. That is a very different bug and should be filed seperately. Yes "unrecognizable insn" is the same bug the instruction is way different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug target/27650] internal compiler error while compiling Gecode
--- Comment #7 from Harmon dot Nine at gmail dot com 2006-06-06 23:02 --- Bugfix worked for me. Compilation definitely got farther. However, there's another bug. Pls. see bug 26622. Gecode may be a good compiler test package; it seems to use some advanced C++ features. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug target/27650] internal compiler error while compiling Gecode
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-06 23:14 ---
(In reply to comment #7)
> Bugfix worked for me. Compilation definitely got farther. However, there's
> another bug. Pls. see bug 26622.
As mentioned in that PR, the problem there is unrelated to your code.
The rtl pattern which is being complained about:
(insn 491 490 492 18 ././kernel/core.icc:1448 (set (reg:SI 223)
(const:SI (plus:SI (mem:SI (symbol_ref:SI ("#i._ZN6Gecode5Space3vtdE")
) [0 S4 A8])
(const_int 1024 [0x400] -1 (nil)
(nil))
Why is this wrapping itself inside a const when it cannot be a const as it is
loading from memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug target/27922] final link failed: Nonrepresentable section on output
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-06 23:27 --- First is how did you build the shared libraries libjscore.so and libglib-2.0.so. Second, kjs/.libs/testkjs: hidden symbol `__udivsi3' in /work/jlime/dev/donkey/6xx/build/tmp/cross/lib/gcc/sh3-linux/4.1.1/libgcc.a(_udivsi3.o) is referenced by DSO usually means you built one of those shared libraries directly with ld instead of invoking gcc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27922
[Bug target/19770] gcc.c-torture/compile/20050113-1.c: ICE: in extract_insn, at recog.c:2083
--- Comment #5 from danglin at gcc dot gnu dot org 2006-06-06 23:31 --- Reconfirmed in 3.4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19770
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #8 from csm at gnu dot org 2006-06-07 00:08 ---
A workaround is to replace:
while (running)
counter++;
with:
while (isRunning ())
counter++;
And to add a method:
boolean isRunning ()
{
return running;
}
I'm working on a patch for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-06-07 00:14 --- (In reply to comment #8) > A workaround is to replace: > > while (running) > counter++; Is running marked as volatile? If it is, then this is a dup of bug 1305, otherwise this is a bug in both the library sources and still a dup of bug 1305 after that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug fortran/27786] Bad interaction between Cray pointer, assumed-size array and bounds checking
-- langton at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |langton at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27786
[Bug c++/27924] New: internal compiler error: extract_insn, while compiling Gecode
-- Summary: internal compiler error: extract_insn, while compiling Gecode Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Harmon dot Nine at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27924
[Bug c++/27924] internal compiler error: extract_insn, while compiling Gecode
--- Comment #1 from Harmon dot Nine at gmail dot com 2006-06-07 00:34 --- G++ command used to generate pre-compiled source: /usr/local/bin/g++ -v -save-temps -I. -I. -DNDEBUG -Wall -ggdb -O3 -fno-strict-aliasing -finline-limit=3000 -ffast-math -mthreads -DGECODE_BUILD_INT -c -o int/var/imp.o int/var/imp.cc Output and pre-compiled source attached -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27924
[Bug c++/27924] internal compiler error: extract_insn, while compiling Gecode
--- Comment #2 from Harmon dot Nine at gmail dot com 2006-06-07 00:35 --- Created an attachment (id=11616) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11616&action=view) Stdout and Stderr of gcc command to make pre-processed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27924
[Bug c++/27924] internal compiler error: extract_insn, while compiling Gecode
--- Comment #3 from Harmon dot Nine at gmail dot com 2006-06-07 00:36 --- Created an attachment (id=11617) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11617&action=view) pre-compiled source if imp.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27924
