[Bug c/26494] -pedantic-errors can be overridden by -W*
--- Comment #8 from patchapp at dberlin dot org 2007-01-25 09:55 --- Subject: Bug number PR 26494 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/2007-01/msg02068.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
[Bug web/30584] New: bugzilla: cannot add comments
I tried to add a comment to my bug #28686. Being a common user, I could not modify the asignee, that was static text only no entry field. When I comitted my addition, I was asked for my password, and then told: You tried to change the Assignee field from [EMAIL PROTECTED] to __UNKNOWN__, but only the assignee of the bug, or a sufficiently empowered user may change that field. This effectively prevents me from adding comments to the bug report. Another thing that might be related: When I log in on the home page or through the Log In link on any report I get to the home page, and my status is logged in. When I jump from the home page to a specific bug, by entering its number in the form and clicking Find or by directly entering its URL, my status is back to not logged in, as I have the Log In link in my footer. It would be useful to have this bugzill as a Product as well. gcc is definitely not what this is really about, but I found no better alternative. -- Summary: bugzilla: cannot add comments Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Martin dot vGagern at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30584
[Bug web/30584] bugzilla: cannot add comments
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-25 10:59 --- Try deleting all cookies related to gcc bugzilla, there was a change in setup recently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30584
[Bug web/30584] bugzilla: cannot add comments
--- Comment #2 from Martin dot vGagern at gmx dot net 2007-01-25 11:03 --- No luck there. But here it works! strange! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30584
[Bug inline-asm/28686] ebp from clobber list used as operand
--- Comment #2 from Martin dot vGagern at gmx dot net 2007-01-25 11:06 --- As this has been unconfirmed for so long and should be relatively easy to confirm, here are the commands to reproduce the problems above: gcc -fPIC -fomit-frame-pointer -O2 -S ebp.c grep DEBUG ebp.s gcc-O1 -S ebp.c grep DEBUG ebp.s gcc -fPIC -O0 -S ebp.c grep DEBUG ebp.s In case you want to reproduce all the combinations given in the table at the end of my source file, you can use this bash loop: for ((i=0; i 32; ++i)); do ARGS=-O$((i%4)); ARGS=$( [[ $((i4)) -eq 0 ]] || echo -fomit-frame-pointer )$ARGS; ARGS=$( [[ $((i8)) -eq 0 ]] || echo -fPIC )$ARGS; ARGS=$( [[ $((i16)) -eq 0 ]] || echo -DNBEFORE )$ARGS; echo -- $ARGS --; gcc $ARGS -S ebp.c grep DEBUG ebp.s done It might be you can reproduce this behaviour, but are not certain it is a bug. I can understand you might doubt a single of my three mentioned problems, but do you really believe they are all three as things should be? If in doubt, perhaps best concentrate on problem 1, ebp being clobbered and still used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686
Re: updating bugzilla entry with an additional comment. not allowed
Christian BRUEL wrote: After loged in with my Bugzilla account, I'm trying to add a new Additional Comment to the bug #29845. I didn't modify any of the other fields. I keep getting the following error message: You're not the only one Christian. See bug #30584. Andrew
[Bug web/30584] bugzilla: cannot add comments
--- Comment #3 from Martin dot vGagern at gmx dot net 2007-01-25 11:08 --- Clearing browser cache helped. Maybe bugzilla did not mark a page as changed that had in fact changed for some reason. I'm ready to provide additional information if I can. Just ask. Unfortunately it is too late to record the network traffic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30584
[Bug rtl-optimization/28772] scheduler is too slow and O(n^2) for ia64
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2007-01-25 11:41 --- (In reply to comment #3) scheduling:6473.35 (100%) usr 0.60 (88%) sys6473.98 (100%) wall 499608 kB (90%) ggc On which revision of gcc-4_2-branch or trunk have you seen it? It looks to me that this issue was fixed in rev. 112936 on April 14 2006. On current trunk scheduler is accounted for 12% of total compile time: Execution times (seconds) garbage collection: 0.42 ( 1%) usr 0.00 ( 0%) sys 0.44 ( 1%) wall 0 kB ( 0%) ggc callgraph construction: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 322 kB ( 0%) ggc callgraph optimization: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 1 kB ( 0%) ggc CFG verifier : 0.11 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc trivially dead code : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc life analysis : 1.01 ( 2%) usr 0.00 ( 0%) sys 1.02 ( 2%) wall 2595 kB ( 4%) ggc life info update : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.21 ( 0%) usr 0.00 ( 0%) sys 0.22 ( 0%) wall 3461 kB ( 5%) ggc register scan : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.03 ( 0%) usr 0.02 ( 8%) sys 0.04 ( 0%) wall 1066 kB ( 1%) ggc lexical analysis : 0.04 ( 0%) usr 0.02 ( 8%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc parser: 0.07 ( 0%) usr 0.03 (13%) sys 0.09 ( 0%) wall 1832 kB ( 3%) ggc inline heuristics : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 322 kB ( 0%) ggc tree VRP : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1 kB ( 0%) ggc tree copy propagation : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 1 kB ( 0%) ggc tree store copy prop : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree find ref. vars : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree PTA : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 6 kB ( 0%) ggc tree alias analysis : 0.02 ( 0%) usr 0.03 (12%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc tree SSA rewrite : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 900 kB ( 1%) ggc tree SSA other: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA incremental : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree operand scan : 0.38 ( 1%) usr 0.05 (21%) sys 0.38 ( 1%) wall 4839 kB ( 7%) ggc dominator optimization: 0.38 ( 1%) usr 0.00 ( 0%) sys 0.38 ( 1%) wall 5794 kB ( 8%) ggc tree STORE-CCP: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 256 kB ( 0%) ggc tree CCP : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree PRE : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree aggressive DCE : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree DSE : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 5 kB ( 0%) ggc tree SSA to normal: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree rename SSA copies: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA verifier : 0.75 ( 1%) usr 0.00 ( 0%) sys 0.75 ( 1%) wall 0 kB ( 0%) ggc tree STMT verifier: 0.93 ( 2%) usr 0.00 ( 0%) sys 0.88 ( 2%) wall 0 kB ( 0%) ggc callgraph verifier: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc dominance computation : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc expand: 0.30 ( 1%) usr 0.01 ( 4%) sys 0.29 ( 1%) wall 11970 kB (16%) ggc jump : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc forward prop : 0.09 ( 0%) usr 0.01 ( 4%) sys 0.10 ( 0%) wall 602 kB ( 1%) ggc CSE : 1.90 ( 3%) usr 0.00 ( 0%) sys 1.92 ( 3%) wall 2433 kB ( 3%) ggc loop analysis : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc CSE 2 : 1.07 ( 2%) usr 0.00 ( 0%) sys 1.08 ( 2%) wall 703 kB ( 1%) ggc flow analysis : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc combiner : 0.19 (
[Bug c/30575] Missing warning about unitialized variable
--- Comment #1 from muntyan at tamu dot edu 2007-01-25 13:27 ---
The original code warns if you use -O3 (I guess because of inlining or
something), the code below is better:
-
#include stdio.h
int func (void);
int main (void)
{
int foo;
if (func ())
foo = 8;
printf (%d\n, foo);
return 0;
}
-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30575
[Bug bootstrap/30541] Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables down
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-01-25 13:52 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug c/30580] GCC doesn't set floating-point exceptions when performing fp-int conversions
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-01-25 14:06 --- And indeed we should support Annex F in this regard. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||16989 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30580
[Bug tree-optimization/29605] [4.0 Regression] optimization breaks global variable affectation
--- Comment #2 from gdr at gcc dot gnu dot org 2007-01-25 14:14 --- Won't be fixed in GCC-4.0.4. So closing, sorry. The code appears to work in recent versions of GCC. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29605
[Bug java/30585] New: gcj doesn't accept -Wall and -Werror anymore
$ gcj -Werror /tmp/x.java invalid warning: error $ gcj -Wall /tmp/x.java invalid warning: all -- Summary: gcj doesn't accept -Wall and -Werror anymore Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30585
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #16 from tg at mirbsd dot org 2007-01-25 14:28 ---
Interestingly enough, nbd of OpenWrt has found that the bug
doesn't appear (i.e. the assert is triggered) if the function
is inlined (at -O3, with -finline-functions, or the attribute).
I've used a simpler test programme while trying to look at
it myself:
[EMAIL PROTECTED]:~ $ cat x.i
int foo(int a) { return (((a + 100) a) ? 0 : 1); }
int main(void) { return (foo(0x7fff)); }
If that one returns 0, bug, if 1, correct.
I suppose this is not a problem in fold-const.c but in some
other code optimisation.
We'd really appreciate if someone can help with this.
--
tg at mirbsd dot org changed:
What|Removed |Added
Known to fail||3.4.6
Known to work||4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-01-25 14:49 --- Backporting the fix for PR28651 should fix it I guess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug libstdc++/30586] New: [4.2/4.3 regression] Namespace pollution in c++ headers
$ cat abi.cc #include iostream struct abi; void foo (abi ); $ gcc abi.cc abi.cc:3: error: variable or field #8216;foo#8217; declared void abi.cc:3: error: expected primary-expression before #8216;#8217; token abi.cc:3: error: expected primary-expression before #8216;)#8217; token The problem is that bits/atomic_word.h on ia64 includes cxxabi.h which defines namespace abi. Before 4.2, ia64 has used the generic bits/atomic_word.h. -- Summary: [4.2/4.3 regression] Namespace pollution in c++ headers Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug libstdc++/29722] Linking with libsupc++.a creates link time undefined references
--- Comment #11 from bkoz at gcc dot gnu dot org 2007-01-25 15:30 --- Subject: Bug 29722 Author: bkoz Date: Thu Jan 25 15:30:32 2007 New Revision: 121175 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121175 Log: 2007-01-24 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/29722 continued * testsuite/lib/libstdc++.exp (v3_target_compile_as_c): Add libsupc++ library directory. * testsuite/abi/cxx_runtime_only_linkage.cc: Remove hard-coded path specification. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/testsuite/abi/cxx_runtime_only_linkage.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/lib/libstdc++.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29722
[Bug tree-optimization/28778] [4.0/4.1 Regression] alias bug with cast and call clobbered
--- Comment #50 from gdr at gcc dot gnu dot org 2007-01-25 15:51 --- This is not going to be fixed for GCC-4.0.4, so adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug c/27184] [4.0 Regression] Wrong code with pointers to arrays and types and strict aliasing
--- Comment #18 from gdr at gcc dot gnu dot org 2007-01-25 15:54 --- Fixed in GCC-4.1.2 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #11 from gdr at gcc dot gnu dot org 2007-01-25 15:58 --- This PR will not be fixed in GCC-4.0.4, so adjusting the milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug c++/25156] [4.0/4.1/4.2/4.3 Regression] wrong error message (int instead of bool)
--- Comment #9 from gdr at gcc dot gnu dot org 2007-01-25 16:04 --- Adjusting milestone -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c/30477] Integer Overflow detection code optimised away, -fwrapv broken
--- Comment #18 from tg at mirbsd dot org 2007-01-25 16:09 --- Subject: Integer Overflow detection code optimised away, -fwrapv broken Dixi: Commit ID: 10045B8CAF141886704 CVSROOT: /cvs Module name: gcc Changes by:[EMAIL PROTECTED] 2007/01/25 15:21:11 UTC Modified files: gcc: simplify-rtx.c Log message: --- Comment [100]#17 From [101]Richard Guenther 2007-01-25 14:49 --- Backporting the fix for [102]PR28651 should fix it I guess. Yes it does, thanks. To generate a diff of this changeset, execute the following commands: cvs -R rdiff -ur1.5 -r1.6 gcc/gcc/simplify-rtx.c That is: - cutting here may damage your screen surface - Index: gcc/gcc/simplify-rtx.c diff -u gcc/gcc/simplify-rtx.c:1.5 gcc/gcc/simplify-rtx.c:1.6 --- gcc/gcc/simplify-rtx.c:1.5 Thu Mar 30 19:50:29 2006 +++ gcc/gcc/simplify-rtx.c Thu Jan 25 15:21:10 2007 @@ -2686,18 +2686,18 @@ a register or a CONST_INT, this can't help; testing for these cases will prevent infinite recursion here and speed things up. - If CODE is an unsigned comparison, then we can never do this optimization, - because it gives an incorrect result if the subtraction wraps around zero. - ANSI C defines unsigned operations such that they never overflow, and - thus such cases can not be ignored. */ + We can only do this for EQ and NE comparisons as otherwise we may + lose or introduce overflow which we cannot disregard as undefined as + we do not know the signedness of the operation on either the left or + the right hand side of the comparison. */ if (INTEGRAL_MODE_P (mode) trueop1 != const0_rtx + (code == EQ || code == NE) ! ((GET_CODE (op0) == REG || GET_CODE (trueop0) == CONST_INT) (GET_CODE (op1) == REG || GET_CODE (trueop1) == CONST_INT)) 0 != (tem = simplify_binary_operation (MINUS, mode, op0, op1)) - /* We cannot do this for == or != if tem is a nonzero address. */ - ((code != EQ code != NE) || ! nonzero_address_p (tem)) - code != GTU code != GEU code != LTU code != LEU) + /* We cannot do this if tem is a nonzero address. */ + ! nonzero_address_p (tem)) return simplify_relational_operation (signed_condition (code), mode, tem, const0_rtx); - cutting here may damage your screen surface - This applies to gcc 3.4.6 - if you need other versions, YMMV. bye, //mirabile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30477
[Bug c/30587] New: GCC4 reduces local variable padding, making off-by-one vulnerabilities once again critical
I've posted this to the mailing list and figured i might as well post a bug
report to accompany it.
It's not as much of a bug as it a missing feature that gcc3 had.
Basically gcc v3 placed padding between the end of local variables and the
saved frame pointer or other control information and gcc4 no longer does that,
making an off-by-one much more dangerous again (as in gcc v2).
Since a lot of security minded things are now included with default gcc and
some are default compile options, this is probably an unintended effect of code
rewrites.
Here's a link to my post that describes it in full:
http://gcc.gnu.org/ml/gcc/2007-01/msg00993.html
Again:
in main(){ char buf[512]; }
buf[512] is the LSB of the saved frame pointer or other control information
(like %ecx in the new main function). On a gcc3 buf[512] would have just been
extra space, making an extra NULL byte not as security-critical.
The -mpreferred-stack-boundary option should be used when padding is not
desired i think. I'm really unqualified though.
Good luck, and I appreciate the strides towards security.
--
Summary: GCC4 reduces local variable padding, making off-by-one
vulnerabilities once again critical
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: defend dot the dot world at gmail dot com
GCC build triplet: gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
GCC host triplet: linux 32-bit x86
GCC target triplet: linux 32-bit x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30587
[Bug java/30588] New: gcj compiler large jars much slower
An example from frysk: $ /usr/bin/gcj -v Using built-in specs. Reading specs from /usr/lib/gcc/x86_64-redhat-linux/4.1.1/libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) $ /home/mark/src/gcc-install/bin/gcj -v Using built-in specs. Reading specs from /home/mark/src/gcc-install/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig Target: x86_64-unknown-linux-gnu Configured with: /home/mark/src/gcc/configure --prefix=/home/mark/src/gcc-install --enable-java-awt=gtk --disable-bootstrap --disable-checking --enable-plugin --enable-languages=c,c++,java Thread model: posix gcc version 4.3.0 20070125 (experimental) $ time /usr/bin/gcj -I../../frysk/frysk-imports -I. -Igetopt.jar -Ijunit.jar -Werror -Wall -fPIC -g -O -fjni -c antlr.jar real0m36.455s user0m35.666s sys 0m0.644s $ time /home/mark/src/gcc-install/bin/gcj -I../../frysk/frysk-imports -I. -Igetopt.jar -Ijunit.jar -Werror -Wall -fPIC -g -O -fjni -c antlr.jar real0m51.691s user0m50.643s sys 0m0.760s Compiling with -ftime-report gives a hint where this might come from: 4.3 (trunk): tree PTA : 3.80 ( 8%) usr 0.02 ( 1%) sys 3.79 ( 7%) wall 25485 kB ( 2%) ggc tree alias analysis : 10.41 (21%) usr 0.50 (21%) sys 10.83 (21%) wall 600226 kB (42%) ggc With 4.1.1 it is: tree PTA : 5.80 (17%) usr 0.05 ( 3%) sys 5.54 (15%) wall 45994 kB ( 5%) ggc tree alias analysis : 1.48 ( 4%) usr 0.37 (21%) sys 1.90 ( 5%) wall 16749 kB ( 2%) ggc -- Summary: gcj compiler large jars much slower Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30588
[Bug java/30588] gcj compiler large jars much slower
--- Comment #1 from aph at gcc dot gnu dot org 2007-01-25 16:59 --- I'm guessing this is either because of more aggressive alalysis or perhaps we're now compiling unit-at-a-time. In any case, I don't think Java is the correct component. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30588
[Bug bootstrap/30589] New: [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
A simple example of what breaks the libgfortran build:
$ cat a.c
#include math.h
extern float foo(float);
float bar(float x) { return sinhf(x); }
int main(void)
{
float x;
x = bar(x);
x = foo(x);
return 0;
}
$ cat b.c
#include math.h
int foo(float x) { return sinhf(x); }
$ gcc a.c b.c -std=c99
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x0): multiple
definition of `__fpclassifyl'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x0): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x1f): multiple
definition of `__isnan'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x1f): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x55): multiple
definition of `__isnanf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x55): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x7f): multiple
definition of `__isnanl'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x7f): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0xa9): multiple
definition of `__signbit'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0xa9): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0xdc): multiple
definition of `__signbitf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0xdc): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x103): multiple
definition of `__signbitl'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x103): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x12a): multiple
definition of `sinhf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x12a): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x14d): multiple
definition of `coshf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x14d): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x170): multiple
definition of `tanhf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x170): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x193): multiple
definition of `expf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x193): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x1b6): multiple
definition of `frexpf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x1b6): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x1dc): multiple
definition of `ldexpf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x1dc): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x202): multiple
definition of `logb'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x202): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x22f): multiple
definition of `logbf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x22f): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x24a): multiple
definition of `logbl'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x24a): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x271): multiple
definition of `hypotf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x271): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x29d): multiple
definition of `powf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x29d): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x2c9): multiple
definition of `rint'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x2c9): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x2f4): multiple
definition of `rintf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x2f4): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x30d): multiple
definition of `rintl'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x30d): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x332): multiple
definition of `lrint'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x332): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x34f): multiple
definition of `lrintf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x34f): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x360): multiple
definition of `lrintl'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x360): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x371): multiple
definition of `llrint'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x371): first defined
here
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccyLWAx7.o:b.c:(.text+0x391): multiple
definition of `llrintf'
C:/DOCUME~1/coudert/LOCALS~1/Temp/ccuYdlXI.o:a.c:(.text+0x391): first defined
here
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-25 17:01 --- Sorry I have CCed the wrong person. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC|echristo at gcc dot gnu dot |geoffk at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-25 17:02 --- Created an attachment (id=12954) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12954action=view) Preprocessed source file for a.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-25 17:03 --- Created an attachment (id=12955) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12955action=view) Preprocessed source file for b.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug other/30182] FAIL: gcc.dg/pr28796-2.c (test for excess errors)
--- Comment #1 from sje at gcc dot gnu dot org 2007-01-25 17:07 --- Subject: Bug 30182 Author: sje Date: Thu Jan 25 17:06:55 2007 New Revision: 121178 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121178 Log: PR other/30182 * config/pa/pa.c (pa_init_builtins): Set asm names for finite routines. * config/ia64/ia64.c (ia64_init_builtins): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c trunk/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30182
[Bug target/30182] FAIL: gcc.dg/pr28796-2.c (test for excess errors)
--- Comment #2 from sje at cup dot hp dot com 2007-01-25 17:09 --- Resolved with patch to call _Isfinite* routines. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED Component|other |target Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30182
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #4 from jconner at apple dot com 2007-01-25 17:11 --- I'll investigate fixing this in the 4.1 and 4.2 branches, as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #3 from sqrammi at hotmail dot com 2007-01-25 17:11 --- I've modified the source so that there are no warnings and (hopefully) no aliasing violations. The problem still occurs. Here is my line that I use to compile: arm-926ejs-linux-gnu-gcc -Wall -O2 -fno-strict-aliasing gcc4_arm_align_bug.c -o gccbug It happens with or without -static. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #4 from sqrammi at hotmail dot com 2007-01-25 17:12 --- Created an attachment (id=12956) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12956action=view) Modified code - no warnings -- sqrammi at hotmail dot com changed: What|Removed |Added Attachment #12953|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #5 from rearnsha at gcc dot gnu dot org 2007-01-25 17:25 --- -- volatile char buf[512] /*__attribute__ ((aligned (4)))*/; WHat makes you think this buffer will be word-aligned? One of your sub-routines creates a variable with 33 bytes, and when inlining happens there's nothing to stop the compiler from packing these structures onto the stack and starting buf at something like stack-base+33. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #6 from sqrammi at hotmail dot com 2007-01-25 17:28 --- The problem is that the compiler is not either 1) automatically aligning the buffer so that the program actually works or 2) warning the user that their code is retarded and needs to be modified so that all the stacks fit to multiples of 32-bits. wpa_supplicant is wrought with code that does this, but I don't think the maintainers understand the problem because gcc doesn't complain, and the problem doesn't show up until runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c++/30562] [4.3 Regression] ice for legal code with -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-25 17:22 --- This was caused by the MEM-ssa merge, I thought I had a patch but it crashed during build __gcc_bcmp. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|ice for legal code with -O2 |[4.3 Regression] ice for ||legal code with -O2 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-25 17:35 --- (In reply to comment #6) The problem is that the compiler is not either 1) automatically aligning the buffer so that the program actually works or It doesn't have to, because the user hasn't asked it to (align the data). 2) warning the user that their code is retarded and needs to be modified so that all the stacks fit to multiples of 32-bits. It can't, because the various casts are asserting that everything is ok. The compiler isn't psychic and it isn't Lint (though I don't know if Lint would find these specific cases either). I would strongly suggest that if you want this sort of analysis then you take a look at some specialist code analysis tools. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30587] GCC4 reduces local variable padding, making off-by-one vulnerabilities once again critical
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-25 17:41 --- This is not a bug really. There is no reason to think stack layout will not change and will not be because of alignment or anything else. -- 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=30587
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #9 from schwab at suse dot de 2007-01-25 17:47 --- Use -Wcast-align. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #8 from sqrammi at hotmail dot com 2007-01-25 17:45 --- It would be easy to add support to the compiler to at least warn about char arrays of non-CPU-word-size length being placed on the stack, right? It wouldn't even have to be a warning that shows up unless -Wall (or it's own new -W flag) is specified. Either that, or there needs to be a flag that aligns each of the inlined functions' stacks on a CPU-word-size boundary that is turned on by default. I would strongly recommend a new warning flag like this so that the poop hits the fan a little earlier than runtime. There are many projects whose maintainers won't realize this problem in their code unless the compiler warns them. The better GCC gets at optimizing and inlining functions, the more likely this is to happen since developers currently don't think twice about doing a: char ssid[MAX_SSID_LEN+1]; etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #10 from sqrammi at hotmail dot com 2007-01-25 17:55 --- Great. That's perfect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #11 from sqrammi at hotmail dot com 2007-01-25 18:01 --- Thinking about it some more, this actually may be a bug in my Linux kernel configuration that fixes up unaligned accesses. It's probably trying to fix up for a big-endian system on my little-endian system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug target/30582] 64-bit Darwin ABI does not support array field
--- Comment #1 from dalej at gcc dot gnu dot org 2007-01-25 18:29 --- Early drafts of the ABI spec said that, but the final version calls for passing this struct as integers. I believe the following is publicly accessible: http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/ The compiler is doing the right thing. -- dalej at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dalej at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-25 18:29:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30582
[Bug target/30582] 64-bit Darwin ABI does not support array field
--- Comment #2 from dalej at gcc dot gnu dot org 2007-01-25 18:30 --- as above -- dalej at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30582
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|blocker Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug target/30429] internal compiler error: in emit_move_insn, at expr.c:2809
--- Comment #3 from sje at cup dot hp dot com 2007-01-25 18:58 --- I reproduced this bug with 3.4.5, but all the 4.* compilers I tried worked fine (4.0.2, 4.0.3, 4.1.0, 4.1.1) so I think we should close it. Hal, I don't know if the person who got you the testdrive account can help you get a newer GCC but if they can't let me know and I will see if I can help. -- 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=30429
[Bug testsuite/28703] FAIL: gcc.c-torture/execute/pr28651.c execution
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-01-25 19:05 --- Subject: Bug 28703 Author: rguenth Date: Thu Jan 25 19:05:19 2007 New Revision: 121181 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121181 Log: 2007-01-25 Richard Guenther [EMAIL PROTECTED] Backport from mainline: 2006-08-11 Richard Guenther [EMAIL PROTECTED] PR middle-end/28651 * simplify-rtx.c (simplify_const_relational_operation): Simplify A CMP B to A - B CMP 0 only for EQ and NE comparison codes. * gcc.c-torture/execute/pr28651.c: New testcase. 2006-08-14 Richard Guenther [EMAIL PROTECTED] PR testsuite/28703 * gcc.c-torture/execute/pr28651.c: Do not use argc to avoid optimization, instead forbid inlining. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/pr28651.c - copied, changed from r116079, trunk/gcc/testsuite/gcc.c-torture/execute/pr28651.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/simplify-rtx.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28703
[Bug middle-end/28651] [4.0 Regression] signed compare incorrectly false for (int)(U+4)(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-01-25 19:05 --- Subject: Bug 28651 Author: rguenth Date: Thu Jan 25 19:05:19 2007 New Revision: 121181 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121181 Log: 2007-01-25 Richard Guenther [EMAIL PROTECTED] Backport from mainline: 2006-08-11 Richard Guenther [EMAIL PROTECTED] PR middle-end/28651 * simplify-rtx.c (simplify_const_relational_operation): Simplify A CMP B to A - B CMP 0 only for EQ and NE comparison codes. * gcc.c-torture/execute/pr28651.c: New testcase. 2006-08-14 Richard Guenther [EMAIL PROTECTED] PR testsuite/28703 * gcc.c-torture/execute/pr28651.c: Do not use argc to avoid optimization, instead forbid inlining. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/pr28651.c - copied, changed from r116079, trunk/gcc/testsuite/gcc.c-torture/execute/pr28651.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/simplify-rtx.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #1 from pcarlini at suse dot de 2007-01-25 19:13 --- As far as I can see, in gcc4.0.x a special config/cpu/ia64/atomic_word.h already existed... and used, or otherwise something was broken, the file has been added with the below patch. As far as I can see, the _GLIBCXX_GUARD_TEST_AND_ACQUIRE and _GLIBCXX_GUARD_SET_AND_RELEASE macro definitions therein, which make use of facilities in cxxabi.h, are only used in libsupc++/guard.cc via including atomicity.h (which, in turn, includes atomic_word.h). Thus it should be possible to remove those macros from atomic_word.h. Also note that *only* ia64 uses non-defaults for the macros. Benjamin, Jason, can you have a look? // 2004-12-27 Jason Merrill [EMAIL PROTECTED] Add memory barriers to the double-checked locking used for static initialization. * libsupc++/guard.cc (__test_and_acquire): Define default. (_GLIBCXX_GUARD_TEST_AND_ACQUIRE, __set_and_release) (_GLIBCXX_GUARD_SET_AND_RELEASE): Likewise. (recursion_push, recursion_pop): New abstraction functions. (__cxa_guard_acquire): Use _GLIBCXX_GUARD_TEST_AND_ACQUIRE. (__cxa_guard_release): Use _GLIBCXX_GUARD_SET_AND_RELEASE. * config/cpu/generic/cxxabi_tweaks.h (_GLIBCXX_GUARD_TEST): Rename from _GLIBCXX_GUARD_ACQUIRE and reverse sense. (_GLIBCXX_GUARD_SET): Rename from _GLIBCXX_GUARD_RELEASE. * config/cpu/arm/cxxabi_tweaks.h: Likewise. * config/cpu/alpha/atomic_word.h (_GLIBCXX_READ_MEM_BARRIER) (_GLIBCXX_WRITE_MEM_BARRIER): Define. * config/cpu/powerpc/atomic_word.h: Likewise. * config/cpu/sparc/atomic_word.h: Likewise. * config/cpu/generic/atomic_word.h: Define them, commented out. * include/bits/atomicity.h: Define defaults. * config/cpu/ia64/atomic_word.h (__test_and_acquire) (__set_and_release): New inlines. (_GLIBCXX_GUARD_TEST_AND_ACQUIRE): Define. (_GLIBCXX_GUARD_SET_AND_RELEASE): Define. -- pcarlini at suse dot de changed: What|Removed |Added CC||jason at redhat dot com, ||bkoz at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-25 19:13:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #12 from geoffk at gcc dot gnu dot org 2007-01-25 19:18 --- I'm working on this. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-02 20:22:25 |2007-01-25 19:18:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #13 from geoffk at gcc dot gnu dot org 2007-01-25 19:20 --- ... at least, I think I have a patch which will fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #2 from pcarlini at suse dot de 2007-01-25 19:23 --- Humm, maybe the fix is very simple: apparently these days in the ia64 atomic_word.h we don't really need cxxabi.h, only cxxabi_tweaks.h, for __cxxabiv1::__guard. I'll give it a try... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug target/30272] Build failure under SGI Irix (GFortran)
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-01-25 19:25 --- Subject: Bug 30272 Author: dfranke Date: Thu Jan 25 19:25:01 2007 New Revision: 121182 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121182 Log: 2007-01-25 Daniel Franke [EMAIL PROTECTED] PR target/30272 * inclhack.def(broken_cabs): Also remove definition of cabsl. * fixincl.x: Regenerate. * tests/base/math.h: Update. Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def trunk/fixincludes/tests/base/math.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30272
[Bug tree-optimization/30590] New: tree-nrv optimization clobbers return variable
The following test case, when compiled with g++ -O, has a return
value of 1 (instead of the correct value of 0):
struct test
{
int type;
char buffer[4242]; /* should trigger pass-by-reference */
};
int flag = 0;
struct test
reset (void)
{
struct test retval;
retval.type = 1;
return retval;
}
struct test
test (void)
{
struct test result;
result.type = 0;
for (int i = 0; i 2; ++i)
{
struct test candidate = reset ();
if (flag)
result = candidate;
}
return result;
}
int
main (void)
{
struct test result = test ();
return result.type;
}
The reason for this appears to be a bug in the tree-nrv (named
return value) optimization pass. Before tree-nrv, the function
test looks like:
struct test candidate;
int i;
int flag.0;
bb 2:
retval.type = 0;
flag.0 = flag;
i = 0;
L0:;
candidate = reset () [return slot optimization];
if (flag.0 != 0) goto L1; else goto L2;
L1:;
retval = candidate;
L2:;
i = i + 1;
if (i != 2) goto L0; else goto L5;
L5:;
return retval;
After tree-nrv, we have:
struct test candidate;
int i;
int flag.0;
bb 2:
retval.type = 0;
flag.0 = flag;
i = 0;
L0:;
retval = reset () [return slot optimization];
if (flag.0 != 0) goto L1; else goto L2;
L1:;
L2:;
i = i + 1;
if (i != 2) goto L0; else goto L5;
L5:;
return retval;
The return value of reset has been redirected directly
into the return value slot of test, instead of the local
variable candidate. tree-nrv.c has some code that is
apparently intended to prevent this type of thing; I'm
not sure why that didn't work here.
The bug occurs (at least) in GCC 4.1.1 and current mainline.
--
Summary: tree-nrv optimization clobbers return variable
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug middle-end/28651] [4.0 Regression] signed compare incorrectly false for (int)(U+4)(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-01-25 20:02 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work|4.2.0 4.1.2 |4.2.0 4.1.2 4.0.4 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-25 20:11 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.2 4.2.0 4.3.0 Known to work||3.4.6 4.0.4 Last reconfirmed|-00-00 00:00:00 |2007-01-25 20:11:47 date|| Summary|tree-nrv optimization |[4.1/4.2/4.3 Regression] |clobbers return variable|tree-nrv optimization ||clobbers return variable http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #14 from geoffk at gcc dot gnu dot org 2007-01-25 20:32 --- Subject: Bug 25127 Author: geoffk Date: Thu Jan 25 20:32:06 2007 New Revision: 121184 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121184 Log: 2007-01-24 Geoffrey Keating [EMAIL PROTECTED] PR 25127 * config/rs6000/rs6000.c (first_altivec_reg_to_save): On Darwin, save Altivec registers in an eh_return function. (compute_vrsave_mask): Likewise. (rs6000_stack_info): Correct AIX/Darwin stack alignment computation for saving Altivec registers. (rs6000_emit_prologue): Don't allocate stack twice in eh_return function. Correct expected value of altivec_save_offset when using save_world. Describe save of R0 to stack when using save_world. Describe stack pointer adjustment when using save_world. Remove duplicated eh_return parameter register saving. Update sp_offset variable after save_world. * config/rs6000/t-darwin (LIB2FUNCS_STATIC_EXTRA): Remove darwin-world.asm. (LIB2FUNCS_EXTRA): Add darwin-world.asm. * config/rs6000/darwin.h (SUBTARGET_OVERRIDE_OPTIONS): -m64 implies Altivec. Index: gcc/testsuite/ChangeLog 2007-01-24 Geoffrey Keating [EMAIL PROTECTED] * gcc.target/powerpc/darwin-ehreturn-1.c: New. * g++.dg/eh/simd-2.C: Also run on Darwin. * g++.dg/eh/simd-3.C: New. * g++.dg/eh/simd-4.C: New. Added: trunk/gcc/testsuite/g++.dg/eh/simd-3.C trunk/gcc/testsuite/g++.dg/eh/simd-4.C trunk/gcc/testsuite/gcc.target/powerpc/darwin-ehreturn-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/darwin.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/t-darwin trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/eh/simd-2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug java/30585] gcj doesn't accept -Wall and -Werror anymore
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-25 20:40:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30585
[Bug fortran/30437] [4.0/4.1/4.2/4.3 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-25 21:15 --- Subject: Bug 30437 Author: manu Date: Thu Jan 25 21:15:34 2007 New Revision: 121186 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121186 Log: 2007-01-25 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR fortran/30437 fortran/ * lang.opt (Wall): Remove RejectNegative. * options.c (gfc_handle_option): Wall can be disabled. (set_Wall): Add a parameter for disabling Wall. testsuite/ * gcc.dg/Wall.c: New. * gcc.dg/Wno-all.c: New. * gfortran.dg/Wall.f90: New. * gfortran.dg/Wno-all.f90: New. Added: trunk/gcc/testsuite/gcc.dg/Wall.c trunk/gcc/testsuite/gcc.dg/Wno-all.c trunk/gcc/testsuite/gfortran.dg/Wall.f90 trunk/gcc/testsuite/gfortran.dg/Wno-all.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug libgomp/28209] None of the GOMP_* environment variables are documented
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-01-25 22:33 --- Subject: Bug 28209 Author: dfranke Date: Thu Jan 25 22:33:43 2007 New Revision: 121187 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121187 Log: 2007-01-25 Daniel Franke [EMAIL PROTECTED] Backport from mainline: 2006-12-21 Daniel Franke [EMAIL PROTECTED] PR libgomp/28209 * libgomp.texi: New file. * configure.ac: Add --enable-generated-files-in-srcdir option. * Makefile.am: Add info, dvi, pdf, html targets. On request, copy files to srcdir. * Makefile.in: Regenerated. * testsuite/Makefile.in: Regenerated. * NOTES: Removed. Backport from mainline: 2007-01-14 Daniel Franke [EMAIL PROTECTED] * libgomp.texi: Document implementation specific default values of environment variables. Added: branches/gcc-4_2-branch/libgomp/libgomp.texi Removed: branches/gcc-4_2-branch/libgomp/NOTES Modified: branches/gcc-4_2-branch/libgomp/ChangeLog branches/gcc-4_2-branch/libgomp/Makefile.am branches/gcc-4_2-branch/libgomp/Makefile.in branches/gcc-4_2-branch/libgomp/configure branches/gcc-4_2-branch/libgomp/configure.ac branches/gcc-4_2-branch/libgomp/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28209
[Bug java/30591] New: Cross build fails because native gcj needed to build ecjx
ecjx is a java program used as part of the gcj compilation process. Because it is written in java and runs on the host, it needs a host version of gcj to build it. Here is the error I am getting: make[3]: *** [ecjx] Error 127 make[3]: Leaving directory `/home/daney/gccsvn/mipsel-trunk/mipsel-linux/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/daney/gccsvn/mipsel-trunk/mipsel-linux/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/daney/gccsvn/mipsel-trunk' make: *** [all] Error 2 There seem to be two ways to fix this: 1) In a cross build, build a complete gcc/g++/gcj in build-i686-pc-linux-gnu along with fixincldes and libiberty. 2) Have configure check for a good version of gcj that is already installed and use that -- Summary: Cross build fails because native gcj needed to build ecjx Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: mipsel-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30591
[Bug java/30591] Cross build fails because native gcj needed to build ecjx
--- Comment #1 from daney at gcc dot gnu dot org 2007-01-25 23:12 --- This is actually contains the error from the build output this time: i686-pc-linux-gnu-gcj -o ecjx -findirect-dispatch --main=org.eclipse.jdt.internal.compiler.batch.GCCMain ../../../trunk/libjava/.././libjava/../ecj.jar make[3]: i686-pc-linux-gnu-gcj: Command not found make[3]: *** [ecjx] Error 127 make[3]: Leaving directory `/home/daney/gccsvn/mipsel-trunk/mipsel-linux/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/daney/gccsvn/mipsel-trunk/mipsel-linux/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/daney/gccsvn/mipsel-trunk' make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30591
[Bug c/30592] New: -fmudflap and -Wnested-externs conflict
Using both -fmudflap and -Wnested-externs generates spurious errors. localhost$ touch tmp.c localhost$ gcc -fmudflap -Wnested-externs -S tmp.c built-in:0: warning: nested extern declaration of __mf_lookup_cache built-in:0: warning: nested extern declaration of __mf_lc_shift built-in:0: warning: nested extern declaration of __mf_lc_mask built-in:0: warning: nested extern declaration of __mf_check built-in:0: warning: nested extern declaration of __mf_register built-in:0: warning: nested extern declaration of __mf_unregister built-in:0: warning: nested extern declaration of __mf_init built-in:0: warning: nested extern declaration of __mf_set_options cc1: error: mf-runtime.h: No such file or directory You can ignore the mf-runtime.h error. The ones I'm concerned about here are all of the false nested extern warnings. I can reproduce the problem with all gcc versions from 4.0.x to mainline 4.3. This problem exists only with the C (and maybe C++) front end because of how the C front end handles scoping. The problem here is that the function mudflap_init creates some variables via pushdecl. However, the C front end has an implicit assumption that no variables will be created until after we start parsing, at which time push_file_scope is called. Since mudflap creates variables before push_file_scope is called, they end up being placed in the wrong scope, and the C front end gets confused and emits the warning. A possible solution is to add a builtin_variable hook similar to the existing builtin_function hook. Note that the C front end builtin_function hook calls bind directly, instead of calling pushdecl which then calls bind. A builtin_variable hook could do something similar which would solve the problem. There are also other simpler but less elegant ways to solve the problem. We could mark these mudflap variables with the DECL_IN_SYSTEM_HEADER bit to disable the -Wnested-externs warning for them. Or we could maybe disable the warning for variables in the external_scope, which I think can only happen in this case, though I haven't tried to verify that. -- Summary: -fmudflap and -Wnested-externs conflict Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wilson at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30592
[Bug target/30429] internal compiler error: in emit_move_insn, at expr.c:2809
--- Comment #4 from hald at kc dot rr dot com 2007-01-25 23:36 --- (In reply to comment #3) I reproduced this bug with 3.4.5, but all the 4.* compilers I tried worked fine (4.0.2, 4.0.3, 4.1.0, 4.1.1) so I think we should close it. Hal, I don't know if the person who got you the testdrive account can help you get a newer GCC but if they can't let me know and I will see if I can help. I'm fine with closing this bug if it does not exist in the 4.x series. As to testdrive, I went through the automated process back when it was part of Compaq before the merger with HP, so I don't have any contact to ask for a gcc upgrade. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30429
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #3 from schwab at suse dot de 2007-01-25 23:40 --- Yes, config/cpu/ia64/atomic_word.h already existed before 4.2, but it wasn't picked up until this: 2006-07-14 Benjamin Kosnik [EMAIL PROTECTED] * configure.host: Simplify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug java/27643] ICE in java_mark_cni_decl_local compiling bytecode-native
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-25 23:59 --- Works in svn trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27643
[Bug libgcj/28454] [ecj] runtime annotation support
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-26 00:00 --- Andrew added caching a while back. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28454
[Bug java/28938] [ecj] update build instructions to account for changes
--- Comment #7 from tromey at gcc dot gnu dot org 2007-01-26 00:01 --- I think this is fixed now. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
[Bug java/28067] [meta-bug] Tracking bug for ecj fixes
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-26 00:01 --- All done. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28067
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #15 from geoffk at gcc dot gnu dot org 2007-01-26 00:04 --- Subject: Bug 25127 Author: geoffk Date: Fri Jan 26 00:03:28 2007 New Revision: 121190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121190 Log: 2007-01-24 Geoffrey Keating [EMAIL PROTECTED] PR 25127 * config/rs6000/rs6000.c (first_altivec_reg_to_save): On Darwin, save Altivec registers in an eh_return function. (compute_vrsave_mask): Likewise. (rs6000_stack_info): Correct AIX/Darwin stack alignment computation for saving Altivec registers. (rs6000_emit_prologue): Don't allocate stack twice in eh_return function. Correct expected value of altivec_save_offset when using save_world. Describe save of R0 to stack when using save_world. Describe stack pointer adjustment when using save_world. Remove duplicated eh_return parameter register saving. Update sp_offset variable after save_world. * config/rs6000/t-darwin (LIB2FUNCS_STATIC_EXTRA): Remove darwin-world.asm. (LIB2FUNCS_EXTRA): Add darwin-world.asm. * config/rs6000/darwin.h (SUBTARGET_OVERRIDE_OPTIONS): -m64 implies Altivec. Index: gcc/testsuite/ChangeLog 2007-01-24 Geoffrey Keating [EMAIL PROTECTED] * gcc.target/powerpc/darwin-ehreturn-1.c: New. * g++.dg/eh/simd-2.C: Also run on Darwin. * g++.dg/eh/simd-3.C: New. * g++.dg/eh/simd-4.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/eh/simd-3.C - copied unchanged from r121184, trunk/gcc/testsuite/g++.dg/eh/simd-3.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/eh/simd-4.C - copied unchanged from r121184, trunk/gcc/testsuite/g++.dg/eh/simd-4.C branches/gcc-4_2-branch/gcc/testsuite/gcc.target/powerpc/darwin-ehreturn-1.c - copied unchanged from r121184, trunk/gcc/testsuite/gcc.target/powerpc/darwin-ehreturn-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/rs6000/darwin.h branches/gcc-4_2-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_2-branch/gcc/config/rs6000/t-darwin branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.dg/eh/simd-2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #4 from pcarlini at suse dot de 2007-01-26 00:04 ---
(In reply to comment #3)
Yes, config/cpu/ia64/atomic_word.h already existed before 4.2, but it wasn't
picked up until this:
2006-07-14 Benjamin Kosnik [EMAIL PROTECTED]
* configure.host: Simplify.
I see. The problem is that, in 4_1-branch and 4_0-branch the case ${host_cpu}
switch in configure.host lacks the appropriate entries for alpha, powerpc and
sparc. That is a separate, rather serious, bug, in my opinion, which should be
fixed at least in 4_1-branch. I mean to do that, barring contrary opinions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug target/25127] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
--- Comment #16 from geoffk at gcc dot gnu dot org 2007-01-26 00:05 --- This should be fixed now in the trunk and 4.2 branches. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|geoffk at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug libgcj/29594] jv-convert with no args NPE
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-26 00:05 --- Testing a fix. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-26 00:05:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29594
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #5 from pcarlini at suse dot de 2007-01-26 00:14 --- Disregard sparc in my previos post, was already ok, sorry. In summary, in 4_1-branch, additional entries are needed in the atomic_word_dir switch for alpha, ia64 and powerpc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug fortran/30437] [4.0/4.1/4.2 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-26 00:22 --- Fixed in 4.3. -- manu at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] - |-Wno-all is rejected (even |Wno-all is rejected (even |when fortran is not |when fortran is not |included) |included) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-01-26 00:23 --- This is probably because the mingw math.h header does not support C99. Francois, where does this header come from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug libgcj/29594] jv-convert with no args NPE
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-26 00:24 --- It turns out to be pretty hard to make jv-convert use the classpath getopt code, since all gcj classes are built by the main compilation and not the tools compilation (in libjava/classpath/). I'm going to go for a simpler stop-gap patch and then look at moving the jv-convert functionality into classpath's native2ascii. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29594
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-01-26 00:24 --- CVS mingw runtime header _mingw.h has this, which avoids the problem: # if ( __MINGW_GNUC_PREREQ(4, 3) __STDC_VERSION__ = 199901L) # define __CRT_INLINE extern inline __attribute__((__gnu_inline__)) # else # define __CRT_INLINE extern __inline__ # endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug fortran/23060] %VAL, %REF and %DESCR constructs not implemented
--- Comment #16 from dmarkman at mac dot com 2007-01-26 01:05 --- it looks like that suggested code doesn't work for x86_64 platform. I changed ADDR declaration to INTEGER *8 and gfortran -m64 percentval.f returns the following errors: CALL SUB1( %VAL( ADDR ), SIZE ) 1 Error: Kind of by-value argument at (1) is larger than default kind I did it on Mac OS X 10.4.8 and with gcc 4.2 but I guess it could work on Leopard 10.5 but I didn't check it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug libgcj/29594] jv-convert with no args NPE
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-26 01:05 --- Subject: Bug 29594 Author: tromey Date: Fri Jan 26 01:05:13 2007 New Revision: 121197 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121197 Log: PR libgcj/29594: * gnu/gcj/convert/Convert.java (main): Correctly handle missing input or output encodings. Removed unused local variables. Modified: trunk/libjava/ChangeLog trunk/libjava/classpath/lib/gnu/gcj/convert/Convert.class trunk/libjava/gnu/gcj/convert/Convert.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29594
[Bug libgcj/29594] jv-convert with no args NPE
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-26 01:06 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29594
[Bug fortran/30594] New: Calling inquire (iolength) crashes with -malign-double
With GNU Fortran 95 (GCC) 4.3.0 20070125 (experimental), the programme program main integer size integer*1 var open (10, file=conftestval, status=unknown) inquire (iolength=size) var write (10, *) size close (10) end compiled with the options /Users/eschnett/gcc/bin/gfortran -o conftest conftest.f -malign-double leads to a bus error: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x2ff8 0x0025ca38 in *__gfortran_st_iolength (dtp=0xb0c0) at /Users/eschnett/src/gcc/libgfortran/io/transfer.c:2630 2630*dtp-iolength = 0; The problem seems to be that struct st_parameter_dt changes its layout depending on whether -malign-double is in effect or not, making the compiled programme incompatible with the run-time library. I see two solutions: Either this struct should be modified so that it is independent of -malign-double, or the compiler should take special measures when building the tree for this structure, making sure to use standard alignments. Since I don't know how to build trees with non-standard alignments, I will send a patch that permutes the elements st_parameter_dt. -- Summary: Calling inquire (iolength) crashes with -malign-double Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: i386-apple-darwin8.8.1 GCC host triplet: i386-apple-darwin8.8.1 GCC target triplet: i386-apple-darwin8.8.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594
[Bug fortran/23060] %VAL, %REF and %DESCR constructs not implemented
--- Comment #17 from dmarkman at mac dot com 2007-01-26 01:45 --- after looking at the gcc/fortran/trans_types.c I tried to use -fdefault-integer-8 switch and everything was fine -- dmarkman at mac dot com changed: What|Removed |Added CC||dmarkman at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
Re: GCC bug report - Xubuntu kernel compile fails w/gcc bug report request
Jonathan Brickman wrote: as indicated by anyone who knows what I should be trying next! I tried to send this via the GCC web bug report system, but I could not find any way to attach this file, which the docs said is essential. First file the bug report, you will then immediately be taken to a page where you can attach the file to the newly created bug report. This is a bit awkward, yes, but I believe all bugzilla installations work this way. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug c/20631] Support -std=c90 as alias for -std=c89
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-26 02:08 --- Do we really want this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20631
[Bug java/30591] Cross build fails because native gcj needed to build ecjx
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-26 02:23 --- FWIW I don't think we want to fail outright if no suitable gcj is found. The whole business with compiling and installing ecj.jar is a convenience, not a strict necessity. The user can always make his own ecj1 somehow (e.g, I use a shell script). So one idea would be to look for a gcj for the build machine, and if not found, disable compilation of ecjx. What do you think? -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-26 02:23:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30591
[Bug c/30595] New: gcc3.4.6 generates incorrect ppc32 code for combination of bitfields and shifts
The code generated for a ppc32 for the 1 line function f below is incorrect.
Not that it should matter but this is a cross compiler, built with cross-tool.
typedef struct {
unsigned char c;
unsigned int i:24;
} e_t;
f(e_t *p)
{
p-i= 8;
}
#include stdio.h
int
main(int argc, char *argv[])
{
e_t x = { .c='a', .i=0x12345 };
f(x);
printf((0x12345 8 ) 0xff = %x\n, x.i);
}
Compiled with -O.
The output is
(0x12345 8 ) 0xff = 234561
The bottom 8 bits should be zero, not the contents of x.c.
If one comments out the driver function, so all that you are left with is the f
function, one gets the following assembler. I have added pseudo-C comments.
.file t.c
.section.text
.align 2
.globl f
.type f, @function
f:
lwz 9,0(3) ;; r9 = *p
mr 0,9 ;; r0 = r9
rlwimi 0,9,8,8,31 ;; low24(r0) = low24(rotate8(r9)) ** Wrong
stw 0,0(3) ;; *p = r0
blr ;; return
.size f, .-f
.section.note.GNU-stack,,@progbits
.ident GCC: (GNU) 3.4.6
gcc2.95 generates the correct code, and answer
(0x12345 8 ) 0xff = 234500
--
Summary: gcc3.4.6 generates incorrect ppc32 code for combination
of bitfields and shifts
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ISPARRY at BROCADE dot COM
GCC build triplet: i686-host_pc-linux-gnu
GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30595
[Bug c/24293] Undefined behaviour not diagnosed with -fsyntax-only
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-26 02:47 --- Sorry for my ignorance, what is syntactically wrong with that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24293
[Bug target/27363] ARM gcc 4.1 optimization bug
--- Comment #19 from m dot k dot edwards at gmail dot com 2007-01-26 02:53 --- Still generates bad code for snd_mask_refine in the gcc-4.1-20070115 snapshot. I have verified that the patch claimed to fix this bug is in this snapshot. My gcc is tuned for arm-926ejs, old ABI. -O1 works. -- m dot k dot edwards at gmail dot com changed: What|Removed |Added CC||m dot k dot edwards at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug c/30595] gcc3.4.6 generates incorrect ppc32 code for combination of bitfields and shifts
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30595
[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-01-26 03:37 --- I can reproduce this on non-darwin machine. Erik you were going to suggest a patch? If you want, I will review this for you. I wonder if this is related to changes I made to allow large iolengths, ie 64-bit integers? -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-26 03:37:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594
[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-26 03:53 --- This is not a bug, -malign-double changes the ABI. Stop using options that change the ABI. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594
[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-26 03:54 --- Please read the documentation about options like this, they explictly warn they change the ABI. Warning: if you use the -malign-double switch, structures containing the above types will be aligned differently than the published application binary interface specifications for the 386 and will not be binary compatible with structures in code compiled without that switch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594
[Bug tree-optimization/30358] [4.3 Regression] New ICEs on trunk for IPA CCP
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-26 03:56 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30358
[Bug target/25127] [4.0/4.1 Regression] internal compiler error: in rs6000_emit_prologue, at config/rs6000/rs6000.c:14039
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.3 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25127
[Bug fortran/30411] gfortran MODULE bug for non trivial data types
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-01-26 06:19 --- Can this PR be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30411
