--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-08-07 07:09
---
*** Bug 45222 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-08-07 07:09
---
*** This bug has been marked as a duplicate of 45206 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
This is a follow-up from PR38819 which partially fixes this problem. The
problem remains in RTL optimization passes, and can be triggered on targets
that implement modulo instruction in the hardware (i.e. moxie-elf).
The testcase from PR38819 compiles with -O2 to:
main:
push $sp, $r6
--- Comment #23 from ubizjak at gmail dot com 2010-08-07 08:26 ---
(In reply to comment #21)
The problem is that this is hard to fix without pessimizing the common case.
The rtl gcse pre issue should be tracked by a different bugzilla report.
Follow up at PR45223.
--
--- Comment #1 from ubizjak at gmail dot com 2010-08-07 08:33 ---
Following patch fixes this problem:
Index: gcse.c
===
--- gcse.c (revision 162975)
+++ gcse.c (working copy)
@@ -1693,7 +1693,7 @@
--- Comment #2 from ubizjak at gmail dot com 2010-08-07 08:40 ---
Ugh, with a bit changed testcase:
--cut here--
extern void exit (int);
extern void abort (void);
volatile float a = 1;
volatile float b = 0;
volatile int x = 2;
volatile signed int r = 8;
void __attribute__((noinline))
--- Comment #6 from dominiq at lps dot ens dot fr 2010-08-07 09:01 ---
It turns out that the test in comment #0 was not fixed by the patch in comment
#5, but by revision 162966. However with the slight change
a(4:23:3) = a(4:22:3)
a temporary is still created. The patch in comment
gcc -O3 -c ice-min.i
ice-min.i:168:39: warning: 'struct vdrive_s' declared inside parameter list
[enabled by default]
ice-min.i:168:39: warning: its scope is only this definition or declaration,
which is probably not what you want [enabled by default]
ice-min.i: In function
--- Comment #1 from moonshine at kapsi dot fi 2010-08-07 09:53 ---
Created an attachment (id=21431)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21431action=view)
delta-reduced testcase
This works on 4.4.4 and fails on trunk, I will test on 4.5 branch as well but
have to build it
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-07 10:22 ---
*** This bug has been marked as a duplicate of 45182 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-07 10:22 ---
*** Bug 45224 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-08-07 10:24 ---
See comment #7, this is a feature, not a bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-07 10:37 ---
I don't see what the bug is here - this is a feature of the C++ standard,
we can't really optimize anything here. 5.2.9/8 ... The null pointer
value is converted to the null pointer value of the destination type.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45220
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-07 10:44 ---
Confirmed.
(gdb) call debug_gimple_stmt ($1)
.MEM_15 = PHI .MEM_19
Program received signal SIGSEGV, Segmentation fault.
0x08384621 in gimple_phi_arg_edge (gs=0xb77611b0, i=0)
at
--- Comment #12 from kirr at landau dot phys dot spbu dot ru 2010-08-07
10:49 ---
Could someone please suggest me what I'm maybe doing wrong?
Because I posted backported patches twice (first time on the mailing list) and
there is always silence on gcc side...
And as it is now, -4.4
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-07 10:57 ---
Patch of comment #1 loops obviously OK to me. We shouldn't want to move
trapping insns in any case that I can think of.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from tkoenig at gcc dot gnu dot org 2010-08-07 11:17 ---
(In reply to comment #6)
Hi Dominique,
It turns out that the test in comment #0 was not fixed by the patch in comment
#5, but by revision 162966. However with the slight change
a(4:23:3) = a(4:22:3)
a
--- Comment #13 from mikael at gcc dot gnu dot org 2010-08-07 11:25 ---
(In reply to comment #12)
Could someone please suggest me what I'm maybe doing wrong?
Nothing wrong. Just ping the patch from time to time ;-).
I've set the target milestone to 4.3.6, so that it may get more
--- Comment #4 from ubizjak at gmail dot com 2010-08-07 11:26 ---
(In reply to comment #3)
Patch of comment #1 loops obviously OK to me. We shouldn't want to move
trapping insns in any case that I can think of.
OK, will post patch to gcc-patches after regression test.
--
ubizjak
--- Comment #5 from china dot wenli dot wang at gmail dot com 2010-08-07
11:38 ---
gfgdsgfsg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1456
--- Comment #9 from mikpe at it dot uu dot se 2010-08-07 11:59 ---
(In reply to comment #8)
As of r162787 bootstrap goes a bit further then fails on compare in
stage3-bubble:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-08-07 12:03
---
Subject: Bug 45143
Author: jvdelisle
Date: Sat Aug 7 12:03:23 2010
New Revision: 162978
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162978
Log:
2010-08-07 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-08-07 12:10
---
Subject: Bug 45143
Author: jvdelisle
Date: Sat Aug 7 12:10:25 2010
New Revision: 162979
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162979
Log:
2010-08-07 Jerry DeLisle jvdeli...@gcc.gnu.org
gcc accepts following code.
Basically, this code specify template arguments to ordinary template parameter
pack(i.e. non template template parameter pack).
// given this primary template
template typename ... Types
class Foo { } ;
// gcc accepts this parcial specialization
// If I use template
--- Comment #1 from boostcpp at gmail dot com 2010-08-07 12:18 ---
I also noticed gcc accept this code.
Should I create separate bug report?
template typename ... Types
class Foo { };
// Params is template parameter.
template typename ... Types, typename Params
class Foo typename
--- Comment #2 from boostcpp at gmail dot com 2010-08-07 12:18 ---
My bad. Never mind.
(In reply to comment #1)
I also noticed gcc accept this code.
Should I create separate bug report?
template typename ... Types
class Foo { };
// Params is template parameter.
template
--- Comment #3 from boostcpp at gmail dot com 2010-08-07 12:25 ---
Come to think of it, It just use primary template.
If I don't write the difinition of primary template, gcc issues error.
template typename ... Types
class Foo ;
But still, I think this template keyword usage in
Dear gnu experts,
I have a question on the GCC version.The followed code is ran succesfully under
one version of GCC,but fail when I use gcc3.4.6.The code is:
#include fstream
int set_output()
{
std::ofstream txt_stream;
char txt_stream_file[400];
int status=0;
--- Comment #14 from kirr at landau dot phys dot spbu dot ru 2010-08-07
13:27 ---
Subject: Re: [4.3/4.4 regression] gfortran does not support -Wp, -MD for *.F
On Sat, Aug 07, 2010 at 11:25:26AM -, mikael at gcc dot gnu dot org wrote:
--- Comment #13 from mikael at gcc dot
--- Comment #8 from dominiq at lps dot ens dot fr 2010-08-07 13:40 ---
the only unnecessary temporary still created with current trunk is your first
example.
Again it is because the lower bound of the section is that or the array, but if
increase it I see
pr44235_1_db.f90:22.14:
--- Comment #4 from boostcpp at gmail dot com 2010-08-07 14:17 ---
It doesn't compile the following code which I think well-formed.
#include tuple
template typename ... Types
class Foo ;
template
template typename ... class ... Types,
typename ... Params
class Foo
--- Comment #13 from rwild at gcc dot gnu dot org 2010-08-07 14:18 ---
(In reply to comment #11)
I encountered that issue with gcc 4.3.4 on the following target:
mips-unknown-linux-uclibc. I'm currently confirming with gcc 4.3.5. If it
still
happen, would it be worth pulling to the
--- Comment #18 from rwild at gcc dot gnu dot org 2010-08-07 14:29 ---
Please do the following for me in your toplevel build directory, thanks:
tar cvf config-logs.tar `find . -name config.log -o -name config.cache`
gzip config-logs.tar
and attach the tarball to this issue.
--
--- Comment #4 from truedfx at gentoo dot org 2010-08-07 14:34 ---
I'm having this problem too, and it's still happening with GCC 4.5. The ml
message suggests that this may be hard to fix, but it looks surprisingly easy:
instead of tracing back via INCLUDED_FROM, simply look at
--- Comment #5 from navin dot kumar at gmail dot com 2010-08-07 15:25
---
Hi Richard,
Your explanation doesn't explain why foo1 would emit poorer assembly than foo3.
Or for that matter why fooA would emit poorer assembly than fooB.
In the case of foo1, foo3, fooA, and fooB,
--- Comment #5 from ubizjak at gmail dot com 2010-08-07 15:27 ---
Patch at [1].
[1] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00553.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2010-08-07 15:43
---
I have the patch for backport to 4.5 applied to my local 4.5 branch and I am
regression testing now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-07 16:19 ---
(In reply to comment #5)
Hi Richard,
Your explanation doesn't explain why foo1 would emit poorer assembly than
foo3.
Or for that matter why fooA would emit poorer assembly than fooB.
In the case of foo1,
--- Comment #7 from navin dot kumar at gmail dot com 2010-08-07 16:22
---
Richard, if you can't derive non-NULL-ness from X y = *x, how do foo3 and fooB
avoid the null check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-08-07 16:25 ---
Which means that if the language guarantees that for
Base2* fooA(Derived* x)
{
Base2 y = *x;
return y;
}
x being a null pointer invokes undefined behavior (because references can't
bind to nothing(?)) then
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-08-07 16:27 ---
(In reply to comment #7)
Richard, if you can't derive non-NULL-ness from X y = *x, how do foo3 and
fooB
avoid the null check?
For both cases the C++ frontend do not emit the NULL check.
--
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-07 16:32
---
Ok...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
I noticed this while doing a coverage enabled build. The libcpp Makefile
doesn't enable the coverage options unlike the code in gcc/*
I think it also does not enable coverage for make profiled-bootstrap
This likely gives some compiler performance away.
--
Summary: libcpp Makefile
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2010-08-07 16:52
---
Subject: Bug 43954
Author: jvdelisle
Date: Sat Aug 7 16:51:55 2010
New Revision: 162980
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162980
Log:
2010-08-07 Daniel Franke franke.dan...@gmail.com
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-08-07 16:52
---
Subject: Bug 31588
Author: jvdelisle
Date: Sat Aug 7 16:51:55 2010
New Revision: 162980
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162980
Log:
2010-08-07 Daniel Franke franke.dan...@gmail.com
--- Comment #7 from dominiq at lps dot ens dot fr 2010-08-07 17:07 ---
I was getting back to this and noticed that we no longer ICE on the original
test case. ...
Still gives an ICE on x86_64-apple-darwin10.4.0 revision 162979.
--
--- Comment #10 from navin dot kumar at gmail dot com 2010-08-07 17:27
---
Richard, correct references in C++ cannot bind to NULL. So gcc should derive
non-NULL-ness when the argument is a reference. It seems to correctly do this
in the case of foo3 and fooB, but fails to do so for
--- Comment #3 from danglin at gcc dot gnu dot org 2010-08-07 17:42 ---
I have been unable to duplicate in several subsequent builds.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-07 18:15 ---
1) GCC 3.4.6 is ancient and no longer supported.
2) Your code is not a self-contained testcase, so noone can compile it.
3) std::ofstream::open does not take a string as the second parameter, it takes
a bitmask of
--- Comment #17 from mikael at gcc dot gnu dot org 2010-08-07 18:18 ---
(In reply to comment #14)
Thanks again. But why 4.3? It's 4.4 and 4.5 which need fixing. 4.3 is
ok. Am I misunderstanding something?
Sorry, my mistake.
Changed accordingly (and according to the fix committed by
--- Comment #18 from kirr at landau dot phys dot spbu dot ru 2010-08-07
18:21 ---
Subject: Re: [4.3/4.4 regression] gfortran does not support -Wp, -MD for *.F
On Sat, Aug 07, 2010 at 04:52:14PM -, jvdelisle at gcc dot gnu dot org
wrote:
--- Comment #16 from jvdelisle at gcc
--- Comment #19 from jvdelisle at verizon dot net 2010-08-07 18:25 ---
Subject: Re: [4.4 regression] gfortran does not support
-Wp, -MD for *.F
Thanks a lot!
Only if you could please also apply the -4.4 version. *Please*
The rationale for this is that 4.4 will be the default
--- Comment #8 from dominiq at lps dot ens dot fr 2010-08-07 18:31 ---
With trunk the ICE is a Segmentation fault and the backtrace is
#0 0x0001417aee0b in __gmpz_sub ()
#1 0x0001000e1c8f in transfer_array_component (expr=0x141f04300,
cm=0x141915170, where=0x141915ca8) at
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-07 18:46 ---
It is caused by revision 162842:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00053.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from danglin at gcc dot gnu dot org 2010-08-07 19:32 ---
Starting program: /home/dave/gnu/gcc-4.6/objdir/gcc/testsuite/g++/test
(2,0)
Breakpoint 2, 0x000109f8 in f (x=...) at test.cxx:12
12 x = 1.0 / x;
(gdb) step
std::operator/double (_...@0xc0246388,
--- Comment #2 from danglin at gcc dot gnu dot org 2010-08-07 19:52 ---
With slightly modified test,
#include complex
#include iostream
void g(std::complexdouble x)
{
std::cout x std::endl;
}
void f(std::complexdouble x)
{
g (x);
x = 1.0 / x;
g (x);
}
int
--- Comment #3 from danglin at gcc dot gnu dot org 2010-08-07 19:58 ---
Richard do you know what's wrong? I think the issue is the return slot
optimization.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mr dot chr dot schmidt at online dot de 2010-08-07
19:58 ---
I am able to reproduce this stack overflow with other source files as well -
even somtimes when compiling without -g .
--
mr dot chr dot schmidt at online dot de changed:
What|Removed
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07
19:59 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong
code for complex division
Attached .ii.
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07
19:59 ---
Created an
--- Comment #5 from mr dot chr dot schmidt at online dot de 2010-08-07
20:00 ---
Created an attachment (id=21433)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21433action=view)
cc1plus invocation commands
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
--- Comment #6 from mr dot chr dot schmidt at online dot de 2010-08-07
20:01 ---
Created an attachment (id=21434)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21434action=view)
gdb backtrace
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
The following program fails to compile:
==
#include tuple
typedef std::tupleint,int,int Tuple;
//typedef std::tupleint,int Tuple;
Tuple A() { return Tuple(); }
const Tuple B() { return Tuple(); }
int main()
{
Tuple
--- Comment #1 from jorrit at jorrit dot de 2010-08-07 20:24 ---
I also reported this to Debian: http://bugs.debian.org/592153
--
jorrit at jorrit dot de changed:
What|Removed |Added
--- Comment #19 from danglin at gcc dot gnu dot org 2010-08-07 20:26
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from uros at gcc dot gnu dot org 2010-08-07 20:32 ---
Subject: Bug 45213
Author: uros
Date: Sat Aug 7 20:32:30 2010
New Revision: 162983
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162983
Log:
PR target/45213
* config/i386/i386.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-07 20:36 ---
The argument should have prevented return slot optimization here.
;; x.1 = std::operator/double (D.24646, x.1); [return slot optimization]
Isn't this fixed on trunk since
2010-07-26 Richard Guenther
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-07 20:39 ---
Btw, does this only happen at -O0? If you adjust the testcase like
#include complex
#include iostream
void __attribute__((noinline))
g(std::complexdouble x)
{
std::cout x std::endl;
}
void
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-08-07 20:40 ---
On i?86-linux I see
bb 2:
g (x);
D.24518 = 1.0e+0;
x = std::operator/double (D.24518, x);
g (x);
so no return-slot optimization. So I guess it has something to do with
the callee-copy thing of the x
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07
20:57 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division
;; x.1 = std::operator/double (D.24646, x.1); [return slot optimization]
Isn't this fixed on trunk since
2010-07-26 Richard
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07
21:00 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division
Btw, does this only happen at -O0? If you adjust the testcase like
No, it also fails at -O2 where the entire computation is
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07
21:04 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division
On i?86-linux I see
bb 2:
g (x);
D.24518 = 1.0e+0;
x = std::operator/double (D.24518, x);
g (x);
so no return-slot
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-08-07 21:10
---
Yes, fixed. I will make a test case out of this with the -Wall so we do not
regress.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-08-07 21:16
---
Ok, I see when gimplifying the call that we mark it for NRV because while
x doesn't have it's address taken it's value-expr has and we didn't replace
it at that point but we check
4262 else if
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07
21:36 ---
Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division
So the following should fix this. Can you bootstrap/test this?
Testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
--- Comment #4 from danglin at gcc dot gnu dot org 2010-08-07 22:04 ---
Appears to be fixed on trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-07 22:19
---
Our std::tuple still needs work, but I see am inconsistency here between the
variadic and the non variadic case which I don't understand, irrespective of
library details. Consider the following reduced
-fPIC -quiet -dumpbase 2412-4.c
-mmacosx-version-min=10.6.4 -mtune=generic -auxbase 2412-4 -O2 -w -version
-fgraphite-identity -o
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccuOxnFJ.s
Reading symbols for shared libraries .. done
GNU C (GCC) version 4.6.0 20100807
-identity -fintrinsic-modules-path
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/finclude -o
bounds_check_strlen_8.s
Reading symbols for shared libraries .. done
GNU Fortran (GCC) version 4.6.0 20100807 (experimental)
(x86_64-apple-darwin10.4.0)
compiled by GNU C
--- Comment #2 from danglin at gcc dot gnu dot org 2010-08-08 01:00 ---
Introduced in revision 162842.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
-version-min=10.6.4 -m32
-mtune=generic -auxbase strncmp-1 -Os -w -version -fgraphite-identity -o
strncmp-1.s
Reading symbols for shared libraries .. done
GNU C (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0)
compiled by GNU C version 4.6.0 20100807
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-08-08
01:56 ---
Created an attachment (id=21435)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21435action=view)
gdb log stepping from sese.c:534 breakpoint until crash
--
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2010-08-08 01:59
---
Subject: Bug 31588
Author: jvdelisle
Date: Sun Aug 8 01:59:15 2010
New Revision: 162990
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162990
Log:
2010-08-07 Daniel Franke franke.dan...@gmail.com
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2010-08-08 01:59
---
Subject: Bug 43954
Author: jvdelisle
Date: Sun Aug 8 01:59:15 2010
New Revision: 162990
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162990
Log:
2010-08-07 Daniel Franke franke.dan...@gmail.com
--- Comment #2 from china dot wenli dot wang at gmail dot com 2010-08-08
02:08 ---
(In reply to comment #1)
1) GCC 3.4.6 is ancient and no longer supported.
2) Your code is not a self-contained testcase, so noone can compile it.
3) std::ofstream::open does not take a string as
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-08 02:17 ---
(In reply to comment #2)
Thank you,yeah,the code is not a self-contained testcase.I copile it with
another codes which not show here.
Yes, but we don't want to see a useless chunk of your program, it doesn't help
.c -mmacosx-version-min=10.6.4 -m32
-mtune=generic -auxbase-strip 941014-2.o -O3 -w -version -fomit-frame-pointer
-fgraphite-identity -o 941014-2.s
Reading symbols for shared libraries .. done
GNU C (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-08-08
03:54 ---
Looking through the remaining ICEs with -fgraphite-identity, the majority seems
to fall into this category.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45229
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2010-08-08 05:29
---
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
91 matches
Mail list logo
