--- Comment #3 from christian dot bruel at st dot com 2007-04-03 07:43
---
thank you for reporting this,
There is indeed a data dependency on 'r2' introduced by the cmp/eq instruction,
preventing the mov and the comparaison to be executed in parallel, unlike the
dt on the induction var
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-03 07:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from steven at gcc dot gnu dot org 2007-04-03 07:17 ---
Need to reverse the loop counter here.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-03 06:33 ---
To reproduce this on the trunk use "#define PAR i*2+1000-i-i" instead for the
complex one.
For PPC, VARIABLE_PAR is actually slower, as it tries to use (long unsigned
int) i * 8 as the index and PPC does not have th
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-03 06:23 ---
Most likely what needs to happen is reverse the loop count.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #34 from pinskia at gcc dot gnu dot org 2007-04-03 06:19
---
*** Bug 31181 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-03 06:19 ---
>it is being set before being used within a loop that will always execute at
>least 16 times.
And the compiler does not know it can be executed at least once as -Os
-fno-tree-dominator-opts turns off jump threading
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-04-03 06:03 ---
(In reply to comment #5)
> Why are you storing to the stack?
The PPC issue is only an issue on the trunk, so I filed PR 31455 for that bug.
But I bet this bug is related to some extend.
--
http://gcc.gnu.org/
--
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=31455
Testcase:
#include
#include
#define SIZE 256*1024*1024
float *data;
static inline
double one()
{
int i;
double sum;
sum = 0;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=31455
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-03 05:49 ---
The same thing happens on PPC also:
L6:
lfsx f0,r2,r9
addi r2,r2,4
lfd f13,104(r1)
fadd f13,f13,f0
stfd f13,104(r1)
bdnz L6
Why are you storing to the stack? Ok, part
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-03 04:36 ---
This is not a bug. You are allowed to call protected functions on this but
nobody elses.
This has nothing to do with derived class or not. This is just how C++ works.
--
pinskia at gcc dot gnu dot org changed:
The code:
struct base {
protected:
virtual void foo() {}
};
struct der : public base {
virtual void foo() { p->foo(); }
base* p;
};
gets you:
~/ootbc/sim/test$ g++ foo.cc
foo.cc: In member function 'virtual void der::foo()':
foo.cc:3: error: 'virtual void base::foo()' is prote
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/mnt/gnu/gc
c/objdir/gcc/testsuite/g++/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g+
+.mike/p4736b.C -nostdinc++
-I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc
++-v3/include/hppa2.0w-hp-hpux11.11
-I/mnt/gnu/gcc/objdi
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/mnt/gnu/gc
c/objdir/gcc/testsuite/g++/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/tree-ssa
/pr29585.C -nostdinc++
-I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3
/include/hppa2.0w-hp-hpux11.11
-I/mnt/gnu/gcc/objdir/hpp
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/mnt/gnu/gc
c/objdir/gcc/testsuite/g++/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ctor3
.C -nostdinc++
-I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
/hppa2.0w-hp-hpux11.11
-I/mnt/gnu/gcc/objdir/hppa2.0w-hp
--- Comment #1 from tromey at gcc dot gnu dot org 2007-04-03 01:48 ---
... and it should be using madvise and msync for the other methods.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31450
Right now natFileChannelPosix.cc has stubs for loadImpl and
isLoadedImpl. Instead it should use mincore for the latter,
when mincore is available.
--
Summary: natFileChannelPosix.cc should use mincore
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2007-04-03 01:04
---
Yes, this is fixed, closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
The following const-incorrect program compiles without error on gcc 4.1.0, and
4.3.0 20070323:
class Foo {};
class Bar : public Foo {};
static const Foo *foo = 0;
static Bar *bar = static_cast(foo); // Error, casts away const
void func(const Foo *foo) {
Bar *bar = static_cast(foo); // Error,
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-02 23:28 ---
> You can found the complete ranlux.f subroutine at
> http://www.systella.fr/~bertrand/rpl2/download/rpl-4.00pre8q.tar.bz2
The program does not compile for me:
gfortran ./src/fonctions_speciales.conv.f90
./src/fonc
--- Comment #8 from manu at gcc dot gnu dot org 2007-04-02 23:25 ---
Fixed in GCC 4.3, if someone wants to backport it to old branches, go ahead,
the patch should apply cleanly and the Changelog would be similar.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-02 23:10 ---
Hmm, I cannot reproduce this on x86_64-unknown-linux-gnu/openSUSE 10.2 with
either gcc 4.2 (vanilla) nor with gcc 4.3 (current SVN, very mildly patched)
and with neither -m32 nor -m64 running under valgrind. (This is
--- Comment #5 from aesok at gcc dot gnu dot org 2007-04-02 23:03 ---
Fixed.
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from aesok at gcc dot gnu dot org 2007-04-02 23:00 ---
Subject: Bug 31137
Author: aesok
Date: Mon Apr 2 23:00:28 2007
New Revision: 123439
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123439
Log:
PR target/31137
* config/avr/avr.c (avr_rtx_costs
--- Comment #3 from aesok at gcc dot gnu dot org 2007-04-02 22:53 ---
Subject: Bug 31137
Author: aesok
Date: Mon Apr 2 22:53:14 2007
New Revision: 123438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123438
Log:
PR target/31137
* config/avr/avr.c (avr_rtx_costs
--- Comment #18 from burnus at gcc dot gnu dot org 2007-04-02 22:49 ---
Is this PR fixed or not? Looking at the initial and the additional example, it
seems to be fixed both in 4.2 and in 4.3. Can this PR be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
--- Comment #7 from giovannibajo at libero dot it 2007-04-02 22:47 ---
Anatoly, can you have a look? It's a regression in 4.2 for AVR!
--
giovannibajo at libero dot it changed:
What|Removed |Added
---
--- Comment #2 from aesok at gcc dot gnu dot org 2007-04-02 22:44 ---
Subject: Bug 31137
Author: aesok
Date: Mon Apr 2 22:43:53 2007
New Revision: 123437
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123437
Log:
PR target/31137
* config/avr/avr.c (avr_rtx_costs
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.0.4 4.1.2 4.2.0 4.3.0
Known to work|
typedef struct _st {
int iIndex : 24;
} st;
void f(void)
{
st *next = 0;
int nIndx;
const static int constreg[] = { 0,};
nIndx = 0;
next->iIndex = constreg[nIndx];
}
[EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t2.c -O1
t2.c: In function 'f':
t2.c:10: internal compiler
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-04-02 22:13
---
> It seems that many maintainers ar not doing the complete (and quite time
> consuming bootstrapping) during the non-regression period.
I think that is wrong as most are, just some forgot to double check. Like a
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-04-02 21:52
---
Any news on this one?
The bug makes tree vectorization on pentium 4 totally useless. :-(
Btw, here's a smaller code snippet for testing. Just compile it with
gcc -O -msse2 -ftree-vectorize
on a pentium 4 and see
It would be nice if gfortran had an option to set intent(out) arguments to NaN
or some random values, so that code mistakenly relying on intent(out) arguments
starting with the same value as in the caller would be detected. This is
related to the question of detecting on uninitialized variables.
F
--- Comment #1 from pcarlini at suse dot de 2007-04-02 21:41 ---
Thanks for your report. Luckily you have been able to notice this before the
release of 4.3.0...
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
The following invalid code snippet triggers an ICE on mainline and 4.2 branch:
===
template struct A
{
template friend void foo();
};
void bar()
{
foo<0>();
}
===
bug.cc:1: error:
--- Comment #8 from maskva at searxhmash dot com 2007-04-02 21:27 ---
Created an attachment (id=13319)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13319&action=view)
ned
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31445
More fallout from the variadic templates on mainline:
===
template struct A
{
void foo(T...);
A(T... t) { foo(t); }
};
A a(0);
===
This is only a diagnostic problem in the second
--- Comment #3 from ramiro at lisha dot ufsc dot br 2007-04-02 21:24
---
Hello,
That and many other combinations fix the issue. Including changing the code
around the inline asm, or using different optimizations.
What seems wrong is that gcc uses the same register for 2 outputs. Maybe
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31444
More fallout from the variadic templates on mainline:
===
template struct A
{
template void foo(A);
};
void bar()
{
A().foo<0>(A());
};
===
bug.cc:3: error: parameter packs not exp
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31443
More fallout from the variadic templates on mainline:
===
template struct A
{
template void foo(A);
};
void bar()
{
A<0,int>().foo(A<0,int>());
};
===
bug.cc:3: error: parameter pa
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31442
More fallout from the variadic templates on mainline:
===
template struct A {};
struct B
{
template class C> B(C);
};
B b = A();
===
bug.cc:1: error: parameter packs not expanded w
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31441
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-04-02 21:00
---
The library version doesn't do too badly compared
to the inline version:
$ cat benchmark-inline.f90
program main
implicit none
integer, dimension(1) :: n
real, allocatable :: a(:)
integer :: i
allocate
More fallout from the variadic templates on mainline:
===
template struct A;
template struct A {};
A a;
===
bug.cc:3: error: cannot expand 'T ...' into a fixed-length argument list
bu
Making all in Core
make[3]: Entering directory
`/var/tmp/portage/dev-lang/maude-2.1.1-r2/work/maude-2.1.1/src/Core'
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/Utility
-I../../src/Interface -I../../src/Variable -I../../src/FullCompiler -O2 -pipe
-mcpu=G4 -fomit-frame-pointer -Wno-deprecat
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31439
More fallout from the variadic templates on mainline:
===
template struct A;
template struct A<> {};
template struct A : A {};
A a;
===
bug.cc:3: error: template parameters not used
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31438
More fallout from the variadic templates on mainline:
===
template struct A;
template struct A
{
template A(X);
};
A a(0);
===
bug.cc:3: error: parameter packs not expanded with `..
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31437
More fallout from the variadic templates on mainline:
===
template struct A
{
A(T* p) { (A*)(p); }
};
A a(0);
===
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31436
More fallout from the variadic templates on mainline:
===
template int foo(const T&)
{
union { T t; };
return t;
}
void bar()
{
foo(0);
}
===
bug.cc:1: error: parameter packs not
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31435
More fallout from the variadic templates on mainline:
===
template void foo(T) {}
void bar()
{
foo(0);
}
===
bug.cc:1: error: parameter packs not expanded with `...':
bug.cc:1: note:
--- Comment #32 from schwab at suse dot de 2007-04-02 20:42 ---
unwind-compat is _required_ for the system libunwind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
--- Comment #9 from malitzke at metronets dot com 2007-04-02 20:39 ---
I believe this report can be closed. I was able to find the start date
(2061125)
or a day later when I could no longer bootstrap. It disappeared towards the end
of January 2007. It prevented bootstrapping on x86 but n
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31434
More fallout from the variadic templates on mainline:
===
template void foo(const T...) {}
void bar()
{
foo(0);
}
===
bug.cc: In function 'void foo(T ...) [with T = int]':
bug.cc:5:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31433
More fallout from the variadic templates on mainline:
===
template struct A
{
static int i;
};
A a;
A b;
===
bug.cc:1: error: parameter pack '' must be at the end
of the template par
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31432
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-02 20:27 ---
Adding this to TRANSFER meta-bug, as frame 3 in the backtrace indicates a
relation. No confirmation as I can not tell whether it is a dupe or not.
(gdb) bt
#0 fancy_abort (file=0x86e4fec "../../../gcc/gcc/fortran/t
More fallout from the variadic templates on mainline:
===
template struct A
{
enum { N };
};
A a;
===
bug.cc:1: error: parameter pack '' must be at the end
of the template parameter
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31431
The following (IMHO invalid) code snippet triggers an ICE on mainline:
===
template void foo();
void bar()
{
foo();
}
===
bug.cc: In function 'void bar()':
bug.cc:5: internal compile
--- Comment #8 from jason at gcc dot gnu dot org 2007-04-02 20:12 ---
Subject: Bug 31187
Author: jason
Date: Mon Apr 2 20:12:15 2007
New Revision: 123434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123434
Log:
PR c++/31187
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-02 20:10 ---
Can confirm a crash in f951. Since there were quite a lot of TRANSFER related
reports lately, I can not tell if this a new one.
Backtrace:
Starting program:
/home/daniel/i686-pc-linux-gnu/gcc/libexec/gcc/i686-pc-lin
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
*** Bug 31430 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
*** This bug has been marked as a duplicate of 31429 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
This was caused by the conversion of "l" constaint to hard registers. I sent a
patch to Andreas T. to test as I don't have an up todate sources on my
ppc-darwin machine that I use to test patches.
--
pinskia at
(~100) of regressions: gcc.c-torture/execute/builtins/memcpy-chk.c, ...,
gcc.c-torture/execute/built-in-setjmp.c. Looking at the list, I have found
that this has started on 20070325 for Darwin8:
http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg01225.html
Note that the errors are all of the follo
--
Summary: Is anybody monitoring the daily regression tests on
Darwin 8.5?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 ---
*** This bug has been marked as a duplicate of 31427 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 ---
*** Bug 31428 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
When I compile the following program I get the message "GNU MP: Cannot
reallocate memory"
PROGRAM test
INTEGER(KIND=1) :: i(1)
i = (/ TRANSFER("a", 0) /)
END PROGRAM test
--
Summary: When I compile the following program I get the message
"GNU MP: Cannot reallocate
--- Comment #7 from jason at gcc dot gnu dot org 2007-04-02 18:49 ---
Subject: Bug 31187
Author: jason
Date: Mon Apr 2 18:49:21 2007
New Revision: 123432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123432
Log:
PR c++/31187
When I compile the following program I get the message "GNU MP: Cannot
reallocate memory"
PROGRAM test
INTEGER(KIND=1) :: i(1)
i = (/ TRANSFER("a", 0) /)
END PROGRAM test
--
Summary: When I compile the following program I get the message
"GNU MP: Cannot reallocate
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-04-02 17:44
---
I'll give this another shot.
Maybe inlining isn't even necessary for good performance...
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from eweddington at cso dot atmel dot com 2007-04-02 17:41
---
Can someone please commit this patch? I need this for mingw-hosted cross
toolchains.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-02 17:26 ---
Ah, I see.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from bangerth at dealii dot org 2007-04-02 17:09 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 16:38 ---
This fixes the problem and regtests:
Index: gcc/fortran/parse.c
===
*** gcc/fortran/parse.c (révision 123426)
--- gcc/fortran/parse.c (copie de travail)
--- Comment #31 from sje at cup dot hp dot com 2007-04-02 16:36 ---
When configuring with --with-system-libunwind, GCC should not include
unwind-compat.o (or any unwind code) in the build of libgcc_s. Then the
configure check will work correctly.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-04-02 16:32 ---
I don't think it is a feature.
In C++0x mode, if one includes , one should get std::tuple. That's what
the C++0x working paper says.
In any mode, if one includes , one should get std::tr1::tuple.
That's what TR1 s
--- Comment #8 from bonzini at gnu dot org 2007-04-02 16:22 ---
... because GCC now has -mpc to limit precision for float/double operations.
Even as far as x86 is concerned, this is a "special case" of PR323, and thus
I'm closing it as fixed.
--
bonzini at gnu dot org changed:
--- Comment #7 from bonzini at gnu dot org 2007-04-02 16:21 ---
Reopened...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #94 from bonzini at gnu dot org 2007-04-02 16:20 ---
I think that Uros' patch to add a -mpc switch for precision control would "fix"
this.
The real fix would be to automatically insert fldcw instructions before
float/double operations, in order to limit the precision of the
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-02 16:18 ---
isn't that a feature?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
--- Comment #5 from hjl at lucon dot org 2007-04-02 15:57 ---
Fixed in gcc 4.1.3 and 4.2.0.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONF
--- Comment #4 from hjl at gcc dot gnu dot org 2007-04-02 15:55 ---
Subject: Bug 31380
Author: hjl
Date: Mon Apr 2 15:55:17 2007
New Revision: 123429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123429
Log:
2007-04-02 H.J. Lu <[EMAIL PROTECTED]>
* Backport from mai
--- Comment #3 from hjl at gcc dot gnu dot org 2007-04-02 15:54 ---
Subject: Bug 31380
Author: hjl
Date: Mon Apr 2 15:53:48 2007
New Revision: 123428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123428
Log:
2007-04-02 H.J. Lu <[EMAIL PROTECTED]>
* Backport from mai
When the compiler is provided with -std=c++0x to enable the experimental C++0x
mode, includes of TR1 facilities (e.g., tr1/tuple) do not put TR1 functionality
into namespace std::tr1, breaking backward compatibility. Here's an example
program that compiles without -std=c++0x but does not compile wi
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
1 - 100 of 121 matches
Mail list logo
