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

Re: ICE on using -floop-nest-optimize

On 01/06/2017 03:28 PM, Kyrill Tkachov wrote: On 06/01/17 14:22, Toon Moene wrote: On the attached (Fortran) source, the following version of gfortran draws an ICE: $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target

ICE on using -floop-nest-optimize

that compiler. In the mean time - anyone has a clue ? Thanks, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran

Re: [PATCH, Fortran] Extension: Support legacy PARAMETER statements with -std=legacy (or -fdec?)

ith it (I won't name names). Thanks and kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: GCC 7.0.0 Status Report (2016-10-21)

On 10/26/2016 11:24 AM, Richard Biener wrote: On Tue, Oct 25, 2016 at 9:41 PM, Toon Moene <t...@moene.org> 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 l

Re: GCC 7.0.0 Status Report (2016-10-21)

On 10/25/2016 10:16 AM, Richard Biener wrote: On Mon, Oct 24, 2016 at 10:20 PM, Toon Moene <t...@moene.org> 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/msg0003

Re: GCC 7.0.0 Status Report (2016-10-21)

the vectorization of log/exp/sin/cos/tan functions that I described here: https://gcc.gnu.org/ml/gcc/2016-01/msg00039.html Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather

Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

in scripts and make files ... Whether support for COTAN (in radians) should be part of this option - I rather had it not. 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

Re: Ping : [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

Compiler writers on the committee tell me that you need to overhaul most of the front end (and parts of the run-time library) to get that correct ... Thanks Paul et al. for working on this daunting task ! Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnu

Re: Deprecating basic asm in a function - What now?

and gnashing of teeth. We had at least 15 years of warning ahead of the Y2K problem. Nevertheless, it was only fixed in our code during March-September 1999. Or, as one of my colleagues quipped: The next time, they can ask someone else for this job. -- Toon Moene - e-mail: t...@moene.org - phone

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

concept of the field of the reals). It used integers only for counting and indexing arrays, so it had no purpose for "signed integers that overflowed". Therefore, to the Fortran standard, this was "undefined". It was literally "undefined" - as it was not described by

Re: [patch, fortran] Inline MATMUL(A,TRANSPOSE(B)), PR 66094

mid-April) to fix it, if necessary. 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, fortran] Inline MATMUL(A,TRANSPOSE(B)), PR 66094

On 01/18/2016 08:55 PM, Toon Moene wrote: On 01/17/2016 01:44 PM, Thomas Koenig wrote: So... comments? Toon, would this help you? Could yo maybe give this a spin? Thanks, the nightly test at my home computer will build with your patch. That was the plan; unfortunately, the system

Re: [patch, fortran] Inline MATMUL(A,TRANSPOSE(B)), PR 66094

will be *a lot of work*, because I have to build all kinds of support libraries (for which I now depend on Debian Testing) by hand. But I hope just testing your examples will at least give you an idea (on -march=haswell). Thanks, and kind regards, -- Toon Moene - e-mail: t...@moene.org -

Re: [patch, fortran] Inline MATMUL(A,TRANSPOSE(B)), PR 66094

