LAST_UPDATED: Sat May 18 08:59:19 UTC 2024 (revision r15-644-g7422e050f33)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
FAIL: gcc.target/i386/apx-ndd-tls-1b.c scan-assembler-times addq[
\\t]+%r[a-z0-9]+, a@gottpoff(%rip),
LAST_UPDATED: Fri May 17 14:58:18 UTC 2024 (revision r15-634-gb59de411326)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
FAIL: gcc.target/i386/apx-ndd-tls-1b.c scan-assembler-times addq[
\\t]+%r[a-z0-9]+, a@gottpoff(%rip),
LAST_UPDATED: Thu May 16 08:06:00 UTC 2024 (revision r15-535-ge656656e711)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
FAIL: gcc.dg/tree-ssa/ssa-lim-15.c scan-tree-dump lim2 "Executing store motion"
FAIL: gcc.target/i386/apx-ndd-tls-1b.c
LAST_UPDATED: Mon May 13 09:49:44 UTC 2024 (revision r15-427-gb621482296f)
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target unix
=== libatomic Summary ===
# of expected passes54
=== libffi
LAST_UPDATED: Sun May 12 09:55:03 UTC 2024 (revision r15-386-gb9294757f82)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sat May 11 08:26:15 UTC 2024 (revision r15-377-g3dab8f8a542)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Wed May 8 14:46:58 UTC 2024 (revision r14-10184-gd54151df3ba)
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target unix
=== libatomic Summary ===
# of expected passes54
=== libffi
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
LAST_UPDATED: Wed May 8 07:20:37 UTC 2024 (revision r15-312-g36e87799693)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
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
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 will try
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
it, it is not 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,
--
l log 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 ?
Kind
LAST_UPDATED: Mon May 6 13:39:55 UTC 2024 (revision r15-204-g7c469a9fc78)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Mon May 6 10:24:28 UTC 2024 (revision r15-202-gec1cdad89af)
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target unix
=== libatomic Summary ===
# of expected passes54
=== libffi
LAST_UPDATED: Sat May 4 09:24:11 UTC 2024 (revision r15-164-g6cec31d44a4)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sat May 4 06:54:16 UTC 2024 (revision r14-10167-g532d775fc1c)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Wed May 1 13:13:11 UTC 2024 (revision r15-89-g81f7965e630)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Wed May 1 08:55:59 UTC 2024 (revision r14-10155-g9ccb16d032e)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Tue Apr 30 14:19:50 UTC 2024 (revision r15-70-g0b2735e0797)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Mon Apr 29 09:34:40 UTC 2024 (revision r15-45-gadd51a2514a)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sat Apr 27 09:15:01 UTC 2024 (revision r15-11-g140124ad54e)
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target unix
=== libatomic Summary ===
# of expected passes54
=== libffi
LAST_UPDATED: Sun Apr 21 13:52:27 UTC 2024 (revision r14-10058-ga44d16efa7a)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Fri Apr 19 10:33:06 UTC 2024 (revision r14-10038-gede01dfd9dd)
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target unix
=== libatomic Summary ===
# of expected passes54
=== libffi
LAST_UPDATED: Wed Apr 17 08:11:03 UTC 2024 (revision r14--g9c7cf5d71f0)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Tue Apr 16 13:30:59 UTC 2024 (revision r14-9993-gf949481a1f7)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sun Apr 14 09:35:30 UTC 2024 (revision r14-9958-g3319d1a4aa5)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sat Apr 13 07:08:21 UTC 2024 (revision r14-9953-g1667962ae75)
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target unix
=== libatomic Summary ===
# of expected passes54
=== libffi
LAST_UPDATED: Thu Apr 11 08:24:55 UTC 2024 (revision r14-9910-gcb46aca0a07)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sun Apr 7 06:21:52 UTC 2024 (revision r14-9823-g4e3c8257304)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Fri Apr 5 09:04:44 UTC 2024 (revision r14-9801-g592536eb3c0)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
?
Thanks,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
file 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
LAST_UPDATED: Mon Apr 1 09:43:47 UTC 2024 (revision r14-9737-gd28ea8e5a70)
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target unix
=== libatomic Summary ===
# of expected passes54
=== libffi
LAST_UPDATED: Sat Mar 30 08:26:59 UTC 2024 (revision r14-9728-g6fc84f680d0)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Thu Mar 28 09:04:47 UTC 2024 (revision r14-9702-g7907ff2bcb5)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sun Mar 24 07:21:12 UTC 2024 (revision r14-9649-gbb04a11418f)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Thu Mar 21 08:34:22 UTC 2024 (revision r14-9589-g9d6ff6f1ea2)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sun Mar 17 07:24:11 UTC 2024 (revision r14-9504-gb5490afe3a4)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Fri Mar 15 08:56:15 UTC 2024 (revision r14-9490-g90b9872311c)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Thu Mar 14 09:44:04 UTC 2024 (revision r14-9460-g8f6e0814b4b)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
XPASS: gcc.dg/guality/example.c -O0 execution test
XPASS: gcc.dg/guality/example.c -Og -DPREVENT_OPTIMIZATION
LAST_UPDATED: Sun Mar 10 14:07:58 UTC 2024 (revision r14-9418-g993c6de642f)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
XPASS: gcc.dg/guality/example.c -O0 execution test
XPASS: gcc.dg/guality/example.c -Og -DPREVENT_OPTIMIZATION
LAST_UPDATED: Sun Mar 10 07:25:42 UTC 2024 (revision r14-9417-g6f7d000fcac)
=== acats tests ===
=== acats Summary ===
# of expected passes2328
# of unexpected failures0
Native configuration is x86_64-pc-linux-gnu
=== gcc tests
LAST_UPDATED: Sat Mar 9 16:17:18 UTC 2024 (revision r14-9413-gf5a805d8290)
Native configuration is x86_64-pc-linux-gnu
=== gcc tests ===
Running target unix
XPASS: gcc.dg/guality/example.c -O0 execution test
XPASS: gcc.dg/guality/example.c -Og -DPREVENT_OPTIMIZATION
LAST_UPDATED: Thu Mar 7 09:08:26 UTC 2024 (revision r14-9352-gae1b05641cc)
Native configuration is aarch64-unknown-linux-gnu
=== libatomic tests ===
Running target unix
=== libatomic Summary ===
# of expected passes54
=== libgomp
ml
For me, as for you, it works for x86_64-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807609.html
I hope this helps.
Kind regards,
Toon Moene.
On 2/9/24 11:26, Richard Biener wrote:
The following allows a base term to be derived from an existing
MEM_EXPR, notably the poi
it happens in the test suite of gmp, which I build
locally as part of the build.
It *is* visible in the full log of the bootstrap:
toon@moene:~/compilers$ grep ^FAIL log-thunderx-r14-8681
FAIL: libphobos.exceptions/rt_trap_exceptions.d output pattern test
FAIL: tacos
FAIL: tacosh
FAIL: tadd_si
FAIL
nces 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
building with
bootstrap-lto and bootstrap-O3:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/804807.html
?
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
.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
in there will be 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
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
ot;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
values ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
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 Moene - e-mail: t
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) co
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,
s no "general method" for this, there exists a whole
Working Group under ISO whose responsibility is to identify and list
vulnerabilities in programming languages - Working Group 23.
Its web page is: https://www.open-std.org/jtc1/sc22/wg23/
Kind regards,
--
Toon Moene - e-mail: t...@moe
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-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maarte
ve 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
gh there's no way in hell the Fortran Language Standard (any of
them) guarantees this.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
ur_source&)
/home/toon/compilers/gcc/gcc/gimple-range-fold.cc:558
0x1ac50ba fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/home/toon/compilers/gcc/gcc/gimple-range-fold.cc:489
Please submit a full bug report, with preprocessed source (by using
It was just a comment on the code of the PR ...
Toon.
On 10/13/22 15:44, Aldy Hernandez wrote:
I'm not following. My patch doesn't affect this behavior.
What am I missing?
Aldy
On Thu, Oct 13, 2022 at 3:04 PM Toon Moene wrote:
On 10/13/22 14:36, Aldy Hernandez via Gcc-patches wrote
feature: End expression in DO loop at (1) must be integer
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
2,6 +32,7 @@ private:
void print_irange_bound (const wide_int , tree type) const;
void print_irange_bitmasks (const irange &) const;
void print_frange_nan (const frange &) const;
+ void print_real_value (tree type, const REAL_VALUE_TYPE ) const;
pretty_printer *pp;
};
(and time [hour of
the day, day of the year]).
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
headroom
for improvements in the FP space than the integer space IMHO.
One of the more interesting ones is to try to limit the range of the
input to the trigonometric functions - that way you could use ones
without any argument reduction phase ...
--
Toon Moene - e-mail: t...@moene.org - phone
On 8/29/22 16:36, Aldy Hernandez wrote:
On Mon, Aug 29, 2022 at 4:30 PM Toon Moene wrote:
On 8/29/22 16:15, Aldy Hernandez wrote:
But even with -ffinite-math-only, is there any benefit to propagating
a known NAN? For example:
The original intent (in 2002) for the option -ffinite-math
nd regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
offhand which MODE_ that is) ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
compilers differ in the
treatment of this case, there might be reason to ask the Fortran
Standard Committee for an Interpretation of the Standard ?
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Seems to have been fixed in r13-449.
Compare:
https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761443.html
with (r13-448):
https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761431.html
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738
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_prerequisites
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)
time 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 346 214290
Saturnusho
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
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 214290
Satu
to ask the Fortran Standardization Committee for an interpretation
(of the standard's text).
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
).
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
- and I have not been
disappointed.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
nd regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
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 -214748
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
On 2/9/20 9:55 PM, Steve Kargl wrote:
On Sun, Feb 09, 2020 at 09:15:46PM +0100, Toon Moene wrote:
On 2/6/20 9:01 PM, David Malcolm wrote:
PR analyzer/93405 reports an ICE when attempting to use -fanalyzer on
certain gfortran code. The second patch in this kit fixes
a gfortran.dg/analyzer subdirectory with an analyzer.exp,
setting DEFAULT_FFLAGS on the tests run within it.
I have seen no objections against this proposal, so please go ahead.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk
, 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 home: http:/
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...@moene.org - phone: +31 346
that it is complicated, it is also a good idea to make math
function vectorization orthogonal to OpenMP.
Definitely agree. I always found it a strained relationship, and only
supported it being done that way because it worked.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
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 home: http://moene.org/~
ntless 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 14, 3
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-mail: t
,
--
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
enough to try on its own merits,
even if it's not committed by tomorrow morning ...
Fascinating analysis - 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 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
tcdf.
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://moene.org/~hi
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
1 - 100 of 443 matches
Mail list logo
