Gfortran and using C99 cbrt for X ** (1./3.)
Richard, Somewhere, in a mail lost in my large e-mail clash with my ISP (verizon), you said that gfortran couldn't profit from the pow(x, 1./3.) -> cbrt(x) conversion because gfortran didn't "know" of cbrt. Could you be more explicit about this - I'd like to repair this deficiency, if at all possible. Thanks in advance ! -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2006-01/msg0.html
Re: Gfortran and using C99 cbrt for X ** (1./3.)
Richard Guenther wrote: It's a matter of making the cbrt builtin available - I have a patch for this, but wondered if the fortran frontend can rely on the cbrt library call being available? Or available in a fast variant, not a fallback implementation in libgfortran which does pow (x, 1./3.) which will then of course pessimize pow (x, 2./3.) -> tmp = cbrt(x); tmp * tmp expansion. Couldn't libgfortran just simply borrow, errr, include the glibc version ? That one seems simple and fast enough. OTOH, I somehow assumed this expansion was protected by -funsafe-math-optimizations, but further testing showed me that it is not. This wouldn't scare me one bit (I'm used to the phrase "a processor dependent approximation to the value of", which is used *a lot* in the Fortran Standard), but some people might think this to be too valiant. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2006-01/msg0.html
Re: Gfortran and using C99 cbrt for X ** (1./3.)
Toon Moene wrote: Richard Guenther wrote: It's a matter of making the cbrt builtin available - I have a patch for this, Oh, BTW, my own version of this patch (plus your work in the area of sqrt) had the following effect on a profile breakdown (every routine above 2 %) of the forecasting code in HIRLAM (http://hirlam.org) - just look at the %; the times are not comparable, as you can see from the number of calls of each routine: Before: % cumulative self self total time seconds secondscalls Ks/call Ks/call name 14.29755.79 755.79 116160 0.00 0.00 verint_ 12.66 1425.23 669.43 __ieee754_powf 5.50 1716.19 290.97 116160 0.00 0.00 bixint_ 4.96 1978.62 262.42 121 0.00 0.03 sl2tim_ 4.94 2239.98 261.3615730 0.00 0.00 hlcondcv_ 4.26 2465.30 225.3215730 0.00 0.00 hlvcbr_ 3.62 2656.71 191.4115730 0.00 0.00 hlradia_ 2.85 2807.19 150.48 __ieee754_logf 2.64 2946.87 139.6815730 0.00 0.00 phtask_ 2.34 3070.80 123.93 1452 0.00 0.00 invlo4_ 2.25 3189.55 118.75 __ieee754_expf 2.23 3307.65 118.10 fesetround 2.21 3424.45 116.80 fesetenv 2.08 3534.31 109.8615730 0.00 0.00 hlprevap_ After: % cumulative self self total time seconds secondscalls Ks/call Ks/call name 14.22575.66 575.6693120 0.00 0.00 verint_ 9.83973.59 397.93 __ieee754_powf 5.84 1210.14 236.5593120 0.00 0.00 bixint_ 5.14 1418.12 207.98 97 0.00 0.03 sl2tim_ 5.05 1622.62 204.5012610 0.00 0.00 hlcondcv_ 4.28 1795.91 173.2912610 0.00 0.00 hlvcbr_ 3.64 1943.48 147.5612610 0.00 0.00 hlradia_ 3.12 2069.66 126.19 __ieee754_logf 2.77 2181.96 112.3012610 0.00 0.00 phtask_ 2.39 2278.5696.60 1164 0.00 0.00 invlo4_ 2.34 2373.1294.56 fesetround 2.26 2464.7191.59 fesetenv 2.13 2551.0786.3612610 0.00 0.00 hlprevap_ 2.06 2634.3183.2412610 0.00 0.00 phys_ 2 Ghz Athlon 64, AMD64 Debian testing, gfortran 4.3.0. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2006-01/msg0.html
Re: Gfortran and using C99 cbrt for X ** (1./3.)
Toon Moene wrote: Toon Moene wrote: Richard Guenther wrote: It's a matter of making the cbrt builtin available - I have a patch for this, Oh, BTW, my own version of this patch (plus your work in the area of sqrt) had the following effect on a profile breakdown The speed up is around 5 %. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2006-01/msg0.html
Re: Gfortran and using C99 cbrt for X ** (1./3.)
Richard Guenther wrote:
>> I wrote:
The speed up is around 5 %.
Is this because of cbrt or a combined effect? Can you measure the cbrt
effect in isolation?
This is a combined effect (assuming that things like x**1.5 didn't
expand to x * sqrt (x) before) - however, the number of opportunities of
converting x**N.5 -> x**N * sqrt(x) is very limited in our code.
I artificially up'd the number of opportunities for the x**(N+{1,2}./3.)
-> x**N * cbrt(x)[**2] by changing about two dozen places where
x**0.33 or x**0. or x**0.666 [sic] was used instead of
x**(1./3.) or x**(2./3.). In fact, I'd like to use the carrot of
potential optimizations to get people to use the clearer x**(1./3.) (we
also have a legitimate use of x**0.3, where the 0.3 really is 3./10.)
I can measure the contribution of the cbrt effect in isolation, though
(given the above change of HIRLAM source code).
Cheers,
--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/
Who's working on GNU Fortran:
http://gcc.gnu.org/ml/gcc/2006-01/msg0.html
Re: Gfortran and using C99 cbrt for X ** (1./3.)
Toon Moene wrote: I can measure the contribution of the cbrt effect in isolation, though (given the above change of HIRLAM source code). Well, the effect of the cbrt change (X ** (1./3.) -> cbrt(X)) is close to zero. Some other change must have diminished the number of pow[f] calls substantially. I think Andrew P's patch to declare the Fortran pow functions constant might be a good candidate. [ I did this exercise for g77 in 2000 - I'd never thought that that wouldn't be the basis for people to work on gfortran ... ] Cheers, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2006-01/msg0.html
Re: GCC optimizes integer overflow: bug or feature?
Robert Dewar wrote: Valid programs is too narrow a set, you really do have to pay attention to normal usage. I very well remember the Burroughs 5500 compiler, which took advantage of the stack semantics allowed by the standard, but in fact virtually all Fortran programs of the era assumed static allocation since that's what every other compiler did. As a consequence the 5500 Fortran was completely useless, one factor that certainly caused universities I was aassociated with to avoid this machine. [ Sorry for the late reply ] As we say on the committee: Quality of Implementation Issue. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2006-01/msg0.html
27% regression of gcc 4.3 performance on cpu2k6/calculix
Grigory, Calculix is a combined C/Fortran program. Did you try to compile the Fortran parts with --param max-aliased-vops=default 50> ? Diego up'd the default from 10 to 50 because one (or more) of the (Fortran) Polyhedron benchmarks showed a dramatic performance regression. (Note: I've sent Diego a 900 line Fortran subroutine that crashes the compiler if you give it --param max-aliased-vops=200 or higher). Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Re: ANNOUNCE: Gelato ICE GCC track, San Jose, CA, April 16-18, 2007
Diego Novillo wrote: The following GCC track is part of the Gelato ICE (Itanium Conference & Expo) OK, OK, I'm slow, I know - but this one I finally got: Gelato - Ice [ B ] "I scream, you scream, we all scream for ice cream ... " -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Re: Building mainline and 4.2 on Debian/amd64
Florian Weimer wrote: * Steven Bosscher: On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote: I don't need the 32-bit libraries, so disabling their compilation would be fine. --enable-targets at configure time might do the trick, but I don't know what arguments are accepted. Would --disable-multilib work? I'll try, but I doubt it. According to the installation documentation, amd64 is not a multilib target. Hmmm, I always use it, and I have never run into the problem you mention. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Re: Building mainline and 4.2 on Debian/amd64
Florian Weimer wrote: * Andrew Pinski: Actually it brings up an even more important thing, distros that don't include a 32bit user land is really just broken. Are they? I haven't run into problems yet. (And pretty please, I misread the documentation. It does *not* state that amd64 is not a multilib target. Sorry about that.) I believe the OpenOffice Team had to do some rewriting because they assumed 32-bit ints/pointers, but that's about it. If your bread and butter is Fortran programming, you don't even *know* that the pointers are twice the size on AMD64. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Re: VAX backend status
Matt Thomas wrote: For instance, gcc emits: movab rpb,%r0 movab 100(%r0),%r1 cvtwl (%r1),%r0 but the movab 100(%r0),%r1 is completely unneeded, this should have been emitted as: movab rpb,%r0 cvtwl 100(%r0),%r0 Ah ! A clear case of "all the world's a RISC" syndrome. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Re: Proposal: changing representation of memory references
Zdenek Dvorak wrote: Sorry, but you are completely out here. I have spent a lot of time working with the code for dealing with memory references, trying many different approaches. [ to put a different spin on it ] It just might be that most of Roger Sayle's Fortran front end optimizations - that I will talk about at the GCC Summit - are possible using Zdenek's scheme in the middle end; and hence do not *have* to be done by the front end. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Documenting -fargument-noalias-anything in gcc-4.2/changes.html
Gerald, I do not have easy access to the HTML repository anymore. Martin Michlmayr asked me to add to the 4.2 changes list the inclusion of the new compile time option -fargument-noalias-anything. I constructed the following out of the invoke.texi document, to be included in gcc-4.2/changes.html, after "General Optimizer Improvements": -fargument-noalias-anything specifies that arguments do not alias any other storage. Each language will automatically use whatever option is required by the language standard. You should not need to use these options yourself. I would be glad if you could commit it. Thanks, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Re: RFC: GIMPLE tuples. Design and implementation proposal
Dave Korn wrote: Using a delta is even better than an XOR, because it remains constant when you relocate the data. Could someone explain why we are re-inventing VAX instructions here ? [ OK, 1/2 :-) ] -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
Re: How is lang.opt processed?
Steve Kargl wrote: On Thu, Mar 10, 2005 at 01:10:49PM -0800, James E Wilson wrote: You can't choose any name for front-end options. There are complicated rules for determining whether an option is for the gcc driver or preprocessor or front-end or back-end or assembler or linker or collect or something else. If you deviate from these rules, you are asking for trouble. Jim, Thanks for the detailed explanation of how GCC options work. I'm currently thinking of proposing a RFC with recommendations on how to address this problem with gfortran. Ditto. Jim, are you reading from some documentation about this option processing that I couldn't find ? I've spend hours and hours to try to deduce the option processing rules from debugging various parts of the gcc driver, with no success. Thanks, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Write after approval - processed by "None".
Again I got a reaction of accepting write after approval (this time for Feng Wang) as "processed by: None". This is not encouraging - is someone reading these acceptances (despite the "processed by: None" part) ? FYI, Feng Wang's copyright assignment papers date from September, 2003. Thanks in advance, and kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: reload-branch created
Bernd Schmidt wrote: I have created a new branch, "reload-branch", on which I'm going to check in these changes. Thanks - very important first step to make reload "the preferred way to distribute the software" :-) AKA as complying to the GPL. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Copyright status of example code in Bugzilla - how to deal with when writing testcases.
L.S., An ex-J3 member has started to apply his bag of test programs on gfortran - this could result in potentially hundreds of bug reports in Bugzilla with attached test-code. How do we deal with this, copyright-wise ? Do we have to take special care when deriving test-cases from them ? Thanks in advance for any insight ... -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: Copyright status of example code in Bugzilla - how to deal with when writing testcases.
Daniel Berlin wrote: I think we should just keep on doing what we do, which is produce small minimized testcases that are well within the "de minimis" limits for copyright, or even if they aren't, the tests don't actually do anything useful from a program perspective. The number of questionable testcases we get is small enough that taking this approach, and handling outliers on a case by case basis seems correct to me. Well, yes, that was the question behind my question. In this case we might get 0(100) testcases that each are within the "de minimis" doctrine. The question is: is the total of these testcases (from one source) within that limit ... Cheers, [ Understanding of the doctrine of "de minimis" is courtesy Groklaw - for the rest I'm just a meteorologist - I don't even play a lawyer on TV ] -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF
Peter Brown via RT wrote: Dear Swami, Sorry for our delay in responding to your request. FSF's Assignment Administrator is currently unavailable, and we expect there to be a delay in processing your request for at least another week. Please bear with us whilst we arrange for additional help. We (the GNU Fortran folk) are in trouble too: We're awaiting affirmation of the receipt of Thomas Koenig's papers (sent from Germany on the 19th of March). He has quite a few patches to gfortran in the queue and GCC 4.0 (the first GCC release to contain gfortran) is scheduled for the 15th of April. Please help. Thanks ! -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: [gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF
David Edelsohn wrote: Toon Moene writes: Toon> We (the GNU Fortran folk) are in trouble too: We're awaiting Toon> affirmation of the receipt of Thomas Koenig's papers (sent from Germany Toon> on the 19th of March). He has quite a few patches to gfortran in the Toon> queue and GCC 4.0 (the first GCC release to contain gfortran) is Toon> scheduled for the 15th of April. Toon> Please help. The FSF has advised that we can accept Thomas's patches while the paperwork catches up. David Thanks, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: 2 suggestions
Kaveh R. Ghazi wrote: If people would simply follow the directions here: <http://gcc.gnu.org/install/specific.html#*-*-solaris2*> by setting CONFIG_SHELL to /bin/ksh before configure;make bootstrap, Indeed - I stopped counting how many hours of debugging shell scripts on our Sun server I saved (for my employer) by being on these mailing lists and thereby knowing this. /bin/sh on Solaris is evil. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: GCC 4.0 Freeze
Mark Mitchell wrote: Please treat the GCC 4.0 branch as frozen as of this time. All non-documentation changes now need my explicit approval. I'll spin prerelease bits soon. It's a pity a couple of important gfortran bug fixes "didn't make it", but work is under way to get them applied to 4.0.1. I'm still thinking about the text to warn gfortran users for the fact that this compiler at present doesn't cover all of Fortran 77 - and that we assume distributors to provide access to g77 as long as that's useful. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: GCC 4.0 branch open for regression fixes
Mark Mitchell wrote: The GCC 4.0 branch is now open for regression fixes only, under the usual release branch rules. I presume this means that we (The Fortran Illuminati) can fix any bug in the gfortran frontend, as we don't have any regressions yet (at least not against gfortran itself - there are regressions with respect to g77) ? [ Thanks for your continued support of our product ] :-) -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: GCC 4.1: Buildable on GHz machines only?
Peter Barada wrote: Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the BogoMips of my workstation, and with an NFS rootfs, it gets network bound pretty rapidly and runs even slower compared to a NetBSD machine with a local disk :) Hmmm, Ghz wise and BogoMips wise, this is about half what I have (a 550 Mhz G4 PowerBook). Nevertheless, you don't hear *me* complain ... I build GCC while at work (i.e., while away from the notebook at home :-) Try it ... it works, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: GCC and Floating-Point
Allan Sandfeld Jensen wrote: On Friday 27 May 2005 13:51, Vincent Lefevre wrote: So, yes, -ffast-math by default would really be a bad idea and would make gcc much worse than other compilers. Thanks for the tests. I had no idea GCCs fast-math was that different from other compilers. Maybe the real goal like other have mentioned should be to divide the -ffast-math into multiple switches. Good Luck :-) http://gcc.gnu.org/ml/gcc/2001-08/msg00368.html (it's only four years ago - I can also show you my contributions in this thread in 1999, i.e., the previous millennium). -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]
Vincent Lefevre wrote: On 2005-05-29 18:19:19 +0300, Michael Veksler wrote: If more than 50 people report it, independently, as a bug then it sure is a bug. You might argue whether technically it is a bug, but from user's perspective it is a bug (and you have over 50 duplicates as an evidence). As such it has to be dealt with more positively. Concerning the extended precision, there are two problems. First there is a bug in GCC concerning casts and assignments (see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2). But even this were fixed, many users would still complain. That's why I think that the Linux kernel should set the CPU in double-precision mode, like some other OS's (MS Windows, *BSD) -- but this is off-topic here. It's not off-topic. In fact, Jim Wilson argued this point here: http://gcc.gnu.org/ml/gcc/2003-08/msg01282.html "The best pragmatic solution is probably to set the rounding control to 64-bits, but then we lose access to long double which some people need, and we still have excess precision problems for float." Hope this helps, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: Will Apple still support GCC development?
Samuel Smythe wrote: It is well-known that Apple has been a significant provider of GCC enhancements. But it is also probably now well-known that they have opted to drop the PPC architecture in favor of an x86-based architecture. Will Apple continue to contribute to the PPC-related componentry of GCC, or will such contributions be phased out as the transition is made to the x86-based systems? We don't mind. I bought an Apple G4 PowerBook because it offered me a relatively cheap way to get a 32 bit, big endian machine. The first thing I did after receiving it is wiping out OS X and installing a real operating system, i.e., Debian. A big endian system is indispensible if you are a compiler writer, because little endian hardware hides too many programmer errors; At the previous GCC Summit even the head of the Intel compiler group agreed with me on this and pointed out that the Itanium can be run in big endian mode. In turn, will Apple be providing more x86-related contributions to GCC? Well, they could do all they might. I'm just waiting for IBM coming forward with a Linux PowerPC64 laptop, so that I can continue to use big endian hardware. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Looking for a job: Work from home or at a customer site; HPC, (GNU) Fortran & C
Re: Will Apple still support GCC development?
Mirza Hadzic wrote:
A big endian system is indispensible if you are a compiler writer,
because little endian hardware hides too many programmer errors
Can you show example(s) where little endian hides errors? Just curious...
Sorry, I was already asleep when your mail arrived ...
main()
{
long blah;
(void) foo(&blah);
printf("%ld\n", blah);
}
different file
foo(int *bar)
{
*bar = 42;
}
Works on ILP32 mode machines (both endiannesses), "works" on I32LP64
mode machines (little endian), fails miserably on I32LP64 mode machines
(big endian) *as it should*.
--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Looking for a job: Work from home or at a customer site; HPC, (GNU)
Fortran & C
Re: Will Apple still support GCC development?
Robert Dewar wrote: Toon Moene wrote: The first thing I did after receiving it is wiping out OS X and installing a real operating system, i.e., Debian. Is it really necessary to post flame bait like this, hopefully people ignore this Perhaps the following little exchange rings a bell: C: 'E's not pinin'! 'E's passed on! This customer is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!! THIS IS AN EX-CUSTOMER!! -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Looking for a job: Work from home or at a customer site; HPC, (GNU) Fortran & C
Re: basic VRP min/max range overflow question
Dale Johannesen wrote: 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Hmmm, I see your standard doesn't include the possibility to start WW III (if the right, optional, hardware is connected) ? [ Sorry, couldn't resist :-) ] -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Looking for a job: Work from home or at a customer site; HPC, (GNU) Fortran & C
Re: Reporting bugs: there is nothing to gain in frustrating reporters
Vincent Lefevre wrote: Saying that the x86 processor is buggy is just completely silly. Only some gcc developers think so. No, Kahan thinks so too (sorry, can't come up with a link just right now). The original plan for x87 extended precision floating point was to have a small stack of 80-bit floats on the chip, and an interrupt to the OS if more registers were needed than the number extant on the chip. The OS was then to provide the extra storage to "feign" the unlimited number of 80-bit "registers". Unfortunately, somewhere in the design process of the 8087 things went wrong and the chip only handles 8 80-bit registers, not providing an interrupt (or any other support) to an OS to fake the "virtual" 80-bit registers. Hence our problems. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Looking for a job: Work from home or at a customer site; HPC, (GNU) Fortran & C
Re: Reporting bugs: there is nothing to gain in frustrating reporters
Robert Dewar wrote: I wrote: Unfortunately, somewhere in the design process of the 8087 things went wrong and the chip only handles 8 80-bit registers, not providing an interrupt (or any other support) to an OS to fake the "virtual" 80-bit registers. This is nonsense. It is perfectly possible to extend the stack accurately in memory. That is easily true on the 387, but was also true on the 8087 with just a little bit of fiddling (I know that some people thought this was not possible, but they just did not look hard enough, the Alsys Ada compiler for instance used a stack model for fpt, and dynamically extended this stack in memory, so this is certainly possible). Well, I haven't studied this to such a great detail because I (according to Kahan) belong to the group of people who "don't care about floating point accuracy because their code is so robust they can even run on Cray's", but doesn't this mean that we can solve it in the compiler by having its run time library provide this functionality ? Given that most modern compilations on x86 hardware would use SSE, we could at least comfort the users who do want to use the extra bits of 80-bit floating point land ... It'll be the final nail in the coffing of PR/323 ... -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Looking for a job: Work from home or at a customer site; HPC, (GNU) Fortran & C
Re: Reporting bugs: there is nothing to gain in frustrating reporters
Robert Dewar wrote: Well, I haven't studied this to such a great detail because I (according to Kahan) belong to the group of people who "don't care about floating point accuracy because their code is so robust they can even run on Cray's", but doesn't this mean that we can solve it in the compiler by having its run time library provide this functionality ? You are mixing issues, the issue of extra precision on the x86 has nothing whatever with whether or not such values can be stored in memory (they can), and Kahan's inaccurate impression that there is a problem in extending the stack, if indeed you are quoting him accurately, is not relevant. Hmmm, lets be careful here. In my original reply I said "I do not have a link just right now", which means I might recall things incorrectly. I have read accounts (in a distant past) that the original purpose of the x87 stack of 80-bit floating point values was to have a cache on the processor (initially 8 registers) and the rest supported by "the operating system". That could of course well be the common run time library. If your experience is that such a support (of an indefinite number of 80-bit floating point registers) could easily be provided by the run time library of compiler, that indicates to me that GCC could provide such support. The new thing I learned from your mail is the above. If GCC can support this, than we can properly solve PR/323. This is independent of whether I recall the thing I read in the past correctly. Hope this helps, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Looking for a job: Work from home or at a customer site; HPC, (GNU) Fortran & C
Re: signed is undefined and has been since 1992 (in GCC)
Andrew Pinski wrote: The first change in GCC which changed signed overflow/wrapping to be undefined was added back in 1992 in loop.c. Why are we talking about this now, instead of back when they were added ? Well, I don't know about the rest of the GCC developers at that time (1992), but my first priority *at that time* was to get g77 to the masses, which only happened on the 17th of February 1995. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Looking for a job: Work from home or at a customer site; HPC, (GNU) Fortran & C
moene.indiv.nluug.nl is down and out ...
... due to drinking to much programming fluid (i.e., beer - and it wasn't even free). I've ordered a new laptop - an AMD Athlon 64 based one; supplemented by AMD64 Sarge (yes, I know, Real Men Prefer Big-Endian, but then, Real Men Don't Cry, either). However, delivery might take a few weeks, so I'll be incommunicado during that time, except for the use of this 19th century technology known as the "far-speaker" or "tele-phone": +31 346 214290 In case of emergency, this e-mail address may be used, but do realize that I have a Real Job to perform. Thanks for your patience, -- Toon Moene, KNMI, The Netherlands Phone: +31 30 2206443; e-mail: [EMAIL PROTECTED]
moene.indiv.nluug.nl is back in business (black and white only, though).
L.S., The host of my domain has been forcefully upgraded to an HP zv6025, sporting an Athlon 64 processor, 512 Mbyte of memory and 60 Gbytes of disk. The upgrade took so long (2.5 months) because I was determined to run Debian AMD64 on it (the hardware was delivered next day). Coming weekend I'll concentrate on the crest of Debian installation - the summit of geekdom [ Scene 23: The Bridge of Death ] ... KEEPER: Stop - what's your name ? MOENE: I am Moene, the King of the Blind. KEEPER: What's your quest ? MOENE: My quest is to find the holy XF86Config-4. KEEPER: What's the airspeed accelleration of an unpatched Windows System ? MOENE: Windows 2000 or Windows XP ? KEEPER: I ... I don't know that - Aaaarrhhh! ... BEDEVERE: You sure know a lot about Windows systems ! MOENE:As a King, you have to know these things ... ... ... clop, clop, whinny ...
Vector et emergo: On the vectorization of the HIRLAM Weather Prediction code.
L.S., At the last GCC summit I showed that complete compilation of the HIRLAM Numerical Weather Prediction suite by gfortran/gcc was near completion - only a few compiler bugs were between us and running programs. This (autumn) holiday, I was able to convince myself that the problems on the part of gfortran/gcc were confined to gfortran not knowing the LOC (extension) intrinsic, which will be part of LLNL's "Cray" pointers package, and an "unclassifiable statement" when trying to parse a five part concatenation of substrings (for which I'll file a bug report shortly). All other problems are due to HIRLAM people not following standards closely enough, which I will remedy effectively ;-) Therefore, the next challenge presented itself: Given that the HIRLAM code always has performed well on vector machines (as of '85), it's a natural to compile it with -ftree-vectorize -ftree-vectorizer-verbose=n compiler options, to see what the vectorizer can make of it. Here are the top level results: Loops considered by the vectorizer as potentially vectorizable: 10420. Loops actually vectorized: 2645. Loops not vectorized:7775. of which: - unhandled data-ref: 3479. - complicated access pattern: 1500. - can't determine dependence: 1456. - unsupported use in stmt: 662. - no vectype for type (complex8): 235. - relevant stmt not supported: 120. - mixed data-types:149. I'll send examples of the top three of this list, plus the ultimate example why 235 occurrences of "no vectype for type (complex8)" is an unnessary thing. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 1: This dependence is determinable.
L.S., This code: SUBROUTINE S(N, M) DIMENSION A(N, M), B(N, M) READ*,A,B DO J = 1, M DO I = 1, N A(I, J) = A(I, J) + B(I, J) ENDDO ENDDO PRINT*,A END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect1.f draws the following "not vectorized" message: vect1.f:5: note: not vectorized: can't determine dependence between (*a_23)[D.951_86] and (*a_23)[D.951_86] vect1.f:5: note: vectorized 0 loops in function. That's pretty silly, of course :-) Source and destination A(I,J) overlap exactly, so vectorization of this loop is certainly possible. The equivalent rank-1 example is vectorized without problems. Exempting this one special case from "can't determine dependence" will mean about 1000 more vectorized loops in HIRLAM. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 2: One out of the "unhandled data-ref" garbage bin :-)
L.S., This code: SUBROUTINE S(A, B, N) DIMENSION A(N), B(N) READ*,Z,B DO I = 1, N A(I) = Z * B(I) ENDDO PRINT*,A END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect2.f draws the following "not vectorized" message: vect2.f:4: note: not vectorized: unhandled data-ref vect2.f:4: note: vectorized 0 loops in function. Hmmm, how about broadcasting Z to a vector register and using that in a vectorized version of this loop :-) ? Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 3: Can't vectorize DOUBLE COMPLEX loops ...
L.S., The following code: SUBROUTINE S(N) DOUBLE COMPLEX A(N), B(N) READ*,B DO I = 1, N A(I) = B(I) ENDDO PRINT*,A END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect3.f draws the following "not vectorized" message: vect3.f:4: note: not vectorized: no vectype for stmt: D.929_51 = (*b_8)[D.928_48] scalar_type: complex8 vect3.f:4: note: vectorized 0 loops in function. Which begs the question: Why not vectorizing *after* complex computation has been lowered to the equivalent floating point computation ? HIRLAM contains relatively few complex computation - however, a sizable number of physics problems are more easily expressed using (DOUBLE) COMPLEX quantities. It seems they are on the short end of the rope as far as vectorization is concerned. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 4: complicated access patterns examined.
L.S., This code: SUBROUTINE S(N) DIMENSION A(N), B(N) READ*,ISTART,ISTOP,B DO I = ISTART, ISTOP A(I) = B(I) ENDDO PRINT*,A END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f draws the following "not vectorized" message: vect4.f:4: note: not vectorized: complicated access pattern. vect4.f:4: note: vectorized 0 loops in function. This sort of coding is rather prevalent in HIRLAM, especially in the interesting inner loops. One needs this when not all of the inner area is accessible / computable by the code at hand (for instance because there are inaccessible "halo's" around the subarea that have to be treated specially). The funny thing is that replacing ISTART with a constant makes this loop vectorizable. So what's the fundamental difference (as far as vectorizing is concerned) between a constant and a loop invariant :-) ? Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 5: Another one out of the "unhandled data-ref" grab bag.
L.S., This code: SUBROUTINE S(N) DIMENSION A(N), B(12) COMMON /COM/ B DO I = 1, 12 A(I) = B(I) ENDDO PRINT*,A(1:12) END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect5.f draws the dreaded "unhandled data-ref" message: vect5.f:4: note: not vectorized: unhandled data-ref vect5.f:4: note: vectorized 0 loops in function. Hmmm, this is rather common (pun intended) in old Fortran code. Why is this style "punished" by not being vectorizable ;-) ? Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 6: Honoring Fortran's Alias Requirements - might be a bug.
L.S., This code: SUBROUTINE S(N) INTEGER N COMMON /COM/ A(100) REAL A REAL B(N), C(N), D(N) DO I = 1, N B(I) = D(I) ENDDO DO I = 1, N A(I) = B(I) ENDDO CALL S1(C(1)) END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f draws the following "not vectorized" message: vecta.f:6: note: LOOP VECTORIZED. vecta.f:9: note: not vectorized: can't determine dependence between (*b_15)[D.928_29] and com.a[D.928_29] vecta.f:9: note: vectorized 1 loops in function. This cannot be right. According to the Fortran Standards that have been, that are, and that will be, A (which resides in common) and B (which is a local array) cannot have *any* storage in common. They're disjoint - they won't unite no matter what. So where does the compiler lose this valuable information ? This is a hunt for the more advance vector-sorcerer. Note that removing the (1) from the CALL in the last-but-one line makes the compiler recall the ever important Fortran alias rules. [ Sprinkle the above with :-) liberally ] Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM NN.
L.S., As Dorit indicated - it's better to perform vectorization experiments from the autovect branch. Further data on this with respect to the HIRLAM code base will be based on builds off the autovect branch. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM II: Using the autovect branch compiler.
L.S., Using the autovect branch compiler: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/vec --disable-nls --disable-multilib --enable-languages=f95 Thread model: posix gcc version 4.1.0 20051022 (experimental) I now get the following results: Number of potentially vectorizable loops:9799. Number of loops vectorized: 2658. Number of loops not vectorized: 7141. Of which: - due to unhandled data-refs: 3078. - due to complicated access patterns: 1573. - due to undeterminable dependence:1224. - due to unsupported use in statement: 674. - due to no vectype in statement (complex8):238. So this version of the compiler performs slightly better. The reduction in the number of potentially vectorizable loops is due to me rsync'ing a new version of HIRLAM where various duplicated libraries have been merged. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 1: This dependence is determinable.
This one does get vectorized with autovect-branch: [ example with source and destination array exactly overlapping ] ~/autovect_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec -ftree-vectorizer-verbose=4 -S hilaram1.f90 hilaram1.f90:5: note: dependence distance = 0. hilaram1.f90:5: note: accesses have the same alignment. hilaram1.f90:5: note: dependence distance modulo vf == 0 between (*a_25)[D.949_60] and (*a_25)[D.949_60] hilaram1.f90:5: note: Alignment of access forced using peeling. hilaram1.f90:5: note: Vectorizing an unaligned access. hilaram1.f90:5: note: LOOP VECTORIZED. hilaram1.f90:9: note: vectorized 1 loops in function. dorit Indeed, it works on x86_64-unknown-linux-gnu too, with the autovect branch. > L.S., > > This code: > > SUBROUTINE S(N, M) > DIMENSION A(N, M), B(N, M) > READ*,A,B > DO J = 1, M > DO I = 1, N > A(I, J) = A(I, J) + B(I, J) > ENDDO > ENDDO > PRINT*,A > END Unfortunately, it's only this example that works. I still see a lot of cases when using the autovect branch compiler on HIRLAM. I'll try to distill another example. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
:4: note: ==> examining statement: D.832_43 = (*b_10)[D.831_40] vect4.f:4: note: vectype: vector real4 vect4.f:4: note: nunits = 4 vect4.f:4: note: ==> examining statement: (*a_16)[D.831_40] = D.832_43 vect4.f:4: note: vectype: vector real4 vect4.f:4: note: nunits = 4 vect4.f:4: note: ==> examining statement: i_45 = i_1 + 1 vect4.f:4: note: skip. vect4.f:4: note: ==> examining statement: if (i_1 == D.813_29) goto ; else goto ; vect4.f:4: note: skip. vect4.f:4: note: ==> examining statement: : vect4.f:4: note: skip. vect4.f:4: note: === vect_analyze_dependences === vect4.f:4: note: === vect_analyze_data_ref_accesses === vect4.f:4: note: not consecutive access ^^ This is incorrect. The accesses *are* consecutive; it's just that there is a "jump" at the beginning. vect4.f:4: note: not vectorized: complicated access pattern. vect4.f:4: note: bad data access. Hope this helps. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 6: Honoring Fortran's Alias Requirements - might be a bug.
On Friday 21 October 2005 09:51, Toon Moene wrote: > So where does the compiler lose this valuable information ? > Toon, could you open PRs for these problems? Some of the failures you see look like aliasing problems. It'd be nice to have them in bugzilla, even if they end up being dups of existing reports. I'll try. Unfortunately, I'm still working on a text-only basis (this is what you get when you want Debian Sarge AMD64 on a brand new laptop - I'm not complaining). I'll see if I can manipulate bugzilla this way via lynx. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
Dorit wrote: It looks like maybe a 64bit scalar-evolution issue - when I compile on powerpc-linux with -m64, I also get the "vect4.f:4: note: not consecutive access" message. This problem looks very similar to PR18403 which has been resolved a while ago: ... When compiling for 64bit, there is an extra cast: In the 64bit case however, the vectorizer dumps show that the access-function returned for the index to array b is much more compilcated - the dataref analyzer doesn't seem to be able to extract the evolution/step in this case, and concludes that the access is non-consecutive: ... Ah yes, this was a well-known issue in the days long before vectorization ... In 1997, Richard Henderson hacked g77 to generate 64-bit array indices on 64-bit machines to prevent these casts, which inhibited all sorts of run-of-the-mill induction variable analysis ... This is probably quite invasive. Cheers, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM NN.
Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor? I believe most people do understand these sentences now that FX has kindly provided a translation The importance of gfortran as the HIRLAM consortium is conserned (http://hirlam.knmi.nl) is not that we would use it in an operational setting (i.e., compiling the operational suite with it - we normally use the vendor supplied compiler for that). However, what gfortran enables is HIRLAM research by everyone who can install a GNU/Linux or other free software distribution. One of the things people keep forgetting is that there are still Universities in Europe (or Asia, or Africa) for which the license cost of proprietary Fortran compilers is prohibitive. This translates directly into fewer capable meteorological researchers working on HIRLAM. HIRLAM is not free software - but other Weather Prediction Systems are. Look at http://www.wrf-model.org, for instance. My younger brother (working at Wageningen University in the Meteorology department) already filed a bug report for gfortran based on his experiments compiling that code. There will be more examples. Build it, and they will come ... Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
In the meanwhile, 1.3.0rc1 of SVN will become available ..
Ah, but which is the real one ? [TXT] md5sums.txt 26-Oct-2005 03:41 389 [TXT] sha1sums.txt26-Oct-2005 03:41 491 [ ] subversion-1.3.0-rc1..> 26-Oct-2005 03:42 4.7M [TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:42 189 [CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:43 6.1M [CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:43 189 [ ] subversion-1.3.0-rc1..> 26-Oct-2005 03:44 7.0M [TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:44 189 [ ] subversion-1.3.0-rc1..> 26-Oct-2005 03:45 6.5M [TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:45 189 [CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:47 8.3M [CMP] subversion-1.3.0-rc1..> 26-Oct-2005 03:47 189 [ ] subversion-1.3.0-rc1..> 26-Oct-2005 03:48 11M [TXT] subversion-1.3.0-rc1..> 26-Oct-2005 03:49 189 :-) -- Toon Moene, KNMI, The Netherlands Phone: +31 30 2206443; e-mail: [EMAIL PROTECTED]
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
Dorit wrote: It looks like maybe a 64bit scalar-evolution issue - when I compile on powerpc-linux with -m64, I also get the "vect4.f:4: note: not consecutive access" message. This problem looks very similar to PR18403 which has been resolved a while ago: When compiling for 32bit, we get the following representation for the loop: # i_2 = PHI ; :; D.505_38 = i_2 + -1; D.506_39 = (*b_14)[D.505_38]; (*a_9)[D.505_38] = D.506_39; i_41 = i_2 + 1; if (i_2 == D.489_27) goto ; else goto ; When compiling for 64bit, there is an extra cast: # i_2 = PHI ; :; D.691_41 = (int8) i_2; D.692_42 = D.691_41 + -1; D.693_43 = (*b_16)[D.692_42]; (*a_10)[D.692_42] = D.693_43; i_45 = i_2 + 1; if (i_2 == D.674_29) goto ; else goto ; Shouldn't the cast be hoisted out of the loop ? The cast of a loop invariant variable (i_2) is itself loop-invariant. Anyway, while we're waiting for Daniel to complete the cvs-svn transition, we can have some more fun with vectors: SUBROUTINE S(N) DIMENSION A(N), B(N) READ*,ISTART,ISTOP,B DO I = ISTART, ISTOP A(I) = B(I) ENDDO PRINT*,A END + /usr/snp/bin/gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f vect4.f:4: note: not vectorized: complicated access pattern. vect4.f:4: note: vectorized 0 loops in function. + /usr/snp/bin/gfortran -g -S -O3 -m32 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f vect4.f:4: note: LOOP VECTORIZED. vect4.f:4: note: vectorized 1 loops in function. That's what your experience with powerpc64 was too. SUBROUTINE S(N) DIMENSION A(N), B(12) COMMON /COM/ B DO I = 1, 12 A(I) = B(I) ENDDO PRINT*,A(1:12) END + /usr/snp/bin/gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect5.f vect5.f:4: note: LOOP VECTORIZED. vect5.f:4: note: vectorized 1 loops in function. + /usr/snp/bin/gfortran -g -S -O3 -m32 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect5.f vect5.f:4: note: LOOP VECTORIZED. vect5.f:4: note: vectorized 1 loops in function. Hmmm, this one is now also vectorised with -m64 - obviously a different problem. SUBROUTINE S(N) INTEGER N COMMON /COM/ A(100) REAL A REAL B(N), C(N), D(N) DO I = 1, N B(I) = D(I) ENDDO DO I = 1, N A(I) = B(I) ENDDO CALL S1(C(1)) END + /usr/snp/bin/gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 -ffixed-form vecta.f vecta.f:6: note: LOOP VECTORIZED. vecta.f:9: note: not vectorized: can't determine dependence between (*b_16)[D.928_30] and com.a[D.928_30] vecta.f:9: note: vectorized 1 loops in function. + /usr/snp/bin/gfortran -g -S -O3 -m32 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 -ffixed-form vecta.f vecta.f:6: note: LOOP VECTORIZED. vecta.f:9: note: LOOP VECTORIZED. vecta.f:9: note: vectorized 2 loops in function. But this one only works in 32 bits. I'm now going to try to compile HIRLAM with 32 bit pointers. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
I wrote: I'm now going to try to compile HIRLAM with 32 bit pointers. And ... here are the results: With 64-bit pointers: 2685 out of 9799 loops vectorized. With 32-bit pointers: 3269 out of 8854 loops vectorized. Why there are more loops in the 64-bit case is beyond my understanding - it's the same code base as I worked on with the 32-bit compilation ... Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
How do we retrieve wwwdocs from SVN ?
I might have missed something, but I can't find how to retrieve the - updateable - sources for wwwdocs. Please point me to the (in hindsight obvious) documentation ... Thanks, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
> I just read your contribution to the 2005 gcc summit about gfortran > and HIRLAM. The two PRs(18283 and 21034) you wrote about are now > fixed. LOC is now available. That just leaves some of the extra > functionality of FLUSH(IOSTAT?), does it not? Would it compile > completely if I were to add that functionality? I still have to construct a bug report of something that confuses the parser and that basically looks like this: IMPLICIT CHARACTER*8 (Y) CHARACTER*11 Y1, Y2, Y3 ... YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) // 1 // YB(1:5) 1 Unclassifiable statement at (1) Unfortunately, if I reduce the code to this one (continued) line and the necessary declarations, it doesn't fail ;-) All the other problems are with non-standard code (like flush, getarg, et al.), where I have to find standard-conforming solutions. Note that I'm used to the fact that with almost all OS/compiler combinations we have to make a few local mods, because different compilers support different extensions (not surprising ...) > Given the scale of your code, it would be a triumph worth reporting if > we could get it up and running with gfortran. Yep. I'm convinced that by the time we hold the 2006 GCC summit I can not only compile all of HIRLAM, but present a running example and profiled runs, to direct optimizations. Cheers, -- Toon Moene, KNMI, The Netherlands Phone: +31 30 2206443; e-mail: [EMAIL PROTECTED]
Re: Hard to tell which stage the build is at.
[ this is for debugging purposes - once libgcc moves to its own directory, we can change this ] And how about the plans to move the C frontend to its own directory ? [ grumpy lesser-frontend maintainer ] -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: gcc math functions for OpenMP vectoization
On 6/5/20 6:10 PM, Tobias Burnus wrote: On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote: It is glibc that provides them, not GCC. See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD Minor addition: That header file is included in math.h, i.e. automatically available. For Fortran/gfortran there is math-vector-fortran.h (also provided by glibc) which has the same functions and a similar effect. I wonder if there are Linux distributions where this actually effected already. I know for sure that it is not in Debian Testing (as of two weeks ago) and Red Hat Fedora 30 (similarly). Do you know of any ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: GCC / GFortran (9.3.0; Cygwin 64) Internal Compiler Error on NINT() Function
ave-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below). -> gfortran -save-temps -o nint_error.e *nint_error.f90* nint_error.f90:17:0: 17 | m=nint(y,i16) | internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:396 Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. (and with IDNINT()): -> gfortran -save-temps -o nint_error.e nint_error.f90 nint_error.f90:17:7: 17 | m=idnint(y,i16) | 1 Error: Too many arguments in call to ‘idnint’ at (1) Thanks for looking into this, Bernd (Eggen) PS Here a part of the output if omitting the "KIND" optional argument in NINT(): -> ./nint_error.e | & more i16= 16 1 1 1. 0 2 2 2. 1 3 4 4. 3 4 8 8. 7 [...] 31 1073741824 1073741824.000 1073741823 32 2147483648 2147483648.000 2147483647 33 4294967296 4294967296.000 *-1* As you can see, after 2^31-1 = 2147483647 it goes wrong and yields -1 If increasing the integer by 1, it goes wrong thus: [...] 2147483647 2147483647.000 2147483647 2147483648 2147483648.000 -2147483648 [...] -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: [patch, doc] Update people who can review gfortran patches
On 9/25/20 8:02 AM, Thomas Koenig via Fortran wrote: Hello world, for review of its patches, gfortran relies on a group of people who can approve patches. Unfortuntately, many of them are not active. Others, who have the capability and who have acted as de facto approvers (without anybody minding) are missing. This (somewhat overdue) patch rectifies that. It adds Tobias Burnus, Jakub Jelinek and Dominique d'Humieres to the list of people who can approve other people's patches in gfortran and libgfortran. Among the people who are currently acitive reviewers, there was unanimous consent that this should be done. I'm not 100% sure we need steering committee approval for this (Toon?), if so, I'd like to request it with this mail. Well, I would say, given the procedure you followed in asking relevant people for their consent and the fact that these are not names "out of the blue", I am convinced the steering committee would approve of this. If questions arise, I will take care of them. Thanks for your effort ! Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: GCC association with the FSF
On 4/14/21 6:18 PM, Jeff Law via Gcc wrote: On 4/14/2021 6:08 AM, Richard Biener via Gcc wrote: On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc wrote: N.B. Jeff is no longer @redhat.com so I've changed the CC On Wed, 14 Apr 2021 at 11:03, Thomas Koenig wrote: - All gfortran developers move to the new branch. This will not    happen, I can guarantee you that. This is the part I'm curious about (the rest is obvious, it follows >from there being finite resources and the nature of any fork). But I'm not going to press for reasons. Note the only viable fork will be on the current hosting (which isn't FSF controlled) with the downside of eventually losing the gcc.gnu.org DNS and thus a need to "switch" to a sourceware.org name. I strongly suspect you're right here. Ultimately if one fork reaches critical mass, then it survives and the other dies. That's a function of the developer community.  Right now I don't see the nightmare scenario of both forks being viable playing out -- however I'm more concerned now than I was before due Thomas's comments. When plans for the EGCS were underway, and the (then) Fortran supporters were into the plans, it scared the hell out of me, because it was completely unclear to me where it would end. But in the end: I am a supporter of Free Software, not a organization, or a person, but *developers* who support Free Software. That's what got me to go for the fork of EGCS - and I have not been disappointed. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Reduction Pattern ( Vectorization or Parallelization)
On 07/16/2015 12:53 PM, Richard Biener wrote:
On Sun, Jul 5, 2015 at 1:57 PM, Ajit Kumar Agarwal
For the following code
For(j = 0; j <= N;j++)
{
y = d[j];
For( I = 0 ; I <8 ; i++)
X(a[i]) = X(a[i]) + c[i] * y;
}
Fig(1).
I think the issue here is dependences of X(A[i]) as A[i] might be the same
for different i.
In Fortran this is not allowed on the left-hand side of an assignment.
Does C have any restrictions here ?
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Ubsan build of GCC 6.0 fails with: cp/search.c:1011:41: error: 'otype' may be used uninitialized in this function
See:
https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00699.html
Full error message:
/home/toon/compilers/trunk/gcc/cp/search.c: In function 'int
accessible_p(tree, tree, bool)':
/home/toon/compilers/trunk/gcc/cp/search.c:1011:41: error: 'otype' may
be used uninitialized in this function [-Werror=maybe-uninitialized]
dfs_accessible_data d = { decl, otype };
^
The host compiler is:
toon@moene:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-16'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-5 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20150903 (Debian 5.2.1-16)
Any ideas ?
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
What is guaranteed with the new numbering scheme of GCC releases ?
All, One of my colleagues on the Fortran Standardization Committee asked me the following question: "People are still not too familiar with the new GCC numbering scheme. My impression is that 5.2 is just a maintenance update of 5.1. However, they still want assurance that there are no call interface or module format changes between 5.1 and 5.2 so that libraries and modules built with 5.1 (MPI, for example) will still work with 5.2. Is that the case?" I went to https://gcc.gnu.org/develop.html#num_scheme for answering that question, but it is by far not explicit enough to answer it. Shouldn't we be documenting the shift in numbering schematics on a far more obvious location on our web site, and with more complete semantics ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LLVM to get massive GPU support with Fortran
On 11/16/2015 12:58 AM, Steve Kargl wrote: On Mon, Nov 16, 2015 at 12:04:06AM +0100, Thomas Koenig wrote: See http://arstechnica.com/information-technology/2015/11/llvm-to-get-fortran-compiler-that-targets-parallel-gpus-in-clusters/ It is not entirely clear on what they plan to do. Use gfortran via dragonegg? The 3 DOE labs in the USA have contracted PGI to port (some of) there Fortran FE to LLVM and open source the result. http://lists.llvm.org/pipermail/llvm-dev/2015-November/092404.html To put this in a (timeline) perspective: On the 18th of March, 2000, I announced Andy Vaught's work on the g95 front-end to the gcc-patches mailing list. In 2004 (!) we merged the resulting compiler and run-time library into the gcc (cvs) repository (obviously, after the tree-ssa infrastructure went in - 2004-05-17, but before the creation of the 4.0 release branch - 2005-02-25). Then it took another 2 months for 4.0 to be released. Unless PGI manages to summon massively large (parallel) working groups to accomplish this, it might take a few years to fruition. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LLVM to get massive GPU support with Fortran
On 11/16/2015 10:11 PM, Jack Howarth wrote: On Mon, Nov 16, 2015 at 2:14 PM, Toon Moene wrote: To put this in a (timeline) perspective: On the 18th of March, 2000, I announced Andy Vaught's work on the g95 front-end to the gcc-patches mailing list. In 2004 (!) we merged the resulting compiler and run-time library into the gcc (cvs) repository (obviously, after the tree-ssa infrastructure went in - 2004-05-17, but before the creation of the 4.0 release branch - 2005-02-25). Then it took another 2 months for 4.0 to be released. Unless PGI manages to summon massively large (parallel) working groups to accomplish this, it might take a few years to fruition. On the other hand, the llvm-dev posting implies that PGI will be starting from an existing fortran front-end. If they only need to code the middle-/back-end integration of llvm into a pre-existing mature fortran front-end, the promised late 2016 release date might not be so unlikely. The g95 front-end I mentioned in my 2000-03-18 post to the gcc-patches mailing list was "an existing front-end" by virtue of the fact that Andy Vaught mailed it to me and it did the work. Between 2000 and 2004, this front-end was coupled to the rest of the infrastructure of the GNU Compiler Collection. This was not trivial (just as it will not be trivial to couple the PGI front-end to the LLVM infrastructure). We'll see how many years it'll take, but don't count me in on holding my breath. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LLVM to get massive GPU support with Fortran
On 11/16/2015 10:33 PM, Jack Howarth wrote: Of course one unknown is whether PGI had already done any work internally with the llvm middle-/back-end. If so, they might not be starting from scratch. Perhaps it helps if I repost the following from 12 years ago: https://gcc.gnu.org/ml/fortran/2003-11/msg00052.html Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LLVM to get massive GPU support with Fortran
On 11/16/2015 11:02 PM, Jack Howarth wrote: FYI, this posting has a bit more detail on the actual implementation... http://lists.llvm.org/pipermail/llvm-dev/2015-November/092438.html That surely helps - thanks. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
GNU C library's libmvec and the GNU Compiler *Collection*.
All,
I noticed, around half a year ago, that the incredible team around glibc
found the time to implement vector math (libm) routines.
Previously, free software adherents like me were dependent on vendor
libraries via the -mveclibabi={svml|acml} (on Intel/AMD) for instance.
However, the examples given on the glibc wiki
(https://sourceware.org/glibc/wiki/libmvec, Example 1/Example 2) suggest
that this is a C-only thing (this might make sense given that glibc is
an implementation of the *C* library), but the above vendor-level
options at least work for every front-end language, as far as I know.
Would it be possible to add an option -mveclibabi=glibc to cater for
this *for all languages*; or is this too low level (after all, the glibc
libmvec has code for multiple architectures). If so, at what level
should this be implemented ?
[ This is relevant for our code, because just the switch to *actual*
single precision exp/log/sin/cos implementations in glibc's libm
resulted in a decrease of the running time of our weather forecasting
code by 25 % (this was in glibc 2.16, IIRC). ]
Thanks in advance for your suggestions.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: GNU C library's libmvec and the GNU Compiler *Collection*.
On 01/06/2016 07:46 PM, Toon Moene wrote: [ This is relevant for our code, because just the switch to *actual* single precision exp/log/sin/cos implementations in glibc's libm resulted in a decrease of the running time of our weather forecasting code by 25 % (this was in glibc 2.16, IIRC). ] The reference for this is (on an Ivy Bridge system): https://gcc.gnu.org/ml/gcc-help/2013-01/msg00175.html "I have made a home-build glibc-2.17 (on a core-avx system). It works great - linking against it (instead of using the current Debian-Testing's eglibc-2.13) brought the wall-clock time of my weather forecasting job down from 3:35 hours to 2:45 (mostly due to a more efficient implementation of powf, expf and logf)." So, in minutes of compute time: This is (215-165) / 215 = 0.23 (23 %). However, that number included a part that ran for an hour (60 minutes) in double precision. Excluding that we get (155 - 105) / 155 = 0.32 (32 %) improvement in performance for the single precision part of our weather forecasting code. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: GNU C library's libmvec and the GNU Compiler *Collection*.
On 01/06/2016 07:46 PM, Toon Moene wrote:
Would it be possible to add an option -mveclibabi=glibc to cater for
this *for all languages*; or is this too low level (after all, the glibc
libmvec has code for multiple architectures). If so, at what level
should this be implemented ?
It doesn't look hard to implement this as a variant of
-mveclibabi={svml|acml}.
The implementation of these options is in config/i386/i386.c:
5272 /* Use external vectorized library in vectorizing intrinsics. */
5273 if (opts_set->x_ix86_veclibabi_type)
5274 switch (opts->x_ix86_veclibabi_type)
5275 {
5276 case ix86_veclibabi_type_svml:
5277 ix86_veclib_handler = ix86_veclibabi_svml;
5278 break;
5279
5280 case ix86_veclibabi_type_acml:
5281 ix86_veclib_handler = ix86_veclibabi_acml;
5282 break;
5283
5284 default:
5285 gcc_unreachable ();
5286 }
so I could just write a third "handler":
case ix86_veclibabi_type_glibc:
ix86_veclib_handler = ix86_veclibabi_glibc;
and clone, say, ix86_veclibabi_svml to write ix86_veclibabi_glibc to do
the right thing for generating calls to the glibc libmvec routines.
I hope to have time for this during the summer. As this is stage 1
material anyway, that looks like the right point in time anyway.
Of course, a more general, architecture independent approach might be
preferable, but this at least would be a start.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: [isocpp-parallel] Proposal for new memory_order_consume definition
On 02/28/2016 05:13 PM, Linus Torvalds wrote: Yeah, let's just say that the original C designers were better at their job than a gaggle of standards people who were making bad crap up to make some Fortran-style programs go faster. The original C designers were defining a language that would make it easy to write operating systems in (and not having to rely on assembler). I misled the quote where they said they first tried Fortran (and concluded it didn't fit their purpose). BTW, Fortran was designed around floating point arithmetic (and its non-relation to the mathematical concept of the field of the reals). It used integers only for counting and indexing arrays, so it had no purpose for "signed integers that overflowed". Therefore, to the Fortran standard, this was "undefined". It was literally "undefined" - as it was not described by the standard's text. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Deprecating basic asm in a function - What now?
On 07/04/2016 03:43 PM, Jonathan Wakely wrote: On 22 June 2016 at 10:28, David Wohlferd wrote: And I *get* that it takes time to re-write this, and people have schedules, lives, a need for sleep. But even under the most insanely aggressive schedule I can imagine (if gcc continue to release ~1/year), it will be at least a year before there's a release that has the (disable-able) warning, and another year before we could even think about actually removing this. So someone who plans to use v8.0 in their production code on the day it is released still has a minimum of *two years* to get ready. It doesn't matter how much warning people have to fix such things, most of them won't do it. Then at the last minute some poor person has to spend days or weeks going through other people's code fixing all the problems. If the benefit isn't clear then it's just a pain and causes wailing and gnashing of teeth. We had at least 15 years of warning ahead of the Y2K problem. Nevertheless, it was only fixed in our code during March-September 1999. Or, as one of my colleagues quipped: The next time, they can ask someone else for this job. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: GCC 7.0.0 Status Report (2016-10-21)
On 10/21/2016 03:46 PM, Jakub Jelinek wrote: Status == Trunk which will eventually become GCC 7 is still in Stage 1 but its end is near and we are planning to transition into Stage 3 starting Nov 13th end of day time zone of your choice. Note that I haven't found the time to implement the vectorization of log/exp/sin/cos/tan functions that I described here: https://gcc.gnu.org/ml/gcc/2016-01/msg00039.html Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: GCC 7.0.0 Status Report (2016-10-21)
On 10/25/2016 10:16 AM, Richard Biener wrote: On Mon, Oct 24, 2016 at 10:20 PM, Toon Moene wrote: Note that I haven't found the time to implement the vectorization of log/exp/sin/cos/tan functions that I described here: https://gcc.gnu.org/ml/gcc/2016-01/msg00039.html It works transparently already if you have recent glibc which adds the appropriate attribute to the math function prototypes (basically one release after the release that first implemented the routines though the required patch is trivial to backport as well). But that is for code that read math function prototypes in C style .h files - so not for Fortran or Ada. That was the purpose of my proposal: to treat glibc vectorized log/exp/sin/cos/tan functions like the vendor specific once (-mveclibabi=svml and -mveclibabi=acml), which is front end language agnostic. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: GCC 7.0.0 Status Report (2016-10-21)
On 10/26/2016 11:24 AM, Richard Biener wrote: On Tue, Oct 25, 2016 at 9:41 PM, Toon Moene wrote: But that is for code that read math function prototypes in C style .h files - so not for Fortran or Ada. That was the purpose of my proposal: to treat glibc vectorized log/exp/sin/cos/tan functions like the vendor specific once (-mveclibabi=svml and -mveclibabi=acml), which is front end language agnostic. Ah, indeed. Not sure if I would go the -mveclibabi route though as the glibc implementation is basically OpenMP-SIMD. The list of "vectorized" functions may also depend on glibc version and target so maybe glibc can ship something like a fortran math module which gfortran can include transparently? Like we have the predefs header in C? That is, glibc needs a way to communicate its configuration to fortran... (not sure if a GCC configure time config would be good enough) OK, I still went with the apparent "go-ahead" as worded in https://gcc.gnu.org/ml/gcc/2016-01/msg00045.html but I agree I should test this more vis-a-vis the OpenMP-SIMD approach and whether it can be done as a -mveclibabi adaptation. Anyway - far too late for the GCC-7 effort ... Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
ICE on using -floop-nest-optimize
On the attached (Fortran) source, the following version of gfortran draws an ICE: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.1-5' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.2.1 20161124 (Debian 6.2.1-5) using the following command line arguments: gfortran -S -g -Ofast -fprotect-parens -fbacktrace -march=native -mtune=native -floop-nest-optimize corr_to_spec_2D.F The error message is: corr_to_spec_2D.F:3:0: subroutine corr_to_spec_2D(nx_local,ny_local, internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:445 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. I will retry this with trunk gfortran as soon as my automatic builds have constructed that compiler. In the mean time - anyone has a clue ? Thanks, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news c Library: hljb $Id: corr_to_spec_2D.F 8416 2010-09-08 08:52:33Z ovignes $ c subroutine corr_to_spec_2D(nx_local,ny_local, xny_global, xnxl_global,nyl_global, xkmax_local, xkmax_global,lmax_global, xmype,nproc,nydim,kdim, xlmaxe, xjmin_list,ny_list, xkmin_list,kmax_list, xlevmin_list,levmax_list, xgridsize,lscale, xspec_dens_2D, corr_index) c implicit none c c--- c integer nx_local,ny_local, xny_global, xnxl_global,nyl_global, xkmax_local, xkmax_global,lmax_global, xmype,nproc,nydim,kdim, xlmaxe(0:kmax_local), xjmin_list(nproc),ny_list(nproc), xkmin_list(nproc),kmax_list(nproc), xlevmin_list(0:kdim,nproc), xlevmax_list(0:kdim,nproc) real gridsize,lscale real x spec_dens_2D(-lmax_global:lmax_global,0:kmax_local) integer corr_index c c--- c c Local work space c integer nextended,kextended,i,j,j_global,jlev,k,l,kwave real dist,dx,dy, sum_spec real, allocatable ::corr_extended(:,:,:) complex, allocatable :: spec_corr(:,:) c complex spec_dens_cmpx(-lmax_global:lmax_global,0:kmax_local) real phys_corr_appr(nx_local,ny_local) real phys_corr_orig(nx_local,ny_local) c real spec_eps parameter (spec_eps = 0.01) c c--- c c Allocate space for correlation in physical space c including extension zone and in spectral space c nextended = nyl_global/ny_global+1 if (mype.eq.1) write(6,*)' nextended=',nextended allocate(corr_extended(nxl_global,ny_local,nextended)) allocate(spec_corr(-lmax_global:lmax_global,0:kmax_local)) c c--- c c Construct correlation in physical space call corr_ext( nextended, nxl_global, xny_local,ny_global,nyl_global, x gridsize, lscale, xcorr_extended, corr_index, xmype,nproc,jmin_list ) c
Re: ICE on using -floop-nest-optimize
On 01/06/2017 03:28 PM, Kyrill Tkachov wrote: On 06/01/17 14:22, Toon Moene wrote: On the attached (Fortran) source, the following version of gfortran draws an ICE: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.1-5' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.2.1 20161124 (Debian 6.2.1-5) using the following command line arguments: gfortran -S -g -Ofast -fprotect-parens -fbacktrace -march=native -mtune=native -floop-nest-optimize corr_to_spec_2D.F The error message is: corr_to_spec_2D.F:3:0: subroutine corr_to_spec_2D(nx_local,ny_local, internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:445 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. I will retry this with trunk gfortran as soon as my automatic builds have constructed that compiler. In the mean time - anyone has a clue ? Looks like PR 69823 ? Yep - thanks. So I don't have to put it into Bugzilla - even if the trunk still fails. Saves some work - thanks again ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
ubsan bootstrap on x86_64 trunk rev. 210310: summary of results (BRRR):
This was the configure command: configure flags: --prefix=/home/toon/compilers/install --with-gnu-as --with-gnu-ld --with-build-config=bootstrap-ubsan --enable-languages=all --disable-multilib --disable-nls --with-arch=core-avx2 --with-tune=core-avx2 Here are the numbers: === gcc Summary === # of expected passes108884 # of unexpected failures442 === gfortran Summary === # of expected passes45221 # of unexpected failures565 === g++ Summary === # of expected passes86975 # of unexpected failures1012 See: http://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00845.html -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Reducing Register Pressure through Live range Shrinking through Loops!!
On 05/22/2014 10:16 PM, Vladimir Makarov wrote: It also permits to rematerialize not only on loop borders (although it is the most important points). That would certainly be interesting for the following hot subroutine in our weather forecasting model (attached). Note the loop from (line 157): +IF (KINT.EQ.3) THEN C CUBIC INTERPOLATION to (line 242): + + PALFA(JX,JY,4)*PARG(IDX+1,IDY+1,ILEV+1) ) ) ENDDO ENDDO Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news # 1 "/scratch/hirlam/hl_home/MPI/lib/src/grdy/verint.F" # 1 "" # 1 "" # 1 "/scratch/hirlam/hl_home/MPI/lib/src/grdy/verint.F" c Library:grdy $RCSfile$, $Revision: 7536 $ c checked in by $Author: ovignes $ at $Date: 2009-12-18 14:23:36 +0100 (Fri, 18 Dec 2009) $ c $State$, $Locker$ c $Log$ c Revision 1.3 1999/04/22 09:30:45 DagBjoerge c MPP code c c Revision 1.2 1999/03/09 10:23:13 GerardCats c Add SGI paralllellisation directives DOACROSS c c Revision 1.1 1996/09/06 13:12:18 GCats c Created from grdy.apl, 1 version 2.6.1, by Gerard Cats c SUBROUTINE VERINT ( I KLON , KLAT , KLEV , KINT , KHALO I , KLON1 , KLON2 , KLAT1 , KLAT2 I , KP , KQ , KR R , PARG , PRES R , PALFH , PBETH R , PALFA , PBETA , PGAMA ) C C*** C C VERINT - THREE DIMENSIONAL INTERPOLATION C C PURPOSE: C C THREE DIMENSIONAL INTERPOLATION C C INPUT PARAMETERS: C C KLON NUMBER OF GRIDPOINTS IN X-DIRECTION C KLAT NUMBER OF GRIDPOINTS IN Y-DIRECTION C KLEV NUMBER OF VERTICAL LEVELS C KINT TYPE OF INTERPOLATION C= 1 - LINEAR C= 2 - QUADRATIC C= 3 - CUBIC C= 4 - MIXED CUBIC/LINEAR C KLON1 FIRST GRIDPOINT IN X-DIRECTION C KLON2 LAST GRIDPOINT IN X-DIRECTION C KLAT1 FIRST GRIDPOINT IN Y-DIRECTION C KLAT2 LAST GRIDPOINT IN Y-DIRECTION C KPARRAY OF INDEXES FOR HORIZONTAL DISPLACEMENTS C KQARRAY OF INDEXES FOR HORIZONTAL DISPLACEMENTS C KRARRAY OF INDEXES FOR VERTICAL DISPLACEMENTS C PARG ARRAY OF ARGUMENTS C PALFH ALFA HAT C PBETH BETA HAT C PALFA ARRAY OF WEIGHTS IN X-DIRECTION C PBETA ARRAY OF WEIGHTS IN Y-DIRECTION C PGAMA ARRAY OF WEIGHTS IN VERTICAL DIRECTION C C OUTPUT PARAMETERS: C C PRES INTERPOLATED FIELD C C HISTORY: C C J.E. HAUGEN 1 1992 C C*** C IMPLICIT NONE C INTEGER KLON , KLAT , KLEV , KINT , KHALO, IKLON1 , KLON2 , KLAT1 , KLAT2 C INTEGER KP(KLON,KLAT), KQ(KLON,KLAT), KR(KLON,KLAT) REALPARG(2-KHALO:KLON+KHALO-1,2-KHALO:KLAT+KHALO-1,KLEV) , RPRES(KLON,KLAT) , R PALFH(KLON,KLAT) , PBETH(KLON,KLAT) , R PALFA(KLON,KLAT,4) , PBETA(KLON,KLAT,4), R PGAMA(KLON,KLAT,4) C INTEGER JX, JY, IDX, IDY, ILEV REAL Z1MAH, Z1MBH C IF (KINT.EQ.1) THEN C LINEAR INTERPOLATION C DO JY = KLAT1,KLAT2 DO JX = KLON1,KLON2 IDX = KP(JX,JY) IDY = KQ(JX,JY) ILEV = KR(JX,JY) C PRES(JX,JY) = PGAMA(JX,JY,1)*( C + PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV-1) + + PALFA(JX,JY,2)*PARG(IDX ,IDY-1,ILEV-1) ) + + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY ,ILEV-1) + + PALFA(JX,JY,2)*PARG(IDX ,IDY ,ILEV-1) ) ) C+ + + PGAMA(JX,JY,2)*( C+ + PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV ) + + PALFA(JX,JY,2)*PARG(IDX ,IDY-1,ILEV ) ) + + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY ,ILEV ) + + PALFA(JX,JY,2)*PARG(IDX ,IDY ,ILEV ) ) ) ENDDO ENDDO C ELSE +IF (KINT.EQ.2) THEN C QUADRATIC INTERPOLATION C DO JY = KLAT1,KLAT2 DO JX = KLON1,KLON2 IDX = KP(JX,JY) IDY = KQ(JX,JY) ILEV = KR(JX,JY) C PRES(JX,JY) = PGAMA(JX,JY,1)*( C + PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV-1) + + PALFA(JX,JY,2)*PARG(IDX ,IDY-1,ILEV-1) + + PALFA(JX,JY,3)*PARG(IDX+1,IDY-1,ILEV-1) ) + + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY ,ILEV-1) + + PALFA(JX,JY,2)*PARG(IDX ,IDY ,ILEV-1) + + PALFA(JX,JY,3)*PARG(IDX+1,IDY ,ILEV-1) ) + + PBETA(JX,JY,3)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY+1,ILEV-1) + + PALFA(JX,JY,2)*PARG(IDX ,IDY+1,ILEV-1) + + PALFA(JX,JY,3)*PARG(IDX+1,IDY+1,ILEV-1) ) ) C+
Got this one back (too large: 6.4 Mb) from gcc-results:
Compiler version: 4.10.0 20140702 (experimental) (GCC) Platform: x86_64-unknown-linux-gnu configure flags: --prefix=/home/toon/compilers/install --with-gnu-as --with-gnu-ld --with-build-config=bootstrap-ubsan --enable-languages=all --disable-multilib --disable-nls --with-arch=core-avx2 --with-tune=core-avx2 Note: --with-build-config=bootstrap-ubsan Apparently, the bugs went wild ... Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Got this one back (too large: 6.4 Mb) from gcc-results:
On 07/03/2014 07:11 PM, Marek Polacek wrote: On Thu, Jul 03, 2014 at 07:06:29PM +0200, Toon Moene wrote: Compiler version: 4.10.0 20140702 (experimental) (GCC) Platform: x86_64-unknown-linux-gnu configure flags: --prefix=/home/toon/compilers/install --with-gnu-as --with-gnu-ld --with-build-config=bootstrap-ubsan --enable-languages=all --disable-multilib --disable-nls --with-arch=core-avx2 --with-tune=core-avx2 Note: --with-build-config=bootstrap-ubsan Apparently, the bugs went wild ... I suspect that's because: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01549.html which will go away if/when we fix: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01624.html But I'm only guessing. Thanks - we will see. This is the schedule of test runs here at home: "branch"boot-config languages $ crontab -l 45 00 * * 0 $HOME/BootstrapGCC trunk lto all 45 00 * * 1 $HOME/BootstrapGCC fortran-dev lto fortran 45 00 * * 2 $HOME/BootstrapGCC trunk "asan --disable-werror" all 45 00 * * 3 $HOME/BootstrapGCC fortran-dev "asan --disable-werror" fortran 45 00 * * 4 $HOME/BootstrapGCC trunk ubsan all 45 00 * * 5 $HOME/BootstrapGCC fortran-dev ubsan fortran 45 00 * * 6 $HOME/BootstrapGCC trunk ubsan fortran So the next test with bootstrap-config=ubsan is on Saturday, at 00:45 CEST - see if your fix can beat that :-) Kind regards, and thanks for the explanation ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
LTO detects violations of one-definition-rule ?
Like this (https://gcc.gnu.org/ml/gcc-testresults/2014-09/msg01374.html): /home/toon/compilers/trunk/gcc/tlink.c:62:16: error: type 'struct file_hash_entry' violates one definition rule [-Werror=odr] typedef struct file_hash_entry ^ /home/toon/compilers/trunk/libcpp/files.c:143:8: note: a different type is defined in another translation unit struct file_hash_entry ^ /home/toon/compilers/trunk/gcc/tlink.c:64:15: note: the first difference of corresponding definitions is field 'key' const char *key; ^ /home/toon/compilers/trunk/libcpp/files.c:145:27: note: a field with different name is defined in another translation unit struct file_hash_entry *next; ^ -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: msan and gcc ?
On 10/01/2014 06:21 PM, VandeVondele Joost wrote: 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. That would be interesting - valgrind is certainly impossible to use on our Weather Forecasting code (far too large, as valgrind helpfully points out). -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: msan and gcc ?
On 10/01/2014 08:00 PM, Kostya Serebryany wrote: -gcc folks. Why not use clang then? It offers many more nice features. What's the Fortran front-end called for clang (or do you really think we are going to write Weather Forecasting codes in C :-) ) Kind regards, On Wed, Oct 1, 2014 at 10:58 AM, Toon Moene wrote: On 10/01/2014 06:21 PM, VandeVondele Joost wrote: 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. That would be interesting - valgrind is certainly impossible to use on our Weather Forecasting code (far too large, as valgrind helpfully points out). -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Bootstrap with Ada and bootstrap-config=ubsan fails because gnatlink is not linked against ubsan.
This: https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg01552.html fails because: /home/toon/compilers/trunk/libiberty/xstrdup.c:33: undefined reference to `__ubsan_handle_nonnull_arg' /home/toon/compilers/trunk/libiberty/xstrdup.c:35: undefined reference to `__ubsan_handle_nonnull_arg' /home/toon/compilers/trunk/libiberty/xstrdup.c:35: undefined reference to `__ubsan_handle_nonnull_arg' /home/toon/compilers/trunk/libiberty/xstrdup.c:35: undefined reference to `__ubsan_handle_nonnull_return' /home/toon/compilers/trunk/libiberty/xstrdup.c:35: undefined reference to `__ubsan_handle_nonnull_arg' collect2: error: ld returned 1 exit status ../gcc-interface/Makefile:2585: recipe for target '../../gnatlink' failed make[3]: *** [../../gnatlink] Error 1 Kind regards, -- Toon Moene, KNMI (Weer/Onderzoek), The Netherlands Phone: +31 30 2206443; e-mail: mo...@knmi.nl
Hmm, /sbin/ldconfig.real: /home/toon/compilers/install/lib/../lib64/libstdc++.so.6.0.21-gdb.py is not an ELF file - it has the wrong magic bytes at the start.
On the gcc-results archive, you'll see this:
https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02983.html
but that doesn't show you the real problem:
mkdir -p -- /home/toon/compilers/install/share/gcc-5.0.0/python/libjava
libtool: install: /usr/bin/install -c .libs/libgcj-tools.so.15.0.0T
/home/toon/compilers/install/lib/../lib64/libgcj-tools.so.15.0.0
libtool: install: (cd /home/toon/compilers/install/lib/../lib64 && { ln
-s -f libgcj-tools.so.15.0.0 libgcj-tools.so.15 || { rm -f
libgcj-tools.so.15
&& ln -s libgcj-tools.so.15.0.0 libgcj-tools.so.15; }; })
libtool: install: (cd /home/toon/compilers/install/lib/../lib64 && { ln
-s -f libgcj-tools.so.15.0.0 libgcj-tools.so || { rm -f libgcj-tools.so
&& ln
-s libgcj-tools.so.15.0.0 libgcj-tools.so; }; })
libtool: install: /usr/bin/install -c .libs/libgcj-tools.lai
/home/toon/compilers/install/lib/../lib64/libgcj-tools.la
libtool: install: /usr/bin/install -c install/.libs/libgcj_bc.so.1.0.0
/home/toon/compilers/install/lib/../lib64/libgcj_bc.so.1.0.0
libtool: install: (cd /home/toon/compilers/install/lib/../lib64 && { ln
-s -f libgcj_bc.so.1.0.0 libgcj_bc.so.1 || { rm -f libgcj_bc.so.1 && ln
-s libgcj_bc.so.1.0.0 libgcj_bc.so.1; }; })
libtool: install: (cd /home/toon/compilers/install/lib/../lib64 && { ln
-s -f libgcj_bc.so.1.0.0 libgcj_bc.so || { rm -f libgcj_bc.so && ln -s
libgcj_bc.so.1.0.0 libgcj_bc.so; }; })
libtool: install: /usr/bin/install -c install/.libs/libgcj_bc.lai
/home/toon/compilers/install/lib/../lib64/libgcj_bc.la
libtool: finish:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin"
ldconfig -n /home/toon/compilers/install/lib/../lib64
/sbin/ldconfig.real:
/home/toon/compilers/install/lib/../lib64/libstdc++.so.6.0.21-gdb.py is
not an ELF file - it has the wrong magic bytes at the start.
Well, you betcha a python script is not an ELF file - but why does the
build process think so ?
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
More explicit what's wrong with this: FAILED: Bootstrap (build config: lto; languages: all; trunk revision 217898) on x86_64-unknown-linux-gnu
See: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02259.html What's not in the log file sent to gcc-results: /usr/bin/ld: /dev/shm/wd4296/ccFei5Gg.ltrans0.ltrans.o: relocation R_X86_64_32S against `prime_tab.lto_priv.2' can not be used when making a shared o bject; recompile with -fPIC /dev/shm/wd4296/ccFei5Gg.ltrans0.ltrans.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:409: recipe for target 'libcc1.la' failed make[3]: *** [libcc1.la] Error 1 Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Named parameters
On 03/16/2015 05:06 PM, David Brown wrote:
Basically, the idea is this:
int foo(int a, int b, int c);
void bar(void) {
foo(1, 2, 3); // Normal call
foo(.a = 1, .b = 2, .c = 3) // Same as foo(1, 2, 3)
foo(.c = 3, .b = 2, .a = 1) // Same as foo(1, 2, 3)
}
If only the first variant is allowed (with the named parameters in the
order declared in the prototype), then this would not affect code
generation at all - the designators could only be used for static error
checking.
If the second variant is allowed, then the parameters could be re-ordered.
This is indeed very useful - Fortran has this since the Fortran 90
standard, albeit without the dots (it's unambiguous in Fortran).
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
trunk revision 221714 gets segfault during lto bootstrap.
As is shown here: https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg03014.html. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: lto bootstrap fails.
On 04/11/2015 01:33 AM, Jan Hubicka wrote: On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like this: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html ODR rears its head again ... huh, why is c/c-lang.h getting included in files linked into cc1plus? that seems strange. readelf -wl cc1plus | grep c-lang.h doesn't show anything. I tried to reproduce it and my bootstrap passes with same options as Toon's The following patch ought to be able to tell the particular translation unit causing the conflict. [ Patch elided ] The patch applied cleanly - this is what I got as a result: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html I hope this is useful. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: lto bootstrap fails.
On 04/13/2015 06:00 PM, Trevor Saunders wrote: On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: On 04/11/2015 01:33 AM, Jan Hubicka wrote: On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like this: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html ODR rears its head again ... huh, why is c/c-lang.h getting included in files linked into cc1plus? that seems strange. readelf -wl cc1plus | grep c-lang.h doesn't show anything. I tried to reproduce it and my bootstrap passes with same options as Toon's The following patch ought to be able to tell the particular translation unit causing the conflict. [ Patch elided ] The patch applied cleanly - this is what I got as a result: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html I hope this is useful. ok, so the problem would seem to be graphite-scop-detection.c is including front end specific headers. Can you put a #error in cp-tree.h and recompile graphite-scop-detection.o to see what the path to including it is? Trev I get this: In file included from /home/toon/compilers/trunk/gcc/graphite-scop-detection.c:73:0: /home/toon/compilers/trunk/gcc/cp/cp-tree.h:52:2: error: #error #error ^ (See https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01493.html) -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
LTO bootstrap failure for GCC-5 prerelease.
See: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-uninit.o differs gcc/tree-switch-conversion.o differs gcc/tree-ssa-loop-ivcanon.o differs ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LTO bootstrap failure for GCC-5 prerelease.
On 04/17/2015 10:49 AM, Richard Biener wrote: On Fri, Apr 17, 2015 at 10:16 AM, Toon Moene wrote: See: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-uninit.o differs gcc/tree-switch-conversion.o differs gcc/tree-ssa-loop-ivcanon.o differs With LTO bootstrap you run into PR62077, can you try the workaround, --enable-stage1-checking=release? Richard. Yep, that worked: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02034.html Thanks, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Loop fusion.
L.S., Last week, a colleague of mine from Meteo France held a talk at the yearly meeting of all researchers working on HARMONIE (see http://hirlam.org) discussing the performance of our code when compiled with each of the supported compilers on the Cray XC30 at ECMWF (http://www.ecmwf.int/en/computing/our-facilities). In the context of GCC this is relevant, because one of the three compilers is gfortran (version 4.9.2). One of his slides discussed the differences in optimizations that the three compilers offer; I was surprised to learn that GCC/gfortran doesn't do loop fusion *at all*. Note, I discussed loop fusion (among other optimizations) at LinuxExpo 99 (http://moene.org/~toon/nwp.ps) which, unsurprisingly, was held 16 years ago :-) Why is loop fusion important, especially in Fortran 90 and later programs ? Because without it, every array assignment is a single loop nest, isolated from related, same-shape assignments. Consider this (artificial, but typical) example [updating atmospheric quantities after the computation of the rate of change during a time step of the integration]: SUBROUTINE UPDATE_DT(T, U, V, Q, DTDT, DUDT, DVDT, DQDT, & & NLON, NLAT, NLEV, TSTEP) ... REAL, DIMENSION(NLON, NLAT, NLEV) :: T, U, V, Q, DTDT, DUDT, DVDT, DQDT ... T = T + TSTEP*DTDT ! Update temperature U = U + TSTEP*DUDT ! Update east-west wind component V = V + TSTEP*DVDT ! Update north-south wind component Q = Q + TSTEP*DQDT ! Update specific humidity ... END This generates four consecutive 3 deep loop nests over NLEV, NLAT, NLON. Of course, it would be much more efficient if this were just one loop nest, as Fortran 77 programmers would write it: DO JLEV = 1, NLEV DO JLAT = 1, NLAT DO JLON = 1, NLON T(JLON, JLAT, JLEV) = T(JLON, JLAT, JLEV) + TSTEP*DTDT(JLON, JLAT, JLEV) U(JLON, JLAT, JLEV) = U(JLON, JLAT, JLEV) + TSTEP*DUDT(JLON, JLAT, JLEV) V(JLON, JLAT, JLEV) = V(JLON, JLAT, JLEV) + TSTEP*DVDT(JLON, JLAT, JLEV) Q(JLON, JLAT, JLEV) = Q(JLON, JLAT, JLEV) + TSTEP*DQDT(JLON, JLAT, JLEV) ENDDO ENDDO ENDDO After a loop fusion optimization pass the Fortran 90 and the Fortran 77 code should result in the same assembler output. Is this something the Graphite infrastructure could help with ? From the wiki documentation I get the impression that it only works on single loop nests, but I must confess that I am not familiar with the nomenclature in its description ... Would it be hard to write a loop fusion pass otherwise ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Loop fusion.
On 04/22/2015 09:10 PM, Steven Bosscher wrote: On Wed, Apr 22, 2015 at 6:59 PM, Toon Moene wrote: Why is loop fusion important, especially in Fortran 90 and later programs ? Because without it, every array assignment is a single loop nest, isolated from related, same-shape assignments. Why is this a bad thing? When you're talking about single-node machines, separate loops is probably faster if your arrays are large enough: better cache locality and easier to vectorize. Loop fusion is only a win if you iterate through the same array variables. Writing such a pass is not so hard for the simple, most common cases. The front end could do some of the rewriting from F90-style array assignments to fused loops if it notices consecutive array assignments/operations on the same variables. It could well be that my artificial example was not what my colleague measured ... Indeed, I thought about the front end doing this, but that would limit it to those that the front end could recognize; on the other hand, that might be the right limitation. Thanks ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Large Fortran program succesfully LTO'd.
Honza, At the Cauldron meeting last week I mentioned that I wasn't able to compile our "small" weather forecasting program with LTO. In the mean time I have read some bug reports with "multiple prevailing ..." errors, which made me try linking with the 'gold' linker - that worked. So the only things building the software that I changed were adding -flto and -fuse-ld=gold. Some statistics of the source code: 3902 files totaling 1081944 lines. The result works flawlessly. Over the weekend I will study the LTO diagnostics to see what decisions were made with respect to inlining and other optimizations. Thanks ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: On-Demand range technology [3/5] - The Prototype
On 5/24/19 12:27 AM, Eric Botcazou wrote: There are a couple of testcases in the testsuite that, I believe, require a minimal form of support for symbolic ranges: gcc.dg/tree-ssa/vrp94.c and gnat.dg/opt40.adb. They deal with the following pattern in C: if (x >= y) return 1; z = y - x; if (z <= 0) abort (); return z; where we want to eliminate the abort. Of course the C version doesn't really make sense on its own, but it's the translation of the Ada version where the if (z <= 0) abort (); is generated by the compiler (it's a range check in Ada parlance). I bet compiling anything Fortran-y with array bound checking on (-fbounds-check) would generate ginormous numbers of opportunities for symbolic range checking ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Bug in closed-source, proprietary software that I do not have access to
On 5/25/19 2:52 PM, Thomas Koenig wrote: Hi, consider this: There is a bug, confirmed by several people. This occurs in closed-source, proprietary software, and appears to be due to one of my commits. Despite considerable help from somebody who has access to the source, and putting in quite a few (volunteer) hours myself, there is no test case. So, what to do? Close the PR as INVALID? This would be our standard policy, correct? FYI, the proprietary, closed-source software is SPEC, the corresponding PR is 90539, and the friendly helper is Martin Liska. But the problem seems to be related to netcdf (your comment #22), which is freely available (don't know off-hand which license). Does the problem trigger with netcdf's own test programs ? That would open a way to investigate. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
