public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/42880]  New: trunk does not compile boost MPL
@ 2010-01-27 10:42 piotr dot wyderski at gmail dot com
  2010-01-27 10:44 ` [Bug c++/42880] " piotr dot wyderski at gmail dot com
                   ` (47 more replies)
  0 siblings, 48 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 10:42 UTC (permalink / raw)
  To: gcc-bugs

gcc version 4.5.0 20100126 (rev. 156253) is
not able to compile the following "program":

#include <boost/mpl/size.hpp>

version 20100115 didn't complain. I've checked
it on boost 1.37 and 1.39. For those who don't
have boost installed, there is a preprocessed
file from boost 1.39.


-- 
           Summary: trunk does not compile boost MPL
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: piotr dot wyderski at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
  2010-01-27 10:44 ` [Bug c++/42880] " piotr dot wyderski at gmail dot com
@ 2010-01-27 10:44 ` piotr dot wyderski at gmail dot com
  2010-01-27 10:57 ` paolo dot carlini at oracle dot com
                   ` (45 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 10:44 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from piotr dot wyderski at gmail dot com  2010-01-27 10:43 -------
Created an attachment (id=19724)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19724&action=view)
preprocessed boost 1.39 mpl/size.hpp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
@ 2010-01-27 10:44 ` piotr dot wyderski at gmail dot com
  2010-01-27 10:44 ` piotr dot wyderski at gmail dot com
                   ` (46 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 10:44 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from piotr dot wyderski at gmail dot com  2010-01-27 10:44 -------
Created an attachment (id=19725)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19725&action=view)
compiler error output


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
  2010-01-27 10:44 ` [Bug c++/42880] " piotr dot wyderski at gmail dot com
  2010-01-27 10:44 ` piotr dot wyderski at gmail dot com
@ 2010-01-27 10:57 ` paolo dot carlini at oracle dot com
  2010-01-27 11:06 ` piotr dot wyderski at gmail dot com
                   ` (44 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 10:57 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from paolo dot carlini at oracle dot com  2010-01-27 10:57 -------
I'm seeing two problems here: on x86_64-linux I can see only the last error,
about specialization / redefinition, can well be a non-bug but can also be a
regression, I'm CC-ing Dodji about it; plus, apparently something is
specifically going wrong on cygwin at configure time, I see char_16t etc
issues. I'm CC-ing two cygwin maintainers about it.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dave dot korn dot cygwin at
                   |                            |gmail dot com, dannysmith at
                   |                            |users dot sourceforge dot
                   |                            |net, dodji at gcc dot gnu
                   |                            |dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (2 preceding siblings ...)
  2010-01-27 10:57 ` paolo dot carlini at oracle dot com
@ 2010-01-27 11:06 ` piotr dot wyderski at gmail dot com
  2010-01-27 11:08 ` paolo dot carlini at oracle dot com
                   ` (43 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 11:06 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from piotr dot wyderski at gmail dot com  2010-01-27 11:06 -------
(In reply to comment #3)

The new compiler was built with gcc-4.5.0 20100115. Both were configured as
follows:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.
exe
Target: i686-pc-cygwin
Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap
--en
able-version-specific-runtime-libs --enable-shared --enable-shared-libgcc
--with
-gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers
--disable-nls
 --with-arch=core2 --with-tune=generic --enable-threads=posix
--enable-languages
=c,c++
Thread model: posix
gcc version 4.5.0 20100126 (experimental) (GCC)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (3 preceding siblings ...)
  2010-01-27 11:06 ` piotr dot wyderski at gmail dot com
@ 2010-01-27 11:08 ` paolo dot carlini at oracle dot com
  2010-01-27 12:06 ` davek at gcc dot gnu dot org
                   ` (42 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 11:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from paolo dot carlini at oracle dot com  2010-01-27 11:08 -------
Ok. If you could figure out more precisely *when* the first problem started on
cygwin, it would be very useful. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (4 preceding siblings ...)
  2010-01-27 11:08 ` paolo dot carlini at oracle dot com
@ 2010-01-27 12:06 ` davek at gcc dot gnu dot org
  2010-01-27 12:12 ` paolo dot carlini at oracle dot com
                   ` (41 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 12:06 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from davek at gcc dot gnu dot org  2010-01-27 12:06 -------
I tried building the preprocessed source with my stock 4.3.4 compiler.  The
first two error messages are about the undefined wide char types, then there's
a massive cascade of template errors following on from that.

Cygwin provides a uchar.h that defines char16_t and char32_t.  I checked that
none of the #-directives in the preprocessed source referred to uchar.h, so if
boost fails to include it and boost gets an error about these types being
undefined, I think that is likely to be a boost bug rather than a cygwin or gcc
problem.

I therefore don't propose to investigate this any further, unless new evidence
comes to light.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (5 preceding siblings ...)
  2010-01-27 12:06 ` davek at gcc dot gnu dot org
@ 2010-01-27 12:12 ` paolo dot carlini at oracle dot com
  2010-01-27 12:21 ` paolo dot carlini at oracle dot com
                   ` (40 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 12:12 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from paolo dot carlini at oracle dot com  2010-01-27 12:12 -------
Thanks Dave. Thus, essentially, is submitter wrong that the problem is new?

(the other issue, which I can reproduce on x86_64-linux, stays)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (6 preceding siblings ...)
  2010-01-27 12:12 ` paolo dot carlini at oracle dot com
@ 2010-01-27 12:21 ` paolo dot carlini at oracle dot com
  2010-01-27 12:27 ` piotr dot wyderski at gmail dot com
                   ` (39 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 12:21 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from paolo dot carlini at oracle dot com  2010-01-27 12:21 -------
Also note: something is going on with char16_t / char32_t which I do not
understand at all, at the moment: in that tr1_impl code I did not setup the
specializations for char16_t / char32_t conditionally to some configure check
or header included or actual target, because I was assuming that in C++, in
C++0x mode, those are **always** available. Is that not true? And we didn't
realize for all this time?!?

Note, actually the error means the submitter is passing -std=c++0x on the
command line.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (7 preceding siblings ...)
  2010-01-27 12:21 ` paolo dot carlini at oracle dot com
@ 2010-01-27 12:27 ` piotr dot wyderski at gmail dot com
  2010-01-27 12:29 ` davek at gcc dot gnu dot org
                   ` (38 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 12:27 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #9 from piotr dot wyderski at gmail dot com  2010-01-27 12:27 -------
(In reply to comment #7)
> Thanks Dave. Thus, essentially, is submitter wrong that the problem is new?

My code compiled flawlessly on 4.5.0-20100115,
otherwise I would have reported the issue earlier...

20100126 has been built in a clean directory, so
no interferences with previous builds are possible.

Paolo: yes, -std=gnu++0x -- it's the reason I use trunk.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (8 preceding siblings ...)
  2010-01-27 12:27 ` piotr dot wyderski at gmail dot com
@ 2010-01-27 12:29 ` davek at gcc dot gnu dot org
  2010-01-27 12:30 ` davek at gcc dot gnu dot org
                   ` (37 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 12:29 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #10 from davek at gcc dot gnu dot org  2010-01-27 12:29 -------
(In reply to comment #8)
> Also note: something is going on with char16_t / char32_t which I do not
> understand at all, at the moment: in that tr1_impl code I did not setup the
> specializations for char16_t / char32_t conditionally to some configure check
> or header included or actual target, because I was assuming that in C++, in
> C++0x mode, those are **always** available. Is that not true? And we didn't
> realize for all this time?!?

  I don't understand.  There's no equivalent in g++ of the builtin stdint types
that Joseph added for C, so if you don't include the header that defines them,
no definitions should be available, yes?

> Note, actually the error means the submitter is passing -std=c++0x on the
> command line.

That didn't make any difference to the undefined types errors, but it did fix a
lot of the knock-on errors I was seeing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (9 preceding siblings ...)
  2010-01-27 12:29 ` davek at gcc dot gnu dot org
@ 2010-01-27 12:30 ` davek at gcc dot gnu dot org
  2010-01-27 12:33 ` paolo dot carlini at oracle dot com
                   ` (36 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 12:30 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #11 from davek at gcc dot gnu dot org  2010-01-27 12:30 -------
(In reply to comment #9)
> (In reply to comment #7)
> > Thanks Dave. Thus, essentially, is submitter wrong that the problem is new?
> 
> My code compiled flawlessly on 4.5.0-20100115,
> otherwise I would have reported the issue earlier...

Can you attach the preprocessed source you get from that build of the compiler,
so we can see why it either a) finds definitions of the ucharXX_t types, or b)
doesn't attempt to declare templates referring to them?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (10 preceding siblings ...)
  2010-01-27 12:30 ` davek at gcc dot gnu dot org
@ 2010-01-27 12:33 ` paolo dot carlini at oracle dot com
  2010-01-27 12:35 ` paolo dot carlini at oracle dot com
                   ` (35 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 12:33 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #12 from paolo dot carlini at oracle dot com  2010-01-27 12:33 -------
Then say that explicitly, *always*. Actually, the complete command line is part
of the requirements for PRs.

But, anyway, that error with char16_t and char32_t doesn't make *any* sense to
me. We have plenty of testcases in the C++ testsuite for char16_t and char32_t
on all the targets, working fine without including any header. Can you compile
something as simple as this:

char16_t a;

with -std=c++0x (or -std=gnu++0x)? If you can't, then this is something which
is much more general than boost MPL; if you can, something inside boost MPL is
playing weird tricks with those names.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (11 preceding siblings ...)
  2010-01-27 12:33 ` paolo dot carlini at oracle dot com
@ 2010-01-27 12:35 ` paolo dot carlini at oracle dot com
  2010-01-27 12:36 ` davek at gcc dot gnu dot org
                   ` (34 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 12:35 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #13 from paolo dot carlini at oracle dot com  2010-01-27 12:35 -------
Dave, please grep the C++ testsuite for char16_t and char32_t: you will find
tons of testcases using those types + -std=c++0x on the command line, no
special target-dependent treatments, no includes whatsoever.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (12 preceding siblings ...)
  2010-01-27 12:35 ` paolo dot carlini at oracle dot com
@ 2010-01-27 12:36 ` davek at gcc dot gnu dot org
  2010-01-27 12:39 ` piotr dot wyderski at gmail dot com
                   ` (33 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 12:36 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #14 from davek at gcc dot gnu dot org  2010-01-27 12:36 -------
(In reply to comment #12)
> on all the targets, working fine without including any header. Can you compile
> something as simple as this:
> 
> char16_t a;
> 
> with -std=c++0x (or -std=gnu++0x)? 

This is from head r.156219

$ cat test.cpp
char16_t a;

DKAdmin@ubik /tmp/boost
$ g++-4 -std=c++0x -c test.cpp ; echo $?
0

DKAdmin@ubik /tmp/boost
$ g++-4 -v
Using built-in specs.
COLLECT_GCC=g++-4
COLLECT_LTO_WRAPPER=/gnu/gcc/install-lto/opt/gcc-tools/bin/../libexec/gcc/i686-p
c-cygwin/4.5.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /gnu/gcc/gcc/configure --prefix=/opt/gcc-tools -v
--with-gmp=/u
sr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs
--
enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit
--wi
th-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions
--disable-symver
s --enable-libjava --enable-interpreter --program-suffix=-4 --enable-libgomp
--d
isable-libssp --disable-libada --enable-threads=posix --with-arch=i686
--with-tu
ne=generic CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4
--with-ec
j-jar=/usr/share/java/ecj.jar --disable-win32-registry --disable-libgcj-debug
--
enable-lto --enable-languages=c,c++,fortran,java,lto,objc,obj-c++
--enable-graph
ite
Thread model: posix
gcc version 4.5.0 20100121 (experimental) (GCC)

DKAdmin@ubik /tmp/boost
$


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (13 preceding siblings ...)
  2010-01-27 12:36 ` davek at gcc dot gnu dot org
@ 2010-01-27 12:39 ` piotr dot wyderski at gmail dot com
  2010-01-27 12:39 ` davek at gcc dot gnu dot org
                   ` (32 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 12:39 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #16 from piotr dot wyderski at gmail dot com  2010-01-27 12:39 -------

> Can you attach the preprocessed source you get from that build of the compiler

Unfortunately not, because I assumed that the new compiler
will work, so make install overwritten the binaries of 0115.
Anyway, I think I have an earlier build somewhere (20100107)
which also works, so I will provide you a preprocessed source
from that version.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (14 preceding siblings ...)
  2010-01-27 12:39 ` piotr dot wyderski at gmail dot com
@ 2010-01-27 12:39 ` davek at gcc dot gnu dot org
  2010-01-27 12:42 ` paolo dot carlini at oracle dot com
                   ` (31 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 12:39 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #15 from davek at gcc dot gnu dot org  2010-01-27 12:38 -------
And this is r.155967

$ cat test.cpp
char16_t a;

DKAdmin@ubik /tmp/boost
$ g++-4 -std=c++0x -c test.cpp ; echo $?
0

DKAdmin@ubik /tmp/boost
$


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (15 preceding siblings ...)
  2010-01-27 12:39 ` davek at gcc dot gnu dot org
@ 2010-01-27 12:42 ` paolo dot carlini at oracle dot com
  2010-01-27 12:45 ` davek at gcc dot gnu dot org
                   ` (30 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 12:42 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #17 from paolo dot carlini at oracle dot com  2010-01-27 12:42 -------
So, as a matter of fact, char16_t and char32_t normally work on cygwin too.
Then, what the heck is boost doing?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (16 preceding siblings ...)
  2010-01-27 12:42 ` paolo dot carlini at oracle dot com
@ 2010-01-27 12:45 ` davek at gcc dot gnu dot org
  2010-01-27 12:47 ` piotr dot wyderski at gmail dot com
                   ` (29 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 12:45 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #18 from davek at gcc dot gnu dot org  2010-01-27 12:45 -------
(In reply to comment #17)
> So, as a matter of fact, char16_t and char32_t normally work on cygwin too.

Ah, hang on.  I may have got some of my revision numbers mixed up there.  (I
have a number of objdirs lying around built at various times from the same
sandbox.)

Here are two fairly recent ones:


$ /gnu/gcc/install-lto/opt/gcc-tools/bin/g++-4  -std=c++0x -c mpl_size_hpp.ii
; echo $?
0

$ /gnu/gcc/install-obj2/opt/gcc-tools/bin/g++-4  -std=c++0x -c mpl_size_hpp.ii
 ; echo $?
In file included from
/usr/include/boost_1_39_0/boost/mpl/aux_/include_preproces
sed.hpp:37:0,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/full_lambda.hpp:4
4,
                 from /usr/include/boost_1_39_0/boost/mpl/lambda.hpp:22,
                 from /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:20,
                 from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19,

                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19,
                 from br.cpp:2:
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49
2: error: specialization of
'boost::mpl::aux::template_arity<boost::mpl::lambda<
mpl_::na, mpl_::na> >' after instantiation
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49
2: error: redefinition of 'struct
boost::mpl::aux::template_arity<boost::mpl::la
mbda<mpl_::na, mpl_::na> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::lambda<mpl_::na, mpl_::na> >'
In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18:0,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19,

                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19,
                 from br.cpp:2:
/usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: specialization
of 'boost::mpl::aux::template_arity<boost::mpl::iter_fold<> >' after
instantiati
on
/usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: redefinition
of
 'struct boost::mpl::aux::template_arity<boost::mpl::iter_fold<> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::iter_fold<> >'
In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:19:0,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19,

                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19,
                 from br.cpp:2:
/usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error:
specializa
tion of 'boost::mpl::aux::template_arity<boost::mpl::iterator_range<> >' after
i
nstantiation
/usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error:
redefiniti
on of 'struct boost::mpl::aux::template_arity<boost::mpl::iterator_range<> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::iterator_range<> >'
In file included from
/usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19:
0,
                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19,
                 from br.cpp:2:
/usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: specialization
o
f 'boost::mpl::aux::template_arity<boost::mpl::distance<> >' after
instantiation

/usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: redefinition of
'struct boost::mpl::aux::template_arity<boost::mpl::distance<> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::distance<> >'
In file included from br.cpp:2:0:
/usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: specialization of
'b
oost::mpl::aux::template_arity<boost::mpl::size<> >' after instantiation
/usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: redefinition of
'str
uct boost::mpl::aux::template_arity<boost::mpl::size<> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::size<> >'
1

DKAdmin@ubik /tmp/boost
$ /gnu/gcc/install-lto/opt/gcc-tools/bin/g++-4  -std=c++0x -c mpl_size_hpp.ii
; echo $?
0

DKAdmin@ubik /tmp/boost
$



However, note there's still no problem with the wide char types.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (17 preceding siblings ...)
  2010-01-27 12:45 ` davek at gcc dot gnu dot org
@ 2010-01-27 12:47 ` piotr dot wyderski at gmail dot com
  2010-01-27 12:48 ` davek at gcc dot gnu dot org
                   ` (28 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 12:47 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #19 from piotr dot wyderski at gmail dot com  2010-01-27 12:47 -------

> Then say that explicitly, *always*. Actually,
> the complete command line is part of the requirements for PRs.

Sorry, I misunderstood you. I use -std=gnu++0x in my
actual program, which today became uncompilable. For
the PR it was:

    g++ -std=gnu++0x br.cpp -I/usr/include/boost_1_39_0/

Without extensions enabled, merely:

    g++ br.cpp -I/usr/include/boost_1_39_0/

the compiler also emits an error list, however much
shorter (it's probably what you see on Linux): specialization
after instantiation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (18 preceding siblings ...)
  2010-01-27 12:47 ` piotr dot wyderski at gmail dot com
@ 2010-01-27 12:48 ` davek at gcc dot gnu dot org
  2010-01-27 12:53 ` paolo dot carlini at oracle dot com
                   ` (27 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 12:48 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #20 from davek at gcc dot gnu dot org  2010-01-27 12:48 -------
(In reply to comment #18)
> (In reply to comment #17)
> > So, as a matter of fact, char16_t and char32_t normally work on cygwin too.
> 
> Ah, hang on.  I may have got some of my revision numbers mixed up there.  (I
> have a number of objdirs lying around built at various times from the same
> sandbox.)
> 
> Here are two fairly recent ones:

Those versions are:

gcc version 4.5.0 20100121 (experimental) (GCC)
gcc version 4.5.0 20100125 (experimental) (GCC)

So I can confirm the specialisation error that you've also seen on x86_64-linux
has also appeared on cygwin, but I can't yet confirm any bug about the char
types.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (19 preceding siblings ...)
  2010-01-27 12:48 ` davek at gcc dot gnu dot org
@ 2010-01-27 12:53 ` paolo dot carlini at oracle dot com
  2010-01-27 12:59 ` davek at gcc dot gnu dot org
                   ` (26 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 12:53 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #21 from paolo dot carlini at oracle dot com  2010-01-27 12:53 -------
Excellent Dave. Thus, we are looking for confirmation of the char16_t /
char32_t issue, we don't see it on our cygwin and linux machines.

And we should nail down more precisely in time the specialization /
redefinition issue, can be a regression or g++ becoming more strict.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (20 preceding siblings ...)
  2010-01-27 12:53 ` paolo dot carlini at oracle dot com
@ 2010-01-27 12:59 ` davek at gcc dot gnu dot org
  2010-01-27 13:04 ` piotr dot wyderski at gmail dot com
                   ` (25 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 12:59 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #22 from davek at gcc dot gnu dot org  2010-01-27 12:59 -------
(In reply to comment #21)
> Excellent Dave. Thus, we are looking for confirmation of the char16_t /
> char32_t issue, we don't see it on our cygwin and linux machines.

OK, so I'll try updating my most recent build from 156219 to 156253 and see if
that makes a difference re. the char types.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (21 preceding siblings ...)
  2010-01-27 12:59 ` davek at gcc dot gnu dot org
@ 2010-01-27 13:04 ` piotr dot wyderski at gmail dot com
  2010-01-27 13:09 ` piotr dot wyderski at gmail dot com
                   ` (24 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 13:04 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #23 from piotr dot wyderski at gmail dot com  2010-01-27 13:04 -------

cmdline:

  g++ [-std=gnu++0x] br.cpp -I/usr/include/boost_1_39_0/

On gcc version 4.5.0 20090604 (experimental) (GCC):
compiled OK

On gcc version 4.5.0 20100107 (experimental) (GCC)
compiled OK

On 20100115 it was also OK, but I can't prove it.

On 20100126: a lot of errors, the amount depends
on the presence of -std=gnu++0x

I have no intermediate builds between 15 and 26,
so can't reduce the range any more.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (22 preceding siblings ...)
  2010-01-27 13:04 ` piotr dot wyderski at gmail dot com
@ 2010-01-27 13:09 ` piotr dot wyderski at gmail dot com
  2010-01-27 13:12 ` davek at gcc dot gnu dot org
                   ` (23 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 13:09 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #24 from piotr dot wyderski at gmail dot com  2010-01-27 13:08 -------
Created an attachment (id=19727)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19727&action=view)
preprocessed boost 1.39 mpl/size.hpp (20100107)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (23 preceding siblings ...)
  2010-01-27 13:09 ` piotr dot wyderski at gmail dot com
@ 2010-01-27 13:12 ` davek at gcc dot gnu dot org
  2010-01-27 13:26 ` piotr dot wyderski at gmail dot com
                   ` (22 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 13:12 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #25 from davek at gcc dot gnu dot org  2010-01-27 13:12 -------
(In reply to comment #24)
> Created an attachment (id=19727)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19727&action=view) [edit]
> preprocessed boost 1.39 mpl/size.hpp (20100107)
> 

Apart from include file paths in # lines, the two files are identical.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (24 preceding siblings ...)
  2010-01-27 13:12 ` davek at gcc dot gnu dot org
@ 2010-01-27 13:26 ` piotr dot wyderski at gmail dot com
  2010-01-27 15:17 ` davek at gcc dot gnu dot org
                   ` (21 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: piotr dot wyderski at gmail dot com @ 2010-01-27 13:26 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #26 from piotr dot wyderski at gmail dot com  2010-01-27 13:25 -------

> Apart from include file paths in # lines, the two files are identical.

I double-checked the compilers used to generate
them -- the attachments are correct. So the issue
must be inside the compiler itself, not in its
stdc++ includes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (25 preceding siblings ...)
  2010-01-27 13:26 ` piotr dot wyderski at gmail dot com
@ 2010-01-27 15:17 ` davek at gcc dot gnu dot org
  2010-01-27 15:31 ` davek at gcc dot gnu dot org
                   ` (20 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 15:17 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #27 from davek at gcc dot gnu dot org  2010-01-27 15:17 -------
(In reply to comment #26)
> > Apart from include file paths in # lines, the two files are identical.
> 
> I double-checked the compilers used to generate
> them -- the attachments are correct. So the issue
> must be inside the compiler itself, not in its
> stdc++ includes.

Indeed, and that matches what Paolo said in comment 13.  I've now built
r.156253 and here is the output from compiling your testcase; it still shows no
sign of the charXX_t problem:

$ /gnu/gcc/install-obj3/opt/gcc-tools/bin/g++-4  -std=c++0x  o.cpp
In file included from
/usr/include/boost_1_39_0/boost/mpl/aux_/include_preproces
sed.hpp:37:0,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/full_lambda.hpp:4
4,
                 from /usr/include/boost_1_39_0/boost/mpl/lambda.hpp:22,
                 from /usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:20,
                 from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19,

                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19,
                 from br.cpp:2:
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49
2: error: specialization of
'boost::mpl::aux::template_arity<boost::mpl::lambda<
mpl_::na, mpl_::na> >' after instantiation
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/full_lambda.hpp:555:49
2: error: redefinition of 'struct
boost::mpl::aux::template_arity<boost::mpl::la
mbda<mpl_::na, mpl_::na> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::lambda<mpl_::na, mpl_::na> >'
In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:18:0,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19,

                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19,
                 from br.cpp:2:
/usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: specialization
of 'boost::mpl::aux::template_arity<boost::mpl::iter_fold<> >' after
instantiati
on
/usr/include/boost_1_39_0/boost/mpl/iter_fold.hpp:45:531: error: redefinition
of
 'struct boost::mpl::aux::template_arity<boost::mpl::iter_fold<> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::iter_fold<> >'
In file included from /usr/include/boost_1_39_0/boost/mpl/distance.hpp:19:0,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19,

                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19,
                 from br.cpp:2:
/usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error:
specializa
tion of 'boost::mpl::aux::template_arity<boost::mpl::iterator_range<> >' after
i
nstantiation
/usr/include/boost_1_39_0/boost/mpl/iterator_range.hpp:38:521: error:
redefiniti
on of 'struct boost::mpl::aux::template_arity<boost::mpl::iterator_range<> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::iterator_range<> >'
In file included from
/usr/include/boost_1_39_0/boost/mpl/aux_/size_impl.hpp:19:
0,
                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:19,
                 from br.cpp:2:
/usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: specialization
o
f 'boost::mpl::aux::template_arity<boost::mpl::distance<> >' after
instantiation

/usr/include/boost_1_39_0/boost/mpl/distance.hpp:74:485: error: redefinition of
'struct boost::mpl::aux::template_arity<boost::mpl::distance<> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::distance<> >'
In file included from br.cpp:2:0:
/usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: specialization of
'b
oost::mpl::aux::template_arity<boost::mpl::size<> >' after instantiation
/usr/include/boost_1_39_0/boost/mpl/size.hpp:38:421: error: redefinition of
'str
uct boost::mpl::aux::template_arity<boost::mpl::size<> >'
/usr/include/boost_1_39_0/boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:92:
1: error: previous definition of 'struct
boost::mpl::aux::template_arity<boost::
mpl::size<> >'

DKAdmin@ubik /tmp/boost
$


.... except, of course, if I omit -std=c++0x:


$ /gnu/gcc/install-obj3/opt/gcc-tools/bin/g++-4   o.cpp
In file included from
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/ty
pe_traits:51:0,
                 from
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bi
ts/move.h:38,
                 from
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bi
ts/stl_pair.h:60,
                 from
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/ut
ility:71,
                 from
/usr/include/boost_1_39_0/boost/config/no_tr1/utility.hpp:
21,
                 from
/usr/include/boost_1_39_0/boost/config/select_stdlib_confi
g.hpp:20,
                 from /usr/include/boost_1_39_0/boost/config.hpp:40,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/config/msvc.hpp:1
9,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/config/adl.hpp:17
,
                 from
/usr/include/boost_1_39_0/boost/mpl/aux_/adl_barrier.hpp:1
7,
                 from /usr/include/boost_1_39_0/boost/mpl/bool_fwd.hpp:17,
                 from /usr/include/boost_1_39_0/boost/mpl/bool.hpp:17,
                 from /usr/include/boost_1_39_0/boost/mpl/has_xxx.hpp:18,
                 from /usr/include/boost_1_39_0/boost/mpl/aux_/has_tag.hpp:17,
                 from /usr/include/boost_1_39_0/boost/mpl/sequence_tag.hpp:18,
                 from /usr/include/boost_1_39_0/boost/mpl/size.hpp:18,
                 from br.cpp:2:
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits:112
:42: error: 'char16_t' was not declared in this scope
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits:112
:50: error: template argument 1 is invalid
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits:113
:42: error: 'char32_t' was not declared in this scope
/opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits:113
:50: error: template argument 1 is invalid


So, the bug is that it #includes tr1_impl even if the compiler is not in c++0x
mode perhaps?  It appears to be coming from the regular type_traits header:

# 1 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/stddef.h" 1 3 4
# 45 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/cstddef" 2 3
# 43 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/type_traits" 2 3
# 51 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/type_traits" 3
# 1 "/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits"
1 3
# 30
"/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits"   3
namespace std
{

# 43
"/opt/PREFIX/LIB/gcc/i686-pc-cygwin/4.5.0/include/c++/tr1_impl/type_traits"


Hmmm.  That comes from here:

    44  #if defined(_GLIBCXX_INCLUDE_AS_CXX0X)
    45  #  include <tr1_impl/type_traits>
    46  #else
    47  #  define _GLIBCXX_INCLUDE_AS_CXX0X
    48  #  define _GLIBCXX_BEGIN_NAMESPACE_TR1
    49  #  define _GLIBCXX_END_NAMESPACE_TR1
    50  #  define _GLIBCXX_TR1
    51  #  include <tr1_impl/type_traits>
    52  #  undef _GLIBCXX_TR1
    53  #  undef _GLIBCXX_END_NAMESPACE_TR1
    54  #  undef _GLIBCXX_BEGIN_NAMESPACE_TR1
    55  #  undef _GLIBCXX_INCLUDE_AS_CXX0X
    56  #endif

and then tr1_impl/type_traits has:

   111  #ifdef _GLIBCXX_INCLUDE_AS_CXX0X
   112    _DEFINE_SPEC(0, __is_integral_helper, char16_t, true)
   113    _DEFINE_SPEC(0, __is_integral_helper, char32_t, true)
   114  #endif

That kind of looks peculiar to me, but I don't know how the libstdc headers are
put together.  But why would we #define _GLIBCXX_INCLUDE_AS_CXX0X when we're
not in C++0x mode?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (26 preceding siblings ...)
  2010-01-27 15:17 ` davek at gcc dot gnu dot org
@ 2010-01-27 15:31 ` davek at gcc dot gnu dot org
  2010-01-27 15:32 ` paolo dot carlini at oracle dot com
                   ` (19 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 15:31 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #28 from davek at gcc dot gnu dot org  2010-01-27 15:31 -------
I've just gone back through the older compiler versions I have lying around. 
None of them can successfully compile the testcase without -std=c++0x at all,
they all complain about the missing types in the same way.  So I think the
stuff to do with char types is just a red-herring that happened while Piotr was
trying out the standalone testcase, by omitting the -std flag.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (27 preceding siblings ...)
  2010-01-27 15:31 ` davek at gcc dot gnu dot org
@ 2010-01-27 15:32 ` paolo dot carlini at oracle dot com
  2010-01-27 15:41 ` paolo dot carlini at oracle dot com
                   ` (18 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 15:32 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #29 from paolo dot carlini at oracle dot com  2010-01-27 15:31 -------
To be clear: when the tr1_impl/type_traits implementation code is included as
tr1 code, is included from <tr1/type_traits> that is, _GLIBCXX_INCLUDE_AS_CXX0X
is undefined and no error should happen. Likewise, when the
tr1_impl/type_traits code is included as C++0x code, from <type_traits> that
is, the macro is defined, but no problem should occur in that case too because
char16_t and char32_t are certainly available in C++0x mode.

In practice, on linux I can compile the provided one-line snippet, both with
-std=c++0x and without, and get *only* the errors unrelated to char16_t /
char32_t. This doesn't suprise me, because in the libstdc++ testsuite we are
*very* careful about these things: we have tons of testcases including
<type_traits> and <tr1/type_traits> in normal mode, c++0x mode, etc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (28 preceding siblings ...)
  2010-01-27 15:32 ` paolo dot carlini at oracle dot com
@ 2010-01-27 15:41 ` paolo dot carlini at oracle dot com
  2010-01-27 15:48 ` davek at gcc dot gnu dot org
                   ` (17 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 15:41 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #30 from paolo dot carlini at oracle dot com  2010-01-27 15:41 -------
If Dave, you have evidence that older versions of GCC always needed -std=c++0x
in order to compile this boost code, this is a cygwin-specific issue: I just
tried with a 4.4.x gcc and I can compile it without -std=c++0x.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (29 preceding siblings ...)
  2010-01-27 15:41 ` paolo dot carlini at oracle dot com
@ 2010-01-27 15:48 ` davek at gcc dot gnu dot org
  2010-01-27 15:57 ` paolo dot carlini at oracle dot com
                   ` (16 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 15:48 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #31 from davek at gcc dot gnu dot org  2010-01-27 15:48 -------
(In reply to comment #30)
> If Dave, you have evidence that older versions of GCC always needed -std=c++0x
> in order to compile this boost code, this is a cygwin-specific issue: I just
> tried with a 4.4.x gcc and I can compile it without -std=c++0x.

This is 4.3.4, the stock cygwin distro version right now:

DKAdmin@ubik /tmp/boost
$ cat test.cpp
char16_t a;

DKAdmin@ubik /tmp/boost
$ g++ -c test.cpp
test.cpp:1: error: 'char16_t' does not name a type

DKAdmin@ubik /tmp/boost
$ g++ -c test.cpp -std=c++0x
test.cpp:1: error: 'char16_t' does not name a type

DKAdmin@ubik /tmp/boost

I take it that much is unsurprising?

This is the oldest version of trunk I have lying around, from r155967:

DKAdmin@ubik /tmp/boost
$ /gnu/gcc/install-clean/opt/gcc-tools/bin/g++-4 -c test.cpp
test.cpp:1:1: error: 'char16_t' does not name a type

DKAdmin@ubik /tmp/boost
$ /gnu/gcc/install-clean/opt/gcc-tools/bin/g++-4 -c test.cpp  -std=c++0x

DKAdmin@ubik /tmp/boost

That is also how everything up to r156253 behaves.  Is there something wrong
with that?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (30 preceding siblings ...)
  2010-01-27 15:48 ` davek at gcc dot gnu dot org
@ 2010-01-27 15:57 ` paolo dot carlini at oracle dot com
  2010-01-27 16:08 ` davek at gcc dot gnu dot org
                   ` (15 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 15:57 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #32 from paolo dot carlini at oracle dot com  2010-01-27 15:56 -------
Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really
honest, personally I'm not interested in cygwin much. My suggestion is just
making sure the C++ front-end is fine for cygwin vs char16_t / char32_t, ans
simply running the C++ testsuite should be more than enough. If eventually you
come to the conclusion that some special workrounds in the C++ runtime is
needed to support cygwin, let's discuss that separately.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (31 preceding siblings ...)
  2010-01-27 15:57 ` paolo dot carlini at oracle dot com
@ 2010-01-27 16:08 ` davek at gcc dot gnu dot org
  2010-01-27 16:14 ` paolo dot carlini at oracle dot com
                   ` (14 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 16:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #33 from davek at gcc dot gnu dot org  2010-01-27 16:07 -------
(In reply to comment #32)
> Dave, the issue with char16_t / cha32_t is cygwin specific, and, to be really
> honest, personally I'm not interested in cygwin much. My suggestion is just
> making sure the C++ front-end is fine for cygwin vs char16_t / char32_t, ans
> simply running the C++ testsuite should be more than enough. If eventually you
> come to the conclusion that some special workrounds in the C++ runtime is
> needed to support cygwin, let's discuss that separately.

I'll run the testsuite on today's build and see if it differs from my most
recent run, which was pretty clean.  More later when that finishes.

(I thought the problem was that the preprocessed testcase was prepared using
-std=c++0x and therefore embeds all the #ifdef decisions made using that
standard, and so the preprocessed testcase must be compiled using the same
-std= which was used to prepare it.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (32 preceding siblings ...)
  2010-01-27 16:08 ` davek at gcc dot gnu dot org
@ 2010-01-27 16:14 ` paolo dot carlini at oracle dot com
  2010-01-27 17:55 ` davek at gcc dot gnu dot org
                   ` (13 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 16:14 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #34 from paolo dot carlini at oracle dot com  2010-01-27 16:14 -------
Right Dave, that's why we ask submitters to also provide the actual command
line used. Anyway, sorry about a bit of harshness on my side, I'm afraid we are
digressing too much in this thread: for sure, if I just take the one-liner
provided by submitter the errors I get are the same, with and without
-std=c++0x, and with 4.4.x I can compile it with no errors, irrerspective of
the command-line switches. This is what I consider sane behavior modulo the
*possible*, yet to be confirmed, C++ front-end issue with specialization /
redefinition.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (33 preceding siblings ...)
  2010-01-27 16:14 ` paolo dot carlini at oracle dot com
@ 2010-01-27 17:55 ` davek at gcc dot gnu dot org
  2010-01-27 18:09 ` paolo dot carlini at oracle dot com
                   ` (12 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 17:55 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #35 from davek at gcc dot gnu dot org  2010-01-27 17:55 -------
(In reply to comment #34)

> digressing too much in this thread: for sure, if I just take the one-liner
> provided by submitter the errors I get are the same, with and without
> -std=c++0x, and with 4.4.x I can compile it with no errors, irrerspective of
> the command-line switches. 

Right, you mean the one-liner #include <boost/mpl/size.hpp>, so of course if
you compile it either different way the live #ifdefs respond correctly, and in
the non -std=c++0x compile, you don't get the template definitions for the wide
char types.  I don't have boost installed, so I've been relying on the
preprocessed source, which of course is good only for C++-0x.  (I wasn't clear
whether you were implying that the charXX_t definitions should exist in
non-c++0x mode, but I think now that they are c++0x only and that because you
were using live boost headers your compile succeeds.)

> This is what I consider sane behavior modulo the
> *possible*, yet to be confirmed, C++ front-end issue with specialization /
> redefinition.

Testsuite run is showing nothing unexpected either, and I couldn't really
imagine what Cygwin could possibly have done to break the presence of a couple
of builtin types in the C++ FE anyway.  So yes, sorry for taking some time to
get to this point, but I now also think that's the only possible issue here,
and there is no cygwin specific problem nor char types problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (34 preceding siblings ...)
  2010-01-27 17:55 ` davek at gcc dot gnu dot org
@ 2010-01-27 18:09 ` paolo dot carlini at oracle dot com
  2010-01-27 18:14 ` paolo dot carlini at oracle dot com
                   ` (11 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 18:09 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #36 from paolo dot carlini at oracle dot com  2010-01-27 18:09 -------
I removed the compiler error output, as misleading.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (35 preceding siblings ...)
  2010-01-27 18:09 ` paolo dot carlini at oracle dot com
@ 2010-01-27 18:14 ` paolo dot carlini at oracle dot com
  2010-01-27 18:15 ` paolo dot carlini at oracle dot com
                   ` (10 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 18:14 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #37 from paolo dot carlini at oracle dot com  2010-01-27 18:14 -------
Actually, I'm going to remove all the preprocessed files too. Please attach a
version built without -std=c++0x on the command line, the issue, if one exists,
has absolutely nothing to do with c++0x.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (36 preceding siblings ...)
  2010-01-27 18:14 ` paolo dot carlini at oracle dot com
@ 2010-01-27 18:15 ` paolo dot carlini at oracle dot com
  2010-01-27 18:16 ` jwakely dot gcc at gmail dot com
                   ` (9 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 18:15 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #38 from paolo dot carlini at oracle dot com  2010-01-27 18:15 -------
Thanks Dave, we are fully on the same page now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (37 preceding siblings ...)
  2010-01-27 18:15 ` paolo dot carlini at oracle dot com
@ 2010-01-27 18:16 ` jwakely dot gcc at gmail dot com
  2010-01-27 18:17 ` davek at gcc dot gnu dot org
                   ` (8 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: jwakely dot gcc at gmail dot com @ 2010-01-27 18:16 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #39 from jwakely dot gcc at gmail dot com  2010-01-27 18:15 -------
looks as though the .ii was created using -std=c++0x and then the compiler
output obtained by compiling it without -std=c++0x 

that's never going to work


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (38 preceding siblings ...)
  2010-01-27 18:16 ` jwakely dot gcc at gmail dot com
@ 2010-01-27 18:17 ` davek at gcc dot gnu dot org
  2010-01-27 18:25 ` paolo dot carlini at oracle dot com
                   ` (7 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: davek at gcc dot gnu dot org @ 2010-01-27 18:17 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #40 from davek at gcc dot gnu dot org  2010-01-27 18:17 -------
(In reply to comment #39)
> looks as though the .ii was created using -std=c++0x and then the compiler
> output obtained by compiling it without -std=c++0x 
> 
> that's never going to work
> 

:) Yeah, I finally got there sometime around comment 33.

I'll be ducking out of this one now, unless anyone needs me.  Cheers all!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (39 preceding siblings ...)
  2010-01-27 18:17 ` davek at gcc dot gnu dot org
@ 2010-01-27 18:25 ` paolo dot carlini at oracle dot com
  2010-01-28  6:25 ` hjl dot tools at gmail dot com
                   ` (6 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-27 18:25 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #41 from paolo dot carlini at oracle dot com  2010-01-27 18:25 -------
Created an attachment (id=19731)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19731&action=view)
preprocessed on x86_64-linux

In case somebody wants to play with it immediately, and doesn't have boost at
hand, I'm attaching a .ii created on x86_64-linux (boost 1.39), the issue in
any case doesn't have anything special to do with cygwin.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (40 preceding siblings ...)
  2010-01-27 18:25 ` paolo dot carlini at oracle dot com
@ 2010-01-28  6:25 ` hjl dot tools at gmail dot com
  2010-01-28  8:26 ` dodji at gcc dot gnu dot org
                   ` (5 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: hjl dot tools at gmail dot com @ 2010-01-28  6:25 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #42 from hjl dot tools at gmail dot com  2010-01-28 06:25 -------
It is caused by revision 156106:

http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00573.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
  GCC build triplet|i686-pc-cygwin              |
   GCC host triplet|i686-pc-cygwin              |
 GCC target triplet|i686-pc-cygwin              |
   Last reconfirmed|0000-00-00 00:00:00         |2010-01-28 06:25:36
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (41 preceding siblings ...)
  2010-01-28  6:25 ` hjl dot tools at gmail dot com
@ 2010-01-28  8:26 ` dodji at gcc dot gnu dot org
  2010-01-28  8:38 ` dodji at gcc dot gnu dot org
                   ` (4 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-01-28  8:26 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #43 from dodji at gcc dot gnu dot org  2010-01-28 08:26 -------
Created an attachment (id=19738)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19738&action=view)
A somewhat reduced test case.

This is a reduced test case, just in case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (42 preceding siblings ...)
  2010-01-28  8:26 ` dodji at gcc dot gnu dot org
@ 2010-01-28  8:38 ` dodji at gcc dot gnu dot org
  2010-01-28  9:45 ` paolo dot carlini at oracle dot com
                   ` (3 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-01-28  8:38 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #44 from dodji at gcc dot gnu dot org  2010-01-28 08:37 -------
This actually looks like another instance of PR c++/42758.

*** This bug has been marked as a duplicate of 42758 ***


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (43 preceding siblings ...)
  2010-01-28  8:38 ` dodji at gcc dot gnu dot org
@ 2010-01-28  9:45 ` paolo dot carlini at oracle dot com
  2010-01-28 22:53 ` jason at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  47 siblings, 0 replies; 49+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-01-28  9:45 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #45 from paolo dot carlini at oracle dot com  2010-01-28 09:45 -------
Thanks HJ and Dodji.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (44 preceding siblings ...)
  2010-01-28  9:45 ` paolo dot carlini at oracle dot com
@ 2010-01-28 22:53 ` jason at gcc dot gnu dot org
  2010-01-29 14:31 ` dodji at gcc dot gnu dot org
  2010-02-07  4:46 ` hjl at gcc dot gnu dot org
  47 siblings, 0 replies; 49+ messages in thread
From: jason at gcc dot gnu dot org @ 2010-01-28 22:53 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #46 from jason at gcc dot gnu dot org  2010-01-28 22:52 -------
Subject: Bug 42880

Author: jason
Date: Thu Jan 28 22:52:36 2010
New Revision: 156336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156336
Log:
        PR c++/42880
        * semantics.c (begin_class_definition): Don't use type_as_string.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/semantics.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (45 preceding siblings ...)
  2010-01-28 22:53 ` jason at gcc dot gnu dot org
@ 2010-01-29 14:31 ` dodji at gcc dot gnu dot org
  2010-02-07  4:46 ` hjl at gcc dot gnu dot org
  47 siblings, 0 replies; 49+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-01-29 14:31 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #47 from dodji at gcc dot gnu dot org  2010-01-29 14:31 -------
Subject: Bug 42880

Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797

... and mitigate PR c++/42336

gcc/cp/ChangeLog:
        PR c++/42758
        PR c++/42634
        PR c++/42336
        PR c++/42797
        PR c++/42880
        * cp-tree.h (NON_DEFAULT_TEMPLATE_ARGS_COUNT,
        SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT,
        GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT): New accessor macros.
        * pt.c (coerce_template_parms, type_unification_real,
        expand_template_argument_pack, coerce_template_parameter_pack):
        Set the non default template args count.
        (current_template_args): Always set non defaulted
        template args count when compiled with --enable-checking
        (tsubst_template_args, type_unification_real): Propagate the non
        defaulted template args count.
        * error.c (get_non_default_template_args_count): Renamed
        count_non_default_template_args into this. Don't calculate the
        non default template argument count anymore. Use the new
        accessor macros above to get it.
        (dump_template_argument_list, dump_type, dump_decl,
        dump_template_parms): Adjust.
        * parser.c (cp_parser_template_argument_list): Always set defaulted
        template args count when compiled with --enable-checking.

gcc/testsuite/ChangeLog:
        PR c++/42758
        PR c++/42634
        PR c++/42336
        PR c++/42797
        PR c++/42880
        * g++.dg/other/crash-5.C: New test.
        * g++.dg/other/crash-6.C: New test.
        * g++.dg/other/crash-7.C: New test.
        * g++.dg/other/crash-8.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/other/crash-5.C
    trunk/gcc/testsuite/g++.dg/other/crash-6.C
    trunk/gcc/testsuite/g++.dg/other/crash-7.C
    trunk/gcc/testsuite/g++.dg/other/crash-8.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/error.c
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Bug c++/42880] trunk does not compile boost MPL
  2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
                   ` (46 preceding siblings ...)
  2010-01-29 14:31 ` dodji at gcc dot gnu dot org
@ 2010-02-07  4:46 ` hjl at gcc dot gnu dot org
  47 siblings, 0 replies; 49+ messages in thread
From: hjl at gcc dot gnu dot org @ 2010-02-07  4:46 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #48 from hjl at gcc dot gnu dot org  2010-02-07 04:42 -------
Subject: Bug 42880

Author: hjl
Date: Sun Feb  7 04:41:22 2010
New Revision: 156562

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156562
Log:
Backport testcases from mainline to 4.4.

2010-02-06  H.J. Lu  <hongjiu.lu@intel.com>

        Backport from mainline:
        2010-02-05  Dodji Seketeli  <dodji@redhat.com>

        PR c++/42915
        * g++.dg/other/crash-9.C: New test.

        2010-02-03  Jason Merrill  <jason@redhat.com>

        PR c++/40138
        * g++.dg/ext/builtin11.C: New.

        2010-02-03  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42944
        * gcc.dg/errno-1.c: New testcase.

        2010-02-03  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42927
        * gcc.c-torture/compile/pr42927.c: New testcase.

        2010-01-29  Dodji Seketeli  <dodji@redhat.com>

        PR c++/42758
        PR c++/42634
        PR c++/42336
        PR c++/42797
        PR c++/42880
        * g++.dg/other/crash-5.C: New test.
        * g++.dg/other/crash-7.C: New test.
        * g++.dg/other/crash-8.C: New test.

        2010-01-28  Uros Bizjak  <ubizjak@gmail.com>

        PR target/42891
        * gcc.target/i386/pr42891.c: New test.

        2010-01-28  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42883
        * g++.dg/torture/pr42883.C: New testcase.

        2010-01-28  Michael Matz  <matz@suse.de>

        * gcc.target/i386/pr42881.c: New test.

        2010-01-28  Dodji Seketeli  <dodji@redhat.com>

        PR c++/42713
        PR c++/42820
        * g++.dg/template/typedef27.C: New test case.
        * g++.dg/template/typedef28.C: New test case.

        2010-01-27  Jakub Jelinek  <jakub@redhat.com>

        PR middle-end/42874
        * gcc.dg/vla-22.c: New test.

        2010-01-26  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42250
        * gcc.dg/pr42250.c: New testcase.

        2010-01-25  Tobias Burnus  <burnus@net-b.de>

        PR fortran/42858
        * gfortran.dg/generic_21.f90: New test.

        2010-01-21  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42585
        * gcc.dg/tree-ssa/pr42585.c: New test.

        2010-01-20  Alexandre Oliva  <aoliva@redhat.com>

        PR debug/42715
        * gcc.dg/pr42715.c: New.

        2010-01-20  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42717
        * gcc.c-torture/compile/pr42717.c: New testcase.

        2010-01-19  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42783
        * gfortran.dg/bounds_check_15.f90 : New test.

        2010-01-18  Dodji Seketeli  <dodji@redhat.com>

        PR c++/42766
        * g++.dg/conversion/op6.C: New test.

        2010-01-18  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42781
        * gfortran.fortran-torture/compile/pr42781.f90: New testcase.

        2010-01-17  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42248
        * gcc.c-torture/execute/pr42248.c: New testcase.

        2010-01-17  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42677
        * gfortran.dg/interface_assignment_5.f90: New test.

        2010-01-15  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42739
        * g++.dg/torture/pr42739.C: New testcase.

        2010-01-14 Jerry DeLisle <jvdelisle@gcc.gnu.org>

        PR fortran/42684
        * gfortran.dg/interface_31.f90: New test.

        2010-01-14  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42706
        * gcc.dg/ipa/pr42706.c: New testcase.

        2010-01-14  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42714
        * g++.dg/torture/pr42714.C: New test.

        2010-01-14  Alexander Monakov  <amonakov@ispras.ru>

        PR rtl-optimization/42388
        * gcc.dg/pr42388.c: New.

        2010-01-14  Alexander Monakov <amonakov@ispras.ru>

        PR rtl-optimization/42294
        * gfortran.dg/pr42294.f: New.

        2010-01-14  Ira Rosen  <irar@il.ibm.com>

        PR tree-optimization/42709
        * gcc.dg/vect/pr42709.c: New test.

        2010-01-13  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42730
        * gcc.c-torture/compile/pr42730.c: New testcase.

        2010-01-13  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42704
        * g++.dg/torture/pr42704.C: New test.

        2010-01-13  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42703
        * gcc.c-torture/compile/pr42703.c: New test.

        2010-01-13  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42705
        * gcc.c-torture/compile/pr42705.c: New testcase.

        2010-01-13  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42716
        * gcc.c-torture/compile/pr42716.c: New testcase.

        2010-01-12  Joseph Myers  <joseph@codesourcery.com>

        PR c/42708
        * gcc.c-torture/compile/pr42708-1.c: New test.

        2010-01-09  Alexandre Oliva  <aoliva@redhat.com>

        PR middle-end/42363
        * gcc.dg/torture/pr42363.c: New.

        2010-01-09  Alexandre Oliva  <aoliva@redhat.com>

        PR debug/42604
        PR debug/42395
        * gcc.dg/vect/pr42604.c: New.
        * gcc.dg/vect/pr42395.c: New.

        2010-01-09  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42512
        * gcc.c-torture/execute/pr42512.c: New testcase.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/conversion/op6.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/conversion/op6.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/builtin11.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/ext/builtin11.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-5.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-5.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-7.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-7.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-8.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-8.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-9.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-9.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef27.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/template/typedef27.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef28.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/template/typedef28.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42704.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42704.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42714.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42714.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42739.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42739.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42883.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42883.C
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42703.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42703.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42705.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42705.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42716.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42716.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42717.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42717.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42730.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42730.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42927.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42927.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42248.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/execute/pr42248.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42512.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/execute/pr42512.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/errno-1.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/errno-1.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/ipa/pr42706.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/ipa/pr42706.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42250.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42250.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42388.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42388.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42715.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42715.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42363.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/torture/pr42363.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42395.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42395.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42604.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42604.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42709.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42709.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vla-22.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/vla-22.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42881.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.target/i386/pr42881.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42891.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.target/i386/pr42891.c
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/bounds_check_15.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/bounds_check_15.f90
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/generic_21.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/generic_21.f90
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_31.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/interface_31.f90
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_assignment_5.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/interface_assignment_5.f90
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr42294.f
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/pr42294.f
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90
Modified:
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880


^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2010-02-07  4:46 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-27 10:42 [Bug c++/42880] New: trunk does not compile boost MPL piotr dot wyderski at gmail dot com
2010-01-27 10:44 ` [Bug c++/42880] " piotr dot wyderski at gmail dot com
2010-01-27 10:44 ` piotr dot wyderski at gmail dot com
2010-01-27 10:57 ` paolo dot carlini at oracle dot com
2010-01-27 11:06 ` piotr dot wyderski at gmail dot com
2010-01-27 11:08 ` paolo dot carlini at oracle dot com
2010-01-27 12:06 ` davek at gcc dot gnu dot org
2010-01-27 12:12 ` paolo dot carlini at oracle dot com
2010-01-27 12:21 ` paolo dot carlini at oracle dot com
2010-01-27 12:27 ` piotr dot wyderski at gmail dot com
2010-01-27 12:29 ` davek at gcc dot gnu dot org
2010-01-27 12:30 ` davek at gcc dot gnu dot org
2010-01-27 12:33 ` paolo dot carlini at oracle dot com
2010-01-27 12:35 ` paolo dot carlini at oracle dot com
2010-01-27 12:36 ` davek at gcc dot gnu dot org
2010-01-27 12:39 ` piotr dot wyderski at gmail dot com
2010-01-27 12:39 ` davek at gcc dot gnu dot org
2010-01-27 12:42 ` paolo dot carlini at oracle dot com
2010-01-27 12:45 ` davek at gcc dot gnu dot org
2010-01-27 12:47 ` piotr dot wyderski at gmail dot com
2010-01-27 12:48 ` davek at gcc dot gnu dot org
2010-01-27 12:53 ` paolo dot carlini at oracle dot com
2010-01-27 12:59 ` davek at gcc dot gnu dot org
2010-01-27 13:04 ` piotr dot wyderski at gmail dot com
2010-01-27 13:09 ` piotr dot wyderski at gmail dot com
2010-01-27 13:12 ` davek at gcc dot gnu dot org
2010-01-27 13:26 ` piotr dot wyderski at gmail dot com
2010-01-27 15:17 ` davek at gcc dot gnu dot org
2010-01-27 15:31 ` davek at gcc dot gnu dot org
2010-01-27 15:32 ` paolo dot carlini at oracle dot com
2010-01-27 15:41 ` paolo dot carlini at oracle dot com
2010-01-27 15:48 ` davek at gcc dot gnu dot org
2010-01-27 15:57 ` paolo dot carlini at oracle dot com
2010-01-27 16:08 ` davek at gcc dot gnu dot org
2010-01-27 16:14 ` paolo dot carlini at oracle dot com
2010-01-27 17:55 ` davek at gcc dot gnu dot org
2010-01-27 18:09 ` paolo dot carlini at oracle dot com
2010-01-27 18:14 ` paolo dot carlini at oracle dot com
2010-01-27 18:15 ` paolo dot carlini at oracle dot com
2010-01-27 18:16 ` jwakely dot gcc at gmail dot com
2010-01-27 18:17 ` davek at gcc dot gnu dot org
2010-01-27 18:25 ` paolo dot carlini at oracle dot com
2010-01-28  6:25 ` hjl dot tools at gmail dot com
2010-01-28  8:26 ` dodji at gcc dot gnu dot org
2010-01-28  8:38 ` dodji at gcc dot gnu dot org
2010-01-28  9:45 ` paolo dot carlini at oracle dot com
2010-01-28 22:53 ` jason at gcc dot gnu dot org
2010-01-29 14:31 ` dodji at gcc dot gnu dot org
2010-02-07  4:46 ` hjl at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).