graphite optimizations
Sebastian, With the current r150790 gcc trunk, I am not seeing any particular improvements in the polyhedron benchmarks with the available graphite loop optimizations... Date & Time : 15 Aug 2009 13:41:47 Test Name : gfortran_lin_p4 Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 2000.0 Target Error % : 0.100 Minimum Repeats :10 Maximum Repeats : 100 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 1.60 1 9.73 10 0.0136 aermod 57.99 1 21.16 10 0.0062 air 4.16 1 5.71 10 0.0263 capacita 2.67 1 33.22 10 0.0168 channel 0.99 1 1.83 10 0.0206 doduc 8.18 1 27.29 10 0.0126 fatigue 3.08 1 8.11 10 0.0847 gas_dyn 4.97 1 4.50 14 0.0927 induct 6.74 1 12.42 10 0.0155 linpk 0.99 1 15.41 10 0.0409 mdbx 2.39 1 11.44 10 0.0222 nf 2.65 1 28.07 16 0.0953 protein 7.85 1 36.55 10 0.0144 rnflow 8.30 1 23.89 10 0.0072 test_fpu 6.80 1 9.93 10 0.0161 tfft 0.73 1 1.87 10 0.0534 Geometric Mean Execution Time = 11.31 seconds Date & Time : 15 Aug 2009 14:30:46 Test Name : gfortran_lin_p4_graphite_interchange Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 -fgraphite-identity -floop-interchange %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 2000.0 Target Error % : 0.100 Minimum Repeats :10 Maximum Repeats : 100 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 6.04 1 9.39 10 0.0308 aermod 88.35 1 20.92 10 0.0048 air 7.76 1 0.18 17 0.0939 capacita 3.21 1 33.29 10 0.0098 channel 2.25 1 1.83 12 0.0200 doduc 8.92 1 27.38 10 0.0131 fatigue 5.42 1 8.33 10 0.0464 gas_dyn 5.67 1 4.57 17 0.0977 induct 26.51 1 7.42 10 0.0056 linpk 15.67 1 15.53 10 0.0228 mdbx 2.80 1 11.41 10 0.0088 nf 4.27 1 27.97 15 0.0932 protein 8.25 1 36.18 10 0.0316 rnflow 11.00 1 24.19 10 0.0127 test_fpu 9.62 1 10.69 10 0.0287 tfft 2.32 1 1.91 10 0.0651 Geometric Mean Execution Time = 8.86 seconds Date & Time : 15 Aug 2009 11:43:28 Test Name : gfortran_lin_p4_graphite_stripmine Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 -fgraphite-identity -floop-strip-mine %n.f90 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 2000.0 Target Error % : 0.100 Minimum Repeats :10 Maximum Repeats : 100 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 5.92 1 9.37 10 0.0178 aermod 88.31 1 21.01 10 0.0172 air 7.57 1 0.18 34 0.0914 capacita 3.22 1 33.30 10 0.0111 channel 2.49 1 2.02 11 0.0955 doduc 8.94 1 27.39 10 0.0204 fatigue 5.43 1 8.33 10 0.0571 gas_dyn 5.66 1 4.57 16 0.0885 induct 25.21 1 20.18 10 0.0040
How to make ARM->MaverickCrunch register transfers schedulable?
Hi!
I'd appreciate some input on how to get the pipeline scheduler to
know about the bizarre MaverickCrunch timing characteristics.
Brief: Crunch is an asynchronous ARM coprocessor which has internal
operations from/to its own register set, transfers between its own
registers and the ARM integer registers, and transfers directly
to/from memory.
Softfp is the current favourite ABI, where double arguments are
passed in ARM register pairs, same as softfloat, and a typical double
float function transfers its arguments from ARM registers to the FPU,
does some munging between the FPU registers, then transfers the result
back to ARM regs for the return(). It has to do this 32 bits at a
time:
double adddf(double a, double b) {return (a+b);}
adddf:
cfmv64lrmvdx0, r0
cfmv64hrmvdx0, r1
cfmv64lrmvdx1, r2
cfmv64hrmvdx1, r3
cfaddd mvdx1, mvdx1, mvdx0
cfmvr64lr0, mvdx1
cfmvr64hr1, mvdx1
bx lr
Although you can do one transfer per cycle between the two units, two
consecutive transfers to the same Crunch register incur a delay of
four cycles, so each transfers to crunch registers takes 4 cycles. A
better sequence would be:
cfmv64lrmvdx0, r0
cfmv64lrmvdx1, r2
cfmv64hrmvdx0, r1
cfmv64hrmvdx1, r3
My questions are two:
- can I model the fact that two consecutive writes to the same
register have a latency of four cycles (whereas writes to different
registers can be one per cycle)?
- am I right in thinking to define two new register modes, MAVHI and
MAVLO for the two kinds of writes to the maverick registers, then turn
the movdf (and movdi) definitions for moves to/from ARM registers into
define_split's using the two new modes?
Thanks, sorry it's a bit osbcure!
M
"An expert is someone who knows more and more about less and less:
Re: Trace crash in gargabe collector to the code at fault?
Oliver Kellogg wrote: > On Fri, 2009-08-14 at 10:41 +0100, Andrew Haley wrote: >>> I am stuck here, i.e. I don't know how to find the code >>> that is >>> at fault. >>> Is there some way to trace a pointer entered in >>> G.free_object_list >>> back to its origin in the code? >> The usual way to find this is to use a gdb watchpoint. Find what object is >> being freed, put a breakpoing on ggc_alloc_stat at the point the object is >> created, and then put a watchpoint on the word that is being corrupted. >> >> Andrew. > > Thanks. > I tried as follows: That's not gonna work. Put a breakpoint at the end of ggc_alloc_stat. It'll have to be a conditional breakpoint on the address of the node that's being corrupted. When the object is created, add the watchpoint. Andrew.
Re: Trace crash in gargabe collector to the code at fault?
On Fri, 2009-08-14 at 10:41 +0100, Andrew Haley wrote:
> >
> > I am stuck here, i.e. I don't know how to find the code
> > that is
> > at fault.
> > Is there some way to trace a pointer entered in
> > G.free_object_list
> > back to its origin in the code?
>
> The usual way to find this is to use a gdb watchpoint. Find what object is
> being freed, put a breakpoing on ggc_alloc_stat at the point the object is
> created, and then put a watchpoint on the word that is being corrupted.
>
> Andrew.
Thanks.
I tried as follows:
$ gdb /usr/src/packages/BUILD/gcc-build/gcc/gnat1
GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
[...]
(gdb) catch exception
Catchpoint 1: all Ada exceptions
(gdb) run -g -I../../isf_pmc_interface/libsrc/ada
-I../../isf_pmc_interface/spv/ada
Apc.Init Apc.Init.B_1 Apc.Init.B_1.Pos_Io.Get Apc.Init.B_1.Pos_Io.Get
Apc.Init.B_1.Pos_Io.Get Apc.Init.B_1.Pos_Io.Put Apc.Init.B_1.Pos_Io.Put
Apc.Init.B_1.Pos_Io.Put {GC 17511k -> 17346k} {GC 17348k -> 17340k} {GC
17341k -> 17341k} {GC 17343k -> 17342k} {GC 17344k -> 17343k}
Analyzing compilation unit
{GC 17423k -> 17382k} {GC 17382k -> 17382k} {GC 17395k -> 17393k} {GC
17393k -> 17393k} {GC 17394k -> 17394k} {GC 17394k -> 17394k} {GC 17395k
-> 17395k} {GC 17395k -> 17395k} {GC 17402k -> 17399k} {GC 17399k ->
17399k} {GC 17405k -> 17403k} {GC 17403k -> 17403k} {GC 17409k ->
17407k} {GC 17407k -> 17407k} {GC 17409k -> 17408k} {GC 17408k ->
17408k} {GC 17408k -> 17403k} {GC 17403k -> 17403k}Performing
interprocedural optimizations
{GC 17403k -> 17403k}
{GC 34561k -> +===GNAT BUG
DETECTED==+
| 4.5.0 20090815 (experimental) (i686-pc-linux-gnu) GCC error:
|
| in validate_free_objects, at ggc-page.c:1888
|
| Error detected
around ../../isf_pmc_interface/spv/ada/basic_types.ads:140:26|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.
|
| Use a subject line meaningful to you and us to track the bug.
|
| Include the entire contents of this bug box in the report.
|
| Include the exact gcc or gnatmake command that you entered.
|
| Also include sources listed below in gnatchop format
|
| (concatenated together with no headers between files).
|
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).
[...]
Catchpoint 1, TYPES.UNRECOVERABLE_ERROR at
<__gnat_debug_raise_exception> (e=0x8ddfd3c)
at ../../../SOURCES/gcc/gcc/ada/s-except.adb:44
44 end Debug_Raise_Exception;
Current language: auto; currently ada
(gdb) bt
#0 <__gnat_debug_raise_exception> (e=0x8ddfd3c)
at ../../../SOURCES/gcc/gcc/ada/s-except.adb:44
#1 0x081ca713 in <__gnat_raise_nodefer_with_msg> (e=0x8ddfd3c)
at ../../../SOURCES/gcc/gcc/ada/a-except.adb:800
#2 0x081cb0a9 in <__gnat_raise_exception> (e=0x8ddfd3c, message=0x0)
at ../../../SOURCES/gcc/gcc/ada/a-except.adb:839
#3 0x081fd422 in comperr.compiler_abort (x=0x9813b90, code=-1,
fallback_loc=0x9813bc8) at ../../../SOURCES/gcc/gcc/ada/comperr.adb:415
#4 0x0818401c in internal_error_function (msgid=0x8ccfa23 "in %s, at %
s:%d["00"]", ap=0xbfffc71c)
at ../../../SOURCES/gcc/gcc/ada/gcc-interface/misc.c:372
#5 0x0857a754 in diagnostic_report_diagnostic (context=0x92d0bc0,
diagnostic=0xbfffc720) at ../../../SOURCES/gcc/gcc/diagnostic.c:406
#6 0x0857adfe in internal_error (gmsgid=0x8ccfa23 "in %s, at %s:%
d["00"]") at ../../../SOURCES/gcc/gcc/diagnostic.c:676
#7 0x0857aed3 in fancy_abort (file=0x8cc422c
"../../../SOURCES/gcc/gcc/ggc-page.c["00"]", line=1888,
function=0x8cc42bc "validate_free_objects["00"]")
at ../../../SOURCES/gcc/gcc/diagnostic.c:730
#8 0x0851163c in validate_free_objects ()
at ../../../SOURCES/gcc/gcc/ggc-page.c:1888
#9 0x085117ab in ggc_collect ()
at ../../../SOURCES/gcc/gcc/ggc-page.c:1949
#10 0x089357e2 in cgraph_finalize_function (decl=0xb56de600, nested=0
'["00"]') at ../../../SOURCES/gcc/gcc/cgraphunit.c:550
#11 0x0818886b in end_subprog_body (body=0xb570c5cc)
at ../../../SOURCES/gcc/gcc/ada/gcc-interface/utils.c:2116
#12 0x081ba1ae in Subprogram_Body_to_gnu (gnat_node=571248)
at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:2339
#13 0x081c0d42 in gnat_to_gnu (gnat_node=571248)
at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:4792
#14 0x081c4bc2 in process_decls (gnat_decls=-99950950, gnat_decls2=0,
gnat_end_list=0, pass1p=0 '["00"]', pass2p=1 '["01"]')
at ../../../SOURCES/gcc/gcc/ada/gcc-interface/trans.c:6306
#15 0x081c4cba in process_decls (gnat_decls=-99984793, g
Re: Notes toward re-implementing EH in gimple
> > Yes. Although I'm streamlining things even more now. I've eliminated > the "global" variables that store the excptr/filter, and instead each > individual use location is asking for what it needs locally. > > Further, the actual landing pad itself is *not* generated in gimple. > I had too many problems updating SSA form (in particular PHIs) when > I tried to prevent non-EH edges from using the EH landing pad label. > So now it's really a post-landing-pad label, and the actual landing > pad is still generated in rtl. This sounds fine. > > I wanted > >to more note that it seems to make snese to aim towards EH edges > >arbitrarily redirectable without need to modify basic blocks while doing > >so. > > This is exactly what I've got now. And this too, of course :) > > >What I still fail to see how this scheme is going to avoid need for > >multiple edges from a call. I was under impression that code in > >collect_one_action_chain produces dwarf representation as list labels > >and conditionals executed by runtime. So the runtime actually can > >deliever EH from the call to several EH regions and we ought to have > >edges for all of them. > > collect_one_action_chain only produces one landing_pad label for > any one call site. It does not produce multiple edges. And this is major point of my confussion. I allways assumed that there are multiple labels, not that we always land to the innermost landing pad on the way. > > >In fact I was considering going further here and drop the current > >lexical EH tree representation and instead do the lowering to action > >chains very early and do all the transformations later on the lowered > >chains. It seems a lot easier representation to think of than what we > >have now? > > I'm really not sure what you mean by this. Make the EH region number > associated with each statement be the action chain index? A possibly > interesting idea, but I'm not sure what it gains you. Certainly not > ease of optimization when it comes to cleaning up shadowed catch > handlers. Yes, this is what I was thinking about. In the lowered representation one would actually need to do VRP style dataflow to prove that given EH region is shadowed, while in higher representation we can stick with the current algorithm that is used for CFG buid just without actually building CFG just marking reachability... Honza
Re: Notes toward re-implementing EH in gimple
> On 08/10/2009 08:20 AM, Michael Matz wrote: > >It's not that they _create_ side-effects, but they depend on some. > > Ah, fair enough. I hadn't actually thought that all through. > > >Btw, it's really wonderful that someone tackles EH-on-gimple ;-) > > I hadn't been planning on it, but my trans-mem branch is stalled > on the dominator-breaking representation we have in gimple atm. > > I tried fixing that, but ran quite afoul of Honza's critical edge > splitting pass. There's absolutely no way to split a resx edge > in the current representation, and we're saved only by the fact > that resx statements don't have edges at the moment. Though you You should be able to split it by copying the regions and I was definitly dealing with RESX edges when working on the redirection patch. (we no longer require RESX region number to match region number of exception we are just serving). make_edges do call make_eh_edges for resx: case GIMPLE_RESX: make_eh_edges (last); and make_eh_edges will create them for you. and I do get them in i.e. tramp3d dumps: save_filt.98_8 = [filter_expr] <<>>; save_eptr.97_9 = [exc_ptr_expr] <<>>; std::allocator::~allocator (&D.99154); <<>> = save_eptr.97_9; <<>> = save_filt.98_8; resx 4 # SUCC: 7 [100.0%] (eh) So perhaps you get the edges purged? But that is using can_throw_internal that also handles the edges. > wouldn't know it by looking at the code. Lots of places seem to > think resx should have edges. But deep down in the middle you'd > find that resx doesn't satisfy stmt_could_throw_p, which stops > the eh edge creation right in its tracks. > > So it seems there's nothing to do but rewrite it all. ;-) If it helps in short term, I can try to fix this if you send me your patch fixing the missing edges problem. Honza > > > r~
Re: bootstrap error with --enable-maintainer-mode
On Sat, 2009-08-15 at 17:56 +0200, Ralf Wildenhues wrote: > Which aclocal version do you have in PATH? Looks like 1.10 or newer, > rather than 1.9.6. Yes, that was probably it. Seems like Debian changed that behind my back during a recent update... Thanks! Thomas
Re: bootstrap error with --enable-maintainer-mode
Hello Thomas, * Thomas Koenig wrote on Sat, Aug 15, 2009 at 04:00:13PM CEST: > Does this ring any bells? This is with a recent trunk. > > $ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran > --enable-maintainer-mode && make && make install > > make[3]: Leaving directory `/var/work/gcc-bin/trunk/libdecnumber' > make[3]: Entering directory `/var/work/gcc-bin/trunk/gcc' > (cd ../../../gcc/trunk/gcc && aclocal -I ../config -I ..) > (cd ../../../gcc/trunk/gcc && autoconf) > configure:3123: error: possibly undefined macro: AC_REQUIRE_AUX_FILE > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > make[3]: *** [../../../gcc/trunk/gcc/configure] Error 1 > $ autoconf --version > autoconf (GNU Autoconf) 2.59 Which aclocal version do you have in PATH? Looks like 1.10 or newer, rather than 1.9.6. Cheers, Ralf
enable-build-with-cxx bootstrap compare broken by r149964
Hi, folks, Building with --enable-build-with-cxx fails to bootstrap as follows: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/vec.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_globals.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/guard.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/mt_allocator.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/pool_allocator.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/basic_file.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/system_error.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale_init.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/debug.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/mt_allocator.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/pool_allocator.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/basic_file.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/system_error.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale_init.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/debug.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/atomic.o differs x86_64-unknown-linux-gnu/32/libstdc++-v3/src/atomic.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_alloc.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/vec.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/mt_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/locale.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/pool_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/basic_file.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/system_error.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/locale_init.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/debug.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/mt_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/pool_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/basic_file.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/system_error.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale_init.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/debug.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/future.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/atomic.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/future.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/atomic.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/jlquinn/gcc/dev/build/trunk-cxx' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/jlquinn/gcc/dev/build/trunk-cxx' make: *** [all] Error 2 jlqu...@cerberus:~/gcc/dev/build/trunk-cxx$ After bisecting the svn repository, I tracked the problem down to r149964: XXX Try C++ bootstrap here FAIL r149964 | jason | 2009-07-22 19:03:22 -0400 (Wed, 22 Jul 2009) | 8 lines * mangle.c (mangle_type_string_for_rtti): Rename to be clearer. (needs_fake_anon): New. (write_name): Check it. (write_nested_name): Add a fake anonymous namespace scope if true. * name-lookup.c (get_anonymous_namespace_name): No longer static. * rtti.c, cp-tree.h: Adjust. * libsupc++/typeinfo (__GXX_MERGED_TYPEINFO_NAMES): Default to 0. XXX Try C++ bootstrap here SUCCESS r149962 | vmakarov | 2009-07-22 18:00:17 -0400 (Wed, 22 Jul 2009) | 22 lines 2009-07-22 Vladimir Makarov PR target/37488 * ira-lives.c (bb_has_abnormal_call_pred): New function. (process_bb_node_lives): Use it. Can someone take a look at this please? I came across this while trying to solve why enable-build-with-cxx didn't build on Fedora 11. (I have a patch, but I was waiting to track this down first). Having checked in some of the configure patches for it, I thought I should isolate the actual broken checkin to make sure it wasn't me :-) Thanks, Jerry
bootstrap error with --enable-maintainer-mode
Does this ring any bells? This is with a recent trunk. $ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran --enable-maintainer-mode && make && make install make[3]: Leaving directory `/var/work/gcc-bin/trunk/libdecnumber' make[3]: Entering directory `/var/work/gcc-bin/trunk/gcc' (cd ../../../gcc/trunk/gcc && aclocal -I ../config -I ..) (cd ../../../gcc/trunk/gcc && autoconf) configure:3123: error: possibly undefined macro: AC_REQUIRE_AUX_FILE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make[3]: *** [../../../gcc/trunk/gcc/configure] Error 1 make[3]: Leaving directory `/var/work/gcc-bin/trunk/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/var/work/gcc-bin/trunk' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/var/work/gcc-bin/trunk' make: *** [all] Error 2 $ autoconf autoconf: no input file $ autoconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
lto and gold
I'd like to test lto on a project where objects first go through an archive, and so wanted to follow http://gcc.gnu.org/wiki/LinkTimeOptimization using 'gcc -use-linker-plugin' However, I can't get this to work. gfortran -use-linker-plugin -flto main.f90 test.f90 /data03/vondele/binutils-2.19.1/build/bin/ld: -plugin: unknown option /data03/vondele/binutils-2.19.1/build/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status /data03/vondele/binutils-2.19.1/build/bin/ld -v GNU gold (GNU Binutils 2.19.1) 1.7 I guess this is some configure flag missing, does anybody have a clue? gcc configured as: /data03/vondele/gcc_lto/gcc/configure --prefix=/data03/vondele/gcc_lto/build --with-libelf=/data03/vondele/libelf-0.8.10/build/ --enable-gold --enable-languages=c,c++,fortran --disable-multilib -disable-bootstrap binutils as: ./configure --prefix=/data03/vondele/binutils-2.19.1/build --enable-gold This is what collect2 sees: /data03/vondele/gcc_lto/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/collect2 -plugin /data03/vondele/gcc_lto/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/liblto_plugin.so -plugin-opt=/data03/vondele/gcc_lto/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper -plugin-opt=gfortran -plugin-opt=-flto -flto --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -use-linker-plugin /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtbegin.o -L/data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0 -L/data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../.. /tmp/ccUQ7wr3.o /tmp/cczQrSMz.o -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /data03/vondele/gcc_lto/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtend.o /usr/lib/../lib64/crtn.o Thanks, Joost
Re: Need some Unix and /bin/sh expertise for GCC testsuite
On Sat, 2009-08-15 at 07:53 +0200, Ralf Wildenhues wrote: > > > * Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST: > > > > => gcc/testsuite/ada/acats/run_all.sh > > > > > > > 3/ Here is the point I find surprising: the "ps fauxww" run in the > > > > second "if" show that even if the script is fully sequential > > > > at least one gnatmake subprocess (collect-ld) is still marked as > > > > running > > > > *in parallel* with the ps command in the subsequent "if" of the script! > > Sounds like http://thread.gmane.org/gmane.comp.shells.bash.bugs/11990 > and the NEWS for bash-3.2 contains this entry: > > l. Several fixes to the code that manages the list of terminated jobs and > their exit statuses, and the list of active and recently-terminated jobs > to avoid pid aliasing/wraparound and allocation errors. > > I'd try out a newer bash version. Good catch! The script shown in the discussion is just like mine and the order of magnitude of occurrence is the same. Since upgrading bash will not be an option for everyone, I will propose a patch that "sleep" a bit if gnatmake succeeds and the executable is still not present or empty, I'm testing: # workaround bash process management bug trycount=0 while [ $trycount -le 30 ]; do trycount=$(expr $trycount + 1) if [ -s $dir/tests/$chapter/$i/$binmain -a -x $dir/tests/$chapter/$i/$binmain ]; then break else sleep 1 fi done Thanks again for your help, Laurent
Re: Need some Unix and /bin/sh expertise for GCC testsuite
On Sat, 2009-08-15 at 01:37 +0100, Dave Korn wrote: > Hmpf. That seems to rule out that theory. Gnatlink is still spawning the > gcc driver to link, rather than the linker itself; maybe the driver's doing > something wrong? Is collect-ld a shell script or an executable on your host? It's a script that appears in the build/gcc directory: $ file /home/guerby/build/gcc/collect-ld /home/guerby/build/gcc/collect-ld: Bourne shell script text executable Thanks for your help, Laurent
