* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
@ 2009-04-05 9:09 ` paolo dot carlini at oracle dot com
2009-04-05 13:36 ` hp at gcc dot gnu dot org
` (31 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-05 9:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from paolo dot carlini at oracle dot com 2009-04-05 09:09 -------
I'm removing myself from CC because I'm not more responsible for these issues
than the other maintainers.
Anyway, just wanted to ask if the stdint.h support (the appropriate bits to
close PR 448) is forthcoming for this OS: as regards the stdint.h part of the
issues, I'd like to avoid adding the dg-require-cstdint dance to all the
testcases, etc, because all of that will go away when 448 will be closed.
--
paolo dot carlini at oracle dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|paolo at gcc dot gnu dot org|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
2009-04-05 9:09 ` [Bug libstdc++/39644] " paolo dot carlini at oracle dot com
@ 2009-04-05 13:36 ` hp at gcc dot gnu dot org
2009-04-05 13:48 ` paolo dot carlini at oracle dot com
` (30 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-05 13:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from hp at gcc dot gnu dot org 2009-04-05 13:36 -------
(In reply to comment #1)
> Anyway, just wanted to ask if the stdint.h support (the appropriate bits to
> close PR 448) is forthcoming for this OS:
The cris-elf target uses standard newlib-stdint.h, nothing special about that.
(hm, you mean it doesn't work and that's the reason for those FAILs?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
2009-04-05 9:09 ` [Bug libstdc++/39644] " paolo dot carlini at oracle dot com
2009-04-05 13:36 ` hp at gcc dot gnu dot org
@ 2009-04-05 13:48 ` paolo dot carlini at oracle dot com
2009-04-05 16:46 ` hp at gcc dot gnu dot org
` (29 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-05 13:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from paolo dot carlini at oracle dot com 2009-04-05 13:48 -------
(In reply to comment #2)
> The cris-elf target uses standard newlib-stdint.h, nothing special about that.
> (hm, you mean it doesn't work and that's the reason for those FAILs?)
Hum. Two separate comments: 1- The issue with those fails is only *partially*
due to stdint.h, as you can see from the log2l related fails, which have
nothing to do with stdint.h, of course, and must be fixed anyway; 2- As regards
stdint.h, if you can confirm that cris-elf is already ok for 448 (in practice
that means that gcc installs a fully usable and conforming stdint.h, along with
float.h, and so on, in the */lib/gcc/*/4.5.0/include subdir), then it's
probably libstdc++ fault, in that is currently carrying out configure-time
tests for your target which actually spoil that work. I'm not sure. I'd like to
know more from you. In any case, eventually, when 448 will be closed, *all* the
configure time tests in this area, and testing infrastructure, etc., will be
simply removed, the possibility to include <stdint.h> will be assumed
unconditionally.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (2 preceding siblings ...)
2009-04-05 13:48 ` paolo dot carlini at oracle dot com
@ 2009-04-05 16:46 ` hp at gcc dot gnu dot org
2009-04-05 16:49 ` paolo dot carlini at oracle dot com
` (28 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-05 16:46 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from hp at gcc dot gnu dot org 2009-04-05 16:46 -------
(In reply to comment #3)
> > (hm, you mean it doesn't work and that's the reason for those FAILs?)
>
> Hum. Two separate comments: 1- The issue with those fails is only *partially*
> due to stdint.h, as you can see from the log2l related fails,
Of course. By "those fails" instead of "all fails" I referred to those fails
(oops again :) only. I guess depending on language that's an ambiguous phrase,
so let's use the longer "that subset of the FAILs".
> which have
> nothing to do with stdint.h, of course, and must be fixed anyway;
> 2- As regards
> stdint.h, if you can confirm that cris-elf is already ok for 448 (in practice
> that means that gcc installs a fully usable and conforming stdint.h, along with
> float.h, and so on, in the */lib/gcc/*/4.5.0/include subdir),
It's not *installed* at the time the test-suite run, but from the brief look I
had, I saw nothing wrong with jsm28's stdint stuff. For example, the C
test-cases jsm28 added all pass, so I see no apparent failure. But see below.
> then it's
> probably libstdc++ fault, in that is currently carrying out configure-time
> tests for your target which actually spoil that work. I'm not sure. I'd like to
> know more from you.
I see the following in the testsuite logs (for r145559), which might be a clue:
...
cstdint17453.cc:2: error: expected initializer at end of input
compiler exited with status 1
output is:
cstdint17453.cc:2: error: expected initializer at end of input
UNSUPPORTED: 18_support/headers/cstdint/types_std_c++0x.cc
so (wild speculation) if that dg- support test is wrong, it can explain why the
test-suite filters out all test-cases now "redundantly" gated by
dg-require-cstdint.
> In any case, eventually, when 448 will be closed, *all* the
> configure time tests in this area, and testing infrastructure, etc., will be
> simply removed, the possibility to include <stdint.h> will be assumed
> unconditionally.
Naturally. Not sure about your point: I just reported observations I thought
would be relevant. What fails must be fixed.
--
hp at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-04-05 16:46:18
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (3 preceding siblings ...)
2009-04-05 16:46 ` hp at gcc dot gnu dot org
@ 2009-04-05 16:49 ` paolo dot carlini at oracle dot com
2009-04-05 16:56 ` paolo at gcc dot gnu dot org
` (27 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-05 16:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from paolo dot carlini at oracle dot com 2009-04-05 16:49 -------
(In reply to comment #4)
> > In any case, eventually, when 448 will be closed, *all* the
> > configure time tests in this area, and testing infrastructure, etc., will be
> > simply removed, the possibility to include <stdint.h> will be assumed
> > unconditionally.
>
> Naturally. Not sure about your point: I just reported observations I thought
> would be relevant. What fails must be fixed.
Of course. My point is that if 448 is fixed soon, we can just remove all those
crazy configury bits, assume stdint.h is available unconditionally, and this PR
will be fixed automagically, as part of a library clean-up essentially.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (4 preceding siblings ...)
2009-04-05 16:49 ` paolo dot carlini at oracle dot com
@ 2009-04-05 16:56 ` paolo at gcc dot gnu dot org
2009-04-05 16:59 ` paolo dot carlini at oracle dot com
` (26 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo at gcc dot gnu dot org @ 2009-04-05 16:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from paolo at gcc dot gnu dot org 2009-04-05 16:56 -------
Subject: Bug 39644
Author: paolo
Date: Sun Apr 5 16:56:16 2009
New Revision: 145563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145563
Log:
2009-04-05 Paolo Carlini <paolo.carlini@oracle.com>
PR libstdc++/39644 (partial)
* include/bits/random.tcc (linear_congruential_engine<>::
seed(seed_seq&), independent_bits_engine<>::operator(),
generate_canonical(_UniformRandomNumberGenerator&)): Avoid log2l.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.tcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (5 preceding siblings ...)
2009-04-05 16:56 ` paolo at gcc dot gnu dot org
@ 2009-04-05 16:59 ` paolo dot carlini at oracle dot com
2009-04-05 22:24 ` hp at gcc dot gnu dot org
` (25 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-05 16:59 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from paolo dot carlini at oracle dot com 2009-04-05 16:59 -------
Please, let me know how it goes as far as the fails related to log2* are
concerned. For the other fails, stdint.h related, see my previous message in
the trail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (6 preceding siblings ...)
2009-04-05 16:59 ` paolo dot carlini at oracle dot com
@ 2009-04-05 22:24 ` hp at gcc dot gnu dot org
2009-04-05 22:41 ` paolo dot carlini at oracle dot com
` (24 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-05 22:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from hp at gcc dot gnu dot org 2009-04-05 22:24 -------
(In reply to comment #7)
> Please, let me know how it goes as far as the fails related to log2* are
> concerned.
Revision r145563 seems to have a typo. I now see in the .log (beware,
cutnpaste):
...
compiler exited with status 1
output is:
In file included from
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/random:58,
from
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc:122:
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:
In member function 'result_type std:
:piecewise_linear_distribution<_RealType>::operator()(_UniformRandomNumberGenerator&,
const std::piecewise_linear_distribution<_RealType>::param_type&)':
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:2598:
error: expected ',' or ';' before ')' token
FAIL: 17_intro/headers/c++200x/all.cc (test for excess errors)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (7 preceding siblings ...)
2009-04-05 22:24 ` hp at gcc dot gnu dot org
@ 2009-04-05 22:41 ` paolo dot carlini at oracle dot com
2009-04-05 22:47 ` paolo dot carlini at oracle dot com
` (23 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-05 22:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from paolo dot carlini at oracle dot com 2009-04-05 22:41 -------
Humpf, I see a spurious closed parenthesis for the weakly tested so far case of
_GLIBCXX_USE_C99_MATH_TR1 undefined. In fact, all this math should be probably
done better, but I'm going to remove the parenthesis, let's see if we can move
ahead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (8 preceding siblings ...)
2009-04-05 22:41 ` paolo dot carlini at oracle dot com
@ 2009-04-05 22:47 ` paolo dot carlini at oracle dot com
2009-04-05 22:47 ` paolo dot carlini at oracle dot com
` (22 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-05 22:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from paolo dot carlini at oracle dot com 2009-04-05 22:46 -------
Hans-Peter, please understand that this code is brand new, contributed by an
external friend of the project. Thus, if you spot something trivial, like a
typo, definitely improving the build on your system, just go ahead, don't wait
for me to weak up maybe in a different time zone, or whatever. Thanks in
advance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (9 preceding siblings ...)
2009-04-05 22:47 ` paolo dot carlini at oracle dot com
@ 2009-04-05 22:47 ` paolo dot carlini at oracle dot com
2009-04-05 23:39 ` hp at gcc dot gnu dot org
` (21 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-05 22:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from paolo dot carlini at oracle dot com 2009-04-05 22:47 -------
wake up, of course ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (10 preceding siblings ...)
2009-04-05 22:47 ` paolo dot carlini at oracle dot com
@ 2009-04-05 23:39 ` hp at gcc dot gnu dot org
2009-04-06 2:55 ` hp at gcc dot gnu dot org
` (20 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-05 23:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from hp at gcc dot gnu dot org 2009-04-05 23:38 -------
(In reply to comment #10)
> Hans-Peter, please understand that this code is brand new,
I *do* understand. Please don't misunderstand the intent here. Just because I
report regressions or follow-up requests doesn't mean I insist on it being
handled as a priority issue, not more so than any other regression.
> contributed by an
> external friend of the project. Thus, if you spot something trivial, like a
> typo, definitely improving the build on your system, just go ahead,
That goes without saying, really. I do that, sometimes, depending on
priorities and whatnot. Don't expect much on weekends; I don't...
I do try to be clear and complete and quick enough with regression reports, but
anything more than that has to compete with other priorities.
My earlier comment was just a quick pasting from intermediate results from an
autotester run in-progress, in response to your request. So, I was able to
quickly report something that went wrong, but couldn't verify complete
correctness in that same time-frame, not to the level that I'd be comfortable
checking in a fix, at least this time, right or wrong. I had a brief look, but
wasn't sufficiently sure that it was worth the effort to set up and regtest
manually after removing a ")", also considering the likelihood that it was
already done. I figured you or someone else with svn write access, a clue and
a just-built tree were about to notice yourself, and that a fix would be
committed by the time my autester would start the next round and I'd be able to
verify any correction without setting up a test-run manually.
And even if wasn't so, I'm not expecting (or expecting anyone to expect) quick
fixes, certainly not in less than a day at this time of the week.
...and there you go, the autotester has finished the earlier round (with the
typo) and has picked up the correction (thanks!) I'll know in about 2h, which
perhaps an hour or at most two later than best.
If I'm awake that is.
So, while I'm thankful for the quick response, I'm not expecting it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (11 preceding siblings ...)
2009-04-05 23:39 ` hp at gcc dot gnu dot org
@ 2009-04-06 2:55 ` hp at gcc dot gnu dot org
2009-04-06 9:35 ` paolo dot carlini at oracle dot com
` (19 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-06 2:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from hp at gcc dot gnu dot org 2009-04-06 02:55 -------
(In reply to comment #7)
> Please, let me know how it goes as far as the fails related to log2* are
> concerned.
Revision 145575 only had these following libstdc++ regressions remaining (not
counting the new FAILs), where the log messages are consistent with a
stdint.h-related flaw only; all log2l-related FAILs are fixed AFAICT.
libstdc++.sum 17_intro/using_namespace_std_tr1_neg.cc
libstdc++.sum 26_numerics/headers/random/types_std_c++0x.cc
Thanks! Hopefully I'll find time to analyze the stdint.h-related FAILs more
thoroughly, but I can't commit to that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (12 preceding siblings ...)
2009-04-06 2:55 ` hp at gcc dot gnu dot org
@ 2009-04-06 9:35 ` paolo dot carlini at oracle dot com
2009-04-06 13:36 ` hp at gcc dot gnu dot org
` (18 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-06 9:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from paolo dot carlini at oracle dot com 2009-04-06 09:34 -------
Thanks Hans-Peter. If you can analyze a bit more the stdint.h issues it would
be great. In particular, I would like to know if on such targets stdint.h is
available at C++ library configure time, the configure tests succeed and thus
_GLIBCXX_USE_C99_STDINT_TR1 is defined. Then, there are two possibilities: if
the tests pass, we have to understand why uint_fast32_t is not available, at
the moment I have no idea; if the tests do not pass, the issue is probably
simpler, just matter of waiting for 448 to be closed and removing all the
configure contortions related to stdint.h will likely fix this issue.
--
paolo dot carlini at oracle dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |paolo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (13 preceding siblings ...)
2009-04-06 9:35 ` paolo dot carlini at oracle dot com
@ 2009-04-06 13:36 ` hp at gcc dot gnu dot org
2009-04-06 13:50 ` paolo dot carlini at oracle dot com
` (17 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-06 13:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from hp at gcc dot gnu dot org 2009-04-06 13:36 -------
(In reply to comment #14)
> In particular, I would like to know if on such targets stdint.h is
> available at C++ library configure time, the configure tests succeed
Well *some* configure tests succeed (see "Description"), but grep says, of
cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h:
/* #undef _GLIBCXX_USE_C99_STDINT_TR1 */
> if the tests do not pass, the issue is probably
> simpler, just matter of waiting for 448 to be closed
I can't see that it is a matter of something depending on that PR since all the
target stuff is there, but something definitely goes wrong for libstdc++:
checking for ISO C99 support to TR1 in <math.h>... no
Maybe that newlib provides an incomplete stdint.h which is picked up before the
gcc-generated one; I definitely see two stdint.h. Anyway, later on that bit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (14 preceding siblings ...)
2009-04-06 13:36 ` hp at gcc dot gnu dot org
@ 2009-04-06 13:50 ` paolo dot carlini at oracle dot com
2009-04-06 14:03 ` hp at gcc dot gnu dot org
` (16 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-06 13:50 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from paolo dot carlini at oracle dot com 2009-04-06 13:49 -------
(In reply to comment #15)
> Well *some* configure tests succeed (see "Description"), but grep says, of
> cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h:
> /* #undef _GLIBCXX_USE_C99_STDINT_TR1 */
Ok...
> > if the tests do not pass, the issue is probably
> > simpler, just matter of waiting for 448 to be closed
>
> I can't see that it is a matter of something depending on that PR since all the
> target stuff is there,
I'm afraid you didn't get my point completely: *if* that macro above is
disabled, then the library *assumes* stdint.h is *not* available, in general.
In that case, *any* library code relying on stdint.h should be ifdef-out out
completely, disabled. However, the author of the new std::random bits didn't
take care of doing that - we have been consistently doing that, elsewhere - and
in that case fails are expected.
When 448 will be closed, we'll *remove* completely any configure test for
stdint.h, we'll assume it's available, similarly to float.h for example, we'll
unconditionally include it, and correctly unconditionally enable any facility
relying on it.
To summarize, right now, for std::random the library is in an inconsistent
state for some targets, because the facility is unconditionally enabled but
stdint.h is not unconditionally available.
I hope my explanation is more clear.
The above said, I'm not sure we should spend much time trying to figure out why
for your target the configure checks for stdint.h fail, because, as I said
above, as soon as 448 is closed, all those tests will go away, the library will
simply assume stdint.h (that's the very point of 448, after all, for libstdc++
and all the other target libraries). If, however, you have reasons to believe
your stdint.h is still not ok, it's really not ok, that's another matter, does
not have much to do with libstdc++ proper.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (15 preceding siblings ...)
2009-04-06 13:50 ` paolo dot carlini at oracle dot com
@ 2009-04-06 14:03 ` hp at gcc dot gnu dot org
2009-04-06 14:14 ` paolo dot carlini at oracle dot com
` (15 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-06 14:03 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from hp at gcc dot gnu dot org 2009-04-06 14:03 -------
(In reply to comment #16)
> I hope my explanation is more clear.
Yes, thanks, sorry I didn't get the picture before.
> The above said, I'm not sure we should spend much time trying to figure out why
> for your target the configure checks for stdint.h fail,
Superficially, it looks as if it fails because stdint.h isn't picked up
properly by libstdc++ (in contrast to the C test-suite) so I do think this is
worthwhile. I don't think it's worthwhile to try and make a distinction
between incomplete-target-stdint and libstdc++-stdint-include-issues before
that analysis. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (16 preceding siblings ...)
2009-04-06 14:03 ` hp at gcc dot gnu dot org
@ 2009-04-06 14:14 ` paolo dot carlini at oracle dot com
2009-04-06 14:36 ` paolo dot carlini at oracle dot com
` (14 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-06 14:14 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from paolo dot carlini at oracle dot com 2009-04-06 14:13 -------
(In reply to comment #17)
> Superficially, it looks as if it fails because stdint.h isn't picked up
> properly by libstdc++ (in contrast to the C test-suite) so I do think this is
> worthwhile. I don't think it's worthwhile to try and make a distinction
> between incomplete-target-stdint and libstdc++-stdint-include-issues before
> that analysis. :)
I see what you mean, but one thing is configure time, another the library
proper. Again, when 448 will closed, the library will be cleaned up to not do
*any* configure time checks in this area. Otherwise, <cstdint>, as you can see
yourself is *trivial*, cannot do anything wrong with stdint.h, as <cfloat>
doesn't do anything wrong with float.h. That said, if you notice something
strange just let us know!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (17 preceding siblings ...)
2009-04-06 14:14 ` paolo dot carlini at oracle dot com
@ 2009-04-06 14:36 ` paolo dot carlini at oracle dot com
2009-04-06 15:16 ` hp at gcc dot gnu dot org
` (13 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-06 14:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from paolo dot carlini at oracle dot com 2009-04-06 14:36 -------
One final remark: since you are having problem with uint_fast32_t, unqualified,
what really matters is _GLIBCXX_HAVE_STDINT_H, *not*
_GLIBCXX_USE_C99_STDINT_TR1. Have a look to include/c_global/cstdint for
details: if _GLIBCXX_HAVE_STDINT_H is not defined, then <stdint.h> isn't really
included and any facility including <cstdint> doesn't really include much.
Thus, for your target, the basic issue, at the moment, is why
_GLIBCXX_HAVE_STDINT_H is not defined. Certainly in configure.ac we are running
AC_CHECK_HEADERS on stdint.h...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (18 preceding siblings ...)
2009-04-06 14:36 ` paolo dot carlini at oracle dot com
@ 2009-04-06 15:16 ` hp at gcc dot gnu dot org
2009-04-06 15:22 ` paolo dot carlini at oracle dot com
` (12 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-06 15:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from hp at gcc dot gnu dot org 2009-04-06 15:15 -------
(In reply to comment #19)
> One final remark: since you are having problem with uint_fast32_t, unqualified,
> what really matters is _GLIBCXX_HAVE_STDINT_H, *not*
> _GLIBCXX_USE_C99_STDINT_TR1.
I see in gccobj/cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h:
#define _GLIBCXX_HAVE_STDINT_H 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (19 preceding siblings ...)
2009-04-06 15:16 ` hp at gcc dot gnu dot org
@ 2009-04-06 15:22 ` paolo dot carlini at oracle dot com
2009-04-06 15:32 ` paolo dot carlini at oracle dot com
` (11 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-06 15:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from paolo dot carlini at oracle dot com 2009-04-06 15:21 -------
Interesting. Then you should really look inside the pre-processed
using_namespace_std_tr1_neg.cc and see why uint_fast32_t is not known.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (20 preceding siblings ...)
2009-04-06 15:22 ` paolo dot carlini at oracle dot com
@ 2009-04-06 15:32 ` paolo dot carlini at oracle dot com
2009-04-08 6:47 ` hp at gcc dot gnu dot org
` (10 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-06 15:32 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from paolo dot carlini at oracle dot com 2009-04-06 15:32 -------
Probably, somewhere, an _GLIBCXX_USE_C99_STDINT_TR1 is protecting the inclusion
of <cstdint> itself, thus we are back to square one...
If you want - as I said, I don't think it's really a good way to spend our time
- you should then figure out why the configure-time tests do not enable
_GLIBCXX_USE_C99_STDINT_TR1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (21 preceding siblings ...)
2009-04-06 15:32 ` paolo dot carlini at oracle dot com
@ 2009-04-08 6:47 ` hp at gcc dot gnu dot org
2009-04-08 7:39 ` paolo dot carlini at oracle dot com
` (9 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-08 6:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from hp at gcc dot gnu dot org 2009-04-08 06:47 -------
(In reply to comment #22)
> you should then figure out why the configure-time tests do not enable
> _GLIBCXX_USE_C99_STDINT_TR1.
conftest.cc: In function 'int main()':
conftest.cc:99: error: 'INTPTR_MAX' was not declared in this scope
conftest.cc:100: error: 'INTPTR_MIN' was not declared in this scope
conftest.cc:141: error: 'UINTPTR_MAX' was not declared in this scope
IIRC (not having the standard here), these macros are mandatory with the
__STDC_CONSTANT_MACROS so this is a deficiency in the newlib stdint.h (as
obvious, but absence verified by inspection).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (22 preceding siblings ...)
2009-04-08 6:47 ` hp at gcc dot gnu dot org
@ 2009-04-08 7:39 ` paolo dot carlini at oracle dot com
2009-04-08 13:57 ` paolo dot carlini at oracle dot com
` (8 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-08 7:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from paolo dot carlini at oracle dot com 2009-04-08 07:39 -------
Interesting. Actually, I seem to remember that for some time we didn't have
specific lines in the configure test checking those macros and that led to
unespected fails in the testsuite for some targets which, unexpectedly had
everything in stdint.h but those required macros, exactly as you are saying. I
would suggest looking in the Changelog for a change of mine tightening that
check (thus, touching acinclude). In case, I think you should point out the
problem to the people responsible for the newlib bits of 448, because of course
target libraries assuming stdint.h unconditionally available also assume the
standard conforming behavior for the macros. In fact, I hope I'm wrong, but the
last days I saw some checkins around for the other OSes and I didn't notice the
macros and the machinery using the feature macro...
One last remark, for the record: for C++0x we eventually want those macros
unconditionally available irrespective of the C99 feature macro, thus we'll
probably have to tweak the GCC machinery in that sense, with a bit of
preprocessing directives on top of stdint.h checking the C++ dialect
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (23 preceding siblings ...)
2009-04-08 7:39 ` paolo dot carlini at oracle dot com
@ 2009-04-08 13:57 ` paolo dot carlini at oracle dot com
2009-04-08 20:09 ` hp at gcc dot gnu dot org
` (7 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-08 13:57 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from paolo dot carlini at oracle dot com 2009-04-08 13:57 -------
Actually, Hans-Peter, you should know it well, libstdc++/37147 ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (24 preceding siblings ...)
2009-04-08 13:57 ` paolo dot carlini at oracle dot com
@ 2009-04-08 20:09 ` hp at gcc dot gnu dot org
2009-04-08 20:11 ` hp at gcc dot gnu dot org
` (6 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-08 20:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from hp at gcc dot gnu dot org 2009-04-08 20:08 -------
(In reply to comment #25)
> Actually, Hans-Peter, you should know it well, libstdc++/37147 ;)
Wow. That had completely left my mind!
Anyway, newlib patch sent, further comment in PR448.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (25 preceding siblings ...)
2009-04-08 20:09 ` hp at gcc dot gnu dot org
@ 2009-04-08 20:11 ` hp at gcc dot gnu dot org
2009-04-08 20:20 ` paolo dot carlini at oracle dot com
` (5 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-08 20:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from hp at gcc dot gnu dot org 2009-04-08 20:10 -------
(In reply to comment #26)
> Anyway, newlib patch sent,
...which BTW fixed the regressions, but not the new FAILs. Hm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (26 preceding siblings ...)
2009-04-08 20:11 ` hp at gcc dot gnu dot org
@ 2009-04-08 20:20 ` paolo dot carlini at oracle dot com
2009-04-08 22:52 ` hp at gcc dot gnu dot org
` (4 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-08 20:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from paolo dot carlini at oracle dot com 2009-04-08 20:20 -------
(In reply to comment #27)
> (In reply to comment #26)
> > Anyway, newlib patch sent,
Great, thanks.
> ...which BTW fixed the regressions, but not the new FAILs. Hm.
Wait a minute, by new fails you mean those reported in libstdc++/39629? That is
completely different issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (27 preceding siblings ...)
2009-04-08 20:20 ` paolo dot carlini at oracle dot com
@ 2009-04-08 22:52 ` hp at gcc dot gnu dot org
2009-04-16 22:04 ` bkoz at gcc dot gnu dot org
` (3 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-08 22:52 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from hp at gcc dot gnu dot org 2009-04-08 22:52 -------
(In reply to comment #28)
> Wait a minute, by new fails you mean those reported in libstdc++/39629? That is
> completely different issue.
I mean those mentioned in the "Description" of this PR (but just as a
coincidental observation)...which seem to have a significant overlap, if not
identical to those in PR39629. Good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (28 preceding siblings ...)
2009-04-08 22:52 ` hp at gcc dot gnu dot org
@ 2009-04-16 22:04 ` bkoz at gcc dot gnu dot org
2009-04-28 23:15 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2009-04-16 22:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #30 from bkoz at gcc dot gnu dot org 2009-04-16 22:04 -------
It'll be nice to have stdint.h provided by the compiler.
;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (29 preceding siblings ...)
2009-04-16 22:04 ` bkoz at gcc dot gnu dot org
@ 2009-04-28 23:15 ` pinskia at gcc dot gnu dot org
2009-04-29 11:53 ` paolo dot carlini at oracle dot com
2009-04-29 16:24 ` hp at gcc dot gnu dot org
32 siblings, 0 replies; 34+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-04-28 23:15 UTC (permalink / raw)
To: gcc-bugs
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (30 preceding siblings ...)
2009-04-28 23:15 ` pinskia at gcc dot gnu dot org
@ 2009-04-29 11:53 ` paolo dot carlini at oracle dot com
2009-04-29 16:24 ` hp at gcc dot gnu dot org
32 siblings, 0 replies; 34+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-29 11:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #31 from paolo dot carlini at oracle dot com 2009-04-29 11:53 -------
Hans-Peter, any news about your patch? If I understand correctly, when it will
be in, the testsuite will be again clean.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
2009-04-05 0:01 [Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3 hp at gcc dot gnu dot org
` (31 preceding siblings ...)
2009-04-29 11:53 ` paolo dot carlini at oracle dot com
@ 2009-04-29 16:24 ` hp at gcc dot gnu dot org
32 siblings, 0 replies; 34+ messages in thread
From: hp at gcc dot gnu dot org @ 2009-04-29 16:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #32 from hp at gcc dot gnu dot org 2009-04-29 16:23 -------
(In reply to comment #31)
> Hans-Peter, any news about your patch? If I understand correctly, when it will
> be in, the testsuite will be again clean.
Not clean, but without regressions. :)
If you mean the newlib patch, it's in and indeed for a while there were no
regressions. The fixincludes patch requires testing. But I don't think I
mentioned the fixincludes solution here (it's of no use anyway for the common
installation method used with newlib - compiling in a tree combined with gcc),
so I guess we should close this PR. So done. Thanks for the reminder.
--
hp at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
^ permalink raw reply [flat|nested] 34+ messages in thread