In some cases (e.g. coverage testing) it is useful to emit code for static
functions even if they are never used, which currently is not possible at -O1
and above. The following patch introduces a flag for this, which basically
triggers the same code that keeps those functions alive at -O0. Than
> I think it is fine to bump the default version of isl to be downloaded by
> default.
> Are there other reviewers who would oppose committing this patch?
So, OK for trunk ?
> can isl-0.15 be built with 4.8 and 4.9? ..with an old libc?
isl-0.15 builds for me with gcc 4.6.4, 4.7.4, 4.8.3, 4.9.2, not sure about
older libc.
I can't find any reference to max_align_t in the isl-0.15 source.
(for me actually also isl-0.14 builds fine down to gcc 4.6).
Maybe somebody with
Attached testcases for two previously fixed PRs (and thanks to Dominique who
was quicker for PR67982).
2015-11-03 Joost VandeVondele
PR middle-end/53852
PR middle-end/67518
* gfortran.dg/PR67518.f90: New test.
* gfortran.dg/PR53852.f90: New test.
OK for trunk afte
> Attached testcases for two previously fixed PRs (and thanks to Dominique who
> was quicker for PR67982).
ping ?
Thanks Paul. I believe PR53852 won't be fixed on 4.9/5 as it seems to depend on
the recent graphite cleanup work and recent isl. As such I'll commit to trunk
only.
I see, graphite is optional. Trying to find the dejagnu-ery, I think the
obvious thing is to move the tests from gfortran.dg/ to gfortran.dg/graphite/
I'll do that under the obvious rule, unless this get's preapproved before that
...
r229967
2015-11-08 Joost VandeVondele
* gfortran.dg/PR67518.f90: move from here...
* gfortran.dg/graphite/PR67518.f90: to here.
* gfortran.dg/PR53852.f90: move from here...
* gfortran.dg/graphite/PR53852.f90: to here.
I'm all in favour of requiring isl and enabling graphite by default, but would
suggest to enable it with -Ofast instead.
One reason is that certainly extracting testcases from a PGO build is more
difficult, and initially there will certainly be miscompiles with graphite
(CP2K is right now).
Today, I ran 'gfortran -static-libfortran test.f90' and was very pleased with
the answer:
gfortran: error: unrecognized command line option ‘-static-libfortran’; did you
mean ‘-static-libgfortran’?
So thanks David, and hopefully we get this user experience for the FE as well.
Joost
So, I have tested the patch, it seems to work well.
I would really like to see this feature in the compiler, I'm sure it will help
people developing Fortran code.
I have already an enhancement request, catching the name of 'Keyword argument' :
> cat test.f90
MODULE test
CONTAINS
SUBROUTINE fo
ping ?
https://gcc.gnu.org/ml/fortran/2014-05/msg00162.html
ping ?
https://gcc.gnu.org/ml/fortran/2014-06/msg00114.html
Thanks, can somebody with svn write access commit ?
>> So the negative version is -Wno-use-no-only? That sounds weird.
> What about -Wuse-without-only?
Would be fine with me. Approved with this change ?
Committed revision 214159.
2014-08-19 Joost VandeVondele
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 214158)
+++ MAINTAINERS (working copy)
@@ -561,6 +561,7 @@ Markus
Committed revision 214211.
> OK with the documentation change and with the re-named option. Please
> also update the name in the code.
changes made and committed as r214311
A doc change to refine wording for result value of int, avoiding the word range
and using magnitude as does the standard. Mentions undefined behavior.
2014-08-24 Joost VandeVondele
PR fortran/62245
* intrinsic.texi (INT): clarify result and undefined behavior.
Index: intrins
> One small ask: these lines are too long (already before your patch);
> can you please reformat those lines your patch touches to <80 columns?
sure:
Index: intrinsic.texi
===
--- intrinsic.texi (revision 214408)
+++ intrinsic.
>> +of @var{A} and whose sign is the same as the sign of @var{A}. The result
>> +is undefined if it can not be represented as an @code{INTEGER} of the
>> +given @code{KIND}.
>
>The last sentence above is not needed.
but helpful for gfortran users ?
> There is a general
> prohibition in 13.7.1 a
>> but helpful for gfortran users ?
>The problem is that a similar sentence would then need to be
>added to other intrinsic subroutines/functions where an actual
>argument might produce a result that is out-of-range of the
>representable entity.
So, I could remove the sentence if there is conse
> >The last sentence above is not needed.
So, revised patch without the last sentence.
2014-09-05 Joost VandeVondele
PR fortran/62245
* intrinsic.texi (INT): clarify result.
Index: fortran/intrinsic.texi
===
---
> OK.
Committed revision 214958.
>> > 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
> What is the rationale of
>
> + SUBROUTINE S2
> + USE foo, ONLY: bar ! { dg-bogus "has no ONLY qualifier" }
> + END SUBROUTINE
This explicitly tests that no bogus error message is issued for a use statement
that has an only qualifier ?
> Why do you want -fno-math-errno to be the default for gfortran?
because it was with rth's commit? This makes sense also because errno is a
variable that is defined for C, and not accessible from Fortran. Why would you
want -fmath-errno to be the default ?
> if (flag_associative_math == -1)
>
I have now verified that both new testcases indeed pass with
gcc version 4.6.0 20100520 (experimental) [trunk revision 159620] (GCC)
that is the revision where Tobias enabled associative math by default. So that
this patch fixes a regression.
Attached the reworked patch. The only change is that the warning is now not
part of -Wall, given the consensus on the list.
The patch has been bootstrapped and regtested on x86_64-unknown-linux-gnu. If
OK, please apply to trunk.
gcc/fortran/ChangeLog:
2014-06-04 Joost VandeVondele
PR
Hi Bernd,
reading the patches, it seems like there is no mention of sm_35, only sm_30.
So, I'm wondering what 'sub'targets will initially be supported, and
if/how/when various processors will be selected.
Thanks,
Joost
From my point of view, would be really nice to have.
Joost
Hi Gerald,
cp2k moved to https://www.cp2k.org/ , but isn't running a nightly gcc trunk
tester anymore. So, yes, patch is OK, unfortunately.
Joost
Thanks.. I wonder if you could add the testcase in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71961#c11
to the testsuite, as it catches the underlying issue.
Regards,
Joost VandeVondele
The following fixes two warnings reported by tsan when running OMP'ed code. As
suggested by Andrew Pinski in PR67303 for gomp_iter_guided_next, by employing a
relaxed atomic load. The same pattern occurred a couple of more times, so fixed
as well. I used the same approach for the warning in do_s
Thanks, committed to trunk r227119 with the format fix. Do you want this on the
5 branch as well ?
Joost
For the recent fix of PR53852, isl-0.15 is needed, which is already available
at ftp://gcc.gnu.org/pub/gcc/infrastructure/ . Thus, it seems to make sense to
update the download_prerequisites script, as done with the attached patch.
OK for trunk ?
JoostIndex: contrib/download_prerequisites
=
> can 4.8 and 4.9 be built with isl-0.15?
The patch only influences an in-tree build of isl for trunk, so does it matter ?
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
> +# 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- | ../../.
> 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
> 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
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
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
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
> 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
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
> 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.
>> 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
> 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
> 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: /* {
>>> >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
> 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
>> 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 ?
> 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
Hi Jakub,
thanks!
> +dg-test $gfortran_test_path/[lindex $args 1] ""
> $gfortran_aux_module_flags
> +# cleanup-modules isn't intentionally invoked here.
should this be 'is intentionally not invoked here' ?
I'm currently seeing a lot of errors in the log of make -j32 -k check. Similar
>> What dejagnu version are you using?
> runtest --version
WARNING: Couldn't find the global config file.
Expect version is 5.44.1.15
Tcl version is 8.5
Framework version is1.4.4
> > Framework version is 1.4.4
> You need at least dejagnu 1.5, which includes this fix:
I see, but that's contrary to :
https://gcc.gnu.org/install/prerequisites.html
> Does the following patch fix this? Works for me with dejagnu 1.5.1.
and works for me with 1.4.4
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
The following fixes PR63152 zeroing the data field only for allocatables, not
pointers. The benefit of the patch is a small speedup, and it avoids that code
starts to rely on behavior that is undefined in the standard. With this patch,
something like
INTEGER, DIMENSION(:), POINTER :: foo
IF (AS
>> The following fixes PR63152 zeroing the data field only for allocatables,
>> not pointers. The benefit of the patch is a >small speedup, and it avoids
>> that code starts to rely on behavior that is undefined in the standard. With
>> this patch, >something like
>>
>> INTEGER, DIMENSION(:), PO
A somewhat trivial patch to cleanup whitespace issues in comments: sed "s/\.
\*\//\. \*\//g"
Tested with a recompile only.
Ok for trunk ?
gcc/fortran/ChangeLog:
2014-09-20 Joost VandeVondele
* trans-expr.c (gfc_reset_vptr): Fix comment whitespace.
(gfc_conv_class_to_cl
Hi Tobias,
> However, I wanted to point out that seemingly trivial and obviously
> correct patches can have a downside. (One can still do such changes, but
> at least one should have weighted them against the downside.)
I agree, that's why I asked explicitly.
Joost
Attached patch introduces an optional warning for an OMP parallel/task/teams
construct without explicit default(none). This would effectively catch the
number one reason of easy-to-avoid OMP bugs in our project.
Tested with check-fortran, full bootstrap & check in progress. OK for trunk if
this
> a) I don't like the option name, -Womp-no-default-clause would be IMHO better
a bit related to b), I first had -Womp-no-default-none-clause but it becomes
long and contains twice 'no' (also consider the no-omp-no-default... form).
If you like that more, I'll make that change (see below) other
Hi,
the attached patch fixes PR61234 by introducing a warning for modules used
without an only qualifier, triggered by a flag '-Wuse-no-only'.
It is a two line addition to module.c, plus mechanical changes to initialize
the flag and keep the tests up-to-date. I currently have no copyright
ass
> I think it is really weird if a coding style warning is included in -Wall.
I have no strong opinion on this, I followed the -Wintrinsic-shadow example,
and I'm happy to change things.
Note however, that even the Fortran standard recommends the ONLY option for
example for intrinsic modules, t
Hi,
the Fortran FE sets flag_errno_math and flag_associative_math
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=94447
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=159620
Seemingly it (now?) needs to communicate that it is doing so, since otherwise
this is overwritten later on
Dominque,
after Janne's OK, and FX judgement, I wonder if you have reached a conclusion.
If so, the fsf assignment is now complete, and the patch could be applied.
Joost
> Ok for trunk. Thanks!
Please don't rush! The behavior of -fno-signed-zeros -fno-trapping-math
implying associative math h
>> This explicitly tests that no bogus error message is issued
>> for a use statement that has an only qualifier ?
>
>I don't see the need for '! { dg-bogus "has no ONLY qualifier" }'.
>AFAICT there is no warning emitted for this line (unless you add -Wall)
>and if some day it happens that an error
The attached patch fixes a race condition in libgomp. Based on the suggestions
by Dmitry, and verified that it fixes the corresponding sanitizer warnings.
2012-12-30 Dmitry Vyukov
PR libgomp/55561
* config/linux/wait.h (do_spin): Use atomic load for addr.
* config/lin
The updated changelog entry is below, but somebody with write access should do
the commit, please.
2013-01-31 Dmitry Vyukov
Joost VandeVondele
PR libgomp/55561
* config/linux/wait.h (do_spin): Use atomic load for addr.
* config/linux/ptrlock.c (gomp_
72 matches
Mail list logo
