RE: [wwwdocs] benchmarks/ -- cp2k.berlios.de/gfortran/ seems gone?

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

RE: [PATCH][COMMITTED] Revert r238497 because of PR 71961.

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

RE: [PATCH, fortran, v4] Use Levenshtein spelling suggestions in Fortran FE

From my point of view, would be really nice to have. Joost

RE: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

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

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

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

Re: [PATCH] RFC: Enable graphite at -O3 -fprofile_use

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).

RE: [PATCH] PR67518 and PR53852 -- add testcase.

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.

RE: [PATCH] PR67518 and PR53852 -- add testcase.

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 ...

RE: [PATCH] PR67518 and PR53852 -- add testcase.

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.

RE: [PATCH] PR67518 and PR53852 -- add testcase.

> Attached testcases for two previously fixed PRs (and thanks to Dominique who > was quicker for PR67982). ping ?

[PATCH] PR67518 and PR53852 -- add testcase.

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

RE: [PATCH] select isl-0.15 in download_prerequisites

> 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 ?

RE: [PATCH] select isl-0.15 in download_prerequisites

> 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

[PATCH] PR middle-end/68002: introduce -fkeep-static-functions

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.

RE: [PATCH] select isl-0.15 in 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 ?

[PATCH] select isl-0.15 in download_prerequisites

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

RE: Fix PR libgomp/66761 and PR libgomp/67303 (tsan warnings)

Thanks, committed to trunk r227119 with the format fix. Do you want this on the 5 branch as well ? Joost

Fix PR libgomp/66761 and PR libgomp/67303 (tsan warnings)

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

the nvptx port

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

msan and gcc ?

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

RE: msan and gcc ?

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.

[PATCH] Introduce warning -Womp-default-scope

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

RE: [PATCH] Introduce warning -Womp-default-scope

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)

[PATCH] Fix whitespace in comments.

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 vond...@gcc.gnu.org * trans-expr.c (gfc_reset_vptr): Fix comment whitespace.

RE: [PATCH] Fix whitespace in comments.

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

RE: [PATCH] Fix PR63152

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

[PATCH] Fix PR63152

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

RE: [PATCH] gcc parallel make check

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, box,

RE: [PATCH] Avoid inter-test dependencies in gfortran.dg (PR fortran/56408)

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 to

RE: [PATCH] Avoid inter-test dependencies in gfortran.dg (PR fortran/56408)

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

RE: [PATCH] Avoid inter-test dependencies in gfortran.dg (PR fortran/56408)

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

RE: [PATCH] Avoid inter-test dependencies in gfortran.dg (PR fortran/56408)

Does the following patch fix this? Works for me with dejagnu 1.5.1. and works for me with 1.4.4 Joost

RE: [PATCH] gcc parallel make check

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, box,

RE: [PATCH] gcc parallel make check

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

RE: [PATCH] gcc parallel make check

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 ?

RE: [PATCH] gcc parallel make check

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

RE: [PATCH] gcc parallel make check

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

RE: [PATCH] gcc parallel make check

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 ?

RE: [PATCH] gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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.

RE: [PATCH] RE: gcc parallel make check

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 errors) PASS:

RE: [PATCH] gcc parallel make check

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

RE: [PATCH] gcc parallel make check

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: /* {

RE: [PATCH] gcc parallel make check

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, what about

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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.

RE: [PATCH] RE: gcc parallel make check

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 errors) PASS:

RE: [PATCH] gcc parallel make check

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

RE: [PATCH] gcc parallel make check

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: /* {

RE: [PATCH] gcc parallel make check

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, what about

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

+# 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- |

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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[3-5]*

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

+# 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- |

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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[3-5]*

RE: [PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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

[PATCH] RE: gcc parallel make check

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

RE: [PATCH] RE: gcc parallel make check

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. unmodified

RE: [PATCH] PR fortran/62245 fix INT docs.

The last sentence above is not needed. So, revised patch without the last sentence. 2014-09-05 Joost VandeVondele vond...@gcc.gnu.org PR fortran/62245 * intrinsic.texi (INT): clarify result. Index: fortran/intrinsic.texi

RE: [PATCH] PR fortran/62245 fix INT docs.

OK. Committed revision 214958.

RE: [PATCH] RE: gcc parallel make check

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. unmodified

gcc parallel make check

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

RE: gcc parallel make check

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

RE: gcc parallel make check

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

RE: gcc parallel make check

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

RE: gcc parallel make check

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

[PATCH] PR fortran/62245 fix INT docs.

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 vond...@gcc.gnu.org PR fortran/62245 * intrinsic.texi (INT): clarify result and undefined

RE: [PATCH] PR fortran/62245 fix INT docs.

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) +++

RE: [PATCH] PR fortran/62245 fix INT docs.

+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 against

RE: [PATCH] PR fortran/62245 fix INT docs.

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 consensus.

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

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

RE: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

Committed revision 214211.

RE: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

Thanks, can somebody with svn write access commit ?

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

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] Add myself to MAINTAINERS (Write After Approval)

Committed revision 214159. 2014-08-19 Joost VandeVondele vond...@gcc.gnu.org * MAINTAINERS (Write After Approval): Add myself. Index: MAINTAINERS === --- MAINTAINERS (revision 214158) +++ MAINTAINERS (working copy) @@

RE: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

ping ? https://gcc.gnu.org/ml/fortran/2014-05/msg00162.html

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

ping ? https://gcc.gnu.org/ml/fortran/2014-06/msg00114.html

RE: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

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

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

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/warning

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

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

RE: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

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.

RE: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

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)

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

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 ?

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

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,

[PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

Hi, the Fortran FE sets flag_errno_math and flag_associative_math https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=94447 https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=159620 Seemingly it (now?) needs to communicate that it is doing so, since otherwise this is overwritten later on

RE: Fix for PR55561 race condition in libgomp

The updated changelog entry is below, but somebody with write access should do the commit, please. 2013-01-31 Dmitry Vyukov dvyu...@gcc.gnu.org Joost VandeVondele joost.vandevond...@mat.ethz.ch PR libgomp/55561 * config/linux/wait.h (do_spin): Use atomic load

Re: Reducing fortran testcase with delta.

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: lto and gold

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

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

optimization question

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]

  1   2   >