[Bug tree-optimization/21827] unroll misses simple elimination - works with manual unroll
--- Comment #7 from martsummsw at hotmail dot com 2006-08-27 06:37 --- I am the reporter of this bug (with a new email-adress) This problem seems to be solved with 4.1.1 =) (Consider only #5 and forward - the first is wrong/irrelevant) -- martsummsw at hotmail dot com changed: What|Removed |Added CC||martsummsw at hotmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827
[Bug c++/28774] Request for warning where const/volatile is ignored in a cast
--- Comment #4 from ian at airs dot com 2006-08-27 06:44 --- I disagree. It is always useful to optionally warn about meaningless code. It can be a way to find a real bug in the program. It is not conceptually different from existing warnings like -Wredundant-decls. The code works fine, but something is odd. The behaviour of icc is irrelevant here. If you want to close this again, please give a reason why we should not warn about meaningless code. -- ian at airs dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug c++/28863] ICE on template class with visibility specification
--- Comment #2 from fang at csl dot cornell dot edu 2006-08-27 07:45 --- Looks recently fixed by patch for PR 28659. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28863
[Bug tree-optimization/21827] unroll misses simple elimination - works with manual unroll
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-08-27 10:51 --- The problem is still visible on the mainline, unrolling the loop on the tree level pessimizes the generated code. Zdenek, maybe you can have a look at this (testcase in comment #5). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827
[Bug java/28663] [4.2 regression] gcj fails to binary-compile eclipse's javac
--- Comment #6 from h dot mth at web dot de 2006-08-27 12:31 --- After some testing I can say that this is caused by the fix to bug 27529. -- h dot mth at web dot de changed: What|Removed |Added CC||h dot mth at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #14 from tbm at cyrius dot com 2006-08-27 13:20 --- Bootstrapped and regtested successfully on mipsel-linux-gnu and x86_64-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug tree-optimization/21827] unroll misses simple elimination - works with manual unroll
--- Comment #9 from martsummsw at hotmail dot com 2006-08-27 13:21 --- Hmmm - I am (also) wrong when I claimed it was solved in 4.1.1. It is improved since the example that goes wrong in #5 now is right, but it is just the limit (for when the compiler gets comfused) that is pushed a bit. e.g. for (int bp=0;bp11;++bp) // Up to 11 is fine unrolled in gcc 4.1.1 However 12 and above e.g. for (int bp=0;bp12;++bp) // this still produces the poor performing code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-08-27 14:20
---
So I have a patch that produces (diff typedef long GLint
__attribute__((may_alias)) resunts vs. patch):
--- t.i.030t.alias1.ok 2006-08-27 16:13:54.0 +0200
+++ t.i.030t.alias1 2006-08-27 16:14:17.0 +0200
@@ -174,11 +174,11 @@
Variable: blist, UID 1526, const int *
-Variable: list, UID 1527, int[32], is aliased, is addressable, call clobbered
(, passed to call, is global var ), default def: list_4
+Variable: list, UID 1527, int[32], is addressable, call clobbered (, passed to
call, is incoming pointer ), default def: list_4
Variable: blist.0, UID 1528, const GLint *, symbol memory tag: SMT.30
-Variable: SMT.30, UID 1575, const GLint, is addressable, is global, call
clobbered (, passed to call, is global var ), may aliases: { list }
+Variable: SMT.30, UID 1575, const GLint, is addressable, is global, call
clobbered (, passed to call, is global var )
@@ -195,8 +195,8 @@
Aliased symbols
-list, UID 1527, int[32], is aliased, is addressable, call clobbered (, passed
to call, is global var ), default def: list_4
-SMT.30, UID 1575, const GLint, is addressable, is global, call clobbered (,
passed to call, is global var ), may aliases: { list }
+list, UID 1527, int[32], is addressable, call clobbered (, passed to call, is
incoming pointer ), default def: list_4
+SMT.30, UID 1575, const GLint, is addressable, is global, call clobbered (,
passed to call, is global var )
Dereferenced pointers
@@ -204,7 +204,7 @@
Symbol memory tags
-SMT.30, UID 1575, const GLint, is addressable, is global, call clobbered (,
passed to call, is global var ), may aliases: { list }
+SMT.30, UID 1575, const GLint, is addressable, is global, call clobbered (,
passed to call, is global var )
Flow-sensitive alias information for find
@@ -275,7 +275,8 @@
# blist_1 = PHI blist_3(3), blist_6(4);
L2:;
blist.0_7 = (const GLint *) blist_1;
- # list_9 = V_MAY_DEF list_8;
+ # list_10 = V_MAY_DEF list_8;
+ # SMT.30_11 = V_MAY_DEF SMT.30_9;
aglChoosePixelFormat (blist.0_7);
return;
by noticing that if pt_anything is set, we indeed need to include all
addressable vars in the clobbering:
Index: tree-ssa-alias.c
===
*** tree-ssa-alias.c(revision 116488)
--- tree-ssa-alias.c(working copy)
*** set_initial_properties (struct alias_inf
*** 359,364
--- 359,373
if (!unmodifiable_var_p (referenced_var (j)))
mark_call_clobbered (referenced_var (j), pi-escape_mask);
}
+
+ if (pi-pt_anything)
+ {
+ bitmap_iterator bi;
+ unsigned int j;
+ EXECUTE_IF_SET_IN_BITMAP (addressable_vars, 0, j, bi)
+ if (!unmodifiable_var_p (referenced_var (j)))
+ mark_call_clobbered (referenced_var (j), pi-escape_mask);
+ }
}
/* If the name tag is call clobbered, so is the symbol tag
So what do you think will happen when you add one level of indirection
to the mess, and TBAA now prunes out *that* alias instead, so you miss
it again? (IE break the chain of clobber transitivity one link in the
other direcftion).
Do you have a testcase in mind?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/21827] unroll misses simple elimination - works with manual unroll
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-08-27 14:56 --- (In reply to comment #8) The problem is still visible on the mainline, unrolling the loop on the tree level pessimizes the generated code. Zdenek, maybe you can have a look at this (testcase in comment #5). I probably do not understand what the problem is supposed to be: In auto_unrolled_knight_count8, the loop is fully unrolled (i.e., the loop ceases to exist), and as expected, constant propagation makes sure that the compile-time resolvable conditions are eliminated. In auto_unrolled_knight_count9, the number of unrollings necessary to fully unroll the loop (9) is considered too high, hence the loop gets only partially unrolled (the body of the loop is copied three times). This time, there are no compile-time resolvable conditions. If you really want even large loops to be unrolled, you may play with --param max-completely-peeled-insns and --param max-completely-peel-times parameters. There were thoughts about providing pragmas to enable requiring more unrolling just for specific loops, but as far as I know, nobody is working on that just now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827
[Bug libstdc++/28830] FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/lockfree_weaktoshared.cc
--- Comment #1 from paolo at gcc dot gnu dot org 2006-08-27 15:19 --- Subject: Bug 28830 Author: paolo Date: Sun Aug 27 15:19:23 2006 New Revision: 116489 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116489 Log: 2006-08-27 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28830 * testsuite/tr1/2_general_utilities/memory/shared_ptr/thread/ lockfree_weaktoshared.cc: Rename to... * testsuite/tr1/2_general_utilities/memory/shared_ptr/thread/ default_weaktoshared.cc: ... this; test the default base class. * testsuite/tr1/2_general_utilities/memory/shared_ptr/thread/ mutex_weaktoshared.cc: Run like the other thread tests. Added: trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/memory/shared_ptr/thread/default_weaktoshared.cc - copied, changed from r116401, trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/memory/shared_ptr/thread/lockfree_weaktoshared.cc Removed: trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/memory/shared_ptr/thread/lockfree_weaktoshared.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/memory/shared_ptr/thread/mutex_weaktoshared.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28830
[Bug c++/26573] [4.0/4.1/4.2 regression] Duplicate message for static member in local class
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-27 15:22 --- Subject: Bug 26573 Author: lmillward Date: Sun Aug 27 15:22:05 2006 New Revision: 116490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116490 Log: PR c++/26573 * class.c (check_field_decls): Don't issue error about local classes containing static data members. * g++.dg/other/static2.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/static2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26573
[Bug c++/26573] [4.0/4.1 regression] Duplicate message for static member in local class
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-27 15:22 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression]|[4.0/4.1 regression] |Duplicate message for static|Duplicate message for static |member in local class |member in local class http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26573
[Bug libstdc++/28830] FAIL: tr1/2_general_utilities/memory/shared_ptr/thread/lockfree_weaktoshared.cc
--- Comment #2 from pcarlini at suse dot de 2006-08-27 15:23 --- Fixed. In case, we can always add something more specific for the _S_lockfree base (in any case gets already testing on every ia64, powerpc, alpha, s390...). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28830
[Bug c++/28863] ICE on template class with visibility specification
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-27 15:41 --- You must have something backported to 4.1.x because the patch which orginally caused this was only on the mainline. *** This bug has been marked as a duplicate of 28659 *** -- 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=28863
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-08-27 15:41 --- *** Bug 28863 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bernie at develer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #21 from dberlin at gcc dot gnu dot org 2006-08-27 15:41 --- Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered by noticing that if pt_anything is set, we indeed need to include all addressable vars in the clobbering: This is also equivalent to marking every addressable variable as clobbered whenever a function has any incoming pointers, as they will point to anything, and escape. I listed this as a conservatively correct solution in the email i sent to mark (Mark everything clobbered). So what do you think will happen when you add one level of indirection to the mess, and TBAA now prunes out *that* alias instead, so you miss it again? (IE break the chain of clobber transitivity one link in the other direcftion). Do you have a testcase in mind? Do you really want me to construct one? Hopefully this will suffice: Clobbering is a transitive property. given b = e a = b c = a d = c a store to *d clobbers the values held by c, d, a, and b. We will start with the solution that *d is clobbered, and attempt to propagate it up the chain by following may-alias sets, till we mark e as clobbered. In this case, d, c, a, and b wll have e in their alias set, so we only need to see the alias-set of any one of them to get this correct. However, if you add levels of indirection, like b = e a = b c = a d = c The only way we will get to the fact that e can be clobbered is by following the may-alias sets of each variable, d-c-a-b until we get to something with e in the ma-yalias set. If you add the right casts in, TBAA will prune the addresses from the may-alias set of different variables, and you won't ever get all the way to marking e clobbered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-08-27 15:49 --- Well, yes. If we still had pt_vars at the time of add_call_clobber_ops () we might only do it if one of the actual params of a CALL_EXPR has pt_anything set. But call clobbering is not per call-site or flow-sensitive (yet). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #23 from dberlin at gcc dot gnu dot org 2006-08-27 16:00 --- Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered --- Comment #22 from rguenth at gcc dot gnu dot org 2006-08-27 15:49 --- Well, yes. If we still had pt_vars at the time of add_call_clobber_ops () we might only do it if one of the actual params of a CALL_EXPR has pt_anything set. But call clobbering is not per call-site or flow-sensitive (yet). So just to be clear Given: The workaround is that any function which has *incoming* pointer arguments will have every addressable variable *in that function* marked as call clobbering (IE regardless of what the call), as with your patch. This will also be true with any function that has a store to a global pointer, any function that casts between pointers and ints, and any function that passes pointers to a call. Relatively speaking, this is a very large percentage of all functions written, IMHO. Then all of the following are true (this really is a question, not a statement)? 1. You believe this is a good idea for 4.2, even though it will probably cause a very marked decrease in performance of generated code compared to every previous 4.x series. 2. Even though this bug has been here for all 4.x versions and only reported now, you believe it affects a large enough number of users to make #1 acceptable. As is clear by now, I don't believe #2 is true, which is why i proposed fixing it properly (computing the clobbering sets independently of aliasing, which is going to be some moderate amount of code) in 4.3, and leaving this bug open, as a better solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug target/12477] Request to add ability to disable inline/dllimport warnings
--- Comment #13 from serzholino at gmail dot com 2006-08-27 16:20 --- Confirmed with qt4 on win32 -- serzholino at gmail dot com changed: What|Removed |Added CC||serzholino at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12477
[Bug c/27012] visibility attribute should not be permitted on local variables
--- Comment #6 from jason at gcc dot gnu dot org 2006-08-27 17:44 --- All diagnostics about meaningless attributes are currently warnings. I'm not going to change this one to be different from the others. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27012
[Bug c++/28058] [4.1/4.2 regression] ICE in inline_forbidden_p
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-08-27 17:45 --- Subject: Bug 28058 Author: mmitchel Date: Sun Aug 27 17:45:25 2006 New Revision: 116491 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116491 Log: PR c++/28058 * pt.c (register_specialization): Return error_mark_node for specialization-after-instantiation. * decl2.c (mark_used): Mark the main function used when one of its clones is used. PR c++/28058 * g++.dg/template/spec31.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/spec31.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28058
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #24 from drow at gcc dot gnu dot org 2006-08-27 17:56 --- Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered On Sun, Aug 27, 2006 at 04:00:19PM -, dberlin at dberlin dot org wrote: 1. You believe this is a good idea for 4.2, even though it will probably cause a very marked decrease in performance of generated code compared to every previous 4.x series. I don't think this conversation is going to make any forward progress unless someone tests it. Anyone want to volunteer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug c++/28058] [4.1/4.2 regression] ICE in inline_forbidden_p
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-08-27 18:00 --- Subject: Bug 28058 Author: mmitchel Date: Sun Aug 27 17:59:55 2006 New Revision: 116492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116492 Log: PR c++/28058 * pt.c (register_specialization): Return error_mark_node for specialization-after-instantiation. * decl2.c (mark_used): Mark the main function used when one of its clones is used. PR c++/28058 * g++.dg/template/spec31.C: New test. * g++.old-deja/g++.pt/spec9.C: Adjust error markers. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/spec31.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl2.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++.old-deja/g++.pt/spec9.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28058
[Bug c++/28058] [4.1/4.2 regression] ICE in inline_forbidden_p
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-08-27 18:00 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28058
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #15 from tbm at cyrius dot com 2006-08-27 18:30 --- (In reply to comment #14) Steve Ellcey posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00016.html I posted a better patch here: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00054.html This patch has not been tested yet. There are also some follow up questions raised in this thread that need to be answered. Steve, are you working on clarifying those new questions? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug bootstrap/28864] New: bootstrapping fails when building from non-/bin/sh-compatible shell
For bootstrapping gcc 3.4.6 I have configured it the follwing way:
env CONFIG_SHELL=/bin/ksh /usr/local/tmp/gcc-3.4.6/configure
--prefix=/usr/local --with-ld=/usr/bin/ld --with-as=/usr/bin/as
--enable-languages=c
Building (using GNU make) then ends up like this:
if [ -f specs.ready ] ; then \
true; \
else \
echo timestamp specs.ready; \
fi
(MAKE=/usr/local/pkg/bin/gmake; srcdir=`cd
/usr/local/tmp/gcc-3.4.6/gcc/fixinc ${PWDCMD-pwd}` ; \
CC=cc; CFLAGS= -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE;
LDFLAGS=; \
WARN_CFLAGS=; LIBERTY=`${PWDCMD-pwd}`/../libiberty/libiberty.a; \
export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS LIBERTY; \
cd ./fixinc \
/bin/ksh ${srcdir}/mkfixinc.sh mips-sgi-irix5.3 mips-sgi-irix5.3)
constructing ../fixinc.sh for mips-sgi-irix5.3 to run on mips-sgi-irix5.3
/usr/local/pkg/bin/gmake TARGETS=oneprocess SHELL=/bin/tcsh CC=cc CFLAGS=
-g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE LDFLAGS=
LIBERTY=/usr/local/tmp/b/gcc/../libiberty/libiberty.a install-bin
gmake[2]: Entering directory `/usr/local/tmp/b/gcc/fixinc'
/bin/tcsh /usr/local/tmp/gcc-3.4.6/gcc/fixinc/genfixes machname.h
SHELL=/bin/sh: Command not found.
export: Command not found.
if: Expression Syntax.
gmake[2]: *** [machname.h] Error 1
gmake[2]: Leaving directory `/usr/local/tmp/b/gcc/fixinc'
gmake[1]: *** [fixinc.sh] Error 2
gmake[1]: Leaving directory `/usr/local/tmp/b/gcc'
gmake: *** [all-gcc] Error 2
The reason is found in gcc-3.4.6/gcc/fixinc/mkfixinc.sh which has:
defs=SHELL=\$SHELL\ CC=\$CC\ CFLAGS=\$CFLAGS\ LDFLAGS=\$LDFLAGS\
LIBERTY=\$LIBERTY\
SHELL in my case is the shell I started the build from, /bin/tcsh.
The script that gets called later on, gcc-3.4.6/gcc/fixinc/genfixes, assumes a
/bin/sh-compatible shell though.
To work around the issue one can call GNU make with the SHELL set to /bin/sh or
/bin/ksh.
To fix this one might change SHELL=\$SHELL\ into SHELL=\$CONFIG_SHELL\ in
gcc-3.4.6/gcc/fixinc/genfixes, assuming CONFIG_SHELL must necessarily be a
/bin/sh-compatible shell.
--
Summary: bootstrapping fails when building from non-/bin/sh-
compatible shell
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: georg dot schwarz at freenet dot de
GCC build triplet: mips-sgi-irix5.3
GCC host triplet: mips-sgi-irix5.3
GCC target triplet: mips-sgi-irix5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28864
[Bug target/23322] [4.1/4.2 regression] performance regression, possibly related to caching
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-27 18:45 --- We get: .L66: fldl-40(%ebp) faddl (%esi,%eax,8) addl$1, %eax cmpl%edx, %eax fstpl -40(%ebp) jne .L66 Now on the mainline -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug bootstrap/28864] bootstrapping fails when building from non-/bin/sh-compatible shell
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-27 18:50 --- Actually this is a bug in the make version you are using because a SHELL inside make should and will always be a sh-compatible shell. Also this works for me as I use the tcsh as my shell. One more question, since you are using 3.4.6, can you try 4.0.3 instead as 3.4.x is no longer being maintained? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28864
[Bug rtl-optimization/27567] [4.0/4.1/4.2 Regression] __builtin_memcpy generates redundant stores/moves.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-27 18:59 --- Part of the problem here is that 4.0 removed addressof but that does not explain why 3.4.0 could not do this optimization. Maybe one of the problems is that we are no lowering memcpy at the tree level into VCE (which should fix this one issue). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27567
[Bug middle-end/27567] [4.0/4.1/4.2 Regression] __builtin_memcpy generates redundant stores/moves.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-27 19:00 --- For PPC, we get: stw 3,-16(1) stw 3,48(1) nop nop lfs 1,-16(1) blr Notice the extra store, that does not need to be there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|middle-end GCC build triplet|x86-*-linux | GCC host triplet|x86-*-linux | GCC target triplet|x86-*-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27567
[Bug c++/26965] [4.0/4.1/4.2 Regression] Unnecessary debug info for unused consts in C++
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-08-27 19:02 --- I agree with Daniel's comments in Comment #9. The only reliable fix is to commit to unit-at-a-time, always, for all languages, independent of optimization. Then, after we decide what to emit (cgraph), we can know what debugging information to emit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
[Bug bootstrap/28864] bootstrapping fails when building from non-/bin/sh-compatible shell
--- Comment #2 from georg dot schwarz at freenet dot de 2006-08-27 19:04 --- Subject: Re: bootstrapping fails when building from non-/bin/sh-compatible shell Am 27.08.2006 um 20:50 schrieb pinskia at gcc dot gnu dot org: --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-27 18:50 --- Actually this is a bug in the make version you are using because a SHELL inside it's GNU Make 3.81. Is this a known issue, or are you just assuming it's a bug? make should and will always be a sh-compatible shell. Also this works for me as I use the tcsh as my shell. strange. I can easily reproduce the behavior I reported. One more question, since you are using 3.4.6, can you try 4.0.3 instead as 3.4.x is no longer being maintained? I will, but I think there were some other issues that prevented me from boostrapping 4.X on IRIX 5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28864
[Bug tree-optimization/21827] unroll misses simple elimination - works with manual unroll
--- Comment #11 from martsummsw at hotmail dot com 2006-08-27 19:33 ---
You are right =)
I recall I did play with some params in 3.4, but without result but I did
not in 4.0 - since I did not expect a so (in my head) fairly low number to be
large ...
It would be real nice if gcc had an option forceing it to compile both unrolled
and not unrolled versions of known sizes and at last deciding the speed gain
contra the extra used space. In this case with e.g 14 iterations the space is
not even doubled in space however the speed is increased with more than 400%.
(I know gcc cannot know how much faster it is)
The #pragma would also be real nice
I could dream about a pragma with the following behaviour ...
#pragma unroll-next-loop [guess x1,x2,x3]
and if guess was used (for unknown sizes) it expanded for (int u=0;ux;u++)
to
switch(x)
{
case x1:
unrolled x1 times
break;
case x2:
unrolled x2 times
break;
and so on..
default:
not unrolled ...
}
But to be realistic - you probaly have a lot of work and lot of better
suggestions to put into gcc. So maybe this should just be close now.
Thanks for reply! I am sorry I have wasted your time
regards
Thorbjørn
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827
errors cross-compiling for x86_64
I get the following error when building gcc 3.4.6 as a cross compiler for x86_64 on an IA32 box. I searched the crossgcc and gcc-bugs mail archives, but found no reference to a similar problem. Any know whats going wrong here? Both pthread.h and unistd.h are present in /usr/include on the host. /home/tcullen/x86_64-tools/gcc-obj/gcc/xgcc -B/home/tcullen/x86_64-tools/gcc-obj/gcc/ -B/home/tcullen/x86_64-tools/install/x86_64-pc-linux-gnu/bin/ -B/home/tcullen/x86_64-tools/install/x86_64-pc-linux-gnu/lib/ -isystem /home/tcullen/x86_64-tools/install/x86_64-pc-linux-gnu/include -isystem /home/tcullen/x86_64-tools/install/x86_64-pc-linux-gnu/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -DNATIVE_CROSS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-3.4.6/gcc -I../../gcc-3.4.6/gcc/. -I../../gcc-3.4.6/gcc/../include -fexceptions -c ../../gcc-3.4.6/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o In file included from ./gthr-default.h:1, from ../../gcc-3.4.6/gcc/gthr.h:96, from ../../gcc-3.4.6/gcc/unwind-dw2.c:42: ../../gcc-3.4.6/gcc/gthr-posix.h:43:21: pthread.h: No such file or directory ../../gcc-3.4.6/gcc/gthr-posix.h:44:20: unistd.h: No such file or directory __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Bug middle-end/24548] [4.0/4.1 Regression] __builtin_constant_p not resolved with -O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-27 20:18 --- This works for me on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |__builtin_constant_p not|__builtin_constant_p not |resolved with -O2 |resolved with -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24548
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #25 from mmitchel at gcc dot gnu dot org 2006-08-27 20:25 --- Dan Berlin believes that Richard's patch in Comment #20 is the conservative fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #26 from mmitchel at gcc dot gnu dot org 2006-08-27 20:28 --- I don't understand how TBAA is interacting with the may-alias information. In particular, TBAA doesn't say anything about casts; it says something about loads and stores. In particular, TBAA forbids accessing storage of type A through a pointer to type B, given certain constraints on A and B. It does not forbid casting an A* to a B*. Why are the optimizers pruning may-alias sets on casts? Why isn't the fix just to stop them from doing that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #27 from dberlin at gcc dot gnu dot org 2006-08-27 20:51
---
Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
I don't understand how TBAA is interacting with the may-alias information.
Given a pointer, and some aliases, we ask TBAA, for each alias, is it
possible for a load or store of this type to access this variable, of
this other type. We use the results to answer a different question,
is it possible for a call to function foo, which is being passed this
pointer, to access this variable.
In particular, TBAA doesn't say anything about casts; it says something about
loads and stores. In particular, TBAA forbids accessing storage of type A
through a pointer to type B, given certain constraints on A and B. It does
not
forbid casting an A* to a B*.
Correct.
Why are the optimizers pruning may-alias sets on casts?
They are not..
Why isn't the fix just to stop them from doing that?
Because they are not doing that..
If you look at Andrew's complete, reduced, testcase, you will see that
what is happening is that pretty much the same as what will happen
given:
int bar(void)
{
float a;
float *b1;
int *b2;
a = 5.0;
b1 = a;
b2 = (int *)b1;
foo(b2);
}
void foo(int *a)
{
float *b = a;
printf (%f, *b); /* Or some other use of b */
*b = 9.0;
}
I'm going to use clobbering here to mean both mod and ref, because for
our purposes, it doesn't matter.
What happens is that call clobbering is using the may-alias sets to
try to determine call clobbering.
However, the may-alias set of b2 in function bar will *not*
include a, because a dereference of b2 can *not* validly access a
according to TBAA.
Thus, we will claim variable a is *not* clobbered by the call to
foo, because it won't appear in the may-alias set of b2, and we
compute answers to clobbering questions using alias sets. However, it
*is* validly clobbered, because it is casted back to the right type in
foo, and stored into.
The effect of not marking it clobbered in the *actual testcase* (not
above) will be that DCE will delete the initial store, because it
appears entirely local, due to missing that it could be dereferenced
by the call.
This testcase has been failing since we started using may-alias sets
for determining call-clobbering, which is 4.0.
This is just a subtle difference between aliasing and clobbering.
Aliasing asks about stores and loads, Clobbering asks about calls.
In the context of can a load or store to b2 access a (the aliasing
question), the answer is no.
In the context of can the call to foo do something that uses or
modifies our local variable a (the clobbering question) ,the answer
is yes, *even though it can't happen directly through an access to
b2*.
Thus, the correct solution is to compute the sets used to answer the
question what can be read/modified by a call to a function separate
from the sets used to answer the question what can be loaded/stored
by a dereference of this variable.
Since we have never done that before, it does require new code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug target/19923] [4.0/4.1/4.2 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #38 from pinskia at gcc dot gnu dot org 2006-08-27 21:07 --- For the reduced testcase in comment #12, we get: .L2: movl8(%ebp), %edx movl-4(%edx,%ecx,4), %eax movl%eax, (%esi) movl16(%ebp), %edi movzbl -1(%ecx,%edi), %edx movl%edx, 64(%esi) xorl%edx, %eax movl%eax, 128(%esi) movl12(%ebp), %edi movl-4(%edi,%ecx,4), %eax xorl-16(%ebp), %edx xorl[EMAIL PROTECTED](%ebx,%edx,4), %eax movl%eax, -4(%edi,%ecx,4) movl%eax, -16(%ebp) addl$1, %ecx addl$4, %esi cmpl$17, %ecx jne .L2 Does someone know if this ok produced code or not, I never a good reader of x86 code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #28 from dberlin at gcc dot gnu dot org 2006-08-27 21:09 --- Subject: Re: [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered Since we have never done that before, it does require new code. And to answer what may be a followup, which is why hasn't this broken anything else before, it iss because even though the clobbering question and the alias question are subtly different, the answers are almost always the same. It is only because we prune the local answers using TBAAthat we get different answers depending on context. If you exclude strict type-based rules, the answer to what can foo clobber in the example is the same as asking what can the first argument of foo access in foo and its callees. Because of the type-based rules, we end up with a disconnect. It would be undefined to dereference the first argument of foo without casting it first. In effect, the strict-type rules allow you can take an unaliased pointer in a caller, and validly turn it back into an aliased pointer in the callee. In order to account for this, you need to build the sets without accounting for the type-based rules, and if you want to apply the type-based rules to clobbering, use them on a context-sensitive basis (IE at the point of dereference, determine what could be accessed, and propagate that back up through other functions to get the a better clobber answer). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug target/12477] Request to add ability to disable inline/dllimport warnings
--- Comment #14 from dannysmith at users dot sourceforge dot net
2006-08-27 21:14 ---
(In reply to comment #12)
This happens with Qt4 Win32 as well - lot of warnings - warning: inline
function... attribute ignored. All that's needed is a -Wno-inline-dllimport
type of flag to mingw to suppress these warnings.
This is current (gcc-4.2) behaviour.
What exactly is wrong with using -Wno-attributes to suppress the warnings.
Danny
// warn-inline-dllimport.c
__declspec (dllimport) void f1();
// inline definition (silently) overides earlier dllimport declaration
inline void f1() {}
// inline dllimport in definition emits warning
// both can't be true.
inline __declspec (dllimport) void f2 () {}
void b()
{
f1();
f2();
}
compiling as:
gcc -Wall -c warn-inline-dllimport.c
produces:
warn-inline-dllimport.c:8: warning: inline function 'f2' declared as dllimport:
attribute ignored
compiling as:
gcc -Wall -Wno-attributes -c warn-inline-dllimport.c
gets rid of the attribute warning
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12477
[Bug c/27301] [4.0/4.1/4.2 Regression] ICE on convoluted inline asm with m (statement expression and vla)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-27 21:32 --- On the mainline we get a different ICE now: [EMAIL PROTECTED] gcc]$ ~/gcc-local//bin/gcc t.c t.c: In function foo: t.c:4: internal compiler error: in force_constant_size, at gimplify.c:709 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Which showed up with: 2006-06-23 Olivier Hainque [EMAIL PROTECTED] -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i686-linux, x86_64-linux| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27301
[Bug other/28797] Problems with demangling (__cxa_demangle())
--- Comment #8 from ian at gcc dot gnu dot org 2006-08-27 21:43 --- Subject: Bug 28797 Author: ian Date: Sun Aug 27 21:42:55 2006 New Revision: 116493 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116493 Log: PR other/28797 * cp-demangle.c (d_pointer_to_member_type): Do add a substitution for a qualified member which is not a function. * testsuite/demangle-expected: Add test case. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28797
[Bug other/28797] Problems with demangling (__cxa_demangle())
--- Comment #9 from ian at airs dot com 2006-08-27 21:44 --- I'm going to close this PR since I just fixed the only real problem that I see here. If you see other problems with the demangler, please open a separate PR for each problem. Thanks for reporting the bug. -- ian at airs dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28797
[Bug c/28865] New: Structures with a flexible arrray member have wrong .size
For example this C:
struct {int x; int y[];} obj = {1, {2, 3}};
produces this assembly:
.globl obj
.data
.align 4
.type obj, @object
.size obj, 4
obj:
.long 1
.long 2
.long 3
.size should include the flexible array component.
--
Summary: Structures with a flexible arrray member have wrong
.size
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: qrczak at knm dot org dot pl
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=28865
[Bug target/26658] [4.0/4.1/4.2 Regression] memcpy/memset are not inlining with -march=athlon-xp and size of 128
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-27 21:59 --- I bet this comes down to MOVE_RATIO changing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1/4.2 Regression] |perfomance regression |memcpy/memset are not |between gcc 3.4.5 and 4.* |inlining with -march=athlon- ||xp and size of 128 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26658
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
--- Comment #1 from qrczak at knm dot org dot pl 2006-08-27 22:15 --- A question: when this is fixed, what should be C-level sizeof obj? I hope it would include the flexible array component. This would allow to detect in autoconf whether this bug is fixed, and would be consistent with toplevel arrays whose sizes are derived from their initializer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-27 22:32 --- Janis, Can you do a regression hunt on this bug? I almost think it was caused by revision 112408. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Last reconfirmed|2006-05-29 03:07:05 |2006-08-27 22:32:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug fortran/28866] New: [Regression] Simple if statements are not so simple
The following program fails to compile because the commit
noted in the comment broke the processing of a chain of
matchers.
! { dg-do compile }
! Test fix for regression caused by
! 2006-06-23 Steven G. Kargl [EMAIL PROTECTED]
!PR fortran/27981
!* match.c (gfc_match_if): Handle errors in assignment in simple if.
!
module read
integer i, j, k
contains
subroutine a
if (i .eq. 0) read(j,*) k
end subroutine a
end module read
I'm currently testing a patch to fix the problem. Note, this effects only 4.2.
--
Summary: [Regression] Simple if statements are not so simple
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: kargl at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28866
[Bug fortran/28866] [Regression] Simple if statements are not so simple
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-27 22:44 --- Since I have a patch, I might as well confirm the bug. -- kargl 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-08-27 22:44:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28866
[Bug c++/28349] [4.0/4.1/4.2 regression] ICE with undefined va_arg and references
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-27 23:12 --- I have a simple fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28349
[Bug driver/27622] [4.1/4.2 Regression] gcc hang when compiling with -pipe
--- Comment #11 from ian at airs dot com 2006-08-27 23:23 --- I'll take this. -- ian at airs dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ian at airs dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-05-18 05:19:52 |2006-08-27 23:23:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27622
[Bug c++/28349] [4.0/4.1/4.2 regression] ICE with undefined va_arg and references
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-27 23:23 ---
The patch which I am testing:
Index: call.c
===
--- call.c (revision 116493)
+++ call.c (working copy)
@@ -4544,10 +4544,12 @@ build_x_va_arg (tree expr, tree type)
if (! pod_type_p (type))
{
+ /* Remove reference types so we don't ICE later on. */
+ tree type1 = non_reference (type);
/* Undefined behavior [expr.call] 5.2.2/7. */
warning (0, cannot receive objects of non-POD type %q#T through
%...%;
call will abort at runtime, type);
- expr = convert (build_pointer_type (type), null_node);
+ expr = convert (build_pointer_type (type1), null_node);
expr = build2 (COMPOUND_EXPR, TREE_TYPE (expr),
call_builtin_trap (), expr);
expr = build_indirect_ref (expr, NULL);
---
Since we already build a pointer type, we don't need use the reference type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28349
[Bug driver/27622] [4.1/4.2 Regression] gcc hang when compiling with -pipe
--- Comment #12 from ian at gcc dot gnu dot org 2006-08-27 23:50 --- Subject: Bug 27622 Author: ian Date: Sun Aug 27 23:50:30 2006 New Revision: 116494 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116494 Log: PR driver/27622 * pex-common.h (struct pex_funcs): Add toclose parameter to exec_child field. * pex-common.c (pex_run_in_environment): Pass toclose to exec_child. * pex-djgpp.c (pex_djgpp_exec_child): Add toclose parameter. * pex-unix.c (pex_unix_exec_child): Likewise. * pex-msdos.c (pex_msdos_exec_child): Likewise. * pex-win32.c (pex_win32_exec_child): Likewise. Modified: trunk/libiberty/ChangeLog trunk/libiberty/pex-common.c trunk/libiberty/pex-common.h trunk/libiberty/pex-djgpp.c trunk/libiberty/pex-msdos.c trunk/libiberty/pex-unix.c trunk/libiberty/pex-win32.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27622
[Bug driver/27622] [4.1/4.2 Regression] gcc hang when compiling with -pipe
--- Comment #13 from ian at gcc dot gnu dot org 2006-08-28 00:00 --- Subject: Bug 27622 Author: ian Date: Mon Aug 28 00:00:30 2006 New Revision: 116495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116495 Log: PR driver/27622 * pex-common.h (struct pex_funcs): Add toclose parameter to exec_child field. * pex-common.c (pex_run_in_environment): Pass toclose to exec_child. * pex-djgpp.c (pex_djgpp_exec_child): Add toclose parameter. * pex-unix.c (pex_unix_exec_child): Likewise. * pex-msdos.c (pex_msdos_exec_child): Likewise. * pex-win32.c (pex_win32_exec_child): Likewise. Modified: branches/gcc-4_1-branch/libiberty/ChangeLog branches/gcc-4_1-branch/libiberty/pex-common.c branches/gcc-4_1-branch/libiberty/pex-common.h branches/gcc-4_1-branch/libiberty/pex-djgpp.c branches/gcc-4_1-branch/libiberty/pex-msdos.c branches/gcc-4_1-branch/libiberty/pex-unix.c branches/gcc-4_1-branch/libiberty/pex-win32.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27622
[Bug driver/27622] [4.1/4.2 Regression] gcc hang when compiling with -pipe
--- Comment #14 from ian at airs dot com 2006-08-28 00:02 --- Fixed in mainline and 4.1 branch. As far as I can see, the ICE reporting a Broken pipe error can only happen if the gcc driver itself is invoked with SIGPIPE blocked. That is not the normal case. -- ian at airs dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27622
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #14 from bernie at develer dot com 2006-08-28 00:59 --- Please also backport to 4.1 (see #28863). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-08-28 01:38 --- (In reply to comment #14) Please also backport to 4.1 (see #28863). This never existed on 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and non POD
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-08-28 03:04
---
(In reply to comment #6)
An even smaller test case without a member function is:
Even smaller:
struct A
{
A(const A);
A operator=(const A);
};
void f(volatile A *a) { *a; }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-28 03:08 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Known to fail||3.0.4 4.0.0 4.1.0 4.2.0 ||3.3.3 3.2.3 3.4.0 Last reconfirmed|-00-00 00:00:00 |2006-08-28 03:08:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #16 from bernie at develer dot com 2006-08-28 05:05 --- (In reply to comment #15) This never existed on 4.1. gcc 4.1.1 from FC6 crashes with the testcase of bug 28863. Maybe it's some redhat specific patch, but they follow gcc's 4.0-branch quite closely these days: Using built-in specs. 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 20060825 (Red Hat 4.1.1-19) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug tree-optimization/18219] [4.0/4.1/4.2 Regression] bloats code by 31%
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-08-28 05:11 --- New results from the mainline: optionssize -Os 59 -Os -fno-ivopts 52 -Os -ftree-ch 58 -O2 64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-08-28 05:13 --- (In reply to comment #16) (In reply to comment #15) This never existed on 4.1. gcc 4.1.1 from FC6 crashes with the testcase of bug 28863. Maybe it's some redhat specific patch, but they follow gcc's 4.0-branch quite closely these days: And that is Redhat's branch which has the patch which caused this in the first place on it. The FSF's 4.1 never had this bug. Also redhat does not follow the 4.1 branch closely at all, they backport features like crazy still. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug libfortran/28354] 0.99999 printed as 0. instead of 1. by format(f3.0)
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:14 --- Subject: Bug 28354 Author: jvdelisle Date: Mon Aug 28 05:14:05 2006 New Revision: 116502 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116502 Log: 2006-08-27 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/28354 * io/write.c: Check for special case of zero precision in format and pre-round the real value. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug libfortran/28354] 0.99999 printed as 0. instead of 1. by format(f3.0)
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:17 --- Subject: Bug 28354 Author: jvdelisle Date: Mon Aug 28 05:17:09 2006 New Revision: 116503 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116503 Log: 2006-08-27 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/28354 * gfortran.dg/fmt_zero_precision.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_zero_precision.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug libfortran/28354] [4.1 Only] 0.99999 printed as 0. instead of 1. by format(f3.0)
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-08-28 05:18 --- Fixed on 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|0.9 printed as 0. |[4.1 Only] 0.9 printed |instead of 1. by|as 0. instead of 1. by |format(f3.0)|format(f3.0) Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug c++/25868] [4.0/4.1 Regression] Multiple templates and typedefs cause function prototype not to match
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-28 05:19 --- Fixed in 4.2.0 20060827, was broken in 4.2.0 20060823. Janis, Could you run a regression hunt to figure out what fixed this? Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Known to fail|3.4.5 4.0.3 4.1.0 4.2.0 |3.4.5 4.0.3 4.1.0 Known to work|3.3.6 3.3.3 3.2.3 |3.3.6 3.3.3 3.2.3 4.2.0 Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |Multiple templates and |Multiple templates and |typedefs cause function |typedefs cause function |prototype not to match |prototype not to match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug c++/25868] [4.0/4.1 Regression] Multiple templates and typedefs cause function prototype not to match
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-28 05:22 --- (In reply to comment #7) Note I am thinking revision 116409 fixed this but I am not too sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug c++/26102] [4.1/4.2 regression] using Base::member nonsense
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-28 05:25 --- Janis, Could you do a regression hunt on this bug? Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26102
[Bug tree-optimization/23305] [4.0/4.1/4.2 Regression] Inlining related regression for gcc-4.x
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-28 05:47 --- HUH: # D.34332_4 = PHI D.34332_139(7), D.34332_13(6); # first$current$current$current_3 = PHI first$current$current$current_98(7), first$current$current$current_11(6); # first$current$current$current_282 = PHI first$current$current$current_98(7), first$current$current$current_11(6); L10:; first$current$current$current_98 = first$current$current$current_282 + 8B; tmp$current$current_113 = first$current$current$current_3 + 8B; tmp$current_122 = tmp$current$current_113 - 8B; y_134 = tmp$current_122; D.34330_138 = y_134-value; D.34332_139 = D.34332_4 + D.34330_138; if (last$current$current$current_12 != first$current$current$current_98) goto L10; else goto L12; Isn't _3 the same as _282? Why don't we elimitate it? (there is no way not to create it in the first place with this testcase as it is not really created by any pass). I think if we eliminate that, this should be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23305
[Bug tree-optimization/28868] New: Not elimintation the PHIs which have the same agruments
These two functions should produce the same asm but they don't:
int f(int t, int a, int b)
{
int c, d;
if (t)
{
c = a;
d = a;
}
else
{
c = b;
d = b;
}
return c+d;
}
int f1(int t, int a, int b)
{
int c;
c = t?a:b;
return c+c;
}
f1 is better optimized because it has less register pressure than f.
Note this was reduced from a problem in PR23305.
--
Summary: Not elimintation the PHIs which have the same agruments
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: pinskia at gcc dot gnu dot org
OtherBugsDependingO 23305
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug tree-optimization/28868] Not elimintation the PHIs which have the same agruments
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
