On 5/7/24 20:44, Toon Moene wrote:
On 5/7/24 20:35, Andrew Pinski wrote:
On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote:
On 5/7/24 00:02, Toon Moene wrote:
OK, perhaps on the aarch64 I need the following option to make the
comparison fair:
‘rdma’
Enable Round Double Multiply
On 5/7/24 20:35, Andrew Pinski wrote:
On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote:
On 5/7/24 00:02, Toon Moene wrote:
OK, perhaps on the aarch64 I need the following option to make the
comparison fair:
‘rdma’
Enable Round Double Multiply Accumulate instructions. This is on by
On 5/7/24 00:02, Toon Moene wrote:
OK, perhaps on the aarch64 I need the following option to make the
comparison fair:
‘rdma’
Enable Round Double Multiply Accumulate instructions. This is on by
default for -march=armv8.1-a.
I.e., -mno-rdma
(I hope that's correct - I'll wil
On 5/6/24 23:35, Toon Moene wrote:
On 5/6/24 23:32, Andrew Pinski wrote:
Did you test x86_64 with -march=native (or with -mfma) or just -O3?
The reason why I am asking is aarch64 includes FMA by default while
x86_64 does not.
Most recent x86_64 includes an FMA instruction but since the base
enabled by default.
I am suspect the aarch64 "excessive exceeding the threshold for
errors" are all caused by the more use of FMA rather than anything
else.
Aah, I forgot to include that tidbit, because its readily apparent from
the full logs - I compiled with *just* -O3.
Thanks,
--
g file - there is more
information in it to zoom in on the errors on the aarch64 side (note
that the x86_64 side is not faultless).
Is there a way to pass this information to our websites, so that we do
not "forget" this - or in the alternative, follow the progress in
solving this ?
#x27;t be vulnerable ?
Thanks,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
for reading that was
owned by [the equivalent on VMS] of root - or perform other functions
that only root could do), and then drop them immediately afterwards again.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
fferences are in COMPLEX16 (i.e., complex
computations using 64 bit REAL and IMAGINARY parts).
Perhaps the failing libgo test case is sufficient to track this down ...
I suppose you can reproduce that one more easily.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
S
.html
Thanks in advance.
Kind regards,
Toon Moene.
On 10/16/23 11:14, Sylvain Noiry via Gcc wrote:
Hi,
We are trying to update our patches on complex numbers to take into
account what has been discussed.
The main change from our previous patches consists of replacing vectors
of complex
On 9/26/23 20:40, Toon Moene wrote:
On 9/26/23 09:30, Richard Biener via Gcc wrote:
On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc
wrote:
As I said at the end of the presentation, we have written a paper which
explains
our implementation in details. You can find it on the wiki page
always used only by the same snapshot from the release
branch and so should be compatible with the LTO in it.
This might be an argument to make it a configure option, e.g.
--enable-lto-runtime.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG
t of our .mod files.
But it would be a big win for Fortran ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
ourse) not given with a non-lto libgfortran.
The full question of "lto-ing" run time libraries is more complicated
than just "whether it works" as those who attended the BoF will recall.
Hope this helps,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
when looking at the
result of -fdump-tree-ssa (on x86_64) for:
cat 128.f90
parameter (iq=kind(1q0))
real(kind=iq) :: a, b
read*, a, b
print*, a / b
end
and:
cat complex.f90
complex a,b
read*,a,b
print*,a/b
end
Hope this helps for a continuing fruitful discussion.
Kind regards,
--
Toon Moen
On 9/12/23 11:25, Richard Biener wrote:
On Tue, Sep 5, 2023 at 10:44 PM Toon Moene wrote:
This is even obvious in weather forecasting software I have to deal with
*today* (all written in Fortran). Some models use complex variables to
encode the "spectral" (wave-decomposed) compu
recasting software I have to deal with
*today* (all written in Fortran). Some models use complex variables to
encode the "spectral" (wave-decomposed) computations in parts where that
is useful - others just "degrade" those algorithms to explicitly use reals.
Kind regards,
it a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[3]: *** [Makefile:4584: matmul_i1.lo] Error 1
make[3]: *** Waiting for unfinished jobs
--
Toon Moene - e-m
#x27;ll have to test that first, cleanly.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
On 2/2/22 10:11, Marc Glisse wrote:
On Wed, 2 Feb 2022, Toon Moene wrote:
Fascinating. My gcc directory had both gmp-6.2.1 and -6.1.0, but the
symbolic link 'gmp' pointed to the old one. A similar problem for mpc,
mpfr and isl ...
You need to pass --force to contrib/download_pre
On 2/1/22 22:44, Marc Glisse wrote:
On Tue, 1 Feb 2022, Toon Moene wrote:
I just ran a "ubsan" build on my x86_64-linux-gnu system.
Maybe try with a more recent version of GMP first? gcd_1.c has only 103
lines in release 6.2.1.
A stack trace (UBSAN_OPTIONS=print_stacktrace=1)
88:13: runtime error: shift exponent 64 is too large for 64-bit
type 'long unsigned int'
Note that the test case is pure Fortran source. The undefined error
seems to come from a function inside the graphite library ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 3
rtran directories ?
I would recommend to send this message to the fort...@gcc.gnu.org list
too, then.
Not everyone reads the gcc and gcc-patches lists ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
On 1/7/22 21:14, cert+donotreply--- via Gcc wrote:
Topic 2: There's no such thing as free software, or, how to invest in OSS
security.
Wasn't this Cygnus motto: "We make free software affordable ?"
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 2
).
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
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
.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
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
, the only reaction I got from
git-cognoscenti was "Don't do that - it will ruin history for everybody!".
Thanks ! Might 2020 be the year of git for GCC.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At ho
on wherever the keyboard happened to be. But I don't make these decisions.
So we are going to base this world wide free software endeavor on a
source code system that doesn't keep time by UTC ?
My God - imagine if weather forecasting was done this way.
--
Toon Moene - e-mail: t...@m
t - it can solve 3x3, 4x4, 5x5, and 6x6 Sudoku's. Up til now,
I have only been able to test it on 3x3 and 4x4 examples.
You'll find it on my web page (indicated below).
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At
lf, of countless Fortran books,
whom I met once (when I was on the Fortran Standardization Committee).
He might be persuaded to give us a copy for analysis if this really is
an outlier in performance.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof
ement substring.
Of course, you need to read much more of the F77 Standard to find the
definitions of all these terms, but I think the last line quoted
actually *allows* passing WORK( IETGK ) as an actual argument associated
with an array dummy argument.
Shoot me.
--
Toon Moene - e-ma
On 5/25/19 7:43 PM, Toon Moene wrote:
On 5/25/19 7:31 PM, Thomas Koenig wrote:
Hi Toon,
On 5/25/19 7:01 PM, Steve Kargl wrote:
For WRF, I suppose you or Martin could be a good citizen and
contact the project to report a bug.
I have thought about this. As a person with experience building
netcdf.
The trunk compiler I have at hand is revision 271618, so it includes
your update that's the subject of PR90539.
--
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:
code could be modified and not resemble a fresh WRF setup ...
--
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
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
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,
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
this for speed (is quite
complicated, as I have to build several support libraries with 8.1, like
openmpi, netcdf, hdf{4|5}, fftw ...)
--
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:
On 04/24/2018 09:18 AM, Richard Biener wrote:
On Mon, Apr 23, 2018 at 8:35 PM, Toon Moene wrote:
On 04/23/2018 01:00 PM, Richard Biener wrote:
Note that while it looks "obvious" in the above source fragment the IL
that is presented to optimizers may make things a lot less &q
On 04/23/2018 01:00 PM, Richard Biener wrote:
On Sun, Apr 22, 2018 at 4:27 PM, Toon Moene wrote:
A few days ago there was a rant on the Fortran Standardization Committee's
e-mail list about Fortran's "whole array arithmetic" being unoptimizable.
An example picked at ran
de in the context of graphite.
Is this something that should be pursued ?
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
ously, I'll only be able to implement this once retirement comes
around (i.e., after 2023).
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 03/27/2017 08:29 PM, Marek Polacek wrote:
On Mon, Mar 27, 2017 at 11:16:32AM -0700, Steve Kargl wrote:
On Mon, Mar 27, 2017 at 07:41:12PM +0200, Marek Polacek wrote:
On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
The person developing the warning could *at least* have
sense.
The person developing the warning could *at least* have bootstrapped all
languages and detected, warned and helped the Fortran/Ada/whatever side
to cope with it.
[ Man, I'm glad we don't have this problem in Fortran-the-language ].
--
Toon Moene - e-mail: t...@moene.org -
I guessed correctly - .al is Albania.
What's my prize ?
Forwarded Message
Subject: Test announcement
Date: Mon, 27 Feb 2017 16:21:04 +
From: Noreply via gcc
Reply-To: Noreply , Noreply
To: gcc@gcc.gnu.org
test
http://tracking.desktop.al/tracking/unsubscribe?msgid=xuZX
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
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 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
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
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
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 -
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
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&#
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
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 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
/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 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
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
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
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-
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
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
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/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
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/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
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
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
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:
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
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
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
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
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
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
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
-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
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
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
rs/install
--with-gnu-as --with-gnu-ld --with-build-config=bootstrap-ubsan
--enable-languages=fortran,objc --disable-multilib --disable-nls
--with-arch=core-avx2 --with-tune=core-avx2
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlan
torm-could-make-next-week-a-mess/
--
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 01/03/2014 07:04 PM, Jakub Jelinek wrote:
On Fri, Jan 03, 2014 at 05:04:55PM +0100, Toon Moene wrote:
I am trying to figure out how the top-consuming routines in our
weather models will be compiled when using AVX512 instructions (and
their 32 512 bit registers).
I thought an up-to-date
other-language>
--disable-multilib --disable-nls --with-arch=core-avx2 --with-tune=core-avx2
Is it the --with-arch=core-avx2 ? Or perhaps the --with-gnu-as
--with-gnu-ld (because the installed ones do not support AVX512 yet ?).
Thanks in advance,
--
Toon Moene - e-mail: t...@moene.org
p-object]
::free (v);
^
lto1: all warnings being treated as errors
make[4]: *** [/dev/shm/wd26755/cczzGuTZ.ltrans13.ltrans.o] Error 1
make[4]: *** Waiting for unfinished jobs
lto-wrapper: make returned 2 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
--
nment in GCC.
I bet that in the average Fortran program, most arrays are suitably
aligned (after all, they're either a - by definition - SAVEd array in a
module, or an ALLOCATEd array), and code that does this:
CALL AAP(..., A(2), ...)
is relatively sparse.
--
Toon Moene -
or more
information.
If you are not a "spammer", we apologize for the inconvenience.
You can add yourself to the gcc.gnu.org "global allow list"
by sending email *from*the*blocked*email*address* to:
global-allow-subscribe-toon=moene@gcc.gnu.org
For certain types
on/compilers/gcc/gcc/tree-vect-slp.c:2229:44:
/home/toon/compilers/gcc/gcc/vec.h:316:3: error: attempt to free a
non-heap object 'life' [-Werror=free-nonheap-object]
::free (v);
^
lto1: all warnings being treated as errors
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 2
https://twitter.com/ToonMoene/status/392392928493973504
--
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
for those modules?
Igor,
It helps (:-) to send questions about gfortran and its run time library
libgfortran cc'd to fort...@gcc.gnu.org, because not every GNU Fortran
maintainer reads gcc@gcc.gnu.org
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 2
ubtle part. So my example is just no complex enough
to deal with "loop->num_nodes != 2" ...
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
On 05/31/2013 03:41 PM, Jakub Jelinek wrote:
On Fri, May 31, 2013 at 03:21:51PM +0200, Toon Moene wrote:
SUBROUTINE XYZ(A, B, N)
DIMENSION A(N), B(N)
DO I = 1, N
IF (A(I)> 0.0) THEN
A(I) = B(I) / A(I)
ELSE
A(I) = B(I)
ENDIF
ENDDO
END
Well, in this case (w
er down will prohibit vectorization to do anything on loops like
SUBROUTINE XYZ(A, B, N)
DIMENSION A(N), B(N)
DO I = 1, N
IF (A(I) > 0.0) THEN
A(I) = B(I) / A(I)
ELSE
A(I) = B(I)
ENDIF
ENDDO
END
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 X
onal code in inner
loops is not sufficient to show any speedup on our code.
Nevertheless, it would be a huge improvement on *other* codes if we
could lift this restriction.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At h
"libasan.a" included ...
--
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
th it (it is much *easier*)
- that doesn't mean that a focused course can't make students resident
at KNMI (the Dutch Meteorological Institute) familiar enough with *our*
weather model to work on it.
Don't get your nickers in a twist (as we would say in the seventies).
--
Toon Moene -
ian Tesing (several months ago). Apparently I had picked the wrong
mail package too.
Perhaps test_summary needs some sort of configure-type approach to
figure out what the mail sender is on the host system ...
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maarten
1 - 100 of 345 matches
Mail list logo
