Re: Error building GCC 6.1.0 libstdc++
On 15 July 2016 at 00:45, Patrick Oppenlander wrote: > Hi, > > I'm running into a build problem when building GCC 6.1.0: > > > /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc/xgcc > -shared-libgcc -B/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./gcc > -nostdinc++ > -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/src > -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/src/.libs > -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/libsupc++/.libs > -B/home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/bin/ > -B/home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/lib/ -isystem > /home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/include -isystem > /home/patrick/src/e7/toolchain/stage2/powerpc-eabispe/sys-include > -L/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/./ld-x > c++-header -nostdinc++ -g -O2 > -I/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/powerpc-eabispe > -I/home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include > -I/home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/libsupc++ > -O2 -g > /home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/include/precompiled/extc++.h > -o powerpc-eabispe/bits/extc++.h.gch/O2g.gch > In file included from > /home/patrick/src/e7/toolchain/src/gcc-combined/libstdc++-v3/include/precompiled/extc++.h:69:0: > /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/ext/throw_allocator.h:545:18: > error: 'uniform_real_distribution' in namespace 'std' does not name a > template type > typedef std::uniform_real_distribution distribution_type; > ^ > /home/patrick/src/e7/toolchain/build/gcc-6.1.0-stage2/powerpc-eabispe/libstdc++-v3/include/ext/throw_allocator.h:546:18: > error: 'mt19937' in namespace 'std' does not name a type > typedef std::mt19937 engine_type; > ^~~ > > > I've done some analysis of this and it turns out to be an issue with the C > library I'm using. > > The configure test "checking for ISO C99 support to TR1 in " is > failing. > > This stops _GLIBCXX_USE_C99_STDINT_TR1 from being defined which subsequently > causes the above build failure because doesn't include > anymore. > > Is this a bug in the build system? If _GLIBCXX_USE_C99_STDINT_TR1 is > required then should the configure abort? > > Alternatively, should libstdc++ still build without > _GLIBCXX_USE_C99_STDINT_TR1? Yes. Please report it to bugzilla, thanks.
GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)
Hi! Including in case others also have opinions on "GCC testsuite maintenance". On Fri, 15 Jul 2016 10:21:13 +0200, Jakub Jelinek wrote: > On Fri, Jul 15, 2016 at 09:44:25AM +0200, Thomas Schwinge wrote: > > Does that me we (erroneously) accept any random junk after [...] > > No. The thing is, [...] Thanks for the explanation! > > On Thu, 14 Jul 2016 19:05:52 -0700, Cesar Philippidis > > wrote: > > > --- /dev/null > > > +++ b/gcc/testsuite/gfortran.dg/goacc/vector_length.f90 > > > @@ -0,0 +1,11 @@ > > > +program t > > > + implicit none > > > + integer, parameter :: n = 100 > > > + integer a(n), i > > > + > > > + !$acc parallel loop num_gangs(100) num_workers(1) vector_length(32) > > > + do i = 1, n > > > + a(i) = i > > > + enddo > > > + !$acc end parallel loop > > > +end program t > > > > My preference is that such tests are added to existing test files, for > > example where "!$acc parallel loop" is tested, instead of adding such > > mini files. One of the problem I have with this specific and similar other test cases is, that when coming back to such a test case in a few weeks' time, it is not obvious at all what this is testing, whereas if this were inside a file that generally/already tests all kinds of "!$acc parallel loop" variants, this would be obvious. > No, we want to have as little churn as possible in existing tests, the > general policy is to add new tests (not just for OpenACC/OpenMP, but for > all functionality). Hmm, that's something I had not been aware of, and I can't find this covered in the documentation. So, you're basically saying that files in the testsuite are write-once, and should not be maintained aside from fixing errors, adjusting due to optimization changes, or due to changed diagnostics, and the like? (Of course, I do agree that we shouldn't "randomly" remove/modify test cases that test stuff that is still relevant, but that doesn't apply here, obviously.) In my opinion, the testsuite should be maintained, just like "regular" code, and so related test cases should be consolidated, obsolete ones be removed, and so on, every once in a while, or on demand. So that the GCC testsuite doesn't just always grow (in number of files), but also "stays relevant". Also, the wall-time overhead is much lower if, taking this specific example, that one OpenACC directive test case is tested next to others in an existing testsuite file, as opposed to requiring a separate compiler invocation, being in a separate file. Grüße Thomas
Re: [gimplefe] hacking pass manager
On Sun, Jul 10, 2016 at 6:13 PM, Prasad Ghangal
wrote:
> On 8 July 2016 at 13:13, Richard Biener wrote:
>> On Thu, Jul 7, 2016 at 9:45 PM, Prasad Ghangal
>> wrote:
>>> On 6 July 2016 at 14:24, Richard Biener wrote:
On Wed, Jul 6, 2016 at 9:51 AM, Prasad Ghangal
wrote:
> On 30 June 2016 at 17:10, Richard Biener
> wrote:
>> On Wed, Jun 29, 2016 at 9:13 PM, Prasad Ghangal
>> wrote:
>>> On 29 June 2016 at 22:15, Richard Biener
>>> wrote:
On June 29, 2016 6:20:29 PM GMT+02:00, Prathamesh Kulkarni
wrote:
>On 18 June 2016 at 12:02, Prasad Ghangal
>wrote:
>> Hi,
>>
>> I tried hacking pass manager to execute only given passes. For this I
>> am adding new member as opt_pass *custom_pass_list to the function
>> structure to store passes need to execute and providing the
>> custom_pass_list to execute_pass_list() function instead of all
>passes
>>
>> for test case like-
>>
>> int a;
>> void __GIMPLE (execute ("tree-ccp1", "tree-fre1")) foo()
>> {
>> bb_1:
>> a = 1 + a;
>> }
>>
>> it will execute only given passes i.e. ccp1 and fre1 pass on the
>function
>>
>> and for test case like -
>>
>> int a;
>> void __GIMPLE (startwith ("tree-ccp1")) foo()
>> {
>> bb_1:
>> a = 1 + a;
>> }
>>
>> it will act as a entry point to the pipeline and will execute passes
>> starting from given pass.
>Bike-shedding:
>Would it make sense to have syntax for defining pass ranges to execute
>?
>for instance:
>void __GIMPLE(execute (pass_start : pass_end))
>which would execute all the passes within range [pass_start, pass_end],
>which would be convenient if the range is large.
But it would rely on a particular pass pipeline, f.e. pass-start
appearing before pass-end.
Currently control doesn't work 100% as it only replaces
all_optimizations but not lowering passes or early opts, nor IPA opts.
>>>
>>> Each pass needs GIMPLE in some specific form. So I am letting lowering
>>> and early opt passes to execute. I think we have to execute some
>>> passes (like cfg) anyway to represent GIMPLE into proper form
>>
>> Yes, that's true. Note that early opt passes only optimize but we need
>> pass_build_ssa_passes at least (for into-SSA). For proper unit-testing
>> of GIMPLE passes we do need to guard off early opts somehow
>> (I guess a simple if (flag_gimple && cfun->custom_pass_list) would do
>> that).
>>
>> Then there is of course the question about IPA passes which I think is
>> somewhat harder (one could always disable all IPA passes manually
>> via flags of course or finally have a global -fipa/no-ipa like most
>> other compilers).
>>
> Can we iterate through all ipa passes and do -fdisable-ipa-pass or
> -fenable-ipa-pass equivalent for each?
We could do that, yes. But let's postpone this issue. I think that
startwith is going to be most useful and rather than constructing
a pass list for it "native" support for it in the pass manager is
likely to produce better results (add a 'startwith' member alongside
the pass list member and if it is set the pass manager skips all
passes that do not match 'startwith' and once it reaches it it clears
the field).
In the future I hope we can get away from a static pass list and more
towards rule-driven pass execution (we have all those PROP_* stuff
already but it isn't really used for example). But well, that would be
a separate GSoC project ;)
IMHO startwith will provide everything needed for unit-testing. We can
add a flag on whether further passes should be executed or not and
even a pass list like execute ("ccp1", "fre") can be implemented by
startwith ccp1 and then from there executing the rest of the passes in the
list and stopping at the end.
As said, unit-testing should exercise a single pass if we can control
its input.
>>> In this patch I am skipping execution of passes until pass_startwith
>>> is found. Unlike previous build, now pass manager executes all passes
>>> in pipeline starting from pass_startwith instead of just sub passes.
>>
>> That looks good. I wonder if
>>
>> + if (startwith_p && cfun->startwith)
>> +{
>> + if (pass->name == cfun->pass_startwith->name
>> + || pass->name == "*clean_state")
>>
>> need better be strcmp ()s though. Also the early optimization pipeline
>> should be executed with startwith support as well.
>>
>
> This patch adds startwith support for early opt passes. But for
> starting from some passes (like asan0, optimi
Should the build system use ar rcs instead of ranlib + ar rc?
The build step that invokes "ranlib libbackend.a" (which immediately follows the invocation of "ar rc libbackend.a ...") takes over 7 seconds on my machine and causes the entire 450MB archive to be rewritten. By instead making the build system use ar rcs -- so that the archive and its index are built at once -- the time it takes for the compiler to get rebuilt gets reduced by 25%, from 27s to 20s (in a --disable-bootstrap tree after touching a random source file). This is a pretty significant reduction in compile time and disk io. Is this a good idea? Here's the patchlet I used: -- >8 -- diff --git a/Makefile.in b/Makefile.in index 117fbf5..5ebc3a3 100644 --- a/Makefile.in +++ b/Makefile.in @@ -393,7 +393,7 @@ MAKEINFOFLAGS = --split-size=500 AS = @AS@ AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs CC = @CC@ CXX = @CXX@ DLLTOOL = @DLLTOOL@ diff --git a/Makefile.tpl b/Makefile.tpl index 94a4f79..72ba24b 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -396,7 +396,7 @@ MAKEINFOFLAGS = --split-size=500 AS = @AS@ AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs CC = @CC@ CXX = @CXX@ DLLTOOL = @DLLTOOL@ diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 0786fa3..1c3a637 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -236,7 +236,7 @@ BISONFLAGS = FLEX = @FLEX@ FLEXFLAGS = AR = @AR@ -AR_FLAGS = rc +AR_FLAGS = rcs NM = @NM@ RANLIB = @RANLIB@ RANLIB_FLAGS = @ranlib_flags@ @@ -1883,17 +1883,14 @@ compilations: $(BACKEND) libbackend.a: $(OBJS) -rm -rf libbackend.a $(AR) $(AR_FLAGS) libbackend.a $(OBJS) - -$(RANLIB) $(RANLIB_FLAGS) libbackend.a libcommon-target.a: $(OBJS-libcommon-target) -rm -rf libcommon-target.a $(AR) $(AR_FLAGS) libcommon-target.a $(OBJS-libcommon-target) - -$(RANLIB) $(RANLIB_FLAGS) libcommon-target.a libcommon.a: $(OBJS-libcommon) -rm -rf libcommon.a $(AR) $(AR_FLAGS) libcommon.a $(OBJS-libcommon) - -$(RANLIB) $(RANLIB_FLAGS) libcommon.a # We call this executable `xgcc' rather than `gcc' # to avoid confusion if the current directory is in the path
Re: Should the build system use ar rcs instead of ranlib + ar rc?
On Fri, Jul 15, 2016 at 6:46 PM, Patrick Palka wrote: > The build step that invokes "ranlib libbackend.a" (which immediately > follows the invocation of "ar rc libbackend.a ...") takes over 7 seconds > on my machine and causes the entire 450MB archive to be rewritten. By > instead making the build system use ar rcs -- so that the archive and > its index are built at once -- the time it takes for the compiler to get > rebuilt gets reduced by 25%, from 27s to 20s (in a --disable-bootstrap > tree after touching a random source file). This is a pretty significant > reduction in compile time and disk io. > > Is this a good idea? Yes and no. Do we know if all ar support rcs now? Or is it just binutils's ar? Thanks, Andrew > > Here's the patchlet I used: > > -- >8 -- > > diff --git a/Makefile.in b/Makefile.in > index 117fbf5..5ebc3a3 100644 > --- a/Makefile.in > +++ b/Makefile.in > @@ -393,7 +393,7 @@ MAKEINFOFLAGS = --split-size=500 > > AS = @AS@ > AR = @AR@ > -AR_FLAGS = rc > +AR_FLAGS = rcs > CC = @CC@ > CXX = @CXX@ > DLLTOOL = @DLLTOOL@ > diff --git a/Makefile.tpl b/Makefile.tpl > index 94a4f79..72ba24b 100644 > --- a/Makefile.tpl > +++ b/Makefile.tpl > @@ -396,7 +396,7 @@ MAKEINFOFLAGS = --split-size=500 > > AS = @AS@ > AR = @AR@ > -AR_FLAGS = rc > +AR_FLAGS = rcs > CC = @CC@ > CXX = @CXX@ > DLLTOOL = @DLLTOOL@ > diff --git a/gcc/Makefile.in b/gcc/Makefile.in > index 0786fa3..1c3a637 100644 > --- a/gcc/Makefile.in > +++ b/gcc/Makefile.in > @@ -236,7 +236,7 @@ BISONFLAGS = > FLEX = @FLEX@ > FLEXFLAGS = > AR = @AR@ > -AR_FLAGS = rc > +AR_FLAGS = rcs > NM = @NM@ > RANLIB = @RANLIB@ > RANLIB_FLAGS = @ranlib_flags@ > @@ -1883,17 +1883,14 @@ compilations: $(BACKEND) > libbackend.a: $(OBJS) > -rm -rf libbackend.a > $(AR) $(AR_FLAGS) libbackend.a $(OBJS) > - -$(RANLIB) $(RANLIB_FLAGS) libbackend.a > > libcommon-target.a: $(OBJS-libcommon-target) > -rm -rf libcommon-target.a > $(AR) $(AR_FLAGS) libcommon-target.a $(OBJS-libcommon-target) > - -$(RANLIB) $(RANLIB_FLAGS) libcommon-target.a > > libcommon.a: $(OBJS-libcommon) > -rm -rf libcommon.a > $(AR) $(AR_FLAGS) libcommon.a $(OBJS-libcommon) > - -$(RANLIB) $(RANLIB_FLAGS) libcommon.a > > # We call this executable `xgcc' rather than `gcc' > # to avoid confusion if the current directory is in the path
