--- Additional Comments From paolo dot bonzini at polimi dot it 2004-10-11 07:18
---
Subject: Re: [4.0 Regression] ABI breakage for 16-byte
vectors (non-Altivec ABI ISA)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-10 20:27
---
Causes these two
-exceptions --enable-languages=c,c++
--disable-libgcj
Thread model: posix
gcc version 4.0.0 20041011 (experimental)
--
Summary: ICE involving 'goto' to jump into loop
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
--- Additional Comments From bryner at brianryner dot com 2004-10-11 07:54 ---
Created an attachment (id=7321)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7321action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17928
--
What|Removed |Added
CC||christian at j-son dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 08:52
---
Joseph, your fix is only a partial one. We still ICE if no argument at all
is passed to __builtin_stdarg_start:
=
void foo (char *format, ...)
{
__builtin_stdarg_start
Mark, your patch for PR 17393
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00485.html
breaks the test testsuite/g++.dg/parse/qualified2.C
namespace Glib {
template typename class Value {};
template class Glib::Valueint
--
What|Removed |Added
Target Milestone|--- |3.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17929
--- Additional Comments From aph at redhat dot com 2004-10-11 09:11 ---
Subject: can't build GNU Classpath
I think I'm going to have to give up on this bug. If I can't
duplicate the problem myself and you can't duplicate the propblem on
any machine to which I have access there's
--- Additional Comments From giovannibajo at libero dot it 2004-10-11 09:28
---
(In reply to comment #4)
I disagree with the notion that it is just a diagnostic related issue;
because it comes with a semantics part. Let's not not disguise a
language extension under the name of
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 09:42
---
Roger, your patch for PR 17853
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00486.html
fixed PR17767 on the 3.4 branch. The problem on mainline remains, though.
Could you please have a look?
--
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 10:27
---
*** This bug has been marked as a duplicate of 17560 ***
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 10:28
---
*** Bug 17928 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2004-10-11 10:45
---
Lu Zero, I'm revisiting this bug report. The testcase you provided cannot be
executed to check for the miscompilation, which makes it very difficult for us
to check for the problem.
Would you please
--- Additional Comments From pavenis at latnet dot lv 2004-10-11 10:53 ---
One more trap:
DJGPP includes are expected to be at $prefix/$target/sys-include.
Symbolic link of $prefix/$target/include to it should suffice.
Verified that absence of such directory causes described
--- Additional Comments From giovannibajo at libero dot it 2004-10-11 10:56
---
Zack, do you confirm that the semantics of restrict (in C99 and/or GNU C) allow
us to schedule the load before the store even if there is only one restrict
pointer? Otherwise, this bug report is invalid.
--- Additional Comments From giovannibajo at libero dot it 2004-10-11 10:57
---
Daniel, Richard, is still bug still actual? Can we move this to confirmed
status if you agree on the bug? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202
--- Additional Comments From giovannibajo at libero dot it 2004-10-11 10:58
---
Confirmed. There is some discussion going on about this.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2004-10-11 11:09
---
Created an attachment (id=7322)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7322action=view)
Testcase
Attacched the testcase. In future, please do not copy paste large testcases
into a comment, but
--- Additional Comments From redi at gcc dot gnu dot org 2004-10-11 11:39 ---
Carlo, I realise the text (which I've committed btw) is quite Boost-specific,
that's because
1) Boost is the only code I use which is affected by this PR (selfish, I know)
2) Boost is the only library for which
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 11:47
---
Here's a reduced testcase:
===
int foo()
{
unsigned char c;
switch ((int)c)
{
case -1:
case 0:
case 4:
case 5:
case 42:
return 0;
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|REOPENED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 11:52
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From bruno at clisp dot org 2004-10-11 11:55 ---
This result is even better: shorter than the previous ones, and there are
no useless moves between registers any more.
However, there are more useless moves from register to stack slot and back
from stack slot
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 11:55
---
I think this is case where asm __volatile__ can be moved around (not scheduled though).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14330
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 12:00
---
Closing as works for me as there was no feedback in 3 months (T-9 days) and it worked
for Benjamin
Kosnik.
--
What|Removed |Added
Using the option -mfpmath=sse in g77 (to use SSE instructions for
floating point arithmetic) can create illegal code, or at least
code that is called with illegal arguments. Specifically, I have a
test case where a movapd instruction is called with a second
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 12:03
---
*** This bug has been marked as a duplicate of 14776 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 12:03
---
*** Bug 17930 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From Frank dot Otto at tc dot pci dot uni-heidelberg dot
de 2004-10-11 12:09 ---
(In reply to comment #13)
*** Bug 17930 has been marked as a duplicate of this bug. ***
However, Bug 17930 might still be worth looking at, since it
includes a fortran source file
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 12:21
---
Confirmed. In fact we have:
enum _Ios_Seekdir { _S_ios_seekdir_end = 1L 16 };
class ios_base
{
typedef _Ios_Seekdir seekdir;
static const seekdir beg = seekdir(0);
static const seekdir
--- Additional Comments From redi at gcc dot gnu dot org 2004-10-11 12:22 ---
I've been thinking about this PR, probably too much. I assume my concerns are
unfounded, or we'd have noticed bigger problems by now, but here goes:
The change to gthr-posix.h means that if GCC is configured
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 12:50
---
gcc/fixinc does not exist on the mainline any more (as it was moved to the toplevel)
so this is not a
mainline problem, only a CVS problem so I am removing the target milestone and the
regression
marker
--- Additional Comments From bangerth at dealii dot org 2004-10-11 12:54 ---
I concur with Giovanni: this is a case very much like the format
checking for printf and attribute sentinel. If you simply remove
the attribute statement, then the generated code is exactly the
same in all
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 13:21
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00904.html, Mine.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 13:45
---
Note that I can reproduce it with a full bootstrap compiler but not with just stage 1
so something is
causing wrong code somewhere.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 13:49
---
Andreas, yes please for PPC and/or x86.
It might be we are miscompiling GCC :(.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17656
Consider:
struct flags {
unsigned f0 : 1;
unsigned f1 : 1;
};
_Bool
foo (struct flags *p)
{
if (p-f0)
return 1;
return p-f1;
}
With cc1 -O2 -fomit-frame-pointer, I get
foo:
movl4(%esp), %eax
movb(%eax), %dl
movb%dl, %al
andl$1, %eax
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-11 13:54 ---
Actually, we don't need movl $1, %eax at the end, either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17931
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 14:01
---
Confirmed, combine does not simplify:
(insn 14 13 15 0 (parallel [
(set (reg:QI 64)
(and:QI (reg:QI 63)
(const_int 1 [0x1])))
(clobber (reg:CC 17
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 14:06
---
Note PPC's resulting asm is so much better:
lwz r3,0(r3)
li r0,1
cmpwi cr7,r3,0
blt- cr7,L4
rlwinm r0,r3,2,31,31
L4:
mr r3,r0
blr
But can be improved
When compiling glibc-2.3.3 (configured from a new subdir obj using simply
../configure --enable-add-ons), I get the following error message in glibc
subdirectory elf. The problems seems to be a gcc bug, since gcc-3.3.4 compiles
fine (and since I could not really see why the types should conflict).
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 14:12
---
This is a regression from 2.95.3:
movl 4(%esp),%eax
testb $1,(%eax)
jne .L3
movb (%eax),%al
shrb $1,%al
andl $1,%eax
ret
.p2align 4,,7
.L3:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 14:14
---
See http://gcc.gnu.org/ml/gcc/2004-03/msg00039.html for why this was changed.
*** This bug has been marked as a duplicate of 15095 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 14:14
---
*** Bug 17932 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
Summary|[3.4/4.0 regresssion] ICE |[4.0 regresssion] ICE with
|with qualified name in |qualified name in template
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-11 14:47 ---
The combiner does try to combine andl and testb,
but the suggested combined insn is rejected by combine_validate_cost.
The cost of andl $1, %eax is 4.
The cost of testb %al, %al is 4.
So the original total
--- Additional Comments From pcarlini at suse dot de 2004-10-11 14:47 ---
By the way, the other flags (e.g. openmode, iostate, fmflags) are affected by the
same problem. Unfortunately, I'm not sure we can fix this within the 3.4/4.0 ABI.
--
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 14:53
---
Andrew, 3.4 branch is also affected, since Mark also patched the 3.4 branch:
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00488.html
See for example
http://gcc.gnu.org/ml/gcc-testresults/2004-10/msg00524.html
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 14:57
---
Sorry, Andrew, I didn't see Mark's reply to your patch.
It would have helped, if you said, why you changed the milestone etc.
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 14:58
---
Fixed on the 3.4 branch by
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00909.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17929
--- Additional Comments From dje at gcc dot gnu dot org 2004-10-11 15:03 ---
Failures fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From mark at codesourcery dot com 2004-10-11 15:05 ---
Subject: Re: [4.0 regresssion] ICE with qualified name in
template specialization
reichelt at gcc dot gnu dot org wrote:
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 14:58
The following regression occurs in the objc testsuite:
Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc -B/test/gnu/gcc-3.3/objdir/
gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc/execute/class_self-2.m -w -O2 -
I/test/gnu/gcc-3.3/gcc/gcc/testsuite/../../libobjc -L/test/gnu/gcc-3.3/objdir/hp
--- Additional Comments From aj at gcc dot gnu dot org 2004-10-11 15:28 ---
(In reply to comment #6)
Andreas, yes please for PPC and/or x86.
It might be we are miscompiling GCC :(.
Here's the actual call on 32-bit ppc:
# gcc -DHAVE_CONFIG_H -I. -I. -I..
--- Additional Comments From aj at gcc dot gnu dot org 2004-10-11 15:29 ---
Created an attachment (id=7325)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7325action=view)
Preprocessed file for Linux/PPC
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17656
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-11 15:32 ---
I'll be testing a patch shortly.
--
What|Removed |Added
AssignedTo|unassigned at gcc
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 15:47
---
Here's a reduced testcase that fails with -O on i686-pc-linux-gnu:
int sprintf (char *s, const char *format, ...);
int foo(int i, int j)
{
char *buf,
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-11 15:54 ---
gfortran uses its own constant folder, which uses the mpfr library. Apparently
the precision is too low for double precision. Output from -fdump-parse-tree
includes:
ASSIGN big 6.6686534882e-1_8
So
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 15:55
---
/* Verify the counts of basic block notes in single the basic block
regions. */
Hmm.
--
What|Removed |Added
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-11 16:00 ---
Actually, looking at this again, gfortran's behavior is correct.
If you had written
big = 2.0_8 / 3.0_8
you would have gotten the result you were expecting.
I think, adding a warning would be the best route
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2004-10-11
16:06 ---
Subject: Re: [4.0 Regression] ICE: in schedule_in
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11
15:55 ---
/* Verify the counts of basic block notes in
For whatever reason, the attached program, when compiled with the options
gcc-3.4 -msse2 -O0 test.c -o test
will crash. This is not the case if -O2 is specified or -march=i686.
However, I have a larger testcase (the program this came from) which will fail
regardless of optimization flags or
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 03:42
---
The orginal testcase is now fixed by the patch to the C++ front-end.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-11 16:11
---
Subject: Bug 17657
CVSROOT:
--- Additional Comments From terpstra at ito dot tu-darmstadt dot de 2004-10-11
16:13 ---
Created an attachment (id=7326)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7326action=view)
The program which demonstrates the problem
Here's what I narrowed it down to.
Compile with:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-11 16:17
---
The outer record type is a derived type of the inner record type so the
expression is supposed to be a dereference through a polymorphic access type.
Investigating.
--
What|Removed
--- Additional Comments From terpstra at ito dot tu-darmstadt dot de 2004-10-11
16:17 ---
Oh, and this problem doesn't occure in gcc 3.3.
However, gcc-3.3 ICEs on the larger program.
Since it at least compiles on gcc-3.4, I assume that is a different bug which
got fixed.
--
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-11 16:19
---
Eric, the regression appears with your patch
http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg01039.html
Could you please have a look?
--
What|Removed |Added
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot
de 2004-10-11 16:25 ---
Subject: Re: gfortran .mod files have unusual entries
about private common blocks
[ I've added the bug database to the CC list again, this way this discussion
will be archived
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-11 16:28 ---
This has been a topic of heated discussion in the past. See the bug I added as a
dependency and the various discussions this had spawned. I think as I always
thought that we're safe from the point of view of
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-11 16:37 ---
The most suspicious commits are:
2004-07-10 Tobias Schlueter [EMAIL PROTECTED]
Paul Brook [EMAIL PROTECTED]
PR fortran/13415
* trans-common.c (calculate_length): Remove ...
Consider:
struct flags {
unsigned f0 : 1;
};
_Bool
bar (struct flags *p, struct flags *q)
{
return (!p-f0 !q-f0);
}
With cc1 -O2 -fomit-frame-pointer -march=i386, I get
bar:
movl4(%esp), %eax
testb $1, (%eax)
jne .L9
movl8(%esp), %eax
While attempting to compile the NIST FDS4 code (f90 based) I get the
following error
pcp05454784pcs:~/Codes/Fortran_Compiles/fds_test_compile jakoski$ make
gfortran -c -O3 -ffixed-form mods.f
mods.f:628: internal compiler error: backend decl for module variable
y_f_inlet already exists
Please
The following code snippet does not compile any more on mainline:
==
templateint, int N struct A
{
void foo();
};
templateint N struct A1, N
{
void foo();
};
template void A1, 2::foo();
==
vectors.cc:11: error: prototype
--
What|Removed |Added
BugsThisDependsOn||17936
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17522
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-11 16:59
---
Subject: Bug 17929
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-11 16:59:24
Modified files:
gcc/cp : ChangeLog decl2.c
Log message:
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-11 17:01
---
Fixed in GCC 4.0.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:02
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
On Oct 11, 2004, at 12:38 PM, Joe Koski wrote:
backend decl for module variable
This is most likely the same as PR 17917.
Thanks,
Andrew Pinski
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:04
---
Confirmed.
--
What|Removed |Added
Severity|normal |critical
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:08
---
There are some missed PHI-OPT but that is already fixed on the tcb branch.
there are some missed forward propagation opertunies though (I don't know if they are
fixed on the tcb
or not).
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:09
---
*** This bug has been marked as a duplicate of 10395 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:09
---
*** Bug 17934 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:12
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00918.html.
Confirmed.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:13
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00915.html.
--
What|Removed |Added
--- Additional Comments From lu_zero at gentoo dot org 2004-10-11 17:16 ---
Fixed at least on gcc-3.4.x and in the hammer branch.
gcc-3.3.4 should have other problems (I didn't check yet)
the best way to check about the problem works is just use mplayer or ffplay...
--
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:20
---
Fixed so closing.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From terpstra at ito dot tu-darmstadt dot de 2004-10-11
17:21 ---
My bug #17934 was merged with this one.
However, my test case demonstrates the problem WITHOUT threads.
The same issue appears with a single-threaded application of sufficient complexity.
--
--- Additional Comments From terpstra at ito dot tu-darmstadt dot de 2004-10-11
17:22 ---
This bug does not in any way involve multiple threads.
In my attached test case, gcc starts with an aligned stack and screws up the
alignment by itself.
--
What|Removed
Michael Matz distilled this simple testcase from KDE arts:
#include string
#include list
using namespace std;
static liststring modulePath;
int main()
{
modulePath.push_back(hallo);
return 0;
}
The attached valgrind output clearly shows that ~__pool is still not ok,
unfortunately.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:24
---
Confirmed, this is 4.0 Regression again.
3.4.0 gives:
bar:
movl4(%esp), %eax
xorl%edx, %edx
testb $1, (%eax)
jne .L2
movl8(%esp), %ecx
testb
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:26
---
No, the problem is that main is not aligned see that bug again.
*** This bug has been marked as a duplicate of 10395 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:26
---
*** Bug 17934 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10395
--- Additional Comments From pcarlini at suse dot de 2004-10-11 17:26 ---
Created an attachment (id=7327)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7327action=view)
Valgrind (2.2, --tool=memcheck) output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
--- Additional Comments From pcarlini at suse dot de 2004-10-11 17:38 ---
Forgot to add: to reproduce, remember to provide --enable-__cxa_atexit at build
time!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:43
---
This fixes the problem for me (basically what this patch does is gets rid of the check
for CALL_EXPR
because we do the fold later and it would not cause any other issue):
Diego, what do you think of this
=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --disable-libgcj
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.0 20041011 (experimental)
--
Summary: cannot assign result to const reference if copy ctor is
not accessible
--
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17938
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:53
---
Here is a C example which is almost equivalent to the objective-C example:
struct d
{
int a;
};
void abort(void);
typedef struct d (*f) (int i);
f ff(void);
void test1(void)
{
if ((ff())(0).a != 0)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-11 17:57
---
Please consult http://gcc.gnu.org/bugs.html#cxx_rvalbind.
There are other reports of the same bug.
*** This bug has been marked as a duplicate of 17227 ***
--
What|Removed
1 - 100 of 196 matches
Mail list logo
