--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-18 08:37 ---
> It's 64-bit only, and it appears to be a glibc bug: with glibc on x86_64,
> sinf((float) integer_variable) is slower than (float)sin((double)
> integer_variable).
Can it be that it has been fixed meanwhile? Using d
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-11-18 08:46
---
> The compiler is refusing to see the usage of labels as addresses in other
> places than "goto"s. I think you call this "design". But one cant expect
> the code to produce different results with "optimization"
The following program should print
12
-14.000
but gfortran rejects it with
Error: Contained function 'master.0.func' at (1) has no IMPLICIT type
It fails with GCC 4.1.3, 4.2.1 and 4.3.0 with:
end module m
1
Error: Contained function 'master.0.func' at (1) has no IMPLICIT type
With current trunk on sparc:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O3 busybox-ash.c
busybox-ash.c: In function 'dotcmd':
busybox-ash.c:15: error: found real variable when subvariables should have
appeared
while verifying SSA_NAME shellparam_17 in statement
# shellparam_17 = VDEF
--- Comment #1 from tbm at cyrius dot com 2007-11-18 10:15 ---
Created an attachment (id=14574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14574&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34138
--- Comment #2 from tbm at cyrius dot com 2007-11-18 10:16 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
extern void free (void *__ptr);
struct shparam
{
char **p;
};
static struct shparam shellparam;
void freeparam (volatile struct shparam *param, char **ap)
{
free ((v
--- Comment #9 from kkojima at gcc dot gnu dot org 2007-11-18 10:27 ---
> is that copysignl?
Since the size of long double is 8 for -m2e, copysignl would be.
I think that fortran has no real use on such "short double"
targets, though. I'm inclined to make fortran unsupported
for SH t
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-18 10:37 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #1 from dominiq at lps dot ens dot fr 2007-11-18 10:18 ---
I have applied the patch at
http://gcc.gnu.org/ml/fortran/2007-08/msg00142.html and the warnings have
disappeared without introducing any visible regression (Intel Darwin9.1).
--
http://gcc.gnu.org/bugzilla/show
gfortran.dg/subref_array_pointer_2.f90 fails on Intel Darwin9 at all level of
optimization. The following reduced case shows the origin of the problem:
! { dg-do run }
! Test the fix for PRs29396, 29606, 30625 and 30871, in which pointers
! to arrays with subreferences did not work.
!
type :: t
--- Comment #1 from tbm at cyrius dot com 2007-11-18 11:20 ---
Created an attachment (id=14575)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14575&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34140
With current trunk. This was introduced between 20070916 and 20071020.
(sid)1687:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3 -Wall
gnubg-rollout.c
gnubg-rollout.c: In function 'RolloutGeneral':
gnubg-rollout.c:15: internal compiler error: in is_hidden_global_store, at
tree-ssa-sink
--- Comment #2 from tbm at cyrius dot com 2007-11-18 11:20 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
typedef struct
{
unsigned int fCubeful;
}
evalcontext;
typedef struct
{
evalcontext aec[2];
unsigned int fCubeful:1;
}
rolloutcontext;
void RolloutGeneral (int alt
gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel
Darwin9 at all level of optimization. The following reduced test case shows the
origin of the failure (EXPONENT for real(4), but not for real(8)):
!Program to test SET_EXPONENT intrinsic function.
real*4 x,y
integer*4
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-18 12:50 ---
Whoops, sorry. Reduced testcase:
static void
whichtable(char **pfmt)
{
--*pfmt;
}
void prepare_s(const char *fmt)
{
whichtable((char **)&fmt);
}
./cc1 -quiet -O t2.i
t2.i: In function 'prepare_s':
t2.i:7: int
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-18 13:53 ---
Hm, this is an unlucky case because of the way fold_stmt works. What we have
is
(even more simplified):
void prepare_s(const char *fmt)
{
char ** f = (char **)&fmt;
*f = 0;
}
where it is not hard to see that f
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-11-18 14:15 ---
On further reading into the standard, I believe GCC is doing the right thing.
8.5.3p5 is very specific in saying that one can only bind a reference to an
rvalue if the type of the rvalue is of class type. Otherwise,
--- Comment #5 from george at gly dot bris dot ac dot uk 2007-11-18 14:56
---
I submitted a patch that causes debug info for identifiers in COMMON to be
emitted with DW_TAG_common_block. See
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00311.html
--
george at gly dot bris dot ac d
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-18 14:44 ---
Confirmed. Called from tree_ssa_dce_loop ().
# VUSE { rc }
# rc_45 = VDEF { rc }
rc_45 = D.1197_49 != 0 ? rc_47 : rc_47
WTF? tree if-conversion generates this crap.
--
rguenth at gcc dot gnu dot org changed
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-18 14:37 ---
Confirmed. Also happens on i686.
verify_ssa is after PRE in function dotcmd. -O2 is enough to trigger the
failure if you mark freeparam inline.
--
rguenth at gcc dot gnu dot org changed:
What|R
--- Comment #11 from sparc64 at rediffmail dot com 2007-11-18 14:44 ---
> I agree that we should clarify the documentation if we definitely rule the
> code as being invalid.
Since "&&" is a C extension, I believe one can reserve the right to limit how
long it extends. But this limitatio
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-18 15:50 ---
Subject: Bug 34127
Author: rguenth
Date: Sun Nov 18 15:49:57 2007
New Revision: 130269
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130269
Log:
2007-11-18 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-18 15:50 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #12 from steven at gcc dot gnu dot org 2007-11-18 16:05 ---
This is not a smal thing to fix at all.
"Fixing" this involves teaching the compiler that some labels cannot be moved;
that these labels are optimization barriers (i.e. no insn can be safely moved
up or down across
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-18 16:35 ---
Subject: Bug 34137
Author: burnus
Date: Sun Nov 18 16:35:12 2007
New Revision: 130270
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130270
Log:
2007-11-18 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #65 from pault at gcc dot gnu dot org 2007-11-18 17:16 ---
Well, I think that it's fixed on trunk now.
Go on, make my day and find another!
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fang at csl dot cornell dot edu 2007-11-18 17:26
---
and otool -L (like ldd) shows this:
$ otool -L /sw/lib/gcc4.3/lib/libstdc++.dylib
/sw/lib/gcc4.3/lib/libstdc++.dylib:
/sw/lib/gcc4.3/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.1
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-11-18 17:27
---
How about this:
if (any(abs(ptr3 - (/cos(1.0_4), cos(3.0_4)/)).gt. 1e-05)) call abort ()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34139
--- Comment #64 from pault at gcc dot gnu dot org 2007-11-18 17:14 ---
Subject: Bug 31608
Author: pault
Date: Sun Nov 18 17:14:40 2007
New Revision: 130271
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130271
Log:
2007-11-18 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #2 from burnus at gcc dot gnu dot org 2007-11-18 17:14 ---
FIXED on the trunk (4.3.0). Was simpler than I thought.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
With 4.3.0-20071109, basic C++ linking fails (test taken from configure-style
AC_LINK_IF_ELSE):
$ cat fgets.cc
extern "C" {
char fgets(void);
}
int
main(int argc, char* argv[]) {
fgets();
return 0;
}
$ g++-4 fgets.cc -o fgets
/usr/bin/ld: warning can't open dynamic library: /libg
--- Comment #5 from p dot vanhoof at oma dot be 2007-11-18 18:17 ---
I am not completely sure whether this is the same underlying problem, but I get
a bogus warning "array subscript is above array bounds" with the code snippet
below when compiled with gcc -c -O3 -Wall:
=
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-18 19:18 ---
Subject: Bug 5
Author: jakub
Date: Sun Nov 18 19:18:39 2007
New Revision: 130274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130274
Log:
PR middle-end/5
* optabs.h (optab_table): Ch
--- Comment #3 from dominiq at lps dot ens dot fr 2007-11-18 19:20 ---
--- ../_gcc_clean/gcc/testsuite/gfortran.dg/subref_array_pointer_2.f90
2007-11-15 13:26:25.0 +0100
+++ gcc/testsuite/gfortran.dg/subref_array_pointer_2.f902007-11-18
19:06:02.0 +0100
@@ -81,7
* gcse.c (try_replace_reg): Avoid rtx sharing between REG_EQUAL note
and insn.
* gcc.c-torture/compile/20071118-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20071118-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcse.c
trunk/gcc/testsuite/ChangeLog
--
--- Comment #12 from jakub at gcc dot gnu dot org 2007-11-18 19:23 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-18 19:23 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pault at gcc dot gnu dot org 2007-11-18 19:09 ---
(In reply to comment #1)
> How about this:
>
> if (any(abs(ptr3 - (/cos(1.0_4), cos(3.0_4)/)).gt. 1e-05)) call abort ()
>
Jerry,
Looks "obvious" to me...
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #2 from fang at csl dot cornell dot edu 2007-11-18 19:10
---
In fact, *many* installed .dylibs point incorrectly to /libgcc_s.1.dylib.
libffi.4.dylib
libgcj-tools.9.dylib
libgcj-tools.dylib
libgcj.9.dylib
libgfortran.3.dylib
libgij.9.dylib
libgomp.1.dylib
libobjc-gnu.2.dyl
Reduced from a failure of alloc_comp_constructor.f90
with -fdefault-integer-8 on i686-pc-linux-gnu:
$ cat alloc_1.f90
Program test_constructor
implicit none
type :: thytype
integer(4) :: a(2,2)
end type thytype
type :: mytype
integer(4), allocatable :: a(:, :)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-18 20:06 ---
*** This bug has been marked as a duplicate of 30572 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-11-18 20:06
---
*** Bug 34142 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
On Linux/i686 and Linux/x86-64, revision 130005 causes bootstrap
failure with --disable-checking.
--
Summary: [4.3 Regression] Revision 130005 causes bootstrap
failure
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Seve
--- Comment #1 from hjl at lucon dot org 2007-11-18 20:48 ---
Revision 130005 is
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00197.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-18 20:51 ---
I have mentioned this before but nobody really listens to me.
--disable-checking or turning off the asserts should disable the unitialized
warnings since they are no longer true warnings.
--
pinskia at gcc dot gn
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-18 20:59
---
Subject: Bug 34139
Author: jvdelisle
Date: Sun Nov 18 20:59:41 2007
New Revision: 130277
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130277
Log:
2007-11-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-11-18 20:59
---
Subject: Bug 33317
Author: jvdelisle
Date: Sun Nov 18 20:59:41 2007
New Revision: 130277
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130277
Log:
2007-11-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-11-18 21:15
---
Fixed on trunk. Rev 130276
http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/check.c?view=log&pathrev=130276
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #31 from tkoenig at gcc dot gnu dot org 2007-11-18 21:18
---
Subject: Bug 32770
Author: tkoenig
Date: Sun Nov 18 21:18:07 2007
New Revision: 130279
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130279
Log:
2007-11-18 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #3 from tromey at gcc dot gnu dot org 2007-11-18 21:26 ---
Please post the error message.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-11-18 21:38
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-11-18 21:48
---
The test case given here passes for me on x86-64 with both -m32 and -m64 and
with or without -fdefault-integer-8. hmm!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-11-18 21:49 ---
This would be useful.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-18 21:55 ---
Is this a dup of PR34110?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
--- Comment #5 from andreast at gcc dot gnu dot org 2007-11-18 21:58
---
cc1: warnings being treated as errors
/export/home/tobleran/devel/gcc/head/gcc/gcc/reg-stack.c: In function
\ufffd\ufffd\ufffdswap_to_top\ufffd\ufffd\ufffd:
cc1: error: array subscript is below array bounds
aka du
The test case passes, but somehow _gfortran_compare_string
is still called.
$ gfortran -fdump-tree-original -fdefault-integer-8 single_char_string.f90
$ grep _gfortran.*string single_char_string.f90.003t.original
if (_gfortran_compare_string (MAX_EXPR <(1 - D.507) + D.508, 0>, (char[1:5]
*)
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-11-18 22:04 ---
(In reply to comment #1)
> The test case given here passes for me on x86-64 with both -m32 and -m64 and
> with or without -fdefault-integer-8. hmm!
Does the original test case pass?
--
http://gcc.gnu.org/bugzil
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-18 22:21 ---
Subject: Bug 30988
Author: jakub
Date: Sun Nov 18 22:20:54 2007
New Revision: 130280
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130280
Log:
PR c++/30988
semantics.c (finish_call_expr): Set
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-18 22:21 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #8 from dominiq at lps dot ens dot fr 2007-11-18 22:46 ---
Sorry to reopen the bug, but I have a lot of failures in my tests. A reduced
case is:
integer(8) :: i
i = 1_8
print *, cshift((/.true.,.false.,.true.,.false./),1,dim=i)
end
which fails at runtime with:
Fortran ru
--- Comment #15 from jakub at gcc dot gnu dot org 2007-11-18 22:55 ---
It seems fixincl isn't supported for mingw at all, from what Danny Smith mailed
me privately. 1) mkfixinc.sh makes fixincludes a nop on several targets
including mingw 2) there seems to be either directory separator
--- Comment #16 from jakub at gcc dot gnu dot org 2007-11-18 22:57 ---
Created an attachment (id=14576)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14576&action=view)
gcc43-pr30589.patch
Updated patch with wild guesses what to do about the dir separators.
I can't test it though
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-11-18 23:41
---
OK, the original test case fails as reported. Replacing aborts with printin
the line number that fails:
fail 39
fail 40
fail 80
fail 81
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-11-18 23:45
---
No sorry necessary. Could you post the -fdump-tree-original for your test
case?
In the mean time I will get logged on to a linux PPC machine and see if I see
it there.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-11-19 01:22
---
I found the problem. We key off of the kind of shift to determine which
version of the runtime to resolve to. In your test case, shift is kind=4 so we
load in the cshift0_4 instead of the cshift0_8 version of c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 03:45 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 03:52 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 03:57 ---
t.cc:28: warning: returning reference to temporary
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34075
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-19 04:04 ---
This was fixed by the fix for PR 34127.
*** This bug has been marked as a duplicate of 34127 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-11-19 04:04 ---
*** Bug 34122 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-19 04:10 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|rtl-o
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-19 04:11 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-19 03:48 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-19 04:15 ---
This works on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-19 03:50 ---
With checking enabled, we get:
t.cc:2: internal compiler error: tree check: expected record_type or union_type
or qual_union_type, have lang_type in xref_basetypes, at cp/decl.c:10395
Please submit a full bug report,
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 04:17 ---
Confirmed, the regression part is an error-recovery issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
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
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-19 04:32 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-19 04:34 ---
Fixed. Thanks Janis for doing this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 04:36 ---
I saw this too, see PR 30702.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-19 04:36 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-19 04:38 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-19 04:40 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 04:42 ---
I get this now:
t.cc:21: error: cannot expand 'Args ...' into a fixed-length argument list
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33965
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 04:44 ---
Confirmed, the ICE is an error recovery regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-19 04:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
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=33955
Exactly like PR 33723 except the compound literal is inside a CONSTRUCTOR (you
can combine compound literals and normal constructors to make this worse).
Testcase:
typedef struct
{
int f1, f2, f3, f4, f5, f6, f7, f8;
long int f9, f10;
int f11;
} f;
typedef union
{
f f;
char s[5
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||33723
Target Milestone|--- |4.2.3
http://
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 05:00 ---
3.4.x is no longer maintained so I am going to close this as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-19 05:01 ---
(In reply to comment #2)
> And on ARM too. pinskia: is PR31128 the same as this one?
No, it is unrelated to that bug report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Bootstrap broken on mips- |[4.3 Regression] Bootstrap
|sgi-irix6.5
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-19 05:03 ---
Confirmed, the ICE is an error recovery regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
build toolchains using buildroot. but when compile the
busybox, an internel compiler error show.
/home/mahua/opt/arm/build_arm/busybox-1.1.3/editors/vi.c: In function 'do_cmd':
/home/mahua/opt/arm/build_arm/busybox-1.1.3/editors/vi.c:2989:
internal compiler error: in set_iv, at tree-ssa-loop-ivopt
1 - 100 of 132 matches
Mail list logo
