--- Comment #1 from hjl dot tools at gmail dot com 2009-11-27 08:15 ---
It is caused by revision 154667:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00890.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #16 from burnus at gcc dot gnu dot org 2009-11-27 08:29 ---
(In reply to comment #12)
> > Any tricks I have missed?
> Yes - we could provide for loop versioning in the front end.
[...]
> ELSE
>ABORT "M3 MUST NOT BE ZERO"
> ENDIF
Just for completeness a zeroness check is
--- Comment #31 from burnus at gcc dot gnu dot org 2009-11-27 08:32 ---
Crossref: I have opened a follow up PR 42189 as in the review it was stated
that "gfc_is_constant_expr has unacceptable side effects".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
--- Comment #11 from burnus at gcc dot gnu dot org 2009-11-27 08:34 ---
(In reply to comment #10)
> Just a note of appreciation to Chris for reporting this bug and providing a
> simple and extremely useful test case. When I get a moment, I will add Chris
> to the test case as recognitio
--- Comment #39 from jv244 at cam dot ac dot uk 2009-11-27 08:52 ---
I've rerun the initial (non-reduced) testcase at -O0, and I'm getting now more
reasonable memory usage (2.5Gb), and all time is now in 'expand'. 'expand' is
now about 3 times slower than 1year ago, but this is with chec
--- Comment #7 from jv244 at cam dot ac dot uk 2009-11-27 08:55 ---
Time report shows this is now fixed at -O3. Great job!
Execution times (seconds)
garbage collection: 7.60 ( 1%) usr 0.03 ( 0%) sys 7.65 ( 1%) wall
0 kB ( 0%) ggc
callgraph construction: 0.23 ( 0%) us
--- Comment #40 from jv244 at cam dot ac dot uk 2009-11-27 09:00 ---
with the fix for rename registers this now also runs 'fast' at -O3 (see below),
and memory is reasonable as well. Most time is in expand as well. This is the
time report of -O3:
Execution times (seconds)
garbage colle
--- Comment #17 from rguenther at suse dot de 2009-11-27 09:47 ---
Subject: Re: Weird translation of DO loops
On Thu, 26 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
> --- Comment #13 from tkoenig at gcc dot gnu dot org 2009-11-26 21:56
> ---
> Created an attachment (id=1
--- Comment #18 from rguenther at suse dot de 2009-11-27 09:48 ---
Subject: Re: Weird translation of DO loops
On Thu, 26 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
> --- Comment #15 from tkoenig at gcc dot gnu dot org 2009-11-26 23:43
> ---
> (In reply to comment #14)
>
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-27 10:04 ---
I think this change is intentional, as per the resolutions to
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696
and
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23
--
http://gcc.gnu.
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-27 10:22 ---
class IntSize {
public:
IntSize(int width, int height) : m_width(width), m_height(height) { }
int m_width, m_height;
};
class IntPoint {
public:
IntPoint(int x, int y) : m_x(x), m_y(y) { }
int m_x, m_
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Target Milestone|---
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-27 10:24
---
Definitely intentional, yes.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-27 10:25 ---
4.4.2 works.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |middle-end
Keywords||ice-checki
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
http://gcc
--- 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
--- 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 #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 #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 #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 #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 #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 #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
--
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 #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
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
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
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42057
--- 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
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.4.2
Priority|P3 |P1
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42084
--- 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
--- 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 #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 #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
--
--
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 #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
--- 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
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42168
--
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
Keywords||ice-on-valid-code, wrong-
|
--
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
Component|middle-end |tree-optimization
Keywords||ice
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu dot
|
--- 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
--
--- 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: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 #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
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 #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
--- 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 #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 #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 #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 #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 #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
--
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 #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
--- 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 #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
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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
--
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 #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
--- 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 #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 #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:
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
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
--- 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
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
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
--- 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
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 #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...
--- 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 #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 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 #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
1 - 100 of 115 matches
Mail list logo
