Results of testsuite (branch: master; revision: r15-70; build config: lto,O3; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r15-45; build config: lto,O3; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r15-11; build config: standard; languages: all; tasks: 48) on aarch64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-10058; build config: standard; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-10038; build config: standard; languages: all; tasks: 48) on aarch64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9999; build config: standard; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9993; build config: standard; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9958; build config: lto,O3,checking=all; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9953; build config: lto,O3; languages: all; tasks: 48) on aarch64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9910; build config: lto,O3,checking=all; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9823; build config: lto,O3,checking=all; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9801; build config: lto,O3; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Re: Sourceware mitigating and preventing the next xz-backdoor

? Thanks, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands

Re: Sourceware mitigating and preventing the next xz-backdoor

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

Results of testsuite (branch: master; revision: r14-9737; build config: lto,O3,checking=all; languages: all; tasks: 48) on aarch64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9728; build config: lto,O3,checking=all; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9702; build config: lto,O3,checking=all; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9649; build config: lto,O3,checking=all; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9589; build config: lto,O3,checking=all; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9504; build config: lto,O3,checking=all; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9490; build config: lto,O3; languages: all; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9460; build config: lto,O3; languages: fortran; tasks: 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9418; build config: lto,O3; languages: fortran; tasks: build 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9417; build config: lto,O3,checking=all; languages: all; tasks: build 16, test 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9413; build config: standard; languages: fortran; tasks: build 16, test 16) on x86_64-linux-gnu.

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

Results of testsuite (branch: master; revision: r14-9352; build config: standard; languages: fortran; tasks: build 48, test 48) on aarch64-linux-gnu.

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

Re: [PATCH] rtl-optimization/113597 - recover base term for argument pointers

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

Re: [PATCH]middle-end: check memory accesses in the destination block [PR113588].

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

aarch64 testresults of r14-7229 fails math/cmplx in the libgo tests.

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

Re: [PATCH]middle-end: thread through existing LCSSA variable for alternative exits too [PR113237]

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

Re: Complex numbers support: discussions summary

.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

Re: Complex numbers support: discussions summary

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

Re: Test with an lto-build of libgfortran.

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

Re: Test with an lto-build of libgfortran.

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

Test with an lto-build of libgfortran.

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

Re: [PATCH V3] RISC-V: Remove mem-to-mem VLS move pattern[PR111566]

values ... Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands

Re: Complex numbers support: discussions summary

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

Re: Complex numbers in compilers - upcoming GNU Tools Cauldron.

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

Complex numbers in compilers - upcoming GNU Tools Cauldron.

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,

Re: [RFC] GCC Security policy

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

/home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at

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

Re: [RFC] Exposing complex numbers to target backends

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

Re: Should -ffp-contract=off the default on GCC?

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

Re: [PATCH] range-op-float: Fix up ICE in lower_bound [PR107975]

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

Re: [PATCH] [PR24021] Implement PLUS_EXPR range-op entry for floats.

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

Re: [PATCH] [PR24021] Implement PLUS_EXPR range-op entry for floats.

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

Re: [PATCH] frange: dump hex values when dumping FP numbers.

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; };

Re: [PATCH] [ranger] x == -0.0 does not mean we can replace x with -0.0

(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

Re: [PATCH] [ranger] x == -0.0 does not mean we can replace x with -0.0

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

Re: [PATCH] Add support for floating point endpoints to frange.

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

Re: [PATCH] Add support for floating point endpoints to frange.

nd regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands

Re: [PATCH] Add support for floating point endpoints to frange.

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

Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

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

Re: [COMMITTED] Export global ranges during the VRP block walk.

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

Re: gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

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

Re: gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

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)

gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

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

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

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

Re: [PATCH] Mass rename of C++ .c files to .cc suffix

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

Re: [gen-14164] Invitation to the CERT Vendor Meeting 2022

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

Re: [PATCH, Fortran] Fix setting of array lower bound for named arrays

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

Re: Can gcc itself be tested with ubsan? If so, how?

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

- 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: [PATCH 00/31] VAX: Bring the port up to date (yes, MODE_CC conversion is included)

nd regards, -- 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

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 / GFortran (9.3.0; Cygwin 64) Internal Compiler Error on NINT() Function

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

Re: gcc math functions for OpenMP vectoization

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: [PATCH 1/2] analyzer: gfortran testsuite support

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

