It works on x86, on x86_64 it started failing on mainline between
LAST_UPDATED: Thu Mar 17 23:01:51 UTC 2005
LAST_UPDATED: Fri Mar 18 18:13:38 UTC 2005
,.,. C52103X ACATS 2.5 05-03-18 21:10:49
C52103X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,
THE LENGTHS MUST
--- Additional Comments From John at xza5 dot com 2005-03-19 08:33 ---
Subject: Re: [4.0/4.1 Regression] ICE in simplify_subreg,
at simplify-rtx.c:3674
giovannibajo at libero dot it wrote:
--- Additional Comments From giovannibajo at libero dot it 2005-03-19
01:25 ---
--
Summary: ICE
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
--- Additional Comments From igodard at pacbell dot net 2005-03-19 08:47
---
Created an attachment (id=8421)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8421action=view)
compiler output (-v)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20549
--- Additional Comments From igodard at pacbell dot net 2005-03-19 08:48
---
Created an attachment (id=8422)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8422action=view)
source code (-save-temps, compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20549
--- Additional Comments From laurent at guerby dot net 2005-03-19 09:47
---
Out of curiosity, does it still happen with GCC 4.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20530
It would be nice if the warning comparison is always true due to limited range
of data type could be turned off. From looking at the gcc source I conclude it
can't. I couldn't find a workaround which generates the same code (casting the
smaller type to the wider type just for the comparison
In:
templatetypename T
struct F { typedef T G; };
templatetypename U
struct H {
static Fint f;
typedef typeof(f) A;
typename A::G v1;
typename typeof(f)::G v3;
};
you get:
~/ootbc/members/src$ g++ foo.cc
foo.cc:8: error: expected nested-name-specifier before typeof
foo.cc:8: error: ISO C++
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-19 11:14 ---
IMO, resetting the error code set by the kernel whenever the internal Ada
tasking functions are called successfully is a bug. It can be easily fixed:
* s-osinte-mingw.ads
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-19 11:51
---
One further reduction, still the same misbehavior:
real vx(1)
num=2
do i=1,num
call advance(vx)
end do
contains
subroutine advance(bodies)
real, dimension(:)::bodies
bodies(1) = 1.0
--
Summary: ICE
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
--- Additional Comments From igodard at pacbell dot net 2005-03-19 11:58
---
Created an attachment (id=8423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8423action=view)
compiler output (-v)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
--- Additional Comments From igodard at pacbell dot net 2005-03-19 11:58
---
Created an attachment (id=8424)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8424action=view)
source code (-save-temps, compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20552
--- Additional Comments From joseph at codesourcery dot com 2005-03-19
12:02 ---
Subject: Re: New: Silencing the warning: comparison is always
true due to limited range of data type
On Sat, 19 Mar 2005, qrczak at knm dot org dot pl wrote:
It would be nice if the warning comparison
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
12:12 ---
Subject: Bug 20333
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-19 11:54:49
Modified files:
gcc/cp : ChangeLog parser.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
12:19 ---
Subject: Bug 20333
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 12:16:55
Modified files:
gcc/cp :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
12:27 ---
Subject: Bug 20333
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 12:26:37
Modified files:
gcc/cp :
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-19
12:27 ---
Fixed in 3.4/4.0/4.1.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
12:35 ---
Subject: Bug 20240
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-19 12:35:24
Modified files:
gcc/cp : ChangeLog decl.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
12:42 ---
Subject: Bug 20240
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 12:41:52
Modified files:
gcc/cp :
--
What|Removed |Added
Attachment #8421|application/octet-stream|text/plain
mime type||
--- Additional Comments From b201 at passagen dot se 2005-03-19 13:02
---
Danny, to me it seems you've got the solution.
What will happen next? Will your patch make it into
the next version, or does it have to be approved by
someone else, who might not think it's a bug at all?
Or
--- Additional Comments From p dot obry at wanadoo dot fr 2005-03-19 13:08
---
(In reply to comment #2)
The IS_TARGET_PE_COFF hack works on 3.4.x bit won't on trunk.
Here is a cleaner patch against trunk that replaces the preprocessor tests
with runtime tests. I have tested with
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-19 13:13
---
Confirmed; compile the following reduced testcase with -Wstrict-prototypes
to see the bug. I don't have --enable-checking release branch compilers
(4.0 and previous releases) to hand to see whether this is a
--
What|Removed |Added
Component|c |other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20525
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-19 13:18
---
I see no undefined behavior here. The order is unspecified, not undefined,
and there is nothing more wrong with accessing two volatile objects between
sequence points than there would be in (s.x = 1) + (s.y
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-19
13:20 ---
(In reply to comment #8)
Due to general gfortran lameness only contained functions are ever inlined.
Top-level functions are never inlined.
Why?
I've worked with a Fortrtran 77 compiler (vor
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-19 13:23
---
Could someone with a Darwin build to hand check whether this bug is indeed fixed
as I suggest in my previous comment?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:24 ---
(In reply to comment #10)
(In reply to comment #8)
Due to general gfortran lameness only contained functions are ever inlined.
Top-level functions are never inlined.
Why?
I think Paul means
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:30 ---
Reduced testcase:
templatetypename t1, typename t2
t1 unique(t1 v1, t1 v2, t2 v3){}
struct row
{
int begin() const ;
int end() const;
};
templateint s
void popSlot()
{
row ops;
unique(ops.begin,
--
What|Removed |Added
Attachment #8423|application/octet-stream|text/plain
mime type||
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-19 13:34
---
What you want is a better -Wconversion, warn for any implicit conversion that
may change a value; see bug 9072 (and also bug 6614). Bug 9072 effectively
tracks the need for a better -Wconversion while bug
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-19 13:34
---
*** Bug 20535 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
Keywords||ice-on-invalid-code
Known to work||4.0.0 4.1.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:39 ---
(In reply to comment #2)
Confirmed; compile the following reduced testcase with -Wstrict-prototypes
to see the bug. I don't have --enable-checking release branch compilers
(4.0 and previous releases) to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:45 ---
No you need to add the following to your code:
const char T::a;
Since you don't supply the memory location otherwise (which is required by the
standard).
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:48 ---
*** This bug has been marked as a duplicate of 6709 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
13:48 ---
*** Bug 20551 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-19
13:53 ---
But according the standard, 'const static' data members of an intergral type can
now be initialized _inside_ their class. In this case, the initialization is
_also_ a definition, so _no_ further
--- Additional Comments From charlet at adacore dot com 2005-03-19 13:54
---
Subject: Re: Windows errorcodes wrong in Ada when tasking
IMO, resetting the error code set by the kernel whenever the internal Ada
tasking functions are called successfully is a bug.
So you are saying
--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-19
14:01 ---
#include vector
struct T
{
static char const a = 3;
};
void
fff(char a)
{
}
std::vectorchar b;
int
main()
{
fff(T::a); /* this line of codes is fine. */
b.push_back(T::a); /* however, this line
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
14:01 ---
Subject: Bug 20240
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 14:01:02
Modified files:
gcc/cp :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
14:03 ---
(In reply to comment #2)
But according the standard, 'const static' data members of an intergral type
can
now be initialized _inside_ their class. In this case, the initialization is
_also_ a
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-19
14:15 ---
Fixed in 3.4/4.0/4.1.
--
What|Removed |Added
AssignedTo|lerdsuwa at gcc dot gnu
--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-19
14:15 ---
I understand what you mean.
But why the following codes works:
#include iostream
#include vector
struct T
{
static char const a = 3;
};
std::vectorchar ddd;
int
main()
{
--
What|Removed |Added
CC||ericw at evcohs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20530
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
14:34 ---
(In reply to comment #5)
I understand what you mean.
But why the following codes works:
#include iostream
#include vector
struct T
{
static char const a = 3;
};
std::vectorchar ddd;
int
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
14:43 ---
The following patches might be the cause:
+2005-03-18 Jan Hubicka [EMAIL PROTECTED]
+
+ PR middle-end/20225
+ * cgraph.c (cgraph_mark_reachable_node): Assert that it is not called
+ too
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
14:49 ---
Do you know if this happens on say x86_64 (so it will then be targeted towards
4.0.0 and someone can
look into it)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20510
--- Additional Comments From p dot obry at wanadoo dot fr 2005-03-19 14:52
---
I had a closer look.
In GCC 3.4.x we have TARGET_IS_PE_COFF. So changing _WIN32 by
TARGET_IS_PE_COFF is ok.
In GCC 4.x we have:
#define TARGET_DLLIMPORT_DECL_ATTRIBUTES 1
So instead of using
--- Additional Comments From laurent at guerby dot net 2005-03-19 14:59
---
I haven't tested x86_64 on current 4.0, will try this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:
binutils-2.15.94.0.2-1.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc4-4.0.0-0.8sparc.sparc
glibc-2.3.3-99.sparcv9
glibc-2.3.3-99.sparc64
glibc-devel-2.3.3-99.sparc64
--- Additional Comments From christian dot joensson at gmail dot com
2005-03-19 15:18 ---
[EMAIL PROTECTED] branch]$ /usr/local/src/branch/objdir32/gcc/xgcc -v
-save-temps -B/usr/local/src/branch/objdir32/gcc/ -O1 -w -c -o
2009-2.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-
--- Additional Comments From christian dot joensson at gmail dot com
2005-03-19 15:20 ---
This also happens on mainline, see
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01267.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20553
FAIL: gcc.c-torture/compile/2009-1.c -O0 (test for excess errors)
FAIL: gcc.c-torture/compile/2009-1.c -O1 (test for excess errors)
FAIL: gcc.c-torture/compile/2009-1.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/2009-1.c -O3 -fomit-frame-pointer (test for ex
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
15:34 ---
This also occurs on hppa64-hp-hpux11.11 (4.1.0)
--
What|Removed |Added
CC|
--
What|Removed |Added
CC||christian dot joensson at
||gmail dot com
--- Additional Comments From christian dot joensson at gmail dot com
2005-03-19 15:37 ---
I guess this is related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20553
and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20554
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-19
15:38 ---
Uncovered by a front-end change. Not sure it can work on 64-bit machines now.
--
What|Removed |Added
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
15:40 ---
Just a guess, but I would suspect this is caused by the following change:
2005-03-16 Richard Henderson [EMAIL PROTECTED]
PR middle-end/15700
* varasm.c (struct alias_pair): Rename from
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
15:41 ---
*** This bug has been marked as a duplicate of 20524 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
15:41 ---
*** Bug 20553 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20524
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
15:42 ---
2009-[12].c is a dup of bug 20524.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20554
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
15:44 ---
Subject: Bug 18251
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 15:44:26
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
15:45 ---
Subject: Bug 18251
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 15:45:41
Modified files:
gcc:
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
15:50 ---
On hppa2.0w-hp-hpux* (32-bit SOM targets), there is no assembler support
to create an alias except by emitting a label for the alias at the same
time as the target label. There is no way to defer emitting
After make install, PATH=... with mainline on x86_64 as of 20050319:
For C :
$ gcc z.c
/usr/bin/ld: crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status
For Ada:
$ gnatmake t.adb
fatal error, run-time library not installed correctly
cannot locate file
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
16:15 ---
What I was trying to indicate in the previous comment is that aliases
can be created on targets that don't support ASM_OUTPUT_DEF by emitting
the labels at the same time as the target label.
This happens
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
16:39 ---
*** This bug has been marked as a duplicate of 20537 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
16:39 ---
*** Bug 20555 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
16:46 ---
Subject: Bug 20493
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-19 16:46:04
Modified files:
gcc: ChangeLog fold-const.c
Log
Hi.
I'm writing a lookuptable container derived from 2 std::vectors (one public,
one
private).
The issue I came across can be witnessed by trying to compile:
[CODE]
#include iostream
#include cstdlib
using namespace std;
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
17:25 ---
The last comment needs qualification. The technique doesn't work for
common symbols because of the special assembler semantics used for these
symbols on 32-bit hpux. However, it does work for other code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
17:30 ---
Subject: Bug 20493
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 17:29:54
Modified files:
gcc:
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-19
17:38 ---
Fixed in CVS.
--
What|Removed |Added
Status|NEW
Executing on host: /home/dave/gcc-4.1/objdir/gcc/xgcc -B/home/dave/gcc-4.1/objdi
r/gcc/ /home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.dg/pr18628.c -O2 -lm -o pr1
8628.exe(timeout = 300)
/home/dave/gcc-4.1/gcc/gcc/testsuite/gcc.dg/pr18628.c: In function 'main':
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
17:50 ---
Name lookup happens before accessibility happens. They are not tied together.
This is invalid. You can use a using statement in class C to remove the
ambigous.
--
What|Removed
--
What|Removed |Added
Target Milestone|4.1.0 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20493
--- Additional Comments From Hu dot YuehWei at gmail dot com 2005-03-19
18:25 ---
I see.
But why compiler doesn't also make a temporary variable for the constant defined
in a class scope?
Such as following codes:
struct T
{
static int const a = 3;
};
void
fff(int const a)
{
}
int
__builtin_isinf, __builtin_isnan and the various __builtin_is* functions
for unordered comparisons are declared as functions taking variable
arguments so they can be used directly to implement the corresponding C99
type-generic macros. However, __builtin_isinf does not work properly
as
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
18:35 ---
Bacause T::A is a lvalue.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
18:38 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-19
18:58 ---
Actually you can get this from any trivial implicit set-like
code, for example:
int b;
void foo (int a) {
if (a)
a = 3;
b = a;
}
The out-of-ssa pass turns that
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-19
19:33 ---
FWIW this bug is a major source of ifcvt1 opportunities, so fixing it
has positive downstream effects too.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
19:45 ---
Subject: Bug 18525
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-19 19:45:46
Modified files:
gcc/fortran: ChangeLog dump-parse-tree.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-19
19:53 ---
Subject: Bug 18525
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-19 19:52:53
Modified files:
gcc/fortran:
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-19 19:54
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
cannot link program which uses std::(vector. deque) in SuSE AMDx86_64
The compiler version is the default which comes with SuSE 9.2.
gcc (GCC) 3.3.4 (pre 3.3.5 20040809). The same program on SuSE 9.2
for i386 has no problem linking!
here it is:
---
#include iostream
using
--- Additional Comments From pcarlini at suse dot de 2005-03-19 20:52
---
Sorry about the apparently not-so-helpful reply, but really I think something is
broken with your specific setup: if this were a real bug, then basically no
non-trivial c++ program would work on x86_64, and this
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-19 20:54 ---
In reply to comment #3
From gnat_ugn.texi:
@findex Stdcall
@cindex Convention Stdcall
@item Stdcall
This is relevant only to NT/Win95 implementations of GNAT,
and specifies that the Stdcall
At the moment it only warns, if there _is_ a non-virtual destructor:
-Wnon-virtual-dtor (C++ only)
Warn when a class appears to be polymorphic, thereby requiring a
virtual destructor, yet
it declares a non-virtual one. This warning is enabled by -Wall.
It doesn't
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:04 ---
Fixed in 4.0.0 and above.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:05 ---
Fixed in 4.0.0 and above already.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:05 ---
Actually this is a dup, so reopening.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:06 ---
This is a dup of bug 16190.
*** This bug has been marked as a duplicate of 16190 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:06 ---
*** Bug 20560 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:07 ---
Woops wrong bug.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:07 ---
I had meant PR 11624.
*** This bug has been marked as a duplicate of 11624 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-19
21:07 ---
*** Bug 20560 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From dkouroun at cc dot uoi dot gr 2005-03-19
22:03 ---
Subject: Re: cannot link program which uses std::(vector. deque) in SuSE
AMDx86_64
Quoting pcarlini at suse dot de [EMAIL PROTECTED]:
--- Additional Comments From pcarlini at suse dot de
1 - 100 of 127 matches
Mail list logo
