[Bug preprocessor/28520] New: preprocessed output does not lex to correct tokens
This: #define x = ?x preprocesses to: ?= It should preprocess to: ? = -Chris -- Summary: preprocessed output does not lex to correct tokens Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] New: -E output incorrectly concatenates tokens into trigraphs
gcc -E on: #define z ? ?z( emits: ??( This won't lex correctly when trigraphs are enabled. -Chris -- Summary: -E output incorrectly concatenates tokens into trigraphs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug libgcj/13604] AccessController unfinished
-- gbenson at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |gbenson at redhat dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-08-08 19:52:07 |2006-07-28 08:19:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-28 08:53 --- (In reply to comment #0) It would also be nice to have a compiler parameter to turn off non-standard intrinsics. By the way: the correct option to compile standard code is to use -std=f95. That will turn off all non-standard things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in set_bb_for_stmt, at tree-cfg.c:2775
--- Comment #8 from patchapp at dberlin dot org 2006-07-28 09:00 --- Subject: Bug number profile/28480 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-07/msg01184.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28480
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #31 from patchapp at dberlin dot org 2006-07-28 09:30 --- Subject: Bug number PR rtl-optimization/28071 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-07/msg01185.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #32 from hubicka at ucw dot cz 2006-07-28 09:41 --- Subject: Re: [4.1/4.2 regression] A file that can not be compiled in reasonable time/space Hi, I've added this testcase to our's memory regression tester (see gcc-regression mainling list), so hopefully the quadratic memory consumption issues will be tracked now. It would be nice to have runtime benchmark variant of the test we can track the runtime and compilation time. It seems to uncover quite interesting behaviours across the compiler. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug fortran/28339] gfortran misses a record from a format statement
--- Comment #8 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-28 10:16 --- Resolution: FIXED Fixed on 4.2 What about 4.1.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28339
[Bug c++/28523] New: Throw of a derived class casted to its base class using a C-style cast
The compiler generates the error:
a.cpp: In function #8216;int main()#8217;:
a.cpp:6: internal compiler error: in stabilize_call, at cp/tree.c:2248
For this code:
class A {};
class B : public A {};
int main()
{
throw (A) B();
return 0;
}
Info:
gcc version 4.1.1
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1-src/configure
Thread model: posix
Command line:
g++ -Wall -ansi -pedantic a.cpp
--
Summary: Throw of a derived class casted to its base class using
a C-style cast
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot faustino at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28523
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #5 from r dot schwebel at pengutronix dot de 2006-07-28 10:44 --- (In reply to comment #2) The reduced testcase passes the -O because gcc un-nests the function. Is this true of the original testcase, or does glibc require trampolines? The original testcase doesn't pass; I've removed -fexceptions as suggested by Martin and tried -O and -O1, without success. Same error message as before. Robert -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug tree-optimization/28524] New: x*x in a loop folded to powf(x,2.) which prevents vectorization
$ cat a.c
void foo (float * restrict x, float * restrict y)
{
int i;
for (i = 0; i 1; i++)
x[i] = y[i] * y[i];
}
$ gcc a.c -O1 -ffast-math -msse -mfpmath=sse -ftree-vectorize
-ftree-vectorizer-verbose=5 -std=c99 -c
a.c:5: note: Alignment of access forced using peeling.
a.c:5: note: Vectorizing an unaligned access.
a.c:5: note: not vectorized: relevant stmt not supported: D.1353_14 =
__builtin_powf (D.1352_13, 2.0e+0)
a.c:5: note: vectorized 0 loops in function.
I find in fold-const.c:fold_binary, around line 9091, I found the following:
/* Optimize x*x as pow(x,2.0), which is expanded as x*x. */
--
Summary: x*x in a loop folded to powf(x,2.) which prevents
vectorization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
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=28524
[Bug tree-optimization/28524] x*x in a loop folded to powf(x,2.) which prevents vectorization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 10:51 --- *** This bug has been marked as a duplicate of 21465 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28524
[Bug tree-optimization/21465] autovectorisation conflicts with -ffast-math
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-28 10:51 --- *** Bug 28524 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21465
[Bug tree-optimization/28524] x*x in a loop folded to powf(x,2.) which prevents vectorization
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-28 10:53 --- Richard, next time you tell someone to file a bug report, please at least look quickly at other bug reports which were filed before telling them to file a new one. Finding the other bug was easy because the summary is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28524
[Bug libgcj/13604] AccessController unfinished
--- Comment #8 from gary at gcc dot gnu dot org 2006-07-28 10:54 --- Subject: Bug 13604 Author: gary Date: Fri Jul 28 10:54:11 2006 New Revision: 115793 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115793 Log: 2006-07-28 Gary Benson [EMAIL PROTECTED] Casey Marshall [EMAIL PROTECTED] PR libgcj/13604: * include/java-stack.h (GetClassMethodStack): Declare. * stacktrace.cc (GetClassMethodStack): New method. * java/security/AccessController.java: Removed. * java/security/VMAccessController.java: New file. * java/security/natVMAccessController.cc: Likewise. * Makefile.am (nat_source_files): Added the above. * sources.am, Makefile.in: Rebuilt. Added: trunk/libjava/java/security/VMAccessController.java trunk/libjava/java/security/natVMAccessController.cc Removed: trunk/libjava/java/security/AccessController.java Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in trunk/libjava/include/java-stack.h trunk/libjava/sources.am trunk/libjava/stacktrace.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604
[Bug tree-optimization/28524] x*x in a loop folded to powf(x,2.) which prevents vectorization
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-28 10:55 --- I did do a bugzilla search before writing to mailing-list, searching for the error message relevant stmt not supported in the comment, but it looks like the error message was changed at some point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28524
[Bug libgcj/13604] AccessController unfinished
--- Comment #9 from gbenson at redhat dot com 2006-07-28 10:59 --- Fixed. -- gbenson at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604
[Bug c++/28523] [4.0/4.1/4.2 Regression] Throw of a derived class casted to its base class using a C-style cast
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Summary|Throw of a derived class|[4.0/4.1/4.2 Regression] |casted to its base class|Throw of a derived class |using a C-style cast|casted to its base class ||using a C-style cast Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28523
[Bug c++/28523] [4.0/4.1/4.2 Regression] Throw of a derived class casted to its base class using a C-style cast
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 11:12 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-28 11:12:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28523
[Bug c++/28525] New: ICE after duplicate_decls
While debugging PR 28274 I came across the following problem:
If I apply the second hunk of the patch below, the C++ frontend
crashes on the following code:
==
void foo();
void foo() {}
==
built-in:0: note: OLD DECL2 'struct std::type_info'
zsh: 25734 segmentation fault cc1plus -quiet ~/file.cc
If I also apply the first hunk, erverything works as expected:
built-in:0: note: OLD DECL1 'struct std::type_info'
built-in:0: note: OLD DECL2 'struct std::type_info'
file.cc: In function 'void foo()':
file.cc:2: note: OLD DECL1 'void foo()'
file.cc:2: note: OLD DECL2 'void foo()'
file.cc: At global scope:
file.cc:1: note: OLD DECL1 'struct __cxxabiv1::__fundamental_type_info'
file.cc:1: note: OLD DECL2 'struct __cxxabiv1::__fundamental_type_info'
There seems to be a problem with garbage collection somewhere.
Instead of adding the first hunk, commenting out the call
ggc_free (newdecl);
at the end of duplicate_decls (decl.c) makes things work, too.
Happens on mainline, 4.1 branch, and 4.0 branch
(x86_64-unknown-linux-gnu with checking enabled).
Might be related to PR 27100.
===
--- gcc/gcc/cp/name-lookup.c(revision 115789)
+++ gcc/gcc/cp/name-lookup.c(working copy)
@@ -720,7 +720,9 @@ pushdecl_maybe_friend (tree x, bool is_friend)
}
else
{
- tree olddecl = duplicate_decls (x, t, is_friend);
+ tree olddecl;
+ inform (OLD DECL1 %qD, t);
+ olddecl = duplicate_decls (x, t, is_friend);
/* If the redeclaration failed, we can stop at this
point. */
@@ -729,6 +731,8 @@ pushdecl_maybe_friend (tree x, bool is_friend)
if (olddecl)
{
+ inform (OLD DECL2 %qD, t);
+
if (TREE_CODE (t) == TYPE_DECL)
SET_IDENTIFIER_TYPE_VALUE (name, TREE_TYPE (t));
===
--
Summary: ICE after duplicate_decls
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, GC
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28525
[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work
--- Comment #3 from patchapp at dberlin dot org 2006-07-28 11:35 --- Subject: Bug number PR c++/28274 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-07/msg01189.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug c++/28505] [4.0/4.1/4.2 regression] ICE with invalid constructors
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28505
[Bug tree-optimization/21465] autovectorisation conflicts with -ffast-math
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-28 11:45 --- the vectorizer should recognize this particular case or we might want to expand pow() again at the tree level before the vectorizer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21465
[Bug fortran/28526] New: 'end' is recognized as a variable incorrectly
In compiling the following program, I have got a error message. I think it is a wrong behavior. $ gfortran -v Using built-in specs. Target: powerpc-apple-darwin7.9.0 Configured with: ../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20060512/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.2.0 20060512 (experimental) $ cat end.f90 module m public end interface foo module procedure foo1 end interface interface end module procedure foo2 end interface contains subroutine foo1 end subroutine subroutine foo2 end subroutine end module end program $ gfortran end.f90 In file end.f90:8 interface end 1 Error: VARIABLE attribute conflicts with PROCEDURE attribute at (1) In file end.f90:9 module procedure foo2 1 Error: MODULE PROCEDURE at (1) must be in a generic module interface In file end.f90:10 end interface 1 Error: Expecting END MODULE statement at (1) -- Summary: 'end' is recognized as a variable incorrectly Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iguchi at coral dot t dot u-tokyo dot ac dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28526
[Bug c++/14179] [4.0/4.1/4.2 Regression] out of memory while parsing array with many initializers
--- Comment #45 from bonzini at gnu dot org 2006-07-28 12:20 --- (From update of attachment 8814) The patch is not relevant anymore after the commit that Ian pointed out. -- bonzini at gnu dot org changed: What|Removed |Added Attachment #8814 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #6 from pbrook at gcc dot gnu dot org 2006-07-28 13:19 --- If your test fails with -fno-exceptions then you're hitting a different bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug driver/28528] New: [4.0/4.1/4.2 regression] Trouble compiling header files with -x c++ using g++
The g++ driver has problems with *.h files compiled with -x c++: g++ -c -x c++ file.h yields a precompiled header file.h.gch instead of file.o. g++ -S -x c++ file.h yields an error message: cc1plus: error: output filename specified twice With -x c everything works as expected. Also using gcc (and not g++) with -x c, -x c++, -x c-header, -x c++-header works fine. This is a reression from GCC 3.3.x where using g++ -c -x c++ file.h or g++ -S -x c++ file.h led to the desired results. -- Summary: [4.0/4.1/4.2 regression] Trouble compiling header files with -x c++ using g++ Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #7 from r dot schwebel at pengutronix dot de 2006-07-28 13:46 --- (In reply to comment #6) If your test fails with -fno-exceptions then you're hitting a different bug. Different from ... what? The bug Martin reported is based on my report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug driver/28528] [4.0/4.1/4.2 regression] Trouble compiling header files with -x c++ using g++
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug libgcj/13604] AccessController unfinished
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604
[Bug fortran/28339] gfortran misses a record from a format statement
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-07-28 14:56 --- Lately, unless someone requests, I have not been committing to 4.1 branch. However, since you asked, I will gladly do so. BTW Thanks for the bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28339
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-07-28 15:06 --- I don't believe that it's possible to trigger this ICE unless you specify -fexceptions or -funwind-tables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #9 from r dot schwebel at pengutronix dot de 2006-07-28 15:30 --- (In reply to comment #8) I don't believe that it's possible to trigger this ICE unless you specify -fexceptions or -funwind-tables. Confirmed: Removing -fexceptions from the command line: ICE is still there. Removing -fasynchronous-unwind-tables: IDE doesn't trigger any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #10 from tbm at cyrius dot com 2006-07-28 15:37 --- Here: (sid)96:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -fexceptions orig.c orig.c: In function check_match: orig.c:5165: internal compiler error: in arm_unwind_emit_set, at config/arm/arm.c:15419 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. (sid)97:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft orig.c (sid)98:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -O orig.c (sid)99:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -O2 orig.c (sid)100:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -O3 orig.c (sid)101:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -O3 -fexceptions orig.c (sid)102:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -O2 -fexceptions orig.c (sid)103:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -O1 -fexceptions orig.c (sid)104:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -fexceptions orig.c orig.c: In function check_match: orig.c:5165: internal compiler error: in arm_unwind_emit_set, at config/arm/arm.c:15419 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. (sid)105:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -funwind-tables orig.c orig.c: In function check_match: orig.c:5165: internal compiler error: in arm_unwind_emit_set, at config/arm/arm.c:15419 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. (sid)106:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -funwind-tables -O1 orig.c (sid)107:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -funwind-tables -O2 orig.c (sid)108:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -funwind-tables -O3 orig.c (sid)109:[EMAIL PROTECTED]: ~] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #11 from tbm at cyrius dot com 2006-07-28 15:40 --- And the original ICE at -O2 only shows up when you comine -funwind-tables or -fexceptions with -pg: (sid)119:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -funwind-tables -pg -O2 orig.c orig.c: In function check_match: orig.c:5165: internal compiler error: in arm_unwind_emit_set, at config/arm/arm.c:15419 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. (sid)120:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -fexceptions -pg -O2 orig.c orig.c: In function check_match: orig.c:5165: internal compiler error: in arm_unwind_emit_set, at config/arm/arm.c:15419 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. (sid)121:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -pg -O2 orig.c (sid)122:[EMAIL PROTECTED]: ~] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug tree-optimization/28411] Illegal instruction error with -ftrapv
-- 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-07-17 21:42:32 |2006-07-28 15:50:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28411
[Bug tree-optimization/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #12 from ro at techfak dot uni-bielefeld dot de 2006-07-28 16:03 --- Subject: Re: [4.2 Regression] Ada bootstrap failure on Solaris 10/x86 rguenth at gcc dot gnu dot org writes: Is this now fixed on the mainline? A mainline bootstrap as of 20060724 was successful, so it seems so (although I haven't seen a specific fix addressing this issue). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug tree-optimization/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-07-28 16:21 --- Fixed so closing as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 16:23 --- Hmm, phase 1 preprocessing happens before phase 2 (the macros) so I don't think this is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 16:23 --- Hmm, phase 1 (which includes trigraphs) preprocessing happens before phase 2 (macros) so I don't think this is a bug. And macros cannot produce trigraphs either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #2 from sabre at nondot dot org 2006-07-28 16:26 --- It should print a space for the same reason that this does: #define x - -x -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #2 from sabre at nondot dot org 2006-07-28 16:26 --- It should print a space for the same reason that this does: #define x - -x -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug fortran/28339] gfortran misses a record from a format statement
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-07-28 16:47 --- Subject: Bug 28339 Author: jvdelisle Date: Fri Jul 28 16:46:57 2006 New Revision: 115798 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115798 Log: 2006-07-28 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/28339 * io/transfer.c (next_record_w): Use next_array_record result to set END_FILE. (write_block): Test for END_FILE before the next write occurs. * io/unit.c (get_internal_unit): Initialize iunit-endfile for internal unit. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/transfer.c branches/gcc-4_1-branch/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28339
[Bug fortran/28339] gfortran misses a record from a format statement
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-07-28 16:49 --- Subject: Bug 28339 Author: jvdelisle Date: Fri Jul 28 16:48:58 2006 New Revision: 115799 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115799 Log: 2006-07-28 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/28339 * gfortran.dg/arrayio_8.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/arrayio_8.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28339
[Bug c++/27668] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-07-28 17:01 --- Subject: Bug 27668 Author: lmillward Date: Fri Jul 28 17:01:19 2006 New Revision: 115800 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115800 Log: PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_arg): Likewise. (coerce_template_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash55.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/void2.C: Adjust error markers. * g++.dg/template/nontype5.C: Adjust error markers. Added: trunk/gcc/testsuite/g++.dg/template/crash55.C trunk/gcc/testsuite/g++.dg/template/nontype16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/nontype5.C trunk/gcc/testsuite/g++.dg/template/void2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug c++/27962] [4.0/4.1 regression] ICE with invalid template parameter in specialization
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-07-28 17:01 --- Subject: Bug 27962 Author: lmillward Date: Fri Jul 28 17:01:19 2006 New Revision: 115800 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115800 Log: PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_arg): Likewise. (coerce_template_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash55.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/void2.C: Adjust error markers. * g++.dg/template/nontype5.C: Adjust error markers. Added: trunk/gcc/testsuite/g++.dg/template/crash55.C trunk/gcc/testsuite/g++.dg/template/nontype16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/nontype5.C trunk/gcc/testsuite/g++.dg/template/void2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug c++/27668] [4.0/4.1 regression] ICE with invalid template parameter
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-07-28 17:02 --- Fixed on mainline. Will apply to 4.1 branch when testing completes. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with invalid template |with invalid template |parameter |parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug c++/27962] [4.0/4.1 regression] ICE with invalid template parameter in specialization
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-07-28 17:03 --- Fixed on mainline. Will apply to 4.1 branch when testing completes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug debug/28518] Single stepping until exit ...
--- Comment #3 from alex dot jacob at logicacmg dot com 2006-07-28 19:00 --- Hello, Thanks for the prompt reply. Sadly, I am not able to generate a test case for this. All the while loops I write to try and duplicate this seems to work fine. The specific case where this is a problem is deep inside code which is a link of many objects and shared objects. The strange thing is I can see all the line numbers, can set break to line numbers etc. but when stepping across these lines I get the 'Single...' error. The code itself works fine... Even if I comment out some bits of code still this happens - only in this section of the code !!! I'll have to look at this again later if I come across another occurrence of the same problem (in a different area). I assumed it might be gcc as the message seems to say 'no line number information' and this info is generated by the compiler. I agree that the fault could be in the GDB also...I currently have gdb 6.4 should I try with some earlier version ? What do you think ? Any ideas on the 'warning: Lowest section in /usr/lib/libthread.so.1 is .dynamic' messages ? Cheers, Alex -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28518
[Bug bootstrap/28133] Cross-compile of GCC fails with C compiler cannot create executables error
--- Comment #2 from spkelly at andrew dot cmu dot edu 2006-07-28 19:37 --- (In reply to comment #1) Actually this is a dup of bug 25035. *** This bug has been marked as a duplicate of 25035 *** Actually, I'm getting the same list of errors when trying to build programs ~with~ an i686 to powerpc-eabi cross compiling gcc4.1.1, before and after applying the patch for 25035, and even after rebuilding everything with --disable-libssp. The following output and config.log are from an attempt to build newlib with the successfully-compiled powerpc-*-eabi-gcc (lexically different but functionally identical --host and --target specified to force the newlib configure into recognizing cross-compilation and allowing --with-headers), but the same output happens when attempting to build a 5-line simple arithmetic test app. Not to say this isn't a ~different~ already-known bug, but it doesn't seem to be the 25035 bug. Apologies if I've screwed up the commenting protocol, this is my first time using bugzilla so I don't know how much I can safely write/set/tweak. creating cache ./config.cache checking host system type... powerpc-ibm-eabi checking target system type... powerpc-unknown-eabi checking build system type... i686-pc-linux-gnu checking for a BSD compatible install... /usr/local/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for powerpc-ibm-eabi-gnatbind... no checking for gnatbind... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for correct version of gmp.h... no /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/../../../../powerpc-ibm-eabi/bin/ld: warning: cannot find entry symbol _start; defaulting to 01800074 /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.text+0xc4): In function `__eabi': /scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:232: undefined reference to `__init' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x8):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:146: undefined reference to `__SDATA_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0xc):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:148: undefined reference to `__SBSS_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x14):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:150: undefined reference to `__SDATA2_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x18):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:151: undefined reference to `__SBSS2_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x1c):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:152: undefined reference to `__GOT_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x28):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:155: undefined reference to `__GOT_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x2c):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:156: undefined reference to `__GOT2_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x30):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:157: undefined reference to `__GOT2_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x34):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:158: undefined reference to `__FIXUP_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x38):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:159: undefined reference to `__FIXUP_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x3c):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:163: undefined reference to `__CTOR_LIST__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x40):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:164: undefined reference to `__CTOR_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x44):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:165: undefined reference to `__DTOR_LIST__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x48):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:166: undefined reference to `__DTOR_END__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x4c):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:167: undefined reference to `__EXCEPT_START__' /scratch/spkelly/ppcbin/lib/gcc/powerpc-ibm-eabi/4.1.1/libgcc.a(eabi.o)(.got2+0x50):/scratch/spkelly/gcc-4.1.1/build/gcc/eabi.S:171: undefined reference to `__EXCEPT_END__' collect2: ld returned 1 exit status *** The command 'powerpc-ibm-eabi-gcc -o conftest -g -O2conftest.c' failed. *** You must set the environment variable CC to a working compiler. --- This file contains any messages produced by
[Bug c++/27962] [4.1 regression] ICE with invalid template parameter in specialization
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-07-28 21:17 --- Subject: Bug 27962 Author: lmillward Date: Fri Jul 28 21:17:28 2006 New Revision: 115801 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115801 Log: PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug c++/27668] [4.0/4.1 regression] ICE with invalid template parameter
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-07-28 21:17 --- Subject: Bug 27668 Author: lmillward Date: Fri Jul 28 21:17:28 2006 New Revision: 115801 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115801 Log: PR c++/27668 PR c++/27962 * pt.c (process_template_parm) Store invalid template parameters as error_mark_node in the paramater list. (push_inline_template_parms_recursive): Handle invalid template parameters. (comp_template_parms): Likewise. (check_default_tmpl_args): Likewise. (coerce_template_template_parms): Likewise. (coerce_template_parms): Likewise. (mangle_class_name_for_template): Likewise. (tsubst_template_parms): Likewise. * error.c (dump_template_argument_list): Likewise. * g++.dg/template/crash54.C: New test. * g++.dg/template/nontype16.C: New test. * g++.dg/template/nontype5.C: Adjust error markers. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash54.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype16.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/error.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/nontype5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug c++/27668] [4.0 regression] ICE with invalid template parameter
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-07-28 21:19 --- Fixed in 4.1.2 -- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lmillward at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE with |with invalid template |invalid template parameter |parameter | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug c++/27962] [4.1 regression] ICE with invalid template parameter in specialization
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-07-28 21:20 --- Fixed in 4.1.2 -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #8 from sje at cup dot hp dot com 2006-07-28 21:45 --- If we apply the patch from http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02094.html first then we can apply the patch for PR 27291. I did this on the 4.1 branch and the bug went away. I have not done a full bootstrap with the two patches but will do that over the weekend. -- 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=28221
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #28 from danglin at gcc dot gnu dot org 2006-07-28 21:51
---
I've been trying to figure out why we end up with the strange intialization for
the
parity loop. I see this rtl in the loop2 dump:
;; Start of basic block 7, registers live: (nil)
(code_label 57 56 108 7 47 [1 uses])
(note 108 57 58 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn 58 108 111 7 (set (reg:SI 129)
(and:SI (subreg:SI (reg:DI 113) 4)
(const_int 1 [0x1]))) 126 {andsi3} (nil)
(nil))
(insn 111 58 112 7 (set (reg:SI 136)
(ne:SI (reg:SI 129)
(const_int 0 [0x0]))) 4 {scc} (nil)
(nil))
(insn 112 111 67 7 (set (reg/v:SI 108 [ count ])
(plus:SI (reg/v:SI 108 [ count ])
(reg:SI 136))) 114 {addsi3} (nil)
(nil))
(insn 67 112 68 7 (set (reg/v:SI 109 [ i ])
(plus:SI (reg/v:SI 109 [ i ])
(const_int 1 [0x1]))) 114 {addsi3} (nil)
(nil))
(insn 68 67 69 7 (set (reg:SI 130)
(const_int 64 [0x40])) 37 {*pa.md:2482} (nil)
(nil))
(jump_insn 69 68 71 7 (set (pc)
(if_then_else (ne (reg/v:SI 109 [ i ])
(reg:SI 130))
(label_ref 27)
(pc))) 25 {*pa.md:1710} (nil)
(expr_list:REG_EQUAL (if_then_else (ne (reg/v:SI 109 [ i ])
(const_int 64 [0x40]))
(label_ref 27)
(pc))
(expr_list:REG_BR_PROB (const_int 9844 [0x2674])
(nil
;; End of basic block 7, registers live:
(nil)
;; Start of basic block 8, registers live: (nil)
(note 71 69 73 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn 73 71 74 8 (set (reg:DI 25 %r25 [ D.1497 ])
(reg:DI 110 [ D.1497 ])) 77 {*pa.md:4458} (nil)
(insn_list:REG_LIBCALL 75 (nil)))
(call_insn/u 74 73 75 8 (parallel [
(set (reg:SI 28 %r28)
(call (mem:SI (symbol_ref/v:SI (@__paritydi2) [flags 0x41]) [
0 S4 A32])
(const_int 64 [0x40])))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0x0]))
]) 210 {call_val_symref} (nil)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 25 %r25 [ D.1497 ]))
(nil)))
This gets transformed to the following rtl in the loop2_init dump:
;; Start of basic block 7, registers live: (nil)
(code_label 57 56 108 7 47 [0 uses])
(note 108 57 58 7 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn 58 108 111 7 (set (reg:SI 129)
(and:SI (subreg:SI (reg:DI 113) 4)
(const_int 1 [0x1]))) 126 {andsi3} (nil)
(nil))
(insn 111 58 112 7 (set (reg:SI 136)
(ne:SI (reg:SI 129)
(const_int 0 [0x0]))) 4 {scc} (nil)
(nil))
(insn 112 111 67 7 (set (reg/v:SI 108 [ count ])
(plus:SI (reg/v:SI 108 [ count ])
(reg:SI 136))) 114 {addsi3} (nil)
(nil))
(insn 67 112 68 7 (set (reg/v:SI 109 [ i ])
(plus:SI (reg/v:SI 109 [ i ])
(const_int 1 [0x1]))) 114 {addsi3} (nil)
(nil))
(insn 68 67 69 7 (set (reg:SI 130)
(const_int 64 [0x40])) 37 {*pa.md:2482} (nil)
(nil))
(jump_insn 69 68 116 7 (set (pc)
(if_then_else (ne (reg/v:SI 109 [ i ])
(reg:SI 130))
(label_ref:SI 116)
(pc))) -1 (nil)
(expr_list:REG_EQUAL (if_then_else (ne (reg/v:SI 109 [ i ])
(const_int 64 [0x40]))
(label_ref:SI 116)
(pc))
(expr_list:REG_BR_PROB (const_int 9844 [0x2674])
(nil
;; End of basic block 7, registers live:
(nil)
;; Start of basic block 13, registers live: (nil)
(code_label 116 69 115 13 55 [1 uses])
(note 115 116 71 13 [bb 13] NOTE_INSN_BASIC_BLOCK)
;; End of basic block 13, registers live:
(nil)
;; Start of basic block 8, registers live: (nil)
(note 71 115 73 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn 73 71 74 8 (set (reg:DI 25 %r25 [ D.1497 ])
(reg:DI 110 [ D.1497 ])) 77 {*pa.md:4458} (nil)
(insn_list:REG_LIBCALL 75 (nil)))
(call_insn/u 74 73 75 8 (parallel [
(set (reg:SI 28 %r28)
(call (mem:SI (symbol_ref/v:SI (@__paritydi2) [flags 0x41]) [
0 S4 A32])
(const_int 64 [0x40])))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0x0]))
]) 210 {call_val_symref} (nil)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 25 %r25 [ D.1497 ]))
(nil)))
As a result, jump_insn 69 no longer does anything. All references
to code_label 27 are now gone and this appears to allow stuff that
was originally in the loop to end up as a loop initializers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug libgcj/23682] gnu.java.nio.SelectorImpl.select(long) throws ArrayIndexOutOfBoundsException
--- Comment #5 from tromey at gcc dot gnu dot org 2006-07-28 22:06 --- I have a patch I'm testing. This code in classpath looks quite bad :( I fixed this problem by adding synchronization. However, really very little synchronization should be needed. Instead we could be doing something like building a data structure for poll() ahead of time and tracking changes to the selection keys more directly; I think this would yield better performance. Right now we do multiple allocations for every select operation. Also I suspect that using select(2) instead of poll(2) is bad for applications making large numbers of connections. select has built-in limits on the the number of file descriptors it can use. Finally. our code to select without waiting actually will wait for up to 1ms. This is fixable as well, it looks like the original author just did it the simple way for convenience of writing a single native method. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-04-05 21:38:39 |2006-07-28 22:06:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23682
[Bug c/28529] New: [GCC 3.4.6] internal compiler error: in emit_move_insn, at expr.c:2809
I'm using gcc 3.4.6 and I get an ICE compiling this:
int setjmp(jmp_buf_t buf)
{
__asm__ __volatile__
(
movl %%edi,(%0)\n
movl %%esi,4(%0)\n
movl %%ebp,8(%0)\n
movl %%ebx,16(%0)\n
movl %%edx,20(%0)\n
movl %%ecx,24(%0)\n
leal 8(%%ebp),%%eax\n
movl %%eax,32(%0)\n
movl 4(%%ebp),%%eax\n
movl %%eax,36(%0)\n
:
: b(buf)
);
}
CFLAGS are: -ffreestanding -c -I/home/mike/popcorn-os/kernel/include
-finline-functions -fno-builtin
== Entering directory kernel...
- C compiling: mt.c
./mt.c: In function `mt_init':
./mt.c:14: warning: assignment makes integer from pointer without a cast
./mt.c:23: warning: assignment from incompatible pointer type
./mt.c: In function `setjmp':
./mt.c:28: internal compiler error: in emit_move_insn, at expr.c:2809
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Line 28 is the __asm__ __volatile__ line. (This is in a kernel I'm writing,
which explains the weird CFLAGS.)
Here's a jmp_buf_t in case it matters:
typedef struct
{
uint_32 edi, esi, ebp, esp, ebx, edx, ecx, eax;
uint_32 eip, eflags;
} jmp_buf_t;
--
Summary: [GCC 3.4.6] internal compiler error: in emit_move_insn,
at expr.c:2809
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mmiikkee13 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=28529
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #3 from neil at gcc dot gnu dot org 2006-07-28 23:47 --- Tokenization is correct on reprocessing since ?= is not a token. -- neil at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #3 from neil at gcc dot gnu dot org 2006-07-28 23:48 --- Tokenization is correct since preprocessed output has been through stages 1-3 and starts at stage 4. If you're passing -trigraphs then your command line is incorrect. -- neil at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug inline-asm/28529] [GCC 3.4.6] internal compiler error: in emit_move_insn, at expr.c:2809
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 23:48 --- This code is invalid as you cannot pass a struct in a register. Oh this is a dup of bug 8788 which has been fixed for 4.1.0. *** This bug has been marked as a duplicate of 8788 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28529
[Bug inline-asm/8788] ICE in emit_move_insn, at expr.c:3089
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-07-28 23:48 --- *** Bug 28529 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmiikkee13 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8788
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #4 from sabre at nondot dot org 2006-07-28 23:58 --- I realize that ?= is not a token. However, ?= is. -Chris -- sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #4 from sabre at nondot dot org 2006-07-28 23:59 --- I realize that tokenization is correct. As per: http://gcc.gnu.org/onlinedocs/cppinternals/Token-Spacing.html#Token-Spacing GCC should be emitting the space so that the subsequent relex of the output won't lex incorrectly. -Chris -- sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-29 00:04 --- (In reply to comment #4) I realize that ?= is not a token. However, ?= is. No it is not a token. It is a trigraph which is different than a token. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-29 00:05 --- No it is not a token. It is a trigraph which is different than a token. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #6 from sabre at nondot dot org 2006-07-29 00:05 --- ?= is not a trigraph. -- sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #7 from sabre at nondot dot org 2006-07-29 00:06 --- more specifically ?= is the C++ min-equal extension operator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-07-29 00:08 --- (In reply to comment #6) ?= is not a trigraph. And I don't see it as a token in the C or C++ standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #6 from sabre at nondot dot org 2006-07-29 00:08 --- Andrew, I'm well aware that a trigraph is not a token. If you read the report, I say that gcc -E produces output that a subsequent GCC will not reparse into the same result. Again, this is the whole point of: http://gcc.gnu.org/onlinedocs/cppinternals/Token-Spacing.html#Token-Spacing and the reason why GCC doesn't -E this: #define x - -x to -- -Chris -- sabre at nondot dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #9 from sabre at nondot dot org 2006-07-29 00:09 --- As I mention above, it is a GCC extension. Isn't gcc great? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-07-29 00:12 --- (In reply to comment #9) As I mention above, it is a GCC extension. Isn't gcc great? :) A deperated one at that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-07-29 00:13 --- which should have been removed for 4.2 but was not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #12 from sabre at nondot dot org 2006-07-29 00:13 --- ... which means it's a bug, so please stop closing it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-07-29 00:13 --- So this is only really for C++ mode. And at that is going away so really should be just suspended. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-29 00:14:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-07-29 00:14 --- Suspending until the extension is removed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-07-29 00:15 --- PR 14556 is another PR about this extension. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14556 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #16 from sabre at nondot dot org 2006-07-29 00:15 --- Do what ever you want, but it certainly is a bug with current GCC. I filed this bug out of desire to help free software get better, not out of any great need to have the bug fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-07-29 00:18 --- Actually in C++ mode, this is done correctly so this is invalid based on that. earth:~gcc -E -o - t.cc # 1 t.cc # 1 built-in # 1 command line # 1 t.cc ? = earth:~vi t.c earth:~gcc -E -o - t.c # 1 t.c # 1 built-in # 1 command line # 1 t.c ?= -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #7 from steven at gcc dot gnu dot org 2006-07-29 00:32 --- Seems like a bug to me alright. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-29 00:32:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug gcov/profile/28441] Need atomic increment of gcov counters for MP programs
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-29 00:41 --- Is it necessary to wait with posting until the copyright assignment process is finished, or can the patch be posted for a first review before the assignment is on file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441
[Bug preprocessor/28520] preprocessed output does not lex to correct tokens
--- Comment #18 from sabre at nondot dot org 2006-07-29 01:08 --- ok, fair enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #8 from neil at gcc dot gnu dot org 2006-07-29 05:02 --- This is not a bug. If you are preprocessing preprocessed output, you must use -fpreprocessed as documented. Otherwise many other things will go wrong, not just this. The bug is on your command line. -- neil at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug preprocessor/28521] -E output incorrectly concatenates tokens into trigraphs
--- Comment #9 from sabre at nondot dot org 2006-07-29 05:03 --- ok -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
[Bug libfortran/25289] Cannot handle record numbers large than huge(0_4)
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-07-29 05:12 --- Fixed on 4.2 -- jvdelisle 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=25289
[Bug gcov/profile/28441] Need atomic increment of gcov counters for MP programs
--- Comment #9 from ian at airs dot com 2006-07-29 05:21 --- It is safest to avoid posting the patch to a gcc mailing list before the copyright assignment is signed. It protects us in the (hopefully unlikely) case that the copyright assignment never does get signed. Otherwise we have a posted patch but no right to use it. If that happens, then when we eventually implement the same functionality in a different way, we are open to accusations that we have stolen the patch. Naturally the current SGI, which I presume is the legal owner of the code, would not do that. But I'm afraid we have to consider that there is likely to be a new legal owner of this code in the relatively near future, and we can not predict what they will do. This is all pretty small potatoes, of course, but there is no reason to add an unnecessary legal risk to the gcc project. None of this says that Greg could not sent out the patch to individuals, though, so if you are interested in seeing it, drop him a note and see what he thinks. Hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441
[Bug target/28508] Assembler Error: operand out of range (145 not between -128 and 127) form m32r-target
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-29 05:22 --- So the assembler adds the nops. Hmm, is there a reason why GCC could add them instead? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-29 05:22:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
[Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in set_bb_for_stmt, at tree-cfg.c:2775
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-29 05:22:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28480
[Bug c++/28513] [4.0/4.1/4.2 Regression] QOI: Diagnostic missing since 3.3.x when naming rule is violated
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-29 05:24 --- Confirmed, I was the one who recommended that Roger file this bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-linux-gnu | GCC host triplet|powerpc-linux-gnu | GCC target triplet|powerpc-linux-gnu | Keywords||accepts-invalid Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.2.3 3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-07-29 05:24:31 date|| Summary|QOI: Diagnostic missing |[4.0/4.1/4.2 Regression] |since 3.3.x when naming rule|QOI: Diagnostic missing |is violated |since 3.3.x when naming rule ||is violated Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-29 05:25 --- I think this is 4.2 regression now but I need to reduce it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|libstdc++ vs. anonymous |[4.2 Regression] libstdc++ |namespaces |vs. anonymous namespaces Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug driver/28528] [4.0/4.1/4.2 regression] Trouble compiling header files with -x c++ using g++
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-29 05:27 --- I think the behavior changed in 3.4 with the additional of PCH but I need to double check what happens in 3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug debug/28518] Single stepping until exit ...
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-29 05:28 --- (In reply to comment #3) Any ideas on the 'warning: Lowest section in /usr/lib/libthread.so.1 is .dynamic' messages ? That is a gdb question and I don't know how to answer it. Also are you compiling with just -g or you using optimization also? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28518
[Bug c++/28525] ICE after duplicate_decls
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-29 05:30 --- The ggc_free there is new for 4.0.0 and was added by Mark, maybe you should CC him. If commenting out the ggc_free makes this work, this is unrelated to PR 27100. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28525
