Please look at the interesting behavior of gcc
//a.c
int main(void)
{
print("Hello world\n");
return 0;
}
//header.h
#include
void print(char *);
void print(char *s)
{
printf("%s",s);
}
[r...@localhost JAVA]# gcc a.c -include header.h
[r...@lo
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-02-14
02:12 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00532.html and
testsuite resuilts for proposed patch at
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01258.html.
--
http://gcc.gnu.or
--- Comment #13 from joseph at codesourcery dot com 2010-02-14 02:07
---
Subject: Re: libstdc++ testing does not work remotely
Given the right board file and site.exp, installed libstdc++ testing works
fine for both remote host and remote target (modulo one installed testing
bug: bu
--- Comment #12 from hjl dot tools at gmail dot com 2010-02-14 01:21
---
It is caused by revision 132242:
http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00254.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-14 00:07 ---
User prefetches should never be scheduled. Andreas Krebbel posted a patch
towards that (http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00130.html) but he
hasn't followed up on it, so far.
Of course, in very rare corner
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-13 23:55
---
Any progress on this? Should be really kept open after almost 6 years of
inactivity? Thanks for any update.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15047
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-13 23:45
---
I gather that SUN fixed this problem more than 2 years ago, in Solaris 10
Update 4, see eg:
http://blogs.sun.com/mandalika/entry/solaris_workaround_to_stdio_s
Given that, I'm going to mark this as WONTFIX for
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-13 23:29 ---
This is a gem, the scheduler attempts to schedule the prefetch *after* the
return.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
--- Comment #1 from steven at gcc dot gnu dot org 2010-02-13 23:18 ---
Breakpoint 7, rest_of_handle_sched2 () at ../../trunk/gcc/sched-rgn.c:3534
3534 && ! maybe_skip_selective_scheduling ())
(gdb) p brief_dump_cfg(stderr)
Basic block 2 (reachable, rtl)
Predecessors: ENTRY [100
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #4 from jv244 at cam dot ac dot uk 2010-02-13 21:14 ---
mv 'Build' to 'CC' , Paul, please see previous comment.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
-
--- Comment #3 from jv244 at cam dot ac dot uk 2010-02-13 21:13 ---
testing Paul's patch (http://gcc.gnu.org/ml/fortran/2010-02/msg00093.html) on
CP2K it further halved the number of pack/unpacks. However, some cases still
unexpectedly resulted in a pack. A slightly modified version of t
--- Comment #6 from mikpe at it dot uu dot se 2010-02-13 20:49 ---
A bisection through the binutils weekly and daily snapshots has identified
090505 as the last good snapshot and 090506 as the first bad one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-13 19:56 ---
Of course we'll blow up during var-tracking from within define_functions
anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-13 19:38 ---
With that we get the much more sane
Deciding on functions called once:
Considering define_strings size 840.
Called once from Init_libxg 37 insns.
Inlined into Init_libxg which now has 876 size for a net change of
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-13 19:25 ---
limit += limit * PARAM_VALUE (PARAM_LARGE_FUNCTION_GROWTH) / 100;
/* Check the size after inlining against the function limits. But allow
the function to shrink if it went over the limits by forced inlinin
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-13 19:12 ---
Indeed. After IPA-inline we have:
Init_libxg/4659(4659) @0x7fffef076138 availability:available 65 time, 10
benefit (112338 after inlining) 37 size, 1 benefit (89974 after inlining)
needed reachable body externally_
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-13 19:06 ---
Created an attachment (id=19859)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19859&action=view)
testcase from snd
Testcase from snd.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
/usr/lib64/gcc/x86_64-suse-linux/4.5/cc1 -m32 -fpreprocessed xg.i -quiet
-dumpbase xg.c -mtune=generic -march=i586 -auxbase xg -g -O2 -O2 -Wall -version
-fomit-frame-pointer -fmessage-length=0 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -fno-strict-aliasing -o xg.s --param
ggc-mi
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-02-13
16:04 ---
This alternative fix works as well...
--- /Users/howarth/gcc-4.5-20100211/gcc/varasm.c2010-01-20
18:46:25.0 -0500
+++ gcc/varasm.c2010-02-13 10:58:45.0 -0500
@@ -2345,7 +23
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-02-13
15:41 ---
This should probably be a P2 since it causes a regression on darwin which
breaks their weak linking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-02-13 14:51
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-02-13 14:51
---
Subject: Bug 42871
Author: rguenth
Date: Sat Feb 13 14:50:50 2010
New Revision: 156750
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156750
Log:
2010-02-13 Richard Guenther
PR tree-optimizatio
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-13
14:29 ---
Created an attachment (id=19858)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19858&action=view)
Testcase
gcc -O -flto bug.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43057
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-13
14:27 ---
Created an attachment (id=19857)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19857&action=view)
Backtrace
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43057
GCC 4.5.0 20100211. Configured with --enable-languages=c --enable-checking=all
--disable-bootstrap.
--
Summary: [LTO] fold check: original tree changed by fold
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priori
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-13 13:40
---
typedef char T6[2][4 + 4];
typedef unsigned char _CORBA_Char;
class _CORBA_String_member { };
typedef _CORBA_Char Char;
typedef _CORBA_String_member String_member;
typedef String_member st_1d_t[2];
typedef String_m
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-02-13 13:31
---
(In reply to comment #14)
> (In reply to comment #13)
> > Exactly as I thought. There is/was an unwinding problem with made garbage
> > collection break, there is a glibc fix available or an unwinder fix in gcc
>
Command line:
gcc -O1 -fschedule-insns2 -fsched2-use-superblocks -c testcase.c
testcase.c
int x[1];
void foo()
{
__builtin_prefetch(x);
}
Tested revisions:
trunk r156745 - crash
trunk r153685 - crash
4.4 r156256 - crash
4.4 r155365 - OK (no checkin
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-13 12:44 ---
Re. comment #12, if you mean the extra BB3, that one is not really "extra", it
comes from loop header copying, and it easy to clean up. I assume ifcvt cleans
this up?
Re. comment #12, yes that is expected, but most
--- Comment #3 from pault at gcc dot gnu dot org 2010-02-13 12:43 ---
Subject: Bug 41117
Author: pault
Date: Sat Feb 13 12:42:39 2010
New Revision: 156749
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156749
Log:
2010-02-13 Paul Thomas
PR fortran/41113
PR fo
--- Comment #17 from pault at gcc dot gnu dot org 2010-02-13 12:43 ---
Subject: Bug 41113
Author: pault
Date: Sat Feb 13 12:42:39 2010
New Revision: 156749
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156749
Log:
2010-02-13 Paul Thomas
PR fortran/41113
PR f
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-02-13 12:19
---
But it has a load of fallout already in the gcc.dg/tree-ssa testsuite parts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-02-13 12:18
---
Yep.
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 15)
+++ tree-ssa-dom.c (working copy)
@@ -1455,8 +1455,7 @@ cprop_into_succ
--- Comment #11 from rguenther at suse dot de 2010-02-13 12:07 ---
Subject: Re: [4.5 Regression] gcc.target/mips/octeon-bbit-2.c
failing for -mabi=64
On Sat, 13 Feb 2010, steven at gcc dot gnu dot org wrote:
>
>
> --- Comment #10 from steven at gcc dot gnu dot org 2010-02-13 1
--- Comment #14 from mikpe at it dot uu dot se 2010-02-13 11:52 ---
(In reply to comment #13)
> Exactly as I thought. There is/was an unwinding problem with made garbage
> collection break, there is a glibc fix available or an unwinder fix in gcc
> 4.4.
> Your distributor didn't pick u
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-13 11:39 ---
In the test case of comment #2, the history of the funny PHIs is really odd. At
-O2 we end with this in the .optimized dump:
:
# i_1 = PHI <0(2)>
# s_11 = PHI <0(2)>
:
# i_12 = PHI
# s_13 = PHI
But the
--- Comment #9 from steven at gcc dot gnu dot org 2010-02-13 11:28 ---
Re. comment #8: No other compiler, I have ever seen, allows constants as PHI
args.
Single-argument PHIs should be propagated out. Do you see this in one of the
loop passes, then it's OK because they are probably ther
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-02-13 10:58
---
(In reply to comment #12)
> I upgraded all gcc components to 4.4.3 (before I upgraded only java parts) and
> it works fine. I downgraded to 4.3.3 and put only libgcc_s.so.1 from gcc 4.4.3
> and it works fine. So, t
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-02-13 10:48
---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-13 10:45 ---
Confirmed.
We loop in
0x0823fa53 in cp_build_qualified_type_real (type=0xb39cbf70, type_quals=1,
complain=7) at /home/richard/src/gcc-4_4-branch/gcc/cp/tree.c:781
781 for (t = TYPE_MAIN_VARIANT (type
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-13 10:35 ---
Program received signal SIGSEGV, Segmentation fault.
0x08158cf6 in coverage_checksum_string (chksum=0, string=0x0)
at /home/richard/src/trunk/gcc/coverage.c:484
484 for (i = 0; string[i]; i++)
Looks like t
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-13 10:32 ---
Also fails for me with 4.3 and trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from lucabon at interfree dot it 2010-02-13 10:28 ---
I upgraded all gcc components to 4.4.3 (before I upgraded only java parts) and
it works fine. I downgraded to 4.3.3 and put only libgcc_s.so.1 from gcc 4.4.3
and it works fine. So, the problem was in libgcc_s and it wa
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-02-13 10:23
---
(In reply to comment #21)
> (In reply to comment #20)
> > What is the plan for this bug, fix it for GCC 4.5.0 or for later?
>
> I don't really think I can argue that this is stage3 material, so the plan is
> to fi
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-02-13 10:23
---
To optimize
void foo() {
extern int a;
if(++a) ++a;
}
we need to have partial dead store elimination, basically sink the store
to after the condition:
void bar() {
extern int a;
int tmp =
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-13 10:11 ---
(In reply to comment #3)
> Basically yet another example of why it is a REALLY BAD IDEA to use constants
> as PHI arguments. If the constant from "s =0" would not be propagated into the
> PHI, the statement would not
--- Comment #15 from jwillemsen at remedy dot nl 2010-02-13 10:03 ---
After doing a yum update on FC12 we found that FC12 now also has gcc 4.4.3-4
which also has this bug when compiling ACE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
49 matches
Mail list logo
