--- Comment #8 from vlad at demoninsight dot com 2009-11-28 06:42 ---
I am somewhat unsure about what our best course of action is at this point. Can
we discuss this in gnu forums? Could I help by providing diagnostics?
I'd like to use 4.4.x for its OpenMP support etc in preference to t
--- Comment #1 from zsojka at seznam dot cz 2009-11-28 06:14 ---
Created an attachment (id=19169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19169&action=view)
reduced testcase, comes from gcc sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42205
gcc trunk r154706
command flags: -O1 -ffast-math -floop-interchange
Running on testcase gives:
/mnt/svn/gcc-trunk/binary-154706-lto/bin/gcc -O1 -ffast-math -floop-interchange
-c testcaseN2-min.i -o tmp.o
testcaseN2-min.i: In function ‘adler32’:
testcaseN2-min.i:1:5: error: definition in block 8 do
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-11-28 05:04
---
I missed one regression from the patch in comment #13. Stay tuned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
This bug was previously mentioned in email from Denis. I have confirmed this on
4.5 (after long but educational tour of reload)
http://gcc.gnu.org/ml/gcc/2006-03/msg00783.html
When stacks slots increase from zero in reload() (in my case due to
setup_save_areas() ) the register elimination conditi
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-11-28
02:06 ---
No new failures seen on x86_64-apple-darwin10 at r154715 in the gfortran
testsuite at -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42202
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-11-28 01:46
---
Created an attachment (id=19168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19168&action=view)
Updated patch
This exploratory patch passes all regression tests. I have also successfully
compiled and ru
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-28 01:24 ---
Fixed in 4.5.
a[0] = 0;
a[1] = 1;
memcpy (&b[0], &a[0], 8);
D.8585_1 = b[1];
return D.8585_1;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pogonyshev at gmx dot net 2009-11-28 01:23 ---
Created an attachment (id=19167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19167&action=view)
disassemble results for main()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42203
--- Comment #1 from pogonyshev at gmx dot net 2009-11-28 01:22 ---
Created an attachment (id=19166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19166&action=view)
source code of the program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42203
It seems that even calls to std::copy() with trivially known size are not
inlined. I'm attaching source C++ source file and output of GDB disassemble
command.
Compilation:
g++-4.4 -O3 test3.cpp -o test3
--
Summary: std::copy() results to a call to memmove() and is not
--- Comment #1 from hjl dot tools at gmail dot com 2009-11-28 00:47 ---
It is caused by revision 154688:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00911.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
On Linux/ia64, revision 154697 gave
FAIL: gfortran.dg/alloc_comp_assign_10.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/alloc_comp_assign_10.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
FAIL: gfortran.dg/alloc_comp_assign_2.f
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-27 23:08
---
The issue is pretty simple, actually: std::unique_future (which, by the way,
will be renamed just std::future), is missing move assignment operator. Note,
in N2914 it does *not* exist, has been added only in N3
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-11-27 22:35 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-11-27 22:34 ---
Subject: Bug 42006
Author: jamborm
Date: Fri Nov 27 22:34:40 2009
New Revision: 154715
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154715
Log:
2009-11-27 Martin Jambor
PR middle-end/42006
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-11-27 22:22 ---
Just for the record, this also fails, for similar reasons like the
second testcase above:
union U
{
__complex__ int ci;
__complex__ float cf;
};
float gd;
extern float bar (float, float);
float foo (int b, uni
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-27 22:14 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from lloyd at randombit dot net 2009-11-27 21:39 ---
Created an attachment (id=19165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19165&action=view)
Test case
Here is the full output compiling this on my machine:
$ g++-4.5-20091112 -Wall -W -std=c++0x movable.cpp
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2009-11-27
21:38 ---
In case it helps, a break point on _Unwind_RaiseException () is hit 39 times.
When you continue from the 39th instance of that break point having hit, when
compiling the testme.java test code, you get...
For reasons I do not fully understand, std::vector>'s
push_back fails because it attempts to use the (deleted) copy constructor and
(copying) assignment operator. The std::vector implementation seems to support
move-only objects in C++0x mode, and I don't really see why that is not working
here.
$
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-11-27
21:28 ---
Created an attachment (id=19164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19164&action=view)
complete walk from _Jv_Throw as bz2 archive
Used proposed patch from http://gcc.gnu.org/bugzilla/sho
In the example below f1 and f2 are equivalent functions differing only by the
order of conditions in if(): y && !(x & 1) versus !(x & 1) && y.
There are two lost optimization opportunities here: gcc does not try to pick an
order of conditions which is better, and in both cases it does not use the f
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #1 from pinskia at gmail dot com 2009-11-27 19:12 ---
Subject: Re: New: A problem with -maltivec
Can you attach the preprocessed source for the configure test that is
failing? It looks like the context sensitive keywords is causing the
header to fail to compile.
Sent
Can you attach the preprocessed source for the configure test that is
failing? It looks like the context sensitive keywords is causing the
header to fail to compile.
Sent from my iPhone
On Nov 27, 2009, at 11:00 AM, "galtgendo at o2 dot pl" > wrote:
You'll probably mark this bug as invali
You'll probably mark this bug as invalid,
as it's not my bug and being on x86, I really can't
provide any info.
http://bugs.gentoo.org/show_bug.cgi?id=293899
http://bugs.freedesktop.org/show_bug.cgi?id=25103
As you may see there, a trivial autoconf test was failing
with -maltivec, but even before
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-11-27 18:46 ---
I have started a bootstrap and check of the following (with a testcase
and change log and stuff...) which for some reason fixes this
(renaming introduces the mess, the code as is generated by IPA-SRA is OK):
Index:
--- Comment #6 from danglin at gcc dot gnu dot org 2009-11-27 18:39 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-27 18:31 ---
(In reply to comment #0)
>
> Perhaps -pthread should be implied by -std=c++0x/-std=gnu++0x? (Except at
> least
> nominally one could use std::thread with DCE or Solaris threads, so is
> -pthread
> right anyway?)
-pt
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-11-27 18:23
---
The ARM EABI documentation has now been amended in release 2.08, making GCC's
implementation fully conformant.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
It looks like any use of std::thread compiled in a program without -pthread (or
probably some specific macro set by -pthread, but hard to say as -pthread isn't
really documented to begin with) will crash on the spot. For instance, this
code:
#include
void f() {}
int main()
{
std::thread t
--- Comment #150 from paolo dot carlini at oracle dot com 2009-11-27 16:53
---
*** Bug 42197 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-27 16:53
---
... close as duplicate.
*** This bug has been marked as a duplicate of 21920 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-27 16:52
---
Reopening to...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-27 16:48
---
4.1.x is very old and not maintained anymore. Try something more recent, eg,
4.4.x, and, before reporting anything make sure you are not violating aliasing
rules (double check if the result changes with -fno-st
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-27 16:37
---
Fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo at gcc dot gnu dot org 2009-11-27 16:37 ---
Subject: Bug 38656
Author: paolo
Date: Fri Nov 27 16:36:43 2009
New Revision: 154712
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154712
Log:
cp/
2009-11-27 Paolo Carlini
PR c++/38656
* c
When compiling and executing the little demo program (enclosed) using g++ 4.1.2
on a x86_64 machine it gives differing results when compiled with -O0, -O1
versus -O2, -O3 optimisation flags. I suspect the latter results (with O2, O3)
are wrong.
The same (I think bad) result when tried with g++ 4.
--- Comment #8 from matz at gcc dot gnu dot org 2009-11-27 15:37 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from matz at gcc dot gnu dot org 2009-11-27 15:36 ---
Subject: Bug 42084
Author: matz
Date: Fri Nov 27 15:35:50 2009
New Revision: 154709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154709
Log:
PR rtl-optimization/42084
* cfgexpand.c (maybe_clea
--- Comment #12 from ro at gcc dot gnu dot org 2009-11-27 15:17 ---
Subject: Bug 41810
Author: ro
Date: Fri Nov 27 15:17:04 2009
New Revision: 154708
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154708
Log:
PR target/41810
* gthr-solaris.h (__gthread_mutex_dest
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-27 15:07 ---
Confirmed. This somehow looks like a variant of PR42117. Or of course a
missed folding - though I believe we shouldn't match this big patterns in fold
anymore.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-27 15:02 ---
This is because with GCC 4.3 we properly implement complex arithmetic.
Use -fcx-fortran-rules or -fcx-limited-range for speed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from mrestelli at gmail dot com 2009-11-27 14:45 ---
(In reply to comment #2)
>
> *** This bug has been marked as a duplicate of 41777 ***
>
Sorry! I hit something accidentally on my keyboard, I didn't mean
marking this bug as a duplicate at all...
Apologies!
--
mr
--- Comment #2 from mrestelli at gmail dot com 2009-11-27 14:28 ---
*** This bug has been marked as a duplicate of 41777 ***
--
mrestelli at gmail dot com changed:
What|Removed |Added
--
--- Comment #17 from mrestelli at gmail dot com 2009-11-27 14:28 ---
*** Bug 40850 has been marked as a duplicate of this bug. ***
--
mrestelli at gmail dot com changed:
What|Removed |Added
--
--- Comment #6 from matz at gcc dot gnu dot org 2009-11-27 14:25 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 14:18 ---
This is early IPA-SRA which transforms
:
goto ;
:
p_6.0_3 = (int) p_6_1;
if (p_6.0_3 <= 100)
goto ;
else
goto ;
:
p_6_6 = p_6_1 >> p_6.0_3;
:
# p_6_7 = PHI
if (p_6_7 != 0)
goto ;
else
Not very surprisingly, I get ICEs at tree-sra.c:2148 when compiling
these two examples with the current trunk at -O[123] on x86-64-linux:
==
union U
{
double d;
__complex__ int c;
};
double gd;
extern double bar (union U);
d
--- Comment #4 from matz at gcc dot gnu dot org 2009-11-27 13:26 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
bool xnor_1( bool x, bool y ) { return !( x ^ y ); }
bool xnor_2( bool x, bool y ) { return ( x && y ) || ( !x && !y ); }
both functions should emit (x==y) code, but _2 isn't optimized.
bool xnor_1(bool, bool) (x, y)
{
int D.2085;
:
return x == y;
}
bool xnor_2(bool, bool) (x, y)
{
bool D.
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-27 13:22 ---
int g = 0;
static int
foo(int ui1, int ui2)
{
if (ui2 == 0)
return ui1;
else
return ui1 + ui2;
}
void func_2(long long p)
{
if ((g > p) == (g <= foo(8, (&g != 0
g = 1;
else
g = 2;
}
extern
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-27 13:22 ---
Actually it is some RTL optimization pass that miscompiles this (func_2).
With -fno-delete-null-pointer-checks we defer evaluating &g != 0 until
expansion which then exposes CCP opportunities.
With -O1 -fno-delete-n
--- Comment #3 from matz at gcc dot gnu dot org 2009-11-27 13:09 ---
Subject: Bug 41906
Author: matz
Date: Fri Nov 27 13:08:58 2009
New Revision: 154704
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154704
Log:
PR c++/41906
* tree-eh.c (lower_catch): Stop after
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #30 from mahatma at eu dot by 2009-11-27 12:51 ---
Created an attachment (id=19163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19163&action=view)
(2) for 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
--- Comment #29 from mahatma at eu dot by 2009-11-27 12:49 ---
Created an attachment (id=19162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19162&action=view)
(2) for 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-27 12:49
---
Fixed by my patch for PR35112 in r154698.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #28 from mahatma at eu dot by 2009-11-27 12:45 ---
Yes, I read PR 40838. But last (IMHO) in this thread:
Disabling SSE in whole GCC libs may cause various build problems in SSE-related
-march (mostly with -ffast-math, but IMHO more). So, to use this simple
solution, SSE disa
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-11-27 12:43
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENE
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-27 12:38 ---
With -O1 -fno-move-loop-invariants we get
TOTAL : 83.46 2.1785.63
1650809 kB
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42175
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-27 12:13 ---
At -O2 gcc 4.4 uses about 2.7GB ram and shows:
Execution times (seconds)
df reaching defs : 30.13 ( 6%) usr 7.70 (73%) sys 39.01 ( 8%) wall
0 kB ( 0%) ggc
df live regs : 14.44 ( 3%) usr
I have very simple program which basically does complex matrix convolution
operation.
I am seeing 3 times performance degradation if this program is compiled with
4.3.2 version vs compiled with 4.0.2. I am compiling this program with -O3
option, no additional optimization flags supplied. Also one m
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-11-27 12:00
---
I can't reproduce this with revision 154673. Maybe it is fixed
already? (perhaps by a fix for PR 42151?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 11:58 ---
4.5 shows at -O1:
Execution times (seconds)
garbage collection: 1.66 ( 1%) usr 0.05 ( 0%) sys 1.73 ( 1%) wall
0 kB ( 0%) ggc
callgraph construction: 0.11 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) w
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 11:35 ---
*** Bug 42187 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 11:35 ---
*** This bug has been marked as a duplicate of 42110 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu dot
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |tree-optimization
Keywords||ice
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code, wrong-
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42168
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-27 11:30 ---
Confirmed. The ICE is from verify-ssa after DOM which threads some jumps.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 11:27 ---
Thus invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-27 11:25 ---
Re-confirmed. Might cause wrong-code, so P1 even if ice-checking.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-11-27 11:23
---
I guess this PR should be split further, a bug about the PAREN_EXPR wrt
vectorization and a bug about the yet unanalyzed performance regression.
--
rguenth at gcc dot gnu dot org changed:
What|R
--- Comment #7 from zsojka at seznam dot cz 2009-11-27 11:23 ---
My fault for not using -fgcse-sm in BOOT_CFLAGS. With that, it gets worse:
$ nice -n 19 make -j3 BOOT_CFLAGS="-O2 -fgcse-sm"
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o diff
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-11-27 11:22
---
This is a generic C++ issue; it's not target specific
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42084
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.4.2
Priority|P3 |P1
http://gcc
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 11:20 ---
Is this still an issue?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-27 11:20 ---
P2 for the accepts-invalid, the ICE would have been P5. Please consider
splitting this bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42057
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42054
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-27 11:18 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-27 11:17 ---
Re-confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41988
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-27 11:12 ---
Does this still happen?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
P
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-11-27 11:10
---
Why is this a regression? Does it work with 4.4 and checking enabled?
Does it work with current trunk and release checking?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-27 10:50
---
It is zero, in mainline. I'm not planning to backport anything here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42191
--- Comment #41 from rguenth at gcc dot gnu dot org 2009-11-27 10:50
---
Micha - we still spend most of the time in expand_used_vars even at -O0.
Maybe you want to have a look.
expand: 555.46 (92%) usr 4.88 (77%) sys 579.14 (92%) wall
310089 kB (56%) ggc
integrated
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-27 10:46 ---
Paolo, should int x also be set to zero?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42191
--- Comment #7 from paolo dot carlini at oracle dot com 2009-11-27 10:46
---
Fixed for 4.5.0. Not planning a backport.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo at gcc dot gnu dot org 2009-11-27 10:45 ---
Subject: Bug 35112
Author: paolo
Date: Fri Nov 27 10:44:49 2009
New Revision: 154698
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154698
Log:
/cp
2009-11-27 Paolo Carlini
PR c++/35112
* p
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-27 10:36 ---
I see
umat_single_crystal.f: In function 'umat_single_crystal_':
umat_single_crystal.f:19:0: internal compiler error: in gimple_call_set_arg, at
gimple.h:2088
Please submit a full bug report,
with preprocessed sourc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
http://gcc
1 - 100 of 115 matches
Mail list logo
