[Bug libstdc++/39644] New: [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[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]

The regressed tests are

libstdc++.sum 17_intro/headers/c++200x/all.cc
libstdc++.sum 17_intro/headers/c++200x/all_multiple_inclusion.cc
libstdc++.sum 17_intro/using_namespace_std_tr1_neg.cc
libstdc++.sum 26_numerics/headers/random/types_std_c++0x.cc

With revision 145482 these tests passed.
>From revision 145488 and on, these tests have failed as follows:

Running
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 17_intro/headers/c++200x/all.cc (test for excess errors)
FAIL: 17_intro/headers/c++200x/all_multiple_inclusion.cc (test for excess
errors)
FAIL: 17_intro/using_namespace_std_tr1_neg.cc (test for excess errors)
FAIL: 22_locale/ctype/scan/wchar_t/1.cc execution test
XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for
excess errors)
FAIL: 26_numerics/headers/random/types_std_c++0x.cc (test for excess errors)
FAIL: 26_numerics/random/bernoulli_distribution/cons/default.cc (test for
excess errors)
WARNING: 26_numerics/random/bernoulli_distribution/cons/default.cc compilation
failed to produce executable
FAIL: 26_numerics/random/bernoulli_distribution/cons/parms.cc (test for excess
errors)
WARNING: 26_numerics/random/bernoulli_distribution/cons/parms.cc compilation
failed to produce executable
FAIL: 26_numerics/random/bernoulli_distribution/operators/serialize.cc (test
for excess errors)
WARNING: 26_numerics/random/bernoulli_distribution/operators/serialize.cc
compilation failed to produce executable

Tests shown in context, with old and new FAILs.  See last for a list of new
FAILs with this revision.

The message in the logfile is, for the first regression:

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 'void std::linear_congruential_engine<_UIntType, __a, __c,
__m>::seed(std::seed_seq&)':
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:121:
error: expected unqualified-id before '(' token
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:
In member function 'result_type
std::independent_bits_engine<_RandomNumberEngine, __w,
_UIntType>::operator()()':
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:581:
error: 'log2l' is not a member of 'std'
/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:2596:
error: expected ',' or ';' before ')' token
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:
In function '_RealType
std::generate_canonical(_UniformRandomNumberGenerator&)':
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:2765:
error: 'log2l' is not a member of 'std'
compiler exited with status 1

Most other errors are similar, except for
17_intro/using_namespace_std_tr1_neg.cc and
26_numerics/headers/random/types_std_c++0x.cc:

In file included from
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/random:55,
                 from
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/17_intro/using_namespace_std_tr1_neg.cc:45:
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1371:
error: 'uint_fast32_t' was not declared in this scope
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1371:
error: template argument 1 is invalid
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1371:
error: '<type error>' is not a valid type for a template constant parameter
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1371:
error: '<type error>' is not a valid type for a template constant parameter
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1371:
error: '<type error>' is not a valid type for a template constant parameter
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1372:
error: invalid type in declaration before ';' token
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1377:
error: 'uint_fast32_t' was not declared in this scope
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1377:
error: template argument 1 is invalid
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1377:
error: '<type error>' is not a valid type for a template constant parameter
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.h:1377:
error: '<type error>' is not a valid type for a template constant parameter
(truncated)
PASS: 17_intro/using_namespace_std_tr1_neg.cc  (test for errors, line 64)
PASS: 17_intro/using_namespace_std_tr1_neg.cc  (test for errors, line 64)
FAIL: 17_intro/using_namespace_std_tr1_neg.cc (test for excess errors)

Author and committer of patches in suspect revision range CC:ed.

I see there's no log2l in newlib. Perhaps worthwhile to mention that the
configure test for C99 math.h succeeded:
...
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for exception model to use... call frame
checking for compiler with PCH support... yes
checking for enabled PCH... yes
checking for thread model used by GCC... single
checking for atomic builtins for bool... no
checking for atomic builtins for short... no
checking for atomic builtins for int... no
checking for atomic builtins for long long... no
checking for g++ that supports -ffunction-sections -fdata-sections... yes
checking for underlying I/O to use... stdio
checking for C locale to use... generic
checking for std::allocator base class... new
configure: "C" header strategy set to c_global
checking for enabled long long specializations... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for mbstate_t... yes
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking for enabled wchar_t specializations... yes
checking for sin in -lm... yes
checking for ISO C99 support in <math.h>... yes
checking tgmath.h usability... yes
checking tgmath.h presence... yes
checking for tgmath.h... yes
checking complex.h usability... no
checking complex.h presence... no
checking for complex.h... no
no
checking for ISO C99 support in <stdio.h>... no
checking for ISO C99 support in <stdlib.h>... no
checking for ISO C99 support in <wchar.h>... no
checking for fully enabled ISO C99 support... no
configure: Debug build flags set to -g3 -O0
checking for additional debug build... no
...

