--- Comment #2 from agalakhov at ifmlrs dot uran dot ru 2005-11-18 10:19
---
Exactly the same bug has been fixed about a year ago in g95. You may want to
borrow some of its code.
--
agalakhov at ifmlrs dot uran dot ru changed:
What|Removed |Added
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-18 10:31 ---
Subject: Bug 24497
Author: rakdver
Date: Fri Nov 18 10:31:45 2005
New Revision: 107171
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107171
Log:
PR rtl-optimization/24497
* loop-unroll.c
--- Comment #3 from guerby at gcc dot gnu dot org 2005-11-18 11:44 ---
Subject: Bug 24857
Author: guerby
Date: Fri Nov 18 11:44:20 2005
New Revision: 107175
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107175
Log:
2005-11-18 Laurent GUERBY [EMAIL PROTECTED]
PR
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-18 12:40
---
Subject: Bug 24892
Author: fxcoudert
Date: Fri Nov 18 12:40:42 2005
New Revision: 107177
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107177
Log:
PR fortran/20811
PR fortran/24892
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2005-11-18 12:40
---
Subject: Bug 20811
Author: fxcoudert
Date: Fri Nov 18 12:40:42 2005
New Revision: 107177
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107177
Log:
PR fortran/20811
PR fortran/24892
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2005-11-18 12:42
---
This is now fixed on both 4.0 and mainline. Problems underlined in comment #10
fixed too.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-18 12:43
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-18 12:46
---
This regression on 4.1 was introduced by my patch for PR fortran/20811. I fixed
it in revision 107172 (http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00880.html).
Closing this PR accordingly.
--
fxcoudert at gcc
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-11-18 12:47
---
Fixed in revision 107145 (http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00852.html).
Thanks!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-18 12:54
---
I don't see these warnings any more with the current mainline. Can someone
confirms that they disappeared and then close this bug?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-18 12:59 ---
I think that the following patch is the one responsible:
2005-05-15 Andreas Jaeger [EMAIL PROTECTED]
* m4/eoshift1.m4: Initialize variables to avoid warnings.
* m4/eoshift3.m4: Initialize variables
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-18 13:38
---
(In reply to comment #6)
This is near stuff I am working on so I will work it.
This is amazing because I thought I add it fixed some time ago now. I will look
into it too in the train tonight ;-)
--
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-11-18 13:39
---
This has been marked WAITING for some time, and no activity before that.
Closing it, please reopen and attach a testcase if you have one.
--
fxcoudert at gcc dot gnu dot org changed:
What
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-18 13:51
---
I think this can be marked either as WONTFIX or NEW, with severity Enhancement,
but probably not as WAITING. This is something we understand, and we could
theoretically do. We then have to decide whether we want
--- Comment #4 from machata at post dot cz 2005-11-18 14:27 ---
I believe that this patch does the right thing. I've done bootstrap on
i686-pc-linux-gnu, but I won't be able to run testsuite before friday.
Which just passed on i686-pc-linux-gnu.
--
machata at post dot cz changed:
--- Comment #6 from andreast at gcc dot gnu dot org 2005-11-18 14:31
---
On sparc-solaris I get runtime failures:
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
Undefined first referenced^M
symbol in
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-18 14:59 ---
Can you read http://gcc.gnu.org/contribute.html and send the patch to
[EMAIL PROTECTED]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hp at gcc dot gnu dot org 2005-11-18 15:00 ---
No, it's not fixed. What we fixed was a wholly different thing;
a red herring to the problem. See comment #5.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-18 15:20 ---
I should note that
ld.acq+cmpxchg.rel is a full barrier.
as noted in ia64.c so a mf is not required.
See also http://www.ussg.iu.edu/hypermail/linux/kernel/0205.1/0226.html
--
--- Comment #10 from pcarlini at suse dot de 2005-11-18 15:23 ---
(In reply to comment #9)
I should note that
ld.acq+cmpxchg.rel is a full barrier.
as noted in ia64.c so a mf is not required.
Did you read the last message from Alexander on the libstdc++ mailing list, in
particular
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-18 15:24
---
(In reply to comment #9)
I should note that
ld.acq+cmpxchg.rel is a full barrier.
as noted in ia64.c so a mf is not required.
If that is really the issue, then
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-18 15:27
---
(In reply to comment #10)
Did you read the last message from Alexander on the libstdc++ mailing list, in
particular the last paragraph?
Yes but I trust RTH better than Alexander on this issue.
--
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-18 15:29
---
(In reply to comment #12)
Yes but I trust RTH better than Alexander on this issue.
And if you read the message which I pointed to:
The semaphore instructions also have implicit ordering.
So if I am reading this
--- Comment #14 from pcarlini at suse dot de 2005-11-18 15:32 ---
I'm not sure that specific patch is the culprit, because (see Comment #5) the
threaded testcases started failing before that date. I would like to see the
assembly before and after that date. In any case, it would be nice
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-18 15:35
---
See also:
http://www.linuxbase.org/spec/refspecs/IA64-softdevman-vol1.pdf
Page73.
Which is where the comment in comment #13. So If I read table 4-20 currently
then the memory access will always be ordered in
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-18 15:52 ---
I am going to test this on x86_64-linux-gnu except using gen_int_mode instead
of GEN_INT (trunc_int_for_mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-18 16:17 ---
Let's make it WONTFIX then. Even the theoretical possibility of fixing this
probably doesn't exist. Catching this kind of thing is a Very Hard Problem,
it's more something for a static checker or something like
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 16:37 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2005-11-18 17:44 ---
(In reply to comment #2)
Exactly the same bug has been fixed about a year ago in g95. You may want to
borrow some of its code.
gfortran and g95 have diverged to the point that code in g95
is irrelevant. You, of
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24096
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Lots of ICEs in |[4.1 Regression] Lots of
|vrsave_operation_1 while
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24779
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19524
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-18 17:59
---
Subject: Bug 24914
Author: rearnsha
Date: Fri Nov 18 17:59:37 2005
New Revision: 107187
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107187
Log:
PR target/24914
* arm.c
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
I'm writing a tutorial on a HelloWorld compiler front-end for GCC
(http://svn.gna.org/viewcvs/gsc/branches/hello-world/doc/hello.xml) and noticed
that a function with statements but no DECL_SOURCE_FILE set, seg-faults on
cgraph_finalize_function(), because it calls
--- Comment #1 from barbieri at gmail dot com 2005-11-18 18:09 ---
Created an attachment (id=10274)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10274action=view)
gcc-annotate_with_file_line.patch
Fix segfault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24932
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-18 18:17 ---
Actually this should never happen in general. Your front-end really should be
adding locus on the statements.
I will let someone else decide if this is a real middle-end bug or a bug in
your front-end.
I should
--- Comment #22 from dank at kegel dot com 2005-11-18 18:19 ---
We just ran into this trying to link a .a compiled with gcc-3.4.x
against an app using gcc-4.0.1. Unfortunately, the .a is from a third
party, so we can't share it or even look at the source ourselves.
Here are a couple
--- Comment #15 from jason at gcc dot gnu dot org 2005-11-18 18:34 ---
Created an attachment (id=10275)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10275action=view)
Patch to require nesting
I've attached my compiler patch to enforce this rule. It can't go in until the
debug
--- Comment #3 from barbieri at gmail dot com 2005-11-18 18:36 ---
Created an attachment (id=10276)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10276action=view)
gcc-lower_function_body.patch
Alternative patch that also fix seg fault, but earlier.
It's uglier than the previous,
--- Comment #6 from jgoerzen at complete dot org 2005-11-18 19:01 ---
I have completely obliterated every possible GNU ld from the system now, and am
still getting the SEVERE ERROR I posted as the most recent item.
Please note that the 0711-201 means that this is absolutely coming from
--- Comment #3 from ray at ultramarine dot com 2005-11-18 19:30 ---
(In reply to comment #2)
Actually this has already been fixed for 4.0.3 at least:
open ios0
read ios3
buf 1 2 -77 -77
Due to other bugs, I took your advice and
--- Comment #8 from ray at ultramarine dot com 2005-11-18 19:32 ---
(In reply to comment #3)
Subject: Re: GFORTRAN input and carriage returns
On Thu, 17 Nov 2005, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17
The following code results in an error:
namespace Foo { template typename T void foo();}
struct Bar
{
friend void Foo::fooint();
};
The error is:
/home/stefan/friend.cc:4: error: void Foo::foo() should have been declared
inside Foo
I've briefly attempted to debug this. Here are my
--- Comment #9 from geoffk at geoffk dot org 2005-11-18 19:39 ---
Subject: Re: visibility attributes on namespace scope
On 17/11/2005, at 10:15 PM, jason at redhat dot com wrote:
--- Comment #8 from jason at redhat dot com 2005-11-18 06:15
---
Subject: Re: visibility
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-18 19:54
---
Subject: Bug 24914
Author: rearnsha
Date: Fri Nov 18 19:54:41 2005
New Revision: 107189
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107189
Log:
PR target/24914
* arm.c
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-18 20:00 ---
BFD: ../libsupc++/.libs/libsupc++convenience.a(tinfo2.o): Unrecognized storage
can you alsotry to wipe out binutils ar also?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24859
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-18 20:03 ---
(In reply to comment #3)
a.out: relocation error: a.out: undefined symbol: _gfortran_transfer_array
That means your LD_LIBRARY_PATH is finding an old version of libgfortran.
--
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-18 20:05
---
Sometimes when the reload needs to reload an expression that is a subreg
of a wider register, X, into a different class than X it will call
find_valid_class. This routine simply checks whether the class has any
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 20:08 ---
This is a dup of bug 8355.
*** This bug has been marked as a duplicate of 8355 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-18 20:08 ---
*** Bug 24933 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hp at gcc dot gnu dot org 2005-11-18 20:08 ---
Patch at URL:http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01373.html.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ian at airs dot com 2005-11-18 20:13 ---
Created an attachment (id=10277)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10277action=view)
Patch
This patch appears to fix the problem.
However, I am about to leave for the weekend, and won't be back until Monday.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
profilebootstrap with CFLAGS=-O2 BOOT_CFLAGS=-O2 fails with
/tmp/ccloJJLt.s: Assembler messages:
/tmp/ccloJJLt.s:138: Warning: Corrupted unwind info due to unsupported section
switching
/tmp/ccloJJLt.s:747: Internal error!
Assertion failure in ia64_estimate_size_before_relax at
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-18 20:17 ---
Created an attachment (id=10278)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10278action=view)
testcase
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Firefox 1.5 rc3, if compiled with -ftree-vectorize, always crashes on many web
sites e.g. www.ciao.co.uk. see attachment
.mozconfig:
export MOZ_PHOENIX=1
export CFLAGS=-O3 --param max-inline-insns-single=16 --param
max-inline-insns-auto=16 -fno-unswitch-loops -g -pipe -mmmx -msse
-march=pentium3
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-18 20:18 ---
Created an attachment (id=10279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10279action=view)
profile data 1/2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-18 20:19 ---
Created an attachment (id=10280)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10280action=view)
profile data 2/2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
--- Comment #1 from httpsuser at yahoo dot com 2005-11-18 20:19 ---
Created an attachment (id=10281)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10281action=view)
backtrace
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24935
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-18 20:26 ---
There is not enough information here to fix this bug. We need a short testcase
where the bug is?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-18 20:28 ---
Grrr, the testcase was created with some older binutils. Trying to create one
with one that matches the reported error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-18 20:30 ---
I'll do it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
--- Comment #3 from httpsuser at yahoo dot com 2005-11-18 20:38 ---
1. download Firefox source
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5rc3/source/firefox-1.5rc3-source.tar.bz2
2. compile with my .mozconfig
3. run in gdb with firefox -g
4. browse
--- Comment #5 from ray at ultramarine dot com 2005-11-18 20:51 ---
Subject: Re: iostat on read
On Fri, 18 Nov 2005, pinskia at gcc dot gnu dot org wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-18 20:03
---
(In reply to comment #3)
a.out:
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-18 20:59 ---
Created an attachment (id=10282)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10282action=view)
testcase
new testcase. Compile with
stage1/cc1 -fpreprocessed c-lex.i -quiet -dumpbase c-lex.i -auxbase-strip
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-18 20:59 ---
Created an attachment (id=10283)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10283action=view)
profile data 1/2
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-18 21:00 ---
Created an attachment (id=10284)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10284action=view)
profile data 2/2
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-18 21:00 ---
Created an attachment (id=10285)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10285action=view)
wrong assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
--- Comment #9 from rguenth at gcc dot gnu dot org 2005-11-18 21:01 ---
Arguably an as bug, but maybe we should not use -freorder-blocks-and-partition
on ia64 profiledbootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-18 21:02
---
So if -g does not fix it, then this is not related at all to PR 22313.
We should just disable --freorder-blocks-and-partition if gas is unwilling to
support unwind info when the section changes.
See
--- Comment #11 from rguenth at gcc dot gnu dot org 2005-11-18 21:07
---
See http://sources.redhat.com/bugzilla/show_bug.cgi?id=994 for the binutils
bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
--- Comment #4 from joel at gcc dot gnu dot org 2005-11-18 21:16 ---
arm-rtems4.7 now builds. The empty version is used for all RTEMS target.
Thanks.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from tkoenig at gcc dot gnu dot org 2005-11-18 21:17
---
Updated patch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Following code causing the ice in fortran/trans.c at line 152
$ cat test_forall.f90
program test_forall
type element
character(32), pointer :: name
end type element
type(element) :: charts(50)
character(32), target :: names(50)
There are two pieces of code in gnuDynValue that generate unverifiable (and
wrong!) code.
The following method in this file:
public int component_count()
{
return isNull ? 0 : super.component_count();
}
Generates the following byte code:
Method name:component_count public Signature:
--- Comment #16 from rth at gcc dot gnu dot org 2005-11-18 23:32 ---
Alex's explanation can't be all of it. I hacked the compiler to emit two
mf instructions before and after the sequence here, and it made no
difference to the two tests failing. I really have no idea what's going on.
--- Comment #8 from steven at gcc dot gnu dot org 2005-11-18 23:35 ---
I can't reproduce this with r107187.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 23:36 ---
Confirmed, I might had caused this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2005-11-18 23:37 ---
This does in no way block the removal of loop.c. Rather, the (now latent
again) bug would disappear with loop.c if/when we nuke it.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-18 23:38 ---
Here is what the parse tree looks like:
POINTER ASSIGN MAIN__:charts(MAIN__:i) % name MAIN__:names(MAIN__:i)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from pcarlini at suse dot de 2005-11-18 23:41 ---
(In reply to comment #16)
Alex's explanation can't be all of it. I hacked the compiler to emit two
mf instructions before and after the sequence here, and it made no
difference to the two tests failing. I really have
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 23:51 ---
PR 24938 has a little more anaylsis of the problem.
*** This bug has been marked as a duplicate of 24938 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 23:51 ---
*** Bug 24184 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-18 23:52 ---
By the way it was PR 24184 which I closed as a dup of this one since this has
more information.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-19 00:02 ---
(In reply to comment #6)
Btw., this also happens on armv4l compiling NX:
That might be a different bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-19 00:06 ---
The instruction:
(call_insn:HI 361 360 362 32 (set (parallel:DC [
(expr_list:REG_DEP_TRUE (reg:DF 21 xmm0)
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:DF 22
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-19 00:14 ---
Note the shortest (C) testcase get that pattern is:
_Complex double f(void);
void g(void)
{
_Complex double a = f();
}
Though will not cause the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-19 00:14
---
(In reply to comment #1)
The reason of the problem is that the conversion from complex*N to real*M with
N=2M happens only for selected values. The enclosed patch may help.
This patch is OK but I don't quite
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-19 00:32
---
(In reply to comment #8)
I can't reproduce this with r107187.
I cannot reproduce it either with 107184 either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24857
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7030
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8083
--- Comment #18 from rth at gcc dot gnu dot org 2005-11-19 00:56 ---
Dammit, lemme try again; I patched a different tree than I tested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
1 - 100 of 151 matches
Mail list logo
