--- 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
--- 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++
--- 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_definiti
--- 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
--- 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
--- 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/sho
--- 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
-
--- 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
--- 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 t
--- 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
--- 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
--- 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.
--
ht
--- 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
--- 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 compil
--- 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 ju
--- 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 i
--- 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 cha
--- 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
--- 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 -
--- 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 that is, _GLIBCXX_INCLUDE_AS_CXX0X
is undefined and no error should happen. Likewise, when the
tr1_impl
--- 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. S
--- 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 i
--- 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,
--- 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
--- 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
--- 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
--- 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 fr
--- 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 /
re
--- 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
>
--- 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 uncomp
--- 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 arou
--- 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
--- 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
--- 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;
dkad...@ubik /tmp/boost
$ g++-4 -std=c++0x -c test.cpp ; echo $?
0
dkad...@ubik /tmp/boost
$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- 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.
--- 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
--- 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 o
--- 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
--- 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
--- 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...
20100
--- 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
--- 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
--- 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.
C
--- 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
--- 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
--- 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
--- 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
--- 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
48 matches
Mail list logo