New FAILs with this revision:
+libstdc++.sum 26_numerics/random/bernoulli_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/bernoulli_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/bernoulli_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/bernoulli_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/binomial_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/binomial_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/binomial_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/binomial_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/cauchy_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/cauchy_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/cauchy_distribution/operators/serialize.cc
+libstdc++.sum 26_numerics/random/cauchy_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/chi_squared_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/chi_squared_distribution/cons/parms.cc
+libstdc++.sum
26_numerics/random/chi_squared_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/chi_squared_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/default_random_engine.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/cons/base_copy.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/cons/base_move.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/cons/default.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/cons/seed1.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/cons/seed2.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/cons/seed_seq.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/operators/equal.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/operators/serialize.cc
+libstdc++.sum 26_numerics/random/discard_block_engine/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/discrete_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/discrete_distribution/cons/initlist.cc
+libstdc++.sum 26_numerics/random/discrete_distribution/cons/num_xbound_fun.cc
+libstdc++.sum 26_numerics/random/discrete_distribution/cons/range.cc
+libstdc++.sum 26_numerics/random/discrete_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/discrete_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/exponential_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/exponential_distribution/cons/parms.cc
+libstdc++.sum
26_numerics/random/exponential_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/exponential_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/extreme_value_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/extreme_value_distribution/cons/parms.cc
+libstdc++.sum
26_numerics/random/extreme_value_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/extreme_value_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/fisher_f_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/fisher_f_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/fisher_f_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/fisher_f_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/gamma_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/gamma_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/gamma_distribution/operators/serialize.cc
+libstdc++.sum 26_numerics/random/gamma_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/geometric_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/geometric_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/geometric_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/geometric_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/independent_bits_engine/cons/base_copy.cc
+libstdc++.sum 26_numerics/random/independent_bits_engine/cons/base_move.cc
+libstdc++.sum 26_numerics/random/independent_bits_engine/cons/default.cc
+libstdc++.sum 26_numerics/random/independent_bits_engine/cons/seed1.cc
+libstdc++.sum 26_numerics/random/independent_bits_engine/cons/seed2.cc
+libstdc++.sum 26_numerics/random/independent_bits_engine/cons/seed_seq.cc
+libstdc++.sum 26_numerics/random/independent_bits_engine/operators/equal.cc
+libstdc++.sum
26_numerics/random/independent_bits_engine/operators/serialize.cc
+libstdc++.sum
26_numerics/random/independent_bits_engine/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/knuth_b.cc
+libstdc++.sum 26_numerics/random/linear_congruential_engine/cons/default.cc
+libstdc++.sum 26_numerics/random/linear_congruential_engine/cons/seed1.cc
+libstdc++.sum 26_numerics/random/linear_congruential_engine/cons/seed2.cc
+libstdc++.sum 26_numerics/random/linear_congruential_engine/operators/equal.cc
+libstdc++.sum
26_numerics/random/linear_congruential_engine/operators/serialize.cc
+libstdc++.sum
26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc
+libstdc++.sum
26_numerics/random/linear_congruential_engine/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/lognormal_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/lognormal_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/lognormal_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/lognormal_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/mersenne_twister_engine/cons/default.cc
+libstdc++.sum 26_numerics/random/mersenne_twister_engine/cons/seed1.cc
+libstdc++.sum 26_numerics/random/mersenne_twister_engine/cons/seed2.cc
+libstdc++.sum 26_numerics/random/mersenne_twister_engine/operators/equal.cc
+libstdc++.sum
26_numerics/random/mersenne_twister_engine/operators/serialize.cc
+libstdc++.sum
26_numerics/random/mersenne_twister_engine/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/minstd_rand.cc
+libstdc++.sum 26_numerics/random/minstd_rand0.cc
+libstdc++.sum 26_numerics/random/mt19937.cc
+libstdc++.sum 26_numerics/random/mt19937_64.cc
+libstdc++.sum
26_numerics/random/negative_binomial_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/negative_binomial_distribution/cons/parms.cc
+libstdc++.sum
26_numerics/random/negative_binomial_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/negative_binomial_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/normal_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/normal_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/normal_distribution/operators/serialize.cc
+libstdc++.sum 26_numerics/random/normal_distribution/requirements/typedefs.cc
+libstdc++.sum
26_numerics/random/piecewise_constant_distribution/cons/default.cc
+libstdc++.sum
26_numerics/random/piecewise_constant_distribution/cons/initlist_fun.cc
+libstdc++.sum
26_numerics/random/piecewise_constant_distribution/cons/num_xbound_fun.cc
+libstdc++.sum 26_numerics/random/piecewise_constant_distribution/cons/range.cc
+libstdc++.sum
26_numerics/random/piecewise_constant_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/piecewise_constant_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/piecewise_linear_distribution/cons/default.cc
+libstdc++.sum
26_numerics/random/piecewise_linear_distribution/cons/initlist_fun.cc
+libstdc++.sum
26_numerics/random/piecewise_linear_distribution/cons/num_xbound_fun.cc
+libstdc++.sum 26_numerics/random/piecewise_linear_distribution/cons/range.cc
+libstdc++.sum
26_numerics/random/piecewise_linear_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/piecewise_linear_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/poisson_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/poisson_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/poisson_distribution/operators/serialize.cc
+libstdc++.sum 26_numerics/random/poisson_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/random_device/cons/default.cc
+libstdc++.sum 26_numerics/random/random_device/cons/token.cc
+libstdc++.sum 26_numerics/random/random_device/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/ranlux24.cc
+libstdc++.sum 26_numerics/random/ranlux24_base.cc
+libstdc++.sum 26_numerics/random/ranlux48.cc
+libstdc++.sum 26_numerics/random/ranlux48_base.cc
+libstdc++.sum 26_numerics/random/seed_seq/cons/default.cc
+libstdc++.sum 26_numerics/random/seed_seq/cons/initlist.cc
+libstdc++.sum 26_numerics/random/seed_seq/cons/range.cc
+libstdc++.sum 26_numerics/random/seed_seq/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/cons/base_copy.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/cons/base_move.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/cons/default.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/cons/seed1.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/cons/seed2.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/cons/seed_seq.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/operators/equal.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/operators/serialize.cc
+libstdc++.sum 26_numerics/random/shuffle_order_engine/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/student_t_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/student_t_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/student_t_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/student_t_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/subtract_with_carry_engine/cons/default.cc
+libstdc++.sum 26_numerics/random/subtract_with_carry_engine/cons/seed1.cc
+libstdc++.sum 26_numerics/random/subtract_with_carry_engine/cons/seed2.cc
+libstdc++.sum 26_numerics/random/subtract_with_carry_engine/operators/equal.cc
+libstdc++.sum
26_numerics/random/subtract_with_carry_engine/operators/serialize.cc
+libstdc++.sum
26_numerics/random/subtract_with_carry_engine/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/uniform_int_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/uniform_int_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/uniform_int_distribution/cons/parms_neg.cc
+libstdc++.sum
26_numerics/random/uniform_int_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/uniform_int_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/uniform_real_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/uniform_real_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/uniform_real_distribution/cons/parms_neg.cc
+libstdc++.sum
26_numerics/random/uniform_real_distribution/operators/serialize.cc
+libstdc++.sum
26_numerics/random/uniform_real_distribution/requirements/typedefs.cc
+libstdc++.sum 26_numerics/random/weibull_distribution/cons/default.cc
+libstdc++.sum 26_numerics/random/weibull_distribution/cons/parms.cc
+libstdc++.sum 26_numerics/random/weibull_distribution/operators/serialize.cc
+libstdc++.sum 26_numerics/random/weibull_distribution/requirements/typedefs.cc
(list not truncated if this line seen)


-- 
           Summary: [4.5 Regression]: cris-elf
                    17_intro/headers/c++200x/all.cc plus 3
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[bkoz at gcc dot gnu dot org]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[pinskia at gcc dot gnu dot org]

-- 

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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

------- 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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

------- 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