--- Comment #48 from developer at sandoe-acoustics dot co dot uk
2009-09-28 07:47 ---
(In reply to comment #47)
(In reply to comment #46)
It bootstraps fine here on x86_64-apple-darwin10 as well.
It does ; but there's an error message about -R not being supported any more
--- Comment #30 from rguenther at suse dot de 2009-09-28 08:41 ---
Subject: Re: [4.5 Regression] r147980 (New SRA)
breaks stdargs
On Sun, 27 Sep 2009, ubizjak at gmail dot com wrote:
--- Comment #29 from ubizjak at gmail dot com 2009-09-27 21:09 ---
(In reply to comment
--- Comment #49 from developer at sandoe-acoustics dot co dot uk
2009-09-28 09:02 ---
(In reply to comment #48)
(In reply to comment #47)
(In reply to comment #46)
It bootstraps fine here on x86_64-apple-darwin10 as well.
It does ; but there's an error message about -R not
--- Comment #3 from paolo dot carlini at oracle dot com 2009-09-28 09:17
---
In any case, the code is invalid, try building (and then running) with
-D_GLIBCXX_DEBUG to see the problem. This way, for example, is fine:
for (; it != mymap.end() ; /* it++ */) {
--- Comment #4 from lifelong830114 at gmail dot com 2009-09-28 09:31
---
(In reply to comment #3)
In any case, the code is invalid, try building (and then running) with
-D_GLIBCXX_DEBUG to see the problem. This way, for example, is fine:
for (; it != mymap.end() ; /* it++ */) {
--- Comment #5 from paolo dot carlini at oracle dot com 2009-09-28 09:39
---
The code is invalid everywhere for the reason you mentioned, on linux just
happens by chance to not segfault.
--
paolo dot carlini at oracle dot com changed:
What|Removed
The cs elim pass introduces a conditional store, but does not remove the
original one. If the former is not removed by DSE, this results in worse code.
original thread: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01955.html.
on machines with no predicated stores, disabling this optimization is
--- Comment #1 from chrbr at gcc dot gnu dot org 2009-09-28 10:53 ---
Created an attachment (id=18665)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18665action=view)
case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41486
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-28 11:07 ---
Confirmed.
Instead of doing a dominator walk to find non-trapping stores the pass
could be restructured to walk the use-def chain of .MEMs and look for
kills unless intervening clobbers (or PHI nodes) occur.
--
--- Comment #4 from jsg at openbsd dot org 2009-09-28 11:09 ---
committed here http://gcc.gnu.org/viewcvs?view=revisionrevision=152218
--
jsg at openbsd dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-28 11:16 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #29 from rguenth at gcc dot gnu dot org 2009-09-28 11:17
---
Can you file a new bug for that issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
With -O3 -ffast-math -funroll-loops -flto -fwhole-program both 453.povray
and 483.xalancbmk ICE with
lto1: internal compiler error: in duplicate_node_data, at ipa-pure-const.c:633
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-28 11:35 ---
For povray we come from ipa-cp:
#2 0x00b8a841 in duplicate_node_data (src=0x7435a400,
dst=0x74345900, data=0x0)
at /space/rguenther/src/svn/lto/gcc/ipa-pure-const.c:633
#3
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-28 11:45 ---
The remaining cases should be
*p = a_1;
...
if (...)
*p = b_2;
where sinking the first store is possible and profitable (it's partially dead)
...
if (...)
*p = b_2;
else
*p = a_1;
which
--- Comment #4 from matz at gcc dot gnu dot org 2009-09-28 12:08 ---
tree-ssa-sink doesn't sink anything with vuses in it, and if that weren't the
case then not any global store. And it isn't totally trivial to make it sink
that. It also doesn't move stuff into the post-dominator (not
Using GCC 4.4.1 release version and compiling the following test with
gcc -O2 -fdump-tree-all
struct struct_t {
int* data;
};
void testAutoIncStruct (struct struct_t* sp, int start, int end) {
int i;
for (i = 0; i+start end; i++)
{
sp-data[i+start] = 0;
}
}
--- Comment #1 from rahul at icerasemi dot com 2009-09-28 12:45 ---
See http://gcc.gnu.org/ml/gcc/2009-09/msg00432.html for some followup.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41488
--- Comment #6 from lifelong830114 at gmail dot com 2009-09-28 12:46
---
(In reply to comment #5)
The code is invalid everywhere for the reason you mentioned, on linux just
happens by chance to not segfault.
Ok, I see.
Thank you very much.
--
lifelong830114 at gmail dot com
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2009-09-28
13:29 ---
This issue of r147995 breaking the darwin unwinder due to the new unwinding
information for the function epilog doesn't occur on Leopard. Leopard's linker
doesn't default to compact unwinding unlike Snow
Gfortran fails to compile the module bug2.f90 with the following error message:
bug2.f90:18.4:
Function REACT ()
1
Error: PUBLIC function 'react' at (1) cannot be of PRIVATE type 'aoi'
The compile command simply was 'gfortran -c bug2.f90'.
gcc -v gives:
Reading specs from
--- Comment #1 from kargl at gcc dot gnu dot org 2009-09-28 14:01 ---
The code compiles with
gcc version 4.4.2 20090924
gcc version 4.5.0 20090918
Please upgrade your compiler to a newer version because it is
unlikely that the patch will be backported to the 4.3 branch.
--
kargl
--- Comment #4 from domob at gcc dot gnu dot org 2009-09-28 14:49 ---
For a basically workig (i.e. without some of the finer details and ugly
corner cases, but handling all I would reasonably expect as user) patch, see
http://gcc.gnu.org/ml/fortran/2009-09/msg00255.html.
--
--- Comment #2 from ros at rzg dot mpg dot de 2009-09-28 14:58 ---
Subject: Re: PUBLIC - PRIVATE conflict
I'm sorry. The error message disapeared when using gfortran 4.5 !
So my bug report is obsolete.
+--+
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-28 15:30 ---
Confirmed. Another way is to move loop header copying before FRE.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
It can't sink stores at all due to some defects. For
int foo(int *a, int r)
{
int ret = 0;
*a = 1;
if (r == 3)
*a = 5;
else
ret = r + 20;
return ret;
}
the store to *a should be sunk into the else block.
Likewise for
int foo(int *a, int r, short *b)
{
int ret = 0;
*a =
--- Comment #2 from hubicka at ucw dot cz 2009-09-28 15:34 ---
Subject: Re: ICE in duplicate_node_data, at ipa-pure-const.c:633
I'd say something is removing a cgraph node without properly calling back
to the node removal hook. Or for some reason we re-use a not freed
UID.
I
--- Comment #6 from hjl dot tools at gmail dot com 2009-09-28 15:48 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from dnovillo at gcc dot gnu dot org 2009-09-28 16:24
---
Should be fixed now. We now test for libelf features during configuration.
Please reopen if it still fails.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rmansfield at qnx dot com 2009-09-28 18:54 ---
Problem still happens with 4.5.0 20090928 (experimental) [lto revision 152240]
(lto merged with rev 150842).
Without the langhooks.c patch -flto is currently unusable/untestable
(ICEs on pretty well everything) for arm
--- Comment #10 from rmansfield at qnx dot com 2009-09-28 18:57 ---
Still happens with gcc version 4.5.0 20090928 (experimental) [lto revision
152240] (lto merged with rev 150842)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40409
of default allocators.
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01987.html
I checked with gcc version 4.5.0 20090928 (experimental) [trunk revision
152246] (GCC).
I didn't test 4.4 but the patch should apply there too, no?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41100
seen while building a powerpc-linux-gnu - spu-elf cross compiler, PR40640
looks similiar, but is closed.
/build/buildd/gcc-snapshot-20090923/build/gcc/xgcc
-B/build/buildd/gcc-snapshot-20090923/build/gcc/ -c -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-28 19:13 ---
What version of GCC is being used to compile the new version of GCC?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
--- Comment #2 from doko at ubuntu dot com 2009-09-28 19:16 ---
it's a native powerpc-linux-gnu compiler, biarch, defaulting to 32bit, built
from the same sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
--- Comment #3 from rmansfield at qnx dot com 2009-09-28 19:39 ---
ICE no longer happens with gcc version 4.5.0 20090928 (experimental) [lto
revision 152240] (lto merged with rev 150842)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41173
I have a file that I would like to be able to either execute with a C
interpreter, or compile with GCC.
As you know, Unix uses #!/path/to/interpreter to invoke scripts. Consider
the following program:
#!/usr/bin/c-interpreter
int main() { printf(Hello World\n); }
It would be nice if this could
--- Comment #2 from tobi at gcc dot gnu dot org 2009-09-28 19:58 ---
The way usually recommended is to use a struct for interoperability with
Fortran common blocks, say http://support.microsoft.com/kb/51614
Unfortunately, the idiom use a single variable common block, say common/x/y,
--- Comment #3 from burnus at gcc dot gnu dot org 2009-09-28 20:02 ---
For completeness: I think it was fixed as part of PR 39800.
The compile command simply was 'gfortran -c bug2.f90'.
gcc -v gives
You should have used gfortran -v instead. The 3.3.4 output won't help as
gfortran
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-09-28 20:11 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 41476
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #11 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 40758
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #9 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 41347
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #20 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 41242
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #8 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 41295
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #5 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 41470
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #6 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 40642
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #7 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 41248
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #20 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 41212
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #9 from hjl at gcc dot gnu dot org 2009-09-28 20:39 ---
Subject: Bug 41275
Author: hjl
Date: Mon Sep 28 20:38:53 2009
New Revision: 152250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152250
Log:
2009-09-28 H.J. Lu hongjiu...@intel.com
Backport from
sparc-rtems4.10-gcc (GCC) 4.5.0 20090928 (experimental) [trunk revision 152239]
Test ran as of r151936.
,.,. C34006G ACATS 2.5 88-01-01 00:00:00
C34006G CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED
(IMPLICITLY) FOR DERIVED RECORD TYPES WITHOUT
--- Comment #11 from ian at gcc dot gnu dot org 2009-09-28 21:23 ---
Subject: Bug 40500
Author: ian
Date: Mon Sep 28 21:23:35 2009
New Revision: 152252
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152252
Log:
PR middle-end/40500
* c-opts.c
--- Comment #12 from ian at airs dot com 2009-09-28 21:30 ---
-Wall no longer implies -Wjump-misses-init.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-09-28 21:37 ---
Hmm, this is harder than I thought it would be. The issue is we have only one
labelref but really two label.
I don't know if we can support this with the way cloning is done ...
--
--- Comment #16 from hainque at gcc dot gnu dot org 2009-09-28 21:56
---
Subject: Bug 41100
Author: hainque
Date: Mon Sep 28 21:55:54 2009
New Revision: 152255
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152255
Log:
PR ada/41100
ada/
*
--- Comment #17 from hainque at adacore dot com 2009-09-28 22:07 ---
I checked with gcc version 4.5.0 20090928 (experimental) [trunk revision
152246] (GCC).
I didn't test 4.4 but the patch should apply there too, no?
Yes, and I just applied it. This is not a fullproof resolution
The following is causing a 7% degradation on cpu2000 benchmark 191.fma3d. The
problem was introduced somewhere between revisions 151544 and 151586.
Compile the following with -m32 -O2.
MODULE force_
TYPE :: force_type
The docs says that you can configure libstdc++ with
--enable-clocale=ieee_1003.1-2001. However, this fails in mainline because
_GLIBCXX_NUM_CATEGORIES is only defined for the generic and gnu locales.
See http://gcc.gnu.org/ml/libstdc++/2009-09/msg00091.html .
--
Summary: libstdc++
--- Comment #1 from rmansfield at qnx dot com 2009-09-29 01:44 ---
This appears to be fixed in gcc version 4.5.0 20090928 (experimental) [lto
revision 152240] (lto merged with rev 150842)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41390
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-09-29 02:44
---
Subject: Bug 35862
Author: jvdelisle
Date: Tue Sep 29 02:44:38 2009
New Revision: 152262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152262
Log:
2009-09-28 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-09-29 02:48
---
Subject: Bug 35862
Author: jvdelisle
Date: Tue Sep 29 02:47:54 2009
New Revision: 152263
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152263
Log:
2009-09-28 Jerry DeLisle jvdeli...@gcc.gnu.org
On Linux/x86-64, revision 152251 gave:
FAIL: g++.dg/conversion/dr195.C (test for warnings, line 21)
FAIL: g++.dg/conversion/dr195.C (test for warnings, line 21)
FAIL: g++.dg/conversion/dr195.C (test for warnings, line 22)
FAIL: g++.dg/conversion/dr195.C (test for warnings, line 22)
FAIL:
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-09-29 02:51
---
Subject: Bug 35862
Author: jvdelisle
Date: Tue Sep 29 02:50:48 2009
New Revision: 152264
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152264
Log:
2009-09-28 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-29 03:00 ---
Confirmed.
Patches goto gcc-patc...@gcc.gnu.org after a bootstrap and test with a complete
changelog.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-29 03:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
It looks wrong at -Os. The compiler is valgrind-clean at that level.
reg...@john-home:~/volatile/tmp200$ current-gcc -O small.c -o small
reg...@john-home:~/volatile/tmp200$ ./small
checksum = -13
reg...@john-home:~/volatile/tmp200$ current-gcc -Os small.c -o small
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2009-09-29 05:05
---
Thank you Olivier.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-09-29 05:50 ---
PowerPC has the same issue. Instructions on PPC are all the same size so 3
adds are better than one add plus 3 register moves.
Here is a C example:
int f(int *a);
int g(int *a);
int h(int *a);
void hh(void)
{
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-09-29 05:51 ---
Before CSE:
(insn 13 2 5 2 t.c:8 (set (reg:SI 119)
(plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8]))) -1 (nil))
(insn 5 13 6 2 t.c:8 (set (reg:SI 3 3)
(reg:SI 119)) 332 {*movsi_internal1}
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-29 05:54 ---
gfortran 4.5 has:
struct force_type D.1375;
force_type.0.xext = 0.0;
[...]
D.1375 = force_type.0;
(*(struct force_type[0:] * restrict)
71 matches
Mail list logo
