libstdc++ / uclibc question
Is anyone building GCC (and libstdc++ specifically) with uclibc? I haven't
done this in a while and when I do it now I get this build failure:
/scratch/sellcey/repos/uclibc-ng/src/gcc/libstdc++-v3/include/ext/random.tcc:
In member function '__gnu_cxx::{anonymous}::uniform_on_sphere_helper<_Dimen,
_RealType>::result_type
__gnu_cxx::{anonymous}::uniform_on_sphere_helper<_Dimen,
_RealType>::operator()(_NormalDistribution&, _UniformRandomNumberGenerator&)':
/scratch/sellcey/repos/uclibc-ng/src/gcc/libstdc++-v3/include/ext/random.tcc:1573:44:
error: expected unqualified-id before '(' token
while (__norm == _RealType(0) || ! std::isfinite(__norm));
I am thinking the issue may be isfinite, but I am not sure. I notice there
are some tests like 26_numerics/headers/cmath/c99_classification_macros_c++.cc
that are xfailed for uclibc and I wonder if this is a related problem.
I could not find any uses of isfinite in other C++ files (except cmath)
and the tests that use it are the same ones that are xfailed for uclibc.
Steve Ellcey
sell...@imgtec.com
Extraneous newline emitted between error messages in GCC 6
GCC 6, compared to GCC 5, now emits an extra newline between error messages. Is this intended? $ cat error.c int x = a; int y = b; $ gcc-5 error.c error.c:1:9: error: ‘a’ undeclared here (not in a function) int x = a; ^ error.c:2:9: error: ‘b’ undeclared here (not in a function) int y = b; ^ $ gcc-6 error.c error.c:1:9: error: ‘a’ undeclared here (not in a function) int x = a; ^ error.c:2:9: error: ‘b’ undeclared here (not in a function) int y = b; ^ $
Re: Extraneous newline emitted between error messages in GCC 6
On Mon, Dec 21, 2015 at 01:12:33PM -0500, Patrick Palka wrote: > GCC 6, compared to GCC 5, now emits an extra newline between error > messages. Is this intended? > > $ cat error.c > int x = a; > int y = b; > $ gcc-5 error.c > error.c:1:9: error: ‘a’ undeclared here (not in a function) > int x = a; > ^ > error.c:2:9: error: ‘b’ undeclared here (not in a function) > int y = b; > ^ > $ gcc-6 error.c > error.c:1:9: error: ‘a’ undeclared here (not in a function) > int x = a; > ^ > > error.c:2:9: error: ‘b’ undeclared here (not in a function) > int y = b; > ^ > > $ Started with r229884: Reimplement diagnostic_show_locus, introducing rich_location classes. I think it is a bug and should be fixed. Marek
Re: Extraneous newline emitted between error messages in GCC 6
On Mon, 2015-12-21 at 19:20 +0100, Marek Polacek wrote: > On Mon, Dec 21, 2015 at 01:12:33PM -0500, Patrick Palka wrote: > > GCC 6, compared to GCC 5, now emits an extra newline between error > > messages. Is this intended? > > > > $ cat error.c > > int x = a; > > int y = b; > > $ gcc-5 error.c > > error.c:1:9: error: ‘a’ undeclared here (not in a function) > > int x = a; > > ^ > > error.c:2:9: error: ‘b’ undeclared here (not in a function) > > int y = b; > > ^ > > $ gcc-6 error.c > > error.c:1:9: error: ‘a’ undeclared here (not in a function) > > int x = a; > > ^ > > > > error.c:2:9: error: ‘b’ undeclared here (not in a function) > > int y = b; > > ^ > > > > $ > > Started with r229884: Reimplement diagnostic_show_locus, introducing > rich_location classes. I think it is a bug and should be fixed. I agree. Sorry, my bad. I've filed this as PR other/69006, and I'm investigating it. Dave
Re: gcc-4.9.1 generating different code between two successive builds
On 12/20/2015 11:39 PM, Cole wrote: Hi, I am busy trying to generate a package for gcc that is consistent between two successive builds, and I am now down to the final few files. I am stuck with the file: cilk-abi-cilk-for.o, which is obviously built with -O2, but between two successive builds, the assembly code generated is different. Please refer to [1] for output and details. Would anyone have any suggestions that I might be able to try to get the file to generate the same assembly code? It's been some time since I had to deal with this problem and my recollection is somewhat fuzzy and probably inaccurate. IIRC, part of it was caused by qsort being unstable (I think that was on Solaris). We replaced it with a stable version. Another part of it might have been caused by changes in the address space layout caused by ASLR (causing differences in hash values used by the register allocator or something like that). We disabled ASLR to get around that (and other problems). With that, we had fully repeatable builds. This was in the GCC 4.5 time frame. With newer versions, there's also LTO that can affect things. The -frandom-seed= option exists to make it possible to emit identical object files that might otherwise be different. Martin
Re: gcc-4.9.1 generating different code between two successive builds
HI Martin, Thanks very much for the suggestions as well as all the information about the qsort issues. Did you ever publish your changes as a patch, or create a write up about what was necessary to create a reproducible build? I would be interested to see what others have done, and potentially anything else I may have missed. Thanks /Cole On 21 December 2015 at 21:08, Martin Sebor wrote: > On 12/20/2015 11:39 PM, Cole wrote: >> >> Hi, >> >> I am busy trying to generate a package for gcc that is consistent >> between two successive builds, and I am now down to the final few >> files. >> >> I am stuck with the file: cilk-abi-cilk-for.o, which is obviously >> built with -O2, but between two successive builds, the assembly code >> generated is different. Please refer to [1] for output and details. >> >> Would anyone have any suggestions that I might be able to try to get >> the file to generate the same assembly code? > > > It's been some time since I had to deal with this problem and > my recollection is somewhat fuzzy and probably inaccurate. IIRC, > part of it was caused by qsort being unstable (I think that was > on Solaris). We replaced it with a stable version. Another part > of it might have been caused by changes in the address space > layout caused by ASLR (causing differences in hash values used > by the register allocator or something like that). We disabled > ASLR to get around that (and other problems). With that, we had > fully repeatable builds. This was in the GCC 4.5 time frame. > With newer versions, there's also LTO that can affect things. > The -frandom-seed= option exists to make it possible to emit > identical object files that might otherwise be different. > > Martin >