Re: [PATCH 1/2] analyzer: gfortran testsuite support

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

Re: Fixing gcc git logs

, 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:/

Re: Test GCC conversion with reposurgeon available

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

Re: [PATCH v3] Extend the simd function attribute

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

Re: GCC Spec2017 optimization Wiki

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

Re: GCC Spec2017 optimization Wiki

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

Re: gcc-10 Bug report

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

Re: [PATCH 2/2][GCC][RFC][middle-end]: Add complex number arithmetic patterns to SLP pattern matcher.

, -- 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: Avoid adding impossible copies in ira-conflicts.c:process_reg_shuffles

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

Re: Bug in closed-source, proprietary software that I do not have access to

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

Re: Bug in closed-source, proprietary software that I do not have access to

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

Re: Bug in closed-source, proprietary software that I do not have access to

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

Re: Bug in closed-source, proprietary software that I do not have access to

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

Re: On-Demand range technology [3/5] - The Prototype

ck 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 Netherland

Re: OpenCoarrays integration with gfortran

2.0-3) ... Processing triggers for libc-bin (2.27-6) ... [ previously this led to apt errors, but not now. ] and moved my own installation of the OpenCoarrays-2.2.0.tar.gz out of the way: toon@moene:~$ ls -ld *pen* drwxr-xr-x 6 toon toon 4096 Aug 10 16:01 OpenCoarrays-2.2.0.opzij drwxr-xr-x

Re: [PATCH 08/25] Fix co-array allocation

all After that, it was a breeze to test my mock weather program (moene.org/~toon/random-weather.f90), that I had built until then only with -fcoarray=single. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene

Large Fortran program succesfully LTO'd.

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: [PATCH] combine: Allow combining two insns to two insns

). gfortran82 -S -Ofast -march=native -mtune=native: 458 verint.s.82.loop3 gfortran90 -S -Ofast -march=native -mtune=native: 396 verint.s.90.loop3 But the most stunning difference is the use of the stack [ nn(rsp) ] - see the attached files ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346

Re: [patch, fortran] Handling of .and. and .or. expressions

ining the function reference. In the example above, evaluation of the expression causes Z to become undefined if L defines its argument." 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

Documentation patch for -floop-interchange and -floop-unroll-and-jam.

The documentation of both options is still inconsistent, in both the trunk and the gcc-8 branch. The following is my suggestion to clear this up (and move -floop-unroll-and-jam close to -floop-interchange. ChangeLog: 2018-05-17 Toon Moene <t...@moene.org> * doc/invoke.texi

Interesting statistics on vectorization for Skylake avx512 (i9-7900) - 8.1 vs. 7.3.

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: http

Re: Loop fusion.

On 04/24/2018 09:18 AM, Richard Biener wrote: On Mon, Apr 23, 2018 at 8:35 PM, Toon Moene <t...@moene.org> 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 t

Re: Loop fusion.

On 04/23/2018 01:00 PM, Richard Biener wrote: On Sun, Apr 22, 2018 at 4:27 PM, Toon Moene <t...@moene.org> 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

Loop fusion.

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

New option -floop-unroll-and-jam.

anges loops in a loop nest to improve data locality. Both passes are enabled by default at -O3 and above." However, the documentation of optimization options does not reflect this. Is the following change to the documentation acceptable ? ChangeLog 2018-04-19 Toon Moene <t...@moen

Re: Disable autogeneration of gather instructions on Ryzen and generic

this comment a few years ago, when Jakub Jelinek implemented support for gather in vectorization *of our loops*. Before that, I had only seen programmers do it for our code by rewriting the Fortran into something that was completely unreadable. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346

Re: libmvec simd math functions in fortran

, 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/ Progress

Re: [RFA] Zen tuning part 9: Add support for scatter/gather in vectorizer costmodel

Without gather the most expensive loop in our code couldn't be vectorized (there are only a handful of gather instructions in that loop and dozens of other vector instructions). Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Ma

Re: Warning annoyances in list_read.c

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

Re: Warning annoyances in list_read.c

. 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 - phone: +31 346

Re: [PATCH doc] use "cannot" consistently

ither. I think for non-native speakers of English, using the full word is easier to read (you can't take my experience as an example, as I was exposed to written English 48 years ago). I think replacing the few instances of can't with cannot is worth the clarity. Kind regards, -- Toon Moene -

Fwd: Test announcement

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

  1   2   3   4   5   >