--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-07 09:57 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from uberlord at gentoo dot org 2007-09-07 12:22 ---
Created an attachment (id=14167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14167&action=view)
Always define __sparc64__ if __arch64__
This is patch based on the netbsd-elf.h file and seems to work just file.
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-07 12:13 ---
Btw, is it mandated by the fortran standard to pass a scalar as array
reference?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-07 14:14 ---
Both testcases no longer fail for me on the trunk - do you remember the
revision
you had them reduced on?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
--- Comment #3 from zippel at gcc dot gnu dot org 2007-09-07 14:00 ---
This now fixed on trunk with r128191/r128208.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13021
--- Comment #18 from dominiq at lps dot ens dot fr 2007-09-07 13:49 ---
FX,
Please don't take my comment on the test suite personally.
I think the PR should be resolved as WONTFIX for the reasons you explain and
the test case should fail on the platform on which it fails.
For the m
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-07 12:47
---
(In reply to comment #7)
> Btw, is it mandated by the fortran standard to pass a scalar as array
> reference?
As far as I understand, in this case, it actually is the right thing to do.
--
http://gcc.gnu.org
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-09-07 12:06
---
(In reply to comment #16)
> This way to fix the problem shakes the (little) confidence I have in the test
> suite!
You're, as always, welcome to improve it! (both by submitting code and general
ideas to make it
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-07 11:58 ---
Subject: Bug 0
Author: rguenth
Date: Fri Sep 7 11:57:57 2007
New Revision: 128240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128240
Log:
2007-09-07 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #16 from dominiq at lps dot ens dot fr 2007-09-07 11:42 ---
This way to fix the problem shakes the (little) confidence I have in the test
suite!
Would not it be better to let the tests fail for the mentionned platforms until
a (real) fix is found (as it is done for large_rea
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-07 10:46 ---
Subject: Bug 33321
Author: burnus
Date: Fri Sep 7 10:46:49 2007
New Revision: 128238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128238
Log:
2007-09-07 Tobias Burnus <[EMAIL PROTECTED]>
PR midd
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-07 10:46 ---
Subject: Bug 33321
Author: burnus
Date: Fri Sep 7 10:45:50 2007
New Revision: 128237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128237
Log:
2007-09-07 Tobias Burnus <[EMAIL PROTECTED]>
PR midd
--- Comment #4 from ubizjak at gmail dot com 2007-09-07 10:42 ---
Similar to PR26449, which was _not_ fixed properly (so please don't mark this
one as a duplicate). The problem that was misteriously fixed for one testcase
just resurfaced again. Some info is also in PR32123.
Proposed pat
--- Comment #1 from tbm at cyrius dot com 2007-09-07 14:11 ---
Created an attachment (id=14168)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14168&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[ Forwarded from http://bugs.debian.org/440378 ]
Frank Lichtenheld reported the following bug in gcc from trunk while compiling
the Linux kernel:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O mxb.i
drivers/media/video/mxb.c: In function 'mxb_ioctl':
drivers/media/video/mxb.c:925: error
--- Comment #5 from danglin at gcc dot gnu dot org 2007-09-07 14:57 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00084.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33273
--- Comment #3 from danglin at gcc dot gnu dot org 2007-09-07 14:55 ---
*** This bug has been marked as a duplicate of 33273 ***
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
(Split off from PR 31154.)
The following is accepted but invalid (without using "IMPORT t"):
module x
implicit none
type t
integer :: i
end type t
interface
type(t) function bar()
end function
end interface
end
--
Summary: User-defined type as function result in an inte
Overview
=
When compiling the simple file which is attached to this report, I get the
following message suggesting that I report it here:
compiler_error.cc:18: internal compiler error: in lower_regimplify, at
omp-low.c:4251
Steps to reproduce
Compile the attached file
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64
--- Comment #4 from danglin at gcc dot gnu dot org 2007-09-07 14:55 ---
*** Bug 2 has been marked as a duplicate of this bug. ***
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from steigers at phys dot ethz dot ch 2007-09-07 14:42
---
Created an attachment (id=14170)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14170&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #2 from tbm at cyrius dot com 2007-09-07 14:11 ---
Here's a smaller testcase:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O mxb.c
mxb.c: In function 'mxb_probe':
mxb.c:30: error: unrecognizable insn:
(insn 10 9 11 3 mxb.c:29 (parallel [
(set (mem/s/j/c
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-09-07 14:03
---
I'm closing this as fixed as I don't see the failure any more.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-07 16:16 ---
You are missing a semicolon (;) after the definition of template class RPGVec
and SUCCES is not defined. After I fix those two issues the program compiles.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
#include
#define MEM_COPY(from,to,size) memcpy((to),(from),(size))
#define MEMCOPY(from,to,n_items,type) \
MEM_COPY((char *)(from),(char *)(to),(unsigned)(n_items)*sizeof(type))
template class RPGVec
{
public:
virtual int Copy( RPGVec &Vin);
}
template int RPGVec::Copy( RPGVec &Vin)
{
--- Comment #4 from tromey at gcc dot gnu dot org 2007-09-07 15:26 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from steigers at phys dot ethz dot ch 2007-09-07 14:41
---
Created an attachment (id=14169)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14169&action=view)
Source code which fails to compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-07 10:47 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-07 10:32 ---
Caused bootstrap miscompare on i?86.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-07 10:31 ---
Subject: Bug 32586
Author: rguenth
Date: Fri Sep 7 10:31:09 2007
New Revision: 128236
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128236
Log:
2007-09-07 Richard Guenther <[EMAIL PROTECTED]>
Re
--- Comment #1 from danglin at gcc dot gnu dot org 2007-09-07 16:54 ---
Subject: Bug 33286
Author: danglin
Date: Fri Sep 7 16:54:38 2007
New Revision: 128249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128249
Log:
PR target/33286
* gthr-posix.h (__gthread_act
configure for a FreeBSD/Sparc64 target now forces a default value of ultrasparc
for -mcpu. This means that the default target defines are never used, one of
which is __sparc64__ as needed by a lot of FreeBSD sources. As such, gcc-4
cannot build FreeBSD/Sparc64.
--
Summary: FreeBSD __s
--- Comment #2 from hubicka at gcc dot gnu dot org 2007-09-07 16:05 ---
Apparently it is, it should get out as _U_Qfeq.
I was fixing similar problem yesterday. Perhaps it works now on updated tree?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-07 12:00 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-07 15:54 ---
possibly a fallout of the optabs change?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-07 11:45 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #5 from dorit at gcc dot gnu dot org 2007-09-07 15:00 ---
Subject: Bug 33299
Author: dorit
Date: Fri Sep 7 15:00:11 2007
New Revision: 128242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128242
Log:
PR tree-optimization/33299
* tree-vect-transform.
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-07 10:24 ---
Through this:
else if (ref
&& flag_strict_aliasing
&& TREE_CODE (ref) != INDIRECT_REF
&& !MTAG_P (alias)
&& base
&& (TREE_CODE (base) != INDIRECT_REF
--- Comment #7 from ubizjak at gmail dot com 2007-09-07 10:20 ---
Fixed on mainline.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #6 from uros at gcc dot gnu dot org 2007-09-07 10:18 ---
Subject: Bug 32821
Author: uros
Date: Fri Sep 7 10:17:46 2007
New Revision: 128235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128235
Log:
PR tree-optimization/32821
* tree_if_conv.c (combin
--- Comment #2 from ubizjak at gmail dot com 2007-09-07 09:28 ---
Also ICEs on i686-pc-linux-gnu with -msse2.
The problem is again in:
--cut here--
rtx
expand_simple_binop (enum machine_mode mode, enum rtx_code code, rtx op0,
rtx op1, rtx target, int unsignedp,
--- Comment #2 from danglin at gcc dot gnu dot org 2007-09-07 17:18 ---
Fixed by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from aph at gcc dot gnu dot org 2007-09-07 17:19 ---
Should be fixed now on EABI.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from ebotcazou at gcc dot gnu dot org 2007-09-07 07:08
---
The bug has been fixed by
2005-05-08 Julian Brown <[EMAIL PROTECTED]>
H.J. Lu <[EMAIL PROTECTED]>
Paul Brook <[EMAIL PROTECTED]>
* configure.ac: Set ld_vers_major, ld_vers_mi
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-07 15:02 ---
(In reply to comment #2)
This accept-invalid bug is now tracked as PR4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31154
--- Comment #4 from pcarlini at suse dot de 2007-09-07 17:35 ---
Feedback not forthcoming
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|WAITI
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-07 10:10 ---
We have
Pointed-to sets for pointers in sub0
my_char_ref_1, name memory tag: NMT.30, is dereferenced, points-to vars: {
my_char }
and
Aliased symbols
my_char, UID D.871, char, is addressable, direct reads: 0, di
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-07 10:06 ---
The problem is that DCE2 deletes the my_char = 121; store because aliasing
thinks the array reference doesn't alias the scalar:
;; Function sub0 (sub0)
sub0 ()
{
char[1:1] & my_char_ref;
char D.874;
char my_c
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-09-07 17:54
---
Harold,
As a work around, try putting a LF at the end of the last line of the input
file. I am honing on on this, but don't have it yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
--- Comment #5 from kargl at gcc dot gnu dot org 2007-09-07 16:12 ---
If this is case 2
real x
x = huge(1.0)
x = nearest(x,1.0)
end
and this is case 1
real x
x = nearest(huge(1.0),1.0)
end
then the answers are
> BTW is it normal that gfortran_nearest_r4 (3.4...4e+38, 1
--- Comment #4 from dominiq at lps dot ens dot fr 2007-09-07 08:45 ---
> I think the standard is very clear on that. Quoting F2003 13.7:
> "A program is prohibited from invoking an intrinsic procedure under
> circumstances where a value to be returned in a subroutine argument or
> func
--- Comment #2 from test dot 007 at seznam dot cz 2007-09-07 07:40 ---
(In reply to comment #1)
I'm ashamed.
I still believe the code shouldn't compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33314
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-07 07:33 ---
Subject: Bug 33303
Author: burnus
Date: Fri Sep 7 07:33:26 2007
New Revision: 128229
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128229
Log:
2007-09-07 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-07 07:33 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from raviprakashg at hotmail dot com 2007-09-07 18:40
---
Thank you,
The problem was found to be MEM_COPY was in a different #ifdef loop in my
application that caused the error.
Thank you for your input.
--
raviprakashg at hotmail dot com changed:
What
When I compile the module listed below using the September 6 snapshot version
of gfortran, I get the following message:
c.f90: In function 'local_cum_nc_chisq':
c.f90:15: internal compiler error: in gfc_finish_var_decl, at
fortran/trans-decl.c:510
Please submit a full bug report,
with preprocessed
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-07 18:55 ---
Subject: Bug 32586
Author: rguenth
Date: Fri Sep 7 18:55:15 2007
New Revision: 128251
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128251
Log:
2007-09-07 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-07 18:55 ---
Fixed again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|REO
--- Comment #2 from andreast at gcc dot gnu dot org 2007-09-07 18:59
---
Patch here:
http://gcc.gnu.org/ml/java-patches/2007-q3/msg00235.html
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
-
The GNU gfortran compiler points at the wrong place for the error in a format
when that format is expressed as a literal argument to the FMT keyword in a
READ statement. The message is:
read (11,fmt='(q,a)',end=9) len, rec
1
Warning: Unexpected element in fo
This test
case responds with correct answers for optimization level -O0 but fails at
higher optimization levels. The test case was derived from MPICH2 test
f90_rma/baseattrwinf90.f90 or the corresponding f77_rma/baseattrwinf.f .
> cat bug2867.f90
! Derived from MPICH2 test f90_rma/baseattrwinf90.
> cat bug.ii
void* operator new(unsigned long, void* __p) { }
struct auto_ptr {
int* p;
~auto_ptr() { delete p; }
};
typedef void* T;
struct vector {
void push_back(const T& __x) {
::new(0) T(__x);
insert(__x);
}
void insert
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-09-07 20:16
---
Subject: Bug 33307
Author: jvdelisle
Date: Fri Sep 7 20:16:05 2007
New Revision: 128253
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128253
Log:
2007-09-07 Jerry DeLisle <[EMAIL PROTECTED]>
The following idiom causes unnecessary runtime
overhead:
$ cat compare.f90
function foo(a,b,c,d)
logical :: foo
integer, intent(in):: a,b,c,d
foo = all((/ a, b, c /) /= d)
end function foo
$ gfortran -fdump-tree-optimized -O3 -S compare.f90
The *.optimized file shows
:
D.521 = (int4[0:]
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-09-07 20:23
---
Subject: Bug 33307
Author: jvdelisle
Date: Fri Sep 7 20:23:40 2007
New Revision: 128254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128254
Log:
2007-09-07 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-09-07 20:27
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
St
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
--- Comment #3 from andreast at gcc dot gnu dot org 2007-09-07 20:49
---
Right now all of the targets I test on do not complain anymore about this
failures. So, 'WORKSFORME'
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pda at freeshell dot org 2007-09-07 20:52 ---
Sorry for the long delay in replying, I've been on vacation. I'm giving you
the output from xgcc -v, but have been unable to trap the core dump with gdb.
I even spent some time writing a little program that did the cc1 i
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-07 21:03 ---
(In reply to comment #0)
> > ftn -o x -O2 bug2867.f90
> > aprun -n 1 ./x
> Got incorrect value for WIN_SIZE ( 140733193389056 , should be
>
> 1024 )
> Got wrong value for WIN_DISP_UNIT ( 140733193388036 ,
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341
--- Comment #2 from daney at gcc dot gnu dot org 2007-09-07 21:16 ---
Created an attachment (id=14171)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14171&action=view)
Proposed patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33324
--- Comment #3 from daney at gcc dot gnu dot org 2007-09-07 21:30 ---
I might as well accept the bug as I am testing the fix...
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
---
home/mav/Workspace/Others/boost/boost/xpressive/proto/matches.hpp:409:
internal compiler error: in dependent_type_p, at cp/pt.c:15081
[I'm pressing commit now, I hope I'll have a chance to attach the .ii file and
the full GCC output later]
--
Summary: ICE for gcc version
--- Comment #1 from maurizio dot vitale at polymath-solutions dot com
2007-09-07 21:52 ---
Created an attachment (id=14172)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14172&action=view)
stdout and stderr from gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33342
--- Comment #2 from maurizio dot vitale at polymath-solutions dot com
2007-09-07 21:57 ---
Created an attachment (id=14173)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14173&action=view)
The preprocessed source causing the ICE
file gzipped to comply w/ bugzilla size limits.
-
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-07
22:05 ---
Subject: Re: Segmentation fault bootstrapping on HP-UX 11.11
> As mentioned before, I'm able to bootstrap with HP's compiler, so if this
> information doesn't help you I'll just assume there's a problem wi
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-07 22:33 ---
Confirmed. FRE is guilty:
Replaced D.1654 with ap$p_12(ab) in D.1669_9 = D.1654;
from:
SCC consists of: D.1654_35
Value numbering D.1654_35 stmt = D.1654 = tmp_4;
No store match
Value numbering store D.1654 to tm
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-07 22:33 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
The following invalid program produces an ICE with gfortran (4.3 and 4.2.1).
The program does not ICEs if we replace the invalid line by one of the (valid)
commented lines.
If we don't use automatic arrays (ie we use dimension(length) instead of
dimension(size(vectors)), there is no ICE either.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE for gcc version 4.3.0 |[4.3 Regression] ICE in
|20070907 (experimental
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-09-07 23:50
---
It looks to me that the change I made in Comment #5 was just an optimization;
the warning was already conditionalized on warn_conversion. I just
short-circuited the checking sooner. Declaring the conversion func
Testcase:
struct f { int a; };
int g(struct f *b, struct f *c)
{
struct f g;
if (!b) {
b = &g;
b->a = c->a + 1;
}
else if (!c) {
c = &g;
c->a = b->a + 1;
}
return c->a + b->a;
}
The best way to optimize this is:
struct f { int a; };
int g(struct f *b, struct f *c)
{
i
+FAIL: gcc.c-torture/execute/20030323-1.c compilation, -O2 (internal compiler
error)
+FAIL: gcc.c-torture/execute/20030323-1.c compilation, -O3
-fomit-frame-pointer (internal compiler error)
+FAIL: gcc.c-torture/execute/20030323-1.c compilation, -O3 -g (internal
compiler error)
+FAIL: gcc.c-t
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-08 00:40 ---
Backtrace:
#0 forwarder_block_p (bb=0xf7be) at
/home/apinski/src/local/gcc/gcc/cfganal.c:93
#1 0x10588e48 in update_forwarder_flag (bb=0xf7be) at
/home/apinski/src/local/gcc/gcc/cfgcleanup.c:98
#2 0x1058cb
-FAIL: g++.old-deja/g++.eh/ia64-1.C execution test
+FAIL: g++.old-deja/g++.eh/ia64-1.C (internal compiler error)
+FAIL: g++.old-deja/g++.eh/ia64-1.C (test for excess errors)
+WARNING: g++.old-deja/g++.eh/ia64-1.C compilation failed to produce executable
This showed up between revision 128203 and
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||spu-elf
Summary|[4.3 Regression] g++.old- |[4.3 Regressi
+FAIL: gcc.c-torture/compile/2804-1.c -O3 -fomit-frame-pointer
-funroll-loops (internal compiler error)
+FAIL: gcc.c-torture/compile/2804-1.c -O3 -fomit-frame-pointer
-funroll-loops (test for excess errors)
+FAIL: gcc.c-torture/compile/2804-1.c -O3 -fomit-frame-pointer
-funroll-all
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-08 00:46 ---
ICE:
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/2804-1.c:
In function 'f':^M
/home/apinski/src/local/gcc/gcc/testsuite/gcc.c-torture/compile/2804-1.c:19:
error: invalid rtl sharing found
+FAIL: gfortran.dg/g77/19990826-3.f -O (internal compiler error)
+FAIL: gfortran.dg/g77/19990826-3.f -O (test for excess errors)
This showed up between revision 128118 and 128143.
/home/apinski/src/local/gcc/gcc/testsuite/gfortran.dg/g77/19990826-3.f:319:
error: invalid rtl sharing found in t
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33348
--- Comment #2 from longb at cray dot com 2007-09-08 01:03 ---
Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR
MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
kargl at gcc dot gnu dot org wrote:
> --- Comment #1 from kargl at gcc dot gnu dot org 2007-09-07 21:03 ---
> (In rep
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-08 01:09 ---
This also shows up on powerpc64-linux-gnu.
FAIL: 18_support/numeric_limits/epsilon.cc (test for excess errors)
Excess errors:
/home/apinski/src/local/gcc/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon.cc:39
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-08 01:11 ---
It was fixed between 128118 and 128143 and then showed up again between 128143
and 128201 and still happens as of revision 128251.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pcarlini at suse dot de 2007-09-08 02:08 ---
Jason, could you please have a look to this issue? In my hunt it appeared with
your fix for c++/14032 (r128076). Thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #5 from pcarlini at suse dot de 2007-09-08 02:22 ---
Now the ICE is at line 6586. Can be triggered with this smaller snippet:
struct null_type;
template
struct tuple_impl
{
template
struct append
{
typedef tuple_impl type;
};
int data;
};
template
class tupl
template
__attribute__((always_inline))
static inline void out (unsigned port, T val)
{
asm volatile ("out %0, %w1" : : "a" (val), "Nd" (port));
}
void func (unsigned bits, unsigned val)
{
switch (bits) {
case 8:
out (0x80, static_cast(val));
return;
--- Comment #4 from jason at redhat dot com 2007-09-08 03:52 ---
Subject: Re: [4.3 Regression] ICE in dependent_type_p, at
cp/pt.c:15081
This patch seems to fix the bug, but I haven't had a chance to
regression test it or reduce the testcase, and may not get a chance for
a bit.
Ind
--- Comment #4 from patchapp at dberlin dot org 2007-09-08 05:02 ---
Subject: Bug number PR31154
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00618.html
--
http://gcc.gnu.org/bugzilla/sh
1 - 100 of 105 matches
Mail list logo
