> it was certainly worth it.
since I see msan as a kind of valgrind replacement (similar functionality, but
~10x the speed, partially at the cost of more difficult deployment), I did a
quick search in gcc bugzilla. 982 PRs mention valgrind, so such functionality
is clearly heavily used.
Hi,
I've noticed that gcc includes a msan_interface.h file, and I'm wondering if
this implies that memory sanitizer is already part of gcc. If not, are there
plans to port this useful looking tool to gcc during the current stage 1 ?
Cheers,
Joost
>> > These numbers are useful to try and ensure the overhead (scaling factor)
>> > is reasonable, thanks.
>>
>> A nice improvement indeed. The patched result is 15 times faster
>> than the serial unpatched run. So there is room for improvement
>
> Note, the box used was oldish AMD 16-core, no ht
> So, I’d love to see the numbers for 5 and 20 to double check that 10 is the
> right number to pick. This sort of refinement is trivial post checkin.
So, some timings with the patch, I think this is great.
Doing the testing you suggest, changing the variable doesn't influence things
much (at
>> Regtested on x86_64-linux, ok for trunk?
>
>Oh, forgot to say, PR56408 isn't fixed by this patch, but given the
>higher granularity (10 tests instead of 1) we don't happen to trigger it
>right now.
which means that any commit to that dir could trigger it, right ?
> a newer patch (v8) I'll send soon
attached with updated changelog. Compared to the previously posted v6, only the
libstdc++-v3/testsuite/Makefile.am has been refined to split a little more the
e*/* pattern, and two quickly running goal have been merged, in addition to
fixing the pre-exisiting
>>> >For PR56408 we need some fix.
>> BTW, is there anything special about Fortran ? There are at least 180 test
>> files that contain 'dg-additional-sources' >some in a very non-local way:
>The current scheme comes at its limits in that case. . See the files listed in
>the PR for issues.
So, w
> And these Fortran inter-test dependencies, which Tobias told me is
> PR56408.
> For PR56408 we need some fix.
BTW, is there anything special about Fortran ? There are at least 180 test
files that contain 'dg-additional-sources' some in a very non-local way:
./objc.dg/foreach-2.m: /* {
> Here is a patch I'm testing now:
Hi Jakub,
I also tested your patch to compare timings vs a newer patch (v8) I'll send soon
== patch v8 == make -j32 -k ==
check-fortran 4m58.178s
check-c++ ~10m
check-c ~10m
check 15m29.873s
== patch Jakub
check-c++ ~20m
check-fortran
>> could it be that the pattern in normal1 should have been '[ab]*/ de*/
>> [ep]*/*' ?
>
>Yes, we are running these tests multiple times:
>
>PASS: 23_containers/map/modifiers/erase/abi_tag.cc (test for excess errors)
>PASS: 23_containers/multimap/modifiers/erase/abi_tag.cc (test for excess
>erro
> could it be that the pattern in normal1 should have been '[ab]*/ de*/
> [ep]*/*' ?
I've checked that this fixes the bug in the current trunk split. I.e. files are
stil tested, but now only once. Consider this change added to the previously
submitted patch.
Jakub,
> First of all, the -j2 testing shows more tests tested in gcc and libstdc++:
>
>-# of expected passes 10133
>+# of expected passes 10152
>
>+PASS: 23_containers/set/modifiers/erase/abi_tag.cc (test for excess errors)
>[...]
>
>Not sure where the bug is, could be e.g. in
> You mean enhancing the script to split across arbitrarily long prefixes?
> That would be great.
I've now a script that does something like that:
~/test$ find /data/vjoost/gnu/gcc_trunk/gcc/gcc/testsuite/gfortran.dg/
-maxdepth 1 -type f -printf "%f\n" | ./generate_patterns.py 500 foo
All 3947
Thanks for testing.
The vect-args.c I explained earlier, and is indeed due to i386.exp hardcoding
those.
The libstdc++ double counts didn't appear in my testing, but I'll have a look.
Note that these patterns are handwritten, so error prone.
The long tests in libstdc++ come from (in timing o
Attached is a further revision of the patch, now dealing with check-c++.
Roughly 50% speedup here at '-j32' (18m vs 12m). For my setup
(--enable-languages=c,c++,fortran) I have now improved all targets called in
'make -j32 -k check'. The latter is now 30% faster (15m vs 20m). Note that
there ar
Now with gzipped figure.. why do these bounce ?
> But if there are jobs that just take 1s to complete, then clearly it doesn't
> make sense to split them off as separate job. I think we don't need 100%
> even split, but at least roughly is highly desirable.
Let me add some data, attached is a gr
> If you get whitespace right, one can provide multiple different wildcards to
> a single *.exp file, e.g.
> make check-gcc RUNTESTFLAGS="dg.exp='p[0-9A-Za-qs-z]* pr[9A-Za-z]*'" should
> cover all tests starting with p other than pr[0-8]*.c (where you could split
> say pr[0-2]* into another job, pr
> No. As I wrote earlier, splitting on filenames and test counts only is only
> very rough split, all the splits really need to be backed out by real timing
> data from popular targets.
I'm actually doing quite some testing trying to get a reasonable balance,
checking 'completed in' in all *.l
> +# ls -1 | ../../../contrib/generate_tcl_patterns.sh 300
> "dg.exp=gfortran.dg/"
>
> How does this work with subdirectories? Can we replace ls with find?
The input to the script is general, you can use this to your advantage. For
example, I've been using:
ls -1 g++.*/* | cut -c5- | ../../.
Attached is an extended version of the patch, it brings a 100% improvement in
make -j32 -k check-gcc (down from 20min to <10min) by modification of
check_gcc_parallelize.
It includes one non-trivial part, namely a split of the target exps. They are
now all split using a common choice (based on
>> > Please sort the letters (LC_ALL=C sort) and where consecutive, use ranges.
>> > Thus \[0-9A-Zhjqvx-z\]*
OK, works fine with the attached patch, and looks cleaner in Make-lang.in.
Now, with the proper email address for gcc-patches... I wonder how many time
I'll be punished for typos.
unmodi
> The splits are in the Makefiles, see check_gcc_parallelize
attached is a patch to improve the parallel performance of 'make -jXX -k
check-fortran'. For XX=16, this yields ~50% speedup, and even with XX=4 we
still have 15%, the measured slowdown at XX=1 (<2%) is in the noise of testing.
The pa
>> expect -- /usr/share/dejagnu/runtest.exp --tool gcc lto.exp weak.exp tls.exp
>> ipa.exp tree-ssa.exp debug.exp >dwarf2.exp fixed-point.exp vxworks.exp
>> cilk-plus.exp vmx.exp pch.exp simulate-thread.exp x86_64-costmodel-vect.exp
>> i386-costmodel-vect.exp spu-costmodel-vect.exp ppc-costmodel
> I have to admit that I don't know why that's the case.
Actually Marc answered that one (I had the wrong mail address for gcc@ so
repeat here):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
> See: gcc/fortran/Make-lang.in, which has:
I'll have a look and do some testing what the gains/co
> What did you expect for -j alone? an error?
No, as is standard in gnu make, a new process for any target that can be
processed (i.e. unlimited).
>> ... check-fortran seems to be limited to about ~5 parallel targets ...
>
>Running the make with -j8 gives 7 directories gfortran[1-6]? in gcc/tes
> It is intentional. With -j it is essentially a fork bomb, just don't use it.
well, silently ignoring it for just this target did cost me a lot of time,
while an eventual fork bomb would have been dealt with much more quickly.
>> Somewhat related is there a rule of thumb on how is the gran
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the check
target, while the other targets seem to do just fine. Is that a feature, or
should I file a PR for that
Hi Li,
I've attached 'Fortran-aware' delta. I tries to guess cut a Fortran file
in more reasonable places (e.g. between subroutine boundaries, after
enddos). It works reasonably well, but is a hack.
Especially with Fortran90 and modules, iterated delta runs can help a lot
(i.e. first runs re
I guess this is some configure flag missing, does anybody have a clue?
Yes, you must build with --enable-gold --enable-plugins :-)
Is that for gcc or for binutils (neither documents this in ./configure
--help) ?
I used it for both, but only get this to work with binutils CVS, is that
c
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
I think it is useful to have a bugzilla here.
will do.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
Btw, complete unrolling is also hindred by the artificial limit of maximally
unrolling 16 iterations. Your inner loops iterate 27 times. Also by the
artificial limit of the maximal u
thanks for the info
I think it is useful to have a bugzilla here.
will do.
I tested 4.4, what did you test?
4.3 4.4 4.5
Joost
the attached code (see contract__sparse) is a kernel which I hope gets
optimized well. Unfortunately, compiling (on opteron or core2) it as
gfortran -O3 -march=native -ffast-math -funroll-loops
-ffree-line-length-200 test.f90
./a.out
Sparse: time[s] 0.66804099
New: time[s] 0.2080
actually, I just find out that this seems a 4.4 issue, compiled with 4.3 the
gdb session just goes fine... I also seem to be able to debug small examples
with either 4.3 or 4.4, just CP2K seems to cause troubles (as usual ;-)
I've filed PR39073 for this, somehow hope this can be solved before
Would be great if such a thing could be detected at configure time (i.e.
like missing mpfr.h headers are already detected), with some kind of a
gentle error message.
It wouldn't be detected until the target libs are built, since that's the
first time any 32-bit headers are needed.
Patches welco
thats is on a standard linux (x86_64) box running opensuse 11.0, and a
clean checkout. Is this a known problem?
You haven't installed the 32-bit glibc devel package.
Many thanks, that fixed it.
Would be great if such a thing could be detected at configure time (i.e.
like missing mpfr.h head
Current trunk fails for me with
/data04/vondele/gcc_trunk/obj/./gcc/xgcc
-B/data04/vondele/gcc_trunk/obj/./gcc/
-B/data04/vondele/gcc_trunk/build/x86_64-unknown-linux-gnu/bin/
-B/data04/vondele/gcc_trunk/build/x86_64-unknown-linux-gnu/lib/ -isystem
/data04/vondele/gcc_trunk/build/x86_64-unkno
It would be nice to have a stand-alone testcase for this, so please
file a bugreport.
I've opened PR37150 for this.
Thanks,
Joost
The attached testcase yields (on a core2 duo, gcc trunk):
gfortran -O3 -ftree-vectorize -ffast-math -march=native test.f90
time ./a.out
real0m3.414s
ifort -xT -O3 test.f90
time ./a.out
real0m1.556s
The assembly contains:
ifort gfortran
mulpd 140 0
mulsd
A nightly tester has been set up to track the performance of the
gcc/gfortran compiler (trunk) for typical CP2K runs. Results and code can
be found at:
http://cp2k.berlios.de/gfortran/
I'll consider your suggestions for improvements.
The following patch could be applied to the wwwdocs
Inde
dwarf2out.c:13496: internal compiler error: in extract_insn, at
recog.c:1988
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37045
I've just tested gcc/gfortran with CP2K, which some of you might know from
PR29975 and other messages to the list, and observed some very pleasing
evolution in the runtime of the code. In each case the set of compilation
options is '-O2 -ffast-math -funroll-loops -ftree-vectorize -march=native
42 matches
Mail list logo
