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)
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.
(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?)
(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.
(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.
(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.
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
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.
(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)
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.
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.
wake up, of course ;)
(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.
(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.
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.
(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.
(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.
(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. :)
(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!
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...
(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
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.
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.
(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).
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
Actually, Hans-Peter, you should know it well, libstdc++/37147 ;)
(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.
(In reply to comment #26) > Anyway, newlib patch sent, ...which BTW fixed the regressions, but not the new FAILs. Hm.
(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.
(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.
It'll be nice to have stdint.h provided by the compiler. ;)
Hans-Peter, any news about your patch? If I understand correctly, when it will be in, the testsuite will be again clean.
(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.