--- 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,
--
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
--- 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
--- 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
--- 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,
--- 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
--- 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.
--
--- 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
--- 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
--- 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
--- 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
--- 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),
--- 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...
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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-
--- 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
--- 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
--- 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=gccview=revrev=145563
Log:
2009-04-05 Paolo Carlini paolo.carl...@oracle.com
PR
--- 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.
--
--- 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
--- 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
--- 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,
--- 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
--- 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
--- 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),
32 matches
Mail list logo
