--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-10-03 06:08
---
Try to revert the big SRA patch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-10-03 08:08
---
Further reduced testcase:
integer i(1)
print *, transfer(achar(i), x)
end
The type mismatch disappears if you change the transfer statement into
transfer([x]), x, so this is a problem in the return type
Mainline currently doesn't bootstrap on mips-sgi-irix6.5 due to an ICE while
compiling mips-sgi-irix6.5/64/libgcc/_powitf2.o at stage 1. This happens,
afaict, with any use of the TF mode with either -mabi=64 or -mabi=n32:
$ cat foo.i
void __powitf2 (float x __attribute__ ((mode (TF {}
$
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 09:46
---
Subject: Bug 26682
Author: fxcoudert
Date: Wed Oct 3 09:46:46 2007
New Revision: 128977
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128977
Log:
PR fortran/26682
* options.c
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-10-03 10:02
---
Subject: Bug 31899
Author: rguenth
Date: Wed Oct 3 10:01:43 2007
New Revision: 128978
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128978
Log:
2007-10-03 Doug Kwan [EMAIL PROTECTED]
Richard
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-10-03 10:04
---
Fixed on the trunk, queued for 4.2.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jason at gcc dot gnu dot org 2007-10-03 10:43 ---
Subject: Bug 15764
Author: jason
Date: Wed Oct 3 10:43:42 2007
New Revision: 128979
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128979
Log:
PR c++/15764
* cp/decl.c (wrap_cleanups_r): New
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-03 11:37 ---
Subject: Bug 33198
Author: tobi
Date: Wed Oct 3 11:37:44 2007
New Revision: 128980
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128980
Log:
PR fortran/33198
fortran/
* resolve.c (has_default_initializer):
This was seen on ppc-darwin and x86_64-linux with -m32:
$ cat x.f90
implicit none
type vec3
integer, dimension(1) :: coords
end type vec3
type(vec3), parameter :: v1 = vec3((/ 0 /))
integer :: i
i = 1
print *, v1%coords ((/i/))
end
$ gfortran -m32 x.f90
x.f90:9.23:
print
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Sorry for the details - might not be required as I already tracked down the
problem to the source line...
When NM_FOR_TARGET requires arguments (fex -B -X32_64 for aix), checking for
nm in gcc/configure{,.ac} is broken:
Assume
*) source is /source/gcc-4.2.0
*) builddir is /build
*) configured
I have a rather nasty optimization issue with gfortran (as of yesterday).
As I think it could be an optimization issue and not an gfortran frontend
issue, so I assigned it to the middle-end.
I narrowed my problem to one single fortran function. If I compile this
function with
gfortran -O2
--- Comment #1 from manfred99 at gmx dot ch 2007-10-03 12:46 ---
Created an attachment (id=14288)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14288action=view)
Source code of affected function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #2 from manfred99 at gmx dot ch 2007-10-03 12:47 ---
Created an attachment (id=14289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14289action=view)
Assembler code of original code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
--- Comment #3 from manfred99 at gmx dot ch 2007-10-03 12:49 ---
Created an attachment (id=14290)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14290action=view)
Assembler code when commenting line 315, works
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
This is from https://bugzilla.redhat.com/show_bug.cgi?id=297961
The problem is that .class files can now (as of Java 1.5) contain classes whose
name contains a hyphen. The mangling used to generate internal labels in gcj
passes these hyphens through to the assembler rather than mangling them.
--- Comment #1 from aph at gcc dot gnu dot org 2007-10-03 13:00 ---
Subject: Bug 33639
Author: aph
Date: Wed Oct 3 12:59:57 2007
New Revision: 128981
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128981
Log:
2007-10-03 Andrew Haley [EMAIL PROTECTED]
PR java/33639
--- Comment #2 from aph at gcc dot gnu dot org 2007-10-03 13:02 ---
Fixed.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from dominiq at lps dot ens dot fr 2007-10-03 13:03 ---
On PPC Darwin, I get:
[karma] f90/bug% gfc pr33636.f90
[karma] f90/bug% a.out
0
[karma] f90/bug% gfc -m64 pr33636.f90
[karma] f90/bug% a.out
0
[karma] f90/bug% gfc
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #1 from bangerth at dealii dot org 2007-10-03 14:48 ---
Confirmed, a regression introduced by the new parser in 3.4.0.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-03 15:01 ---
Fixed on trunk.
--
tobi 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 #1 from pinskia at gcc dot gnu dot org 2007-10-03 15:38 ---
One should note the gnu binutils does not support the newer features in aix so
it is really not supported with gcc on aix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33637
--- Comment #4 from ubizjak at gmail dot com 2007-10-03 15:43 ---
Please provide enough sources to create an _executable_ that shows the failure.
We are dealing with runtime failure here.
A _short_ testcase (30 lines) is nice to have, so all non-related parts should
be removed.
--- Comment #3 from spop at gcc dot gnu dot org 2007-10-03 15:45 ---
Subject: Bug 33576
Author: spop
Date: Wed Oct 3 15:45:10 2007
New Revision: 128986
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128986
Log:
2007-10-03 Sebastian Pop [EMAIL PROTECTED]
PR
--- Comment #4 from spop at gcc dot gnu dot org 2007-10-03 15:47 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from tobi at gcc dot gnu dot org 2007-10-03 16:12 ---
Created an attachment (id=14291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291action=view)
Putative patch
This patch fixes the testcase.
FX, I take it that you have a ready-built compiler with
--- Comment #2 from tobi at gcc dot gnu dot org 2007-10-03 16:22 ---
Created an attachment (id=14292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14292action=view)
Putative patch redux
Coming to think of it, the charlen thing can probably also be moved to the
first switch and
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:26
---
(In reply to comment #1)
Created an attachment (id=14291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291action=view) [edit]
Putative patch
I thought about that, because it seems right, but the the
--- Comment #4 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-03 16:36 ---
Subject: Re: Parentheses get wrong kind during matching
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:26
---
(In
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:40
---
(In reply to comment #4)
OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90
for which I have no explanation at the moment, I'll have to doublecheck
if it disappears without my patch.
--- Comment #2 from razin at avaya dot com 2007-10-03 16:44 ---
(In reply to comment #1)
*** This bug has been marked as a duplicate of 27232 ***
Hello!
I am currently experiencing the same problem when using 4.2.1. There is not
particular description if this bug is going to be
--- Comment #6 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-03 16:46 ---
Subject: Re: Parentheses get wrong kind during matching
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:40
---
(In
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:52
---
(In reply to comment #6)
failures of default_format_1.f90 (which I'm seeing as well)
You're seeing failures of default_format_1.f90 on i686-darwin (IIRC, that's
what you've got these days)? That's not supposed
I'm seeing a regression in gcc-4.2.2 prerelease:
FAIL: g++.dg/other/unused1.C scan-assembler
(string|ascii?)z?\\tclass2(|000)
The failure happens on multiple (all?) configurations starting around Sept
13th:
CLEAN results:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00609.html
Benchmark perlbmk from SPEC CPU2000 fails at runtime on powerpc64-linux with
several sets of optimization flags. When built with a compiler configured with
--enable-checks=all, file toke.c fails to build. The following minimized
testcase:
typedef enum { one, two } exp;
extern exp pe;
extern
--- Comment #8 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-10-03 17:06 ---
Subject: Re: Parentheses get wrong kind during matching
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:52
---
(In
Almost any source file compiled for any of a large number of targets
(powerpc*-*, arm-eabi, hppa-linux, mipsel-linux, s390*-linux, sh*-*, sparc*-*)
with -O2 -frtl-abstract-sequences results in the following:
bug1.c: In function foo:
bug1.c:8: error: unrecognizable insn:
(insn 28bug1.c:8:
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-10-03 17:09
---
(In reply to comment #8)
I checked all tests individually, and both the tests related to
tiny(0.0_8) fail.
That means Apple's printf() failures to read and write denormals are not
powerpc-specific. I've
When I compile the program listed below with the command gfortran -c
sysmat.f90 I get the message Warning: Line truncated at (1)
PROGRAM sysmat
! The following line has enough trailing blanks to make it 133 characters long
i = 0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-03 17:39 ---
I think this warning is correct even if the characters are spaces.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33643
Benchmark crafty from SPEC CPU2000 gets an ICE for 32-bit powerpc (linux, aix,
darwin, eabi) when compiled with -O2 -ftrapv, as shown by this minimized test:
extern char *bar (const char *);
int *m, *b;
void
foo (void)
{
int *mv;
int p;
char a[17];
p = bar (a) - a;
for (mv = m; mv b;
--- Comment #1 from janis at gcc dot gnu dot org 2007-10-03 18:08 ---
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=125624
r125624 | dberlin | 2007-06-11 18:02:15 + (Mon, 11 Jun 2007)
This is the merge of the dataflow branch into
Benchmark vortex from SPEC CPU2000 compiled with -O2 -fno-unit-at-atime for
powerpc64-linux fails to build due to a missing symbol. For each of 24 cross
cc1's that I tried, symbol That from the following minimized testcase is not
defined in the .s file:
extern void bar (int *);
void
foo (void)
{
--- Comment #11 from jason at gcc dot gnu dot org 2007-10-03 18:26 ---
Fixed for 4.3.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-10-03 18:39
---
Sorry, this is my fault.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Gcc 4.3 revision 128980 generates:
str.fppized.f90:337.29:
module procedure create
1
Error: Ambiguous interfaces 'create' and 'create' in generic interface
'create_' at (1)
str.fppized.f90:337.29:
Revision 128885 is OK.
--
Summary: [4.3
--- Comment #2 from rsandifo at gcc dot gnu dot org 2007-10-03 18:39
---
Subject: Bug 33635
Author: rsandifo
Date: Wed Oct 3 18:39:30 2007
New Revision: 128991
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128991
Log:
gcc/
PR target/33635
*
--- Comment #3 from rsandifo at gcc dot gnu dot org 2007-10-03 18:42
---
Thanks for the report. As per my gcc-patches@ message,
I think the committed patch is at least a step on the
road to recovery. Please let me know if it fixes things,
or if it still isn't enough.
--
rsandifo
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-10-03 18:51 ---
This may work:
$ svn diff
Index: resolve.c
===
--- resolve.c (revision 128885)
+++ resolve.c (working copy)
@@ -6563,7 +6563,7 @@ resolve_charlen
--- Comment #16 from dorit at gcc dot gnu dot org 2007-10-03 18:52 ---
Ryan, thanks a lot for the info. FYI, I started a discussion about this here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00202.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
In the library .../lib64/libgfortran.a, the 4.1.2 version has a routine
_gfortran_copy_string
in the strong_intrinsics.o component. For the same 4.2.1 library there is no
corresponding entry point.
It appears that codes compiled with 4.1.2 generate internal calls to this entry
point.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-03 18:32 ---
I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-03 19:22 ---
And this is by design. gfortran 4.1 is ABI incompatiable with gfortran 4.2.
This is one of the reasons why in 4.2 (or is it only on the trunk), we added
symbol versioning support. This is not the only place where
--- Comment #10 from dominiq at lps dot ens dot fr 2007-10-03 19:30 ---
gcc/testsuite/gfortran.dg/default_format_1.f90 passes the test if I replace
if (y /= x) res = res + 1
by
z=0.0_k
if (abs(x-y)nearest(z,1.0_k)) res = res + 1
in the two places of test_r8,
--- Comment #11 from dominiq at lps dot ens dot fr 2007-10-03 19:34 ---
BTW I have forgotten to explain why I have to use an auxiliary variable 'z': if
I usenearest(0.0_8,1.0_8); I get
default_format_1_db.f90:70.29:
if (abs(x-y)nearest(0.0_8,1.0_8)) print *, x, y, x-y
--- Comment #2 from longb at cray dot com 2007-10-03 19:44 ---
Subject: Re: _gfortran_copy_string missing in libgfortran.a
I suspected this might be the case, but did not find it documented.
Thanks for the quick reply.
Cheers,
Bill
pinskia at gcc dot gnu dot org wrote:
---
--- Comment #5 from manfred99 at gmx dot ch 2007-10-03 20:10 ---
Subject: Re: optimization bug: wrong code with
-fforce-addr
--- Comment #4 from ubizjak at gmail dot com 2007-10-03 15:43 ---
Please provide enough sources to create an _executable_ that shows the
failure.
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-10-03 20:42 ---
This looks like PR33429. Perhaps we should backport the XFAIL that was
installed on mainline.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Most benchmarks in SPEC CPU2000 fail to compile with an ICE when compiled with
-O2 -fmodulo-sched -freorder-blocks-and-partition for powerpc* and s390*
targets. Compiling the following minimized testcase:
unsigned res;
void
foo (unsigned code, int len)
{
int i;
for (i = 0; i len; i++)
--- Comment #1 from hjl at lucon dot org 2007-10-03 20:33 ---
[EMAIL PROTECTED] build_base_o2.]$ cat bar.f90
module BAR_MODULE
implicit none
private
publiccreate_
interface create_
module procedure create
end interface
contains
subroutine create(self)
--- Comment #2 from hjl at lucon dot org 2007-10-03 20:55 ---
It should be:
[EMAIL PROTECTED] pr33646]$ cat bar.f90
module BAR_MODULE
implicit none
private
publiccreate_
interface create_
module procedure create
end interface
type system_type
--- Comment #3 from pault at gcc dot gnu dot org 2007-10-03 21:21 ---
hj,
It's me - I'll revert the patch that did this, right away.
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33646
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-03
21:23 ---
Subject: Re: bootstrap with ada failed
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-10-03 06:08
---
Try to revert the big SRA patch.
128907 is ok. 128908 is broken.
Dave
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-03 21:02 ---
-frtl-abstract-sequences
It is a size optimization method. This option is to find identical
sequences of code, which can be turned into pseudo-procedures and then replace
all occurrences with calls to the newly
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-03 21:27
---
Subject: Bug 26682
Author: fxcoudert
Date: Wed Oct 3 21:27:39 2007
New Revision: 128993
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128993
Log:
PR fortran/26682
* trans-decl.c
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 21:30
---
I've fixed 1 and 2 (and added an error message when -fwhole-program is used
with Fortran), and there is a separate PR to track 3, so I'll close this one.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-10-03 21:31
---
128907 is ok. 128908 is broken.
OK, thanks for confirming.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-03 21:32 ---
It's me
I have warned you;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33646
--- Comment #5 from hjl at lucon dot org 2007-10-03 21:38 ---
Revision 128954:
http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00058.html
is the cause.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-10-03 22:05
---
(In reply to comment #2)
Created an attachment (id=14292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14292action=view) [edit]
Putative patch redux
That patch regtests fines on x86_64-linux with
--- Comment #9 from hjl at lucon dot org 2007-10-03 22:17 ---
(In reply to comment #8)
Subject: Re: attribute((aligned)) doesn't work for variables on the stack for
greater than required alignement
On 3 Oct 2007 22:04:28 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-10-03 22:07 ---
Subject: Re: attribute((aligned)) doesn't work for variables on the stack for
greater than required alignement
On 3 Oct 2007 22:04:28 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #7 from
--- Comment #7 from hjl at lucon dot org 2007-10-03 22:04 ---
What is the performance impact of
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01167.html
Intel compiler has a very efficient way to align the stack:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28074
It saves stack
--- Comment #8 from jason at gcc dot gnu dot org 2007-10-03 21:54 ---
The error the trunk gives is correct; this is not one of the allowed uses of a
member function name in [expr.prim]p10.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from david_albert at axiometric dot com 2007-10-03 22:06
---
This issue has affected *many* developers on a variety of platforms including
ARM and PPC. There is no elegant way to resolve this without searching through
every line of code. There is a warning -Wcast-align
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-03 22:13 ---
You could open a request for a warning when a null pointer check is optimized
away after dereferencing the pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33629
--- Comment #10 from hjl at lucon dot org 2007-10-03 22:27 ---
For backend with frame pointer and working -fomit-frame-pointer -g, can
we
1. Make -fomit-frame-pointer per function, instead of per file.
2. Enable -fomit-frame-pointer for functions which need stack alignment.
3. Mark
Every test in SPEC CPU2000 causes cc1 to segfault when built with:
-O2
-fno-tree-ch
-fno-tree-copy-prop
-fno-tree-dominator-opts
-fno-tree-store-copy-prop
-fno-tree-vrp
Yes, a normal person wouldn't do that, but in theory we'd like the optimization
passes to not rely on each other.
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-10-03 22:40
---
(In reply to comment #7)
It saves stack pointer in frame pointer. Can we implement it for suitable
cases/backends and properly handle
This only helps x86 really. If you look at my patch, it already implements
Just about any input to gcc for any target results in the following ICE for
-O2 -fno-tree-salias:
bug7.c: In function foo:
bug7.c:1: internal compiler error: in verify_curr_properties, at passes.c:1043
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-03 23:12 ---
*** This bug has been marked as a duplicate of 33092 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-03 23:12 ---
*** Bug 33650 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from hjl at lucon dot org 2007-10-04 00:01 ---
(In reply to comment #11)
This only helps x86 really. If you look at my patch, it already implements
(correctly) handling large cases like 128byte alignment (which people use with
the Cell). What you are proposing will
--- Comment #28 from jason at gcc dot gnu dot org 2007-10-03 23:54 ---
Changing the testcase to use decltype instead of typeof produces this error
with current sources:
wa.C:2: sorry, unimplemented: zero-operand casts cannot be mangled due to a
defect in the C++ ABI
Now that we have
With -O2 and above, the optimizer will remove null pointer checks after the
pointer has been de-referenced. This makes assumptions about the run-time
environment: that de-referencing address 0 is illegal and will cause an MMU
fault. This assumption is invalid in some environments such as those
--- Comment #4 from jason at gcc dot gnu dot org 2007-10-04 01:01 ---
Subject: Bug 11756
Author: jason
Date: Thu Oct 4 01:01:00 2007
New Revision: 128999
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128999
Log:
PR c++/11756
* mangle.c (write_type)
--- Comment #5 from jason at gcc dot gnu dot org 2007-10-04 01:01 ---
This works with decltype, so I'm just going to change the ICE using typeof to a
sorry.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jason at gcc dot gnu dot org 2007-10-04 01:05 ---
The testcase works fine if I change typeof to __decltype and add the necessary
template template to the third line.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from igodard at pacbell dot net 2007-10-04 01:15 ---
Can you spell kludge?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11756
--- Comment #14 from jason at gcc dot gnu dot org 2007-10-04 01:29 ---
Both bug32182 and test_4 work for me with pre-4.3.0 on i686-pc-linux-gnu, so
I'm going to set known to work for 4.3.
--
jason at gcc dot gnu dot org changed:
What|Removed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from jason at gcc dot gnu dot org 2007-10-04 01:45 ---
This is not a bug; Mark's comment in bug 21089 had to do with the fact that
[basic.start.init] says that static initialization happens before dynamic
initialization. Using foo() in Y's initializer makes Y dynamically
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #13 from gdr at cs dot tamu dot edu 2007-10-04 01:46 ---
Subject: Re: ICE when mangling template which uses typeof
jason at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| The testcase works fine if I change typeof to __decltype and add the
necessary
| template template
--- Comment #3 from jason at gcc dot gnu dot org 2007-10-04 01:50 ---
*** This bug has been marked as a duplicate of 7046 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2007-10-04 01:50 ---
*** Bug 21560 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
1 - 100 of 109 matches
Mail list logo