On 01/18/2016 11:14 PM, Thomas Koenig wrote: Hi Toon, It will also perform the following tests (minus the "inline_matmul_13.f90" one, which wasn't included in the attachements :-) Well, here it is. Included, thanks, -- Toon Moene - e-mail: t...@moene.org - phone: +31

Re: GNU C library's libmvec and the GNU Compiler *Collection*.

On 01/06/2016 07:46 PM, Toon Moene wrote: Would it be possible to add an option -mveclibabi=glibc to cater for this *for all languages*; or is this too low level (after all, the glibc libmvec has code for multiple architectures). If so, at what level should this be implemented ? It doesn't

GNU C library's libmvec and the GNU Compiler *Collection*.

just the switch to *actual* single precision exp/log/sin/cos implementations in glibc's libm resulted in a decrease of the running time of our weather forecasting code by 25 % (this was in glibc 2.16, IIRC). ] Thanks in advance for your suggestions. -- Toon Moene - e-mail: t...@moene.org

Re: GNU C library's libmvec and the GNU Compiler *Collection*.

On 01/06/2016 07:46 PM, Toon Moene wrote: [ This is relevant for our code, because just the switch to *actual* single precision exp/log/sin/cos implementations in glibc's libm resulted in a decrease of the running time of our weather forecasting code by 25 % (this was in glibc 2.16

Re: [wwwdocs] Document how to add a new SSH key

On 12/22/2015 02:59 PM, Gerald Pfeifer wrote: Jan (Beulich) ran into this, and indeed I could not find it documented. So I added it. ;-) +ssh username@gcc.gnu.org append-key < KEYFILE Hmm, I get: toon@moene:~$ ssh t...@gcc.gnu.org append-key < .ssh/id_dsa.pub /home/toon/.ssh/confi

Re: [wwwdocs] Document how to add a new SSH key

On 12/23/2015 08:57 PM, Marc Glisse wrote: On Wed, 23 Dec 2015, Toon Moene wrote: On 12/22/2015 02:59 PM, Gerald Pfeifer wrote: +ssh username@gcc.gnu.org append-key < KEYFILE Hmm, I get: toon@moene:~$ ssh t...@gcc.gnu.org append-key < .ssh/id_dsa.pub /home/toon/.ssh/config line

Re: LLVM to get massive GPU support with Fortran

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

Re: LLVM to get massive GPU support with Fortran

/2003-11/msg00052.html Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: LLVM to get massive GPU support with Fortran

On 11/16/2015 11:02 PM, Jack Howarth wrote: FYI, this posting has a bit more detail on the actual implementation... http://lists.llvm.org/pipermail/llvm-dev/2015-November/092438.html That surely helps - thanks. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14

What is guaranteed with the new numbering scheme of GCC releases ?

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 Netherlan

Ubsan build of GCC 6.0 fails with: cp/search.c:1011:41: error: 'otype' may be used uninitialized in this function

[-Werror=maybe-uninitialized] dfs_accessible_data d = { decl, otype }; ^ The host compiler is: toon@moene:~$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured

Re: [C/C++ PATCH] Fix -Wshift-overflow with sign bit

this: https://gcc.gnu.org/ml/gcc-testresults/2015-08/msg01036.html [ Yes, that's at run time, not compile time ... ] -- 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 fortran/52846] [F2008] Support submodules - part 3/3

passed the following (attached) interpretation on submodules the past week (it still has to go to several mail ballots, but still), overwhelmingly prefering option 3: [attached] Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk

Re: Reduction Pattern ( Vectorization or Parallelization)

]) as A[i] might be the same for different i. In Fortran this is not allowed on the left-hand side of an assignment. Does C have any restrictions here ? -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org

Re: [wwwdocs] Skeleton for GCC 6 release notes

-- + + +!-- .. -- +h2 id=languagesNew Languages and Language specific improvements/h2 Aarghh - you forgot Fortran ! /snark. -- 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

Loop fusion.

that I am not familiar with the nomenclature in its description ... Would it be hard to write a loop fusion pass otherwise ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon

Re: Loop fusion.

On 04/22/2015 09:10 PM, Steven Bosscher wrote: On Wed, Apr 22, 2015 at 6:59 PM, Toon Moene wrote: Why is loop fusion important, especially in Fortran 90 and later programs ? Because without it, every array assignment is a single loop nest, isolated from related, same-shape assignments

LTO bootstrap failure for GCC-5 prerelease.

differs gcc/tree-ssa-loop-ivcanon.o differs ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: LTO bootstrap failure for GCC-5 prerelease.

On 04/17/2015 10:49 AM, Richard Biener wrote: On Fri, Apr 17, 2015 at 10:16 AM, Toon Moene t...@moene.org 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

Re: lto bootstrap fails.

On 04/13/2015 06:00 PM, Trevor Saunders wrote: On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: On 04/11/2015 01:33 AM, Jan Hubicka wrote: On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like

Re: lto bootstrap fails.

On 04/11/2015 01:33 AM, Jan Hubicka wrote: On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like this: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html ODR rears its head again ... huh, why is c/c

trunk revision 221714 gets segfault during lto bootstrap.

As is shown here: https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg03014.html. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran

Re: Named parameters

. This is indeed very useful - Fortran has this since the Fortran 90 standard, albeit without the dots (it's unambiguous in Fortran). -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http

More explicit what's wrong with this: FAILED: Bootstrap (build config: lto; languages: all; trunk revision 217898) on x86_64-unknown-linux-gnu

/dev/shm/wd4296/ccFei5Gg.ltrans0.ltrans.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:409: recipe for target 'libcc1.la' failed make[3]: *** [libcc1.la] Error 1 Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14

Re: [PATCH] Make IPA-CP propagate alignment information of pointers

(.., A(2:), ..), which is extremely rare). So this propagation of alignment information will result in basically removing all alignment peeling for Fortran code. Thanks ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands

