pair 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
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 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 foreca
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 aro
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
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] ca
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
te: 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
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 PROT
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
Sa
d64 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 AM
rld'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
tions - 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
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
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
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
eptember, 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/
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:
?
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/
rine.
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
e 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/
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>
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
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 PROTEC
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 Fo
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
nnium).
--
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/
est 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
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.
--
LP64 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
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
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
e 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
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 fo
23. 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
, 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/fo
b to perform.
Thanks for your patience,
--
Toon Moene, KNMI, The Netherlands
Phone: +31 30 2206443; e-mail: [EMAIL PROTECTED]
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'l
s 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/
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.
Kin
"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
t 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,
--
ence (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/
"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,
--
mpiler 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,
--
To
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 2
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.gn
> 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
Satu
^^ 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:
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 h
ent 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: htt
.
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/
MP] 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]
o 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/
nding -
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/
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
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]
[ 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
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
.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 -2
es "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
'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
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://moe
zed 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-
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 Neth
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
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 resu
/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
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
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...@moen
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
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&#
thematical 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 des
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 -
ement 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/; we
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
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
ucted 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/wik
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
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
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
-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
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
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: ht
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
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
efined 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
stall/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, 37
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 2
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:
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
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
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
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
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
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://mo
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
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
7;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,
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 Ma
1 - 100 of 349 matches
Mail list logo
