--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
01:01 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
The following invalid code snippet causes a bogus error message:
==
struct A
{
static operator int();
};
==
bug.cc:3: error: 'static A::operator int()' must be a nonstatic member function
bug.cc:3: error: 'static A::operator int()' must
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
01:18 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
The folding of built-in functions does not always yield results with
the correct return type, causing excess warnings (errors with -pedantic-errors).
char *strchr(const char *, int);
char *strrchr(const char *, int);
char *index(const char *, int);
char *rindex(const char *, int);
char
Compiling the following code snippet with -Wextra, a sensible warning
is issued:
==
struct B {};
struct A : B
{
const int i;
};
==
warn.cc:5: warning: non-static const member 'const int A::i' in class without a
constructor
However, if A is not a
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-15
01:29 ---
Btw, the warning in the second case is missing since gcc 3.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19968
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
01:30 ---
: Search converges between 2004-09-15-014001-trunk (#540) and
2004-09-15-161001-trunk
(#541).
Confirmed.
Caused by:
2004-09-15 Jakub Jelinek [EMAIL PROTECTED]
* expr.c (string_constant):
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
01:32 ---
: Search converges between 2002-10-02-trunk (#92) and 2002-10-03-trunk (#93).
Confirmed.
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19967
--- Additional Comments From joseph at codesourcery dot com 2005-02-15
01:37 ---
Subject: Re: [4.0 Regression] built-in folding causes
excess diagnostics
On Tue, 15 Feb 2005, pinskia at gcc dot gnu dot org wrote:
Caused by:
2004-09-15 Jakub Jelinek [EMAIL PROTECTED]
*
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
01:46 ---
(In reply to comment #2)
Yes I do (depending on which function by the way):
: Search converges between 2004-05-23-trunk (#458) and 2004-06-01-trunk (#459).
2004-05-30 Steven Bosscher [EMAIL PROTECTED]
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-02-15 01:56 ---
Subject: Re: [4.0 Regression] g++.dg/abi/inline1.C fails on hp
3) I'm concerned that the proposed fix requires a linker fix. There won't
be a fix for HP-UX 10 and possibly 11.00. There's
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
02:39 ---
(In reply to comment #8)
Did you mean MOVE_RATIO?
Yes. A value of 2 should be able to reproduce it. If we have any bigger
value, the gimplifier will not
produce the CONST_DECL which we will SRA on it.
The following code breaks when compiled with -O3 or -O2, because the label
seems to be misplaced. This problem seems to be restricted to situations where
I pass the address of a label into an assembly routine to be used. When
compiled without optimizations or with -O1, it works properly. I´m
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
03:14 ---
This is not a bug, Labels can be moved if you don't use them as computed gotos
in which this case you
don't use it for that. Also note asms cannot, I repeat cannot change the flow
of a program at all.
--- Additional Comments From wilson at gcc dot gnu dot org 2005-02-15
04:20 ---
It was fixed by the ivopts patch for 18687, which was a patch to reduce
compilation time. The patch says nothing about fixing bugs, or changing the
result. It only claims to make ivopts faster. Since this
--- Additional Comments From kazu at cs dot umass dot edu 2005-02-15 04:44
---
I've got a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu
For native and cross builds to MinGW (mingw32 or i386-pc-mingw32), Java and
libgcj are unnecessarily disabled by the top-level configure - they have been
building just fine for quite some time now in mainline. To get libgcj to build,
one has to explicitly specify --enable-libgcj to the configure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
05:31 ---
Hmm, we call gimplify_type_sizes from:
/* ??? We really shouldn't need to gimplify the type of the variable
since it already should have been done. But leave this here
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
05:36 ---
(In reply to comment #4)
I think we are missing a SAVE_EXPR somewhere.
Or maybe not as this is type is dependent on the object.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19956
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
05:45 ---
Hmm, here is what is going on:
long int p__x2___PAD___XVZ = x1.F.d == 0 ? 32 : 64;
struct p__x2___PAD x2;
We gimplify p__x2___PAD___XVZ but that is the TYPE_SIZE of p__x2___PAD in which
we ICE as
--
What|Removed |Added
BugsThisDependsOn||19900
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19408
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
05:48 ---
Confirmed on ppc also with the reduced testcase in PR 19408.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
06:00 ---
From the reduced testcase in that PR, we get the following for the constructor
(which is wrong):
{.bandD.636=2, .the_commandD.637=0, ._parentD.648={.bandD.640=2},
.tc_sccD.652=66}
The problem comes from:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
06:00 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
06:03 ---
Confirmed.
--
What|Removed |Added
Severity|normal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
06:15 ---
(In reply to comment #3)
For addition, this is a regression against 3.3.5:
Actually it is not and here is why:
fadds .LC0
.LC0 is actually zero.
And in fact this only can happen with
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
06:17 ---
There is nothing we can do without a testcase, either see if your code compiles
on the mainline or
attach the preprocessed source here (and I will try to reduce it).
--
What|Removed
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-02-15 06:41 ---
Q: As a (new/cautious) target co-maintainer, is this within my domain to fix
without seeking approval?
This is not a regression, so I assume it would wait until after branching.
Correct?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
06:44 ---
Confirmed, reduced testcase:
PROCEDURE C37305A IS
BEGIN
DECLARE
SUBTYPE ST IS INTEGER RANGE 1..10;
TYPE REC(DISC : ST := 1) IS
RECORD
CASE DISC IS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
07:12 ---
Reconfirmed, reduced testcase from c32001e:
PROCEDURE C32001E IS
BEGIN
DECLARE
PACKAGE PKG1 IS
TYPE PACC IS PRIVATE;
FUNCTION INIT5 (I : INTEGER) RETURN PACC;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
07:14 ---
(In reply to comment #9)
Isn't PR 19853 (and 19865) showing that this is not an Ada front-end bug?
Hmm, you might be correct.
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-14 08:18
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00679.html
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
08:52 ---
Subject: Bug 19818
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 08:52:25
Modified files:
include: ChangeLog ansidecl.h
libcpp
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-14
09:12 ---
Patch applied.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
09:36 ---
Subject: Bug 19891
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 09:36:35
Modified files:
gcc/cp : ChangeLog class.c search.c typeck.c
--- Additional Comments From nathan at gcc dot gnu dot org 2005-02-14
09:41 ---
2005-02-11 Nathan Sidwell [EMAIL PROTECTED]
PR c++/19891
* class.c (build_simple_base_path): Build the component_ref
directly.
(update_vtable_entry_for_fn): Walk the
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From dcb314 at hotmail dot com 2005-02-14 10:05
---
This bug is still broken in the snapshot for 3.4
dated 20050211
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18371
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-14
10:22 ---
Is this fixed now?
--
What|Removed |Added
Status|NEW
--- Additional Comments From nathan at gcc dot gnu dot org 2005-02-14
10:27 ---
The killer with packing in C++ is that it is so easy to silently take the
address of a field (pass by reference). Until we actually reflect unalignedness
in the type system *no* packing is really safe in
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-14
10:39 ---
Numbers today (2005-02-13):
target -O2 -Os
i686-linux 8%3%
i386-elf 5% -2%
mips-elf 6%0%
ppc-elf 3% -3%
sh-elf -1% -8%
(note: numbers here and in
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-14
11:12 ---
Regression confirmed for avr-*-rtems* (20050214).
--
What|Removed |Added
Bootstrapping h8300-rtems* (GCC-4.0 - 20050214) fails with:
/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/xgcc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/
-nostdinc
-B/users/rtems/src/rpms/BUILD
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-14
11:34 ---
*** Bug 19949 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
GCC build triplet|powerpc-apple-darwin7.8.0 |
GCC host
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
11:38 ---
Subject: Bug 17428
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 11:37:53
Modified files:
gcc: ChangeLog value-prof.c cfgrtl.c
gcc -v:
Reading specs from /var/gnu/3.4.0/lib/gcc/sparc-sun-solaris2.8/3.4.0/specs
Configured with: ../gcc-3.4.0/configure --prefix=/var/gnu/3.4.0 --disable-nls --
enable-languages=c,c++
Thread model: posix
gcc version 3.4.0
command line:
gcc -save-temps -I../../src/dbserver/include
--- Additional Comments From ddonovan at latentzero dot com 2005-02-14
11:46 ---
Created an attachment (id=8191)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8191action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19950
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
12:01 ---
Subject: Bug 17816
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 12:01:16
Modified files:
gcc/cp : ChangeLog decl.c
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-14
12:01 ---
(In reply to comment #7)
*** Bug 19949 has been marked as a duplicate of this bug. ***
OK, then for completeness:
Regression confirmed for h8300-*-rtems* (GCC-4.0 20050214).
--
What
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
12:25 ---
I can confirm that this is fixed in the 20050213 snapshot.
Both the reduced C test case and the original Fortran routine
don't segfault any more. Thanks to whoever fixed this :-)
I would suggest
--- Additional Comments From nathan at gcc dot gnu dot org 2005-02-14
13:35 ---
2005-02-14 Nathan Sidwell [EMAIL PROTECTED]
PR c++/19884
* pt.c (check_explicit_specialization): Make sure namespace
binding lookup found an overloaded function.
When I compile ACE5.4.2 with the latest snapshot (20050213) I get an ICE.
Michael Cieslinski
g++ -O2 -ftree-vectorize -c -o server.o server.ii
server.cpp: In function 'int main(int, char**)':
server.cpp:89: internal compiler error: in tree_split_edge, at tree-cfg.c:3199
Please submit a full bug
--- Additional Comments From micis at gmx dot de 2005-02-14 13:45 ---
Created an attachment (id=8192)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8192action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19951
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
13:45 ---
Subject: Bug 19895
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 13:45:42
Modified files:
gcc/cp : ChangeLog decl.c pt.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
13:45 ---
Subject: Bug 19884
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 13:45:42
Modified files:
gcc/cp : ChangeLog decl.c pt.c
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
When I compile ACE5.4.2 with the latest snapshot (20050213) I get an ICE.
Michael Cieslinski
g++ -O3 -ftree-vectorize -c -o Hash_Map.o Hash_Map.ii
Hash_Map.cpp: In function 'int main(int, ACE_TCHAR**)':
Hash_Map.cpp:113: internal compiler error: tree check: expected
class 'declaration', have
--- Additional Comments From micis at gmx dot de 2005-02-14 13:55 ---
Created an attachment (id=8193)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8193action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19952
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-14
13:59 ---
Stuart, ping! rth attached a patch 10 days ago and asked for feedback.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19521
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-02-14
14:06 ---
Not a bug. bx lr is the correct instruction to use for returning from
a function on any ARMv4T or later processor.
--
What|Removed |Added
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-14 14:56
---
We need to make this change soon. I'd like to do something that Hans would
approve of, but I don't know exactly what that might be.
Andreas Jaeger says his patch works. Unless someone comes up with something
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
14:57 ---
Subject: Bug 18116
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 14:57:37
Modified files:
libjava: ChangeLog
Added files:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
14:58 ---
Subject: Bug 19907
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 14:58:23
Modified files:
gcc/java : ChangeLog expr.c decl.c
Log
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:00 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:02 ---
Confirmed, here is a testcase which is valid code (yes I checked to make sure
that it is valid):
namespace util
{
class persistent_object_manager;
namespace memory
{
class pointer_manipulator
--- Additional Comments From green at redhat dot com 2005-02-14 15:03
---
Fixed. I checked in a slightly different patch for the dot-slash problem,
having not seen yours until later. This new patch stores the signatures in
dot format instead of implementing a special compare routine.
--- Additional Comments From kent at sas dot com 2005-02-14 15:03 ---
got it now, thanks, and sorry for the interuption. i've made some good progress
over the weekend on getting this to compile - i appreciate you getting me over
the hurdle. paul.
--
--- Additional Comments From green at redhat dot com 2005-02-14 15:04
---
Fix and testcase committed.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-14
15:05 ---
Quite naively, I would say that this could even be ok, just that there will
never be a member variable the address of which one could initialize this
pointer-to-member with. Do you have chapter and
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-14 15:07
---
Is it desirable to have all memory allocated by the GC executable though?
I think libgcj always knows in advance what memory will it need executable,
so wouldn't it be better to provide separate allocation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:14 ---
None of the primary/secondary targets are known to fail so removing the target
milestone.
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18116
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:16 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-14 15:18
---
This seems to me like creeping featurism.
We need to distinguish between fixing this bug in a simple way and adding nice
new properties that would require a change to the garbage collector's API. At
this
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-02-14
15:20 ---
(In reply to comment #3)
I'm not sure how to do anything but run a brand-new alias pass here and
anywhere
else we expose new global variables (e.g DOM?).
Perhaps the easiest approach for 4.0 is to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:41 ---
This comes down to the following reduced testcase:
struct Logging {
friend class Environment;
};
templateclass T struct ArrayCollection
{
int insert(const T theObj)
{
Environment::ReportError();
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:47 ---
I should note this is an ICE right before trying to print out another ICE.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:48 ---
Hmm, we are trying to split an abnormal (most likely an eh) edge.
--
What|Removed |Added
Looking at the following piece of code:
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a, b);
c = a*b;
return creal(c)+cimag(c)0;
}
and compiling this with flag_complex_method=2 and -O3, I find
that the statement is translated to (in
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:52 ---
(In reply to comment #15)
Is this fixed now?
No, it regressed again.
See http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00507.html.
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||18902
nThis||
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
15:55 ---
Confirmed, what we most likely need is a builtin which does the expanding when
we have the
imagianary part as 0.
--
What|Removed |Added
With its 800 pages the GMF is the first publication worldwide for the number of
fairs recorded (more than 16,000 of all sectors, all over the world).
GMF is published twice a year.
The fairs calendar of the first issue starts from January, the second one from
July and both contain all the
--- Additional Comments From christian dot joensson at gmail dot com
2005-02-14 15:56 ---
Again, same checkout, but built for sparc64-linux, test results *with
phython's patch* posted here:
http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg00566.html
Will start a build *without* the
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-14
15:58 ---
Volker, you seem to be on a quest to make gcc accept without crashing even
the most obnoxious wrong code snippets without ICEing.
I wouldn't say that they're obnoxious ;-)
These code snippets are
--- Additional Comments From dje at gcc dot gnu dot org 2005-02-14 16:03
---
With -O2/-O3 -funroll loops -fswitch-loops -fpeel-loops, mgrid (and swim) no
longer regress. With just -O2/-O3, performance regression for mgrid remains
(and swim performance dropped dramatically).
--
--- Additional Comments From ddonovan at latentzero dot com 2005-02-14
16:11 ---
I don't understand!
I have since created another dummy class which has one public static method
that does the same as ReportError() in the Environment class. gcc doesn't
complain about this. It is
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-14
16:29 ---
Yes, it is natural, once you look into the mechanisms used to implement the
features. However, if you focus on the definitions:
- memory allocated for dynamic-sized arrays is released at the time the array
--- Additional Comments From sds at gnu dot org 2005-02-14 17:47 ---
(In reply to comment #9)
- memory allocated with alloca() is released at the time the function that
calls
alloca() returns
oh - I didn't know that.
I always thought that alloca()ted memory is released by the next
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
17:51 ---
Subject: Bug 19608
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 17:50:59
Modified files:
gcc/cp : ChangeLog parser.c
--- Additional Comments From nathan at gcc dot gnu dot org 2005-02-14
17:53 ---
2005-02-14 Nathan Sidwell [EMAIL PROTECTED]
PR c++/19608
* parser.c (cp_parser_late_parsing_for_member): Use
current_function_decl as scope to push to and from.
--
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-02-14 17:54
---
Created an attachment (id=8194)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8194action=view)
reduced testcase
This is a cut-down version of g++.dg/eh/registers1.C which
still fails (when built with
This is a readelf output of test program. The variable in question is
Derived1 d1;
09dd: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_stmt_list : 492
DW_AT_producer: GNU C++ 3.4.3
DW_AT_language: 4 (C++)
DW_AT_name: ../../src/tx_basic_class.cxx
Software Environment:
Linux 2.6.9-5.EL #1 SMP Wed Jan 5 19:23:58 EST 2005 ppc64 ppc64 ppc64
GNU/Linux
gcc version 3.4.3 20041212
(**but seems to be in 3.4.4 and 4.0 code too).
Steps to Reproduce:
1. Source File:
t.C
---
#include locale
--- Additional Comments From jgrimm2 at us dot ibm dot com 2005-02-14
18:34 ---
,with the changes to locale_facet2.h
typo - meant locale_facets.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19955
On x86 and x86_64 at least, always amazing that ACATS didn't catch it.
As noted in the source, removing a constant keyword get rid of the ICE,
so this may have to do with constant-ness.
$ gcc -c p.adb
+===GNAT BUG DETECTED==+
| 4.0.0 20050213
1 - 100 of 182 matches
Mail list logo