Hmm, /sbin/ldconfig.real: /home/toon/compilers/install/lib/../lib64/libstdc++.so.6.0.21-gdb.py is not an ELF file - it has the wrong magic bytes at the start.

at the start. Well, you betcha a python script is not an ELF file - but why does the build process think so ? -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam

Bootstrap with Ada and bootstrap-config=ubsan fails because gnatlink is not linked against ubsan.

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

Re: msan and gcc ?

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

Re: msan and gcc ?

:58 AM, Toon Moene t...@moene.org 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

LTO detects violations of one-definition-rule ?

:145:27: note: a field with different name is defined in another translation unit struct file_hash_entry *next; ^ -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon

Got this one back (too large: 6.4 Mb) from gcc-results:

--with-tune=core-avx2 Note: --with-build-config=bootstrap-ubsan Apparently, the bugs went wild ... Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam

Re: Got this one back (too large: 6.4 Mb) from gcc-results:

On 07/03/2014 07:11 PM, Marek Polacek wrote: On Thu, Jul 03, 2014 at 07:06:29PM +0200, Toon Moene wrote: Compiler version: 4.10.0 20140702 (experimental) (GCC) Platform: x86_64-unknown-linux-gnu configure flags: --prefix=/home/toon/compilers/install --with-gnu-as --with-gnu-ld --with-build

Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)

bootstrap, download mine from last night (x86_64-linux-gnu): http://moene.org/~toon/gcc-tests.log.gz [ I hope there is a way to discard color codings when writing error messages to a file, ugh ] Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738

Re: [PATCH] Add support for -fno-sanitize-recover and -fsanitize-undefined-trap-on-error (PR sanitizer/60275)

[1mESC[31m runtime error: ESC[1mESC[0mESC[1mload of value 32763, which is not a valid value for type 'x86_64_reg_class'ESC[1mESC[0m ? It makes precise grepping needlessly hard ... Otherwise, thanks very much for this work - definitely appreciated ! -- Toon Moene - e-mail: t...@moene.org - phone

ubsan bootstrap on x86_64 trunk rev. 210310: summary of results (BRRR):

# of unexpected failures1012 See: http://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00845.html -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU

Re: Patch ping

common x86-64 one) would be helpful to find bugs in the compilers' frontends, middle end and libraries ... 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

Ah HAH - this SANITY stuff is finally going to show its value for GCC development itself.

--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 Netherlands At home

Re: clang vs free software

-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

Re: How to generate AVX512 instructions now (just to look at them).

On 01/03/2014 10:11 PM, Jakub Jelinek wrote: Hi! On Fri, Jan 03, 2014 at 08:58:30PM +0100, Toon Moene wrote: I don't doubt that would work, what I'm interested in, is (cat verintlin.f): Well, you need gather loads for that and there you hit PR target/59617. I tried your patch

How to generate AVX512 instructions now (just to look at them).

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

Re: How to generate AVX512 instructions now (just to look at them).

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

Hmmm, I think we've seen this problem before (lto build):

]: *** [/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 -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738

Re: Vectorization: Loop peeling with misaligned support.

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 - e-mail: t

Spamming the gcc-testresults mailing list (or not).

for 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 of blocks, this will enable

Something wrong with bootstrap-lto, or lto itself:

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 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org

Sorry, couldn't resist this one:

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

Re: Compilation flags in libgfortran

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 214290

Re: Ubsan merged into trunk

for asan). Kind regards, -- Toon Moene, 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: Question about vectorization limit

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 XG Maartensdijk

Re: Question about vectorization limit

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

Re: Question about vectorization limit

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/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org

Re: Question about vectorization limit

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 home: http://moene.org/~toon/; weather: http://moene.org/~hirlam

undefined reference's in bootstrap-asan.

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

Re: [gomp4] C++ OpenMP 4.0 atomics support

this - it is really hard to get a cross-language standard like this one correct, let alone its implementation. The reports I receive on the OpenMP implementation in GCC (from the gfortran users' side) are without exception positive. Thanks ! -- Toon Moene - e-mail: t...@moene.org - phone: +31

<    1   2   3   4   5   >