[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

--- Comment #28 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Oct  7 20:12:00 2019
New Revision: 276673

URL: https://gcc.gnu.org/viewcvs?rev=276673&root=gcc&view=rev
Log:
2019-10-07  Thomas Koenig 

Backport from trunk
PR fortran/84487
* trans-decl.c (gfc_get_symbol_decl): For __def_init, set
DECL_ARTIFICAL and do not set TREE_READONLY.

2019-10-07  Thomas Koenig 

Backport from trunk
PR fortran/84487
* gfortran.dg/typebound_call_22.f03: xfail.


Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/typebound_call_22.f03

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

--- Comment #27 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Oct  7 20:10:22 2019
New Revision: 276672

URL: https://gcc.gnu.org/viewcvs?rev=276672&root=gcc&view=rev
Log:
2019-10-07  Thomas Koenig 

Backport from trunk
PR fortran/84487
* trans-decl.c (gfc_get_symbol_decl): For __def_init, set
DECL_ARTIFICAL and do not set TREE_READONLY.

2019-10-07  Thomas Koenig 

Backport from trunk
PR fortran/84487
* gfortran.dg/typebound_call_22.f03: xfail.


Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/typebound_call_22.f03

[Bug target/92008] Build failure on cygwin

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008

--- Comment #2 from Thomas Koenig  ---
Created attachment 47001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47001&action=edit
plural.i from adding -save-temps by hand to the Makefile in intl

[Bug target/92008] Build failure on cygwin

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008

--- Comment #3 from Thomas Koenig  ---
If there's anything else needed, let me know.
In the meantime, back to booting Linux :-)

[Bug target/92008] Build failure on cygwin

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008

--- Comment #1 from Thomas Koenig  ---
Created attachment 47000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47000&action=edit
config.status

[Bug target/92008] New: Build failure on cygwin

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008

Bug ID: 92008
   Summary: Build failure on cygwin
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46999&action=edit
config.log

With current cygwin and current trunk, I get

gcc -c  -g -DHAVE_CONFIG_H  -I. -I/home/ig25/trunk/intl plural.c
In file included from /home/ig25/trunk/intl/plural.y:35:0:
/home/ig25/trunk/intl/plural-exp.h:102:23: error: conflicting types for
'libintl_gettextparse'
 # define PLURAL_PARSE libintl_gettextparse
   ^
/home/ig25/trunk/intl/plural.y:40:25: note: in expansion of macro
'PLURAL_PARSE'
 # define __gettextparse PLURAL_PARSE
 ^~~~
plural.c:184:5: note: in expansion of macro '__gettextparse'
 int __gettextparse (void);
 ^~
/home/ig25/trunk/intl/plural-exp.h:102:23: note: previous declaration of
'libintl_gettextparse' was here
 # define PLURAL_PARSE libintl_gettextparse
   ^
/home/ig25/trunk/intl/plural-exp.h:114:12: note: in expansion of macro
'PLURAL_PARSE'
 extern int PLURAL_PARSE PARAMS ((void *arg));
^~~~
/home/ig25/trunk/intl/plural-exp.h:102:23: error: conflicting types for
'libintl_gettextparse'
 # define PLURAL_PARSE libintl_gettextparse
   ^
/home/ig25/trunk/intl/plural.y:40:25: note: in expansion of macro
'PLURAL_PARSE'
 # define __gettextparse PLURAL_PARSE
 ^~~~
plural.c:63:25: note: in expansion of macro '__gettextparse'
 #define yyparse __gettextparse
 ^~
plural.c:1129:1: note: in expansion of macro 'yyparse'
 yyparse (void)
 ^~~
/home/ig25/trunk/intl/plural-exp.h:102:23: note: previous declaration of
'libintl_gettextparse' was here
 # define PLURAL_PARSE libintl_gettextparse
   ^
/home/ig25/trunk/intl/plural-exp.h:114:12: note: in expansion of macro
'PLURAL_PARSE'
 extern int PLURAL_PARSE PARAMS ((void *arg));
^~~~
plural.c: In function 'libintl_gettextparse':
plural.c:64:25: error: too few arguments to function '__gettextlex'
 #define yylex   __gettextlex
 ^
plural.c:1298:16: note: in expansion of macro 'yylex'
   yychar = yylex (&yylval);
^
plural.c:64:25: note: declared here
 #define yylex   __gettextlex
 ^
/home/ig25/trunk/intl/plural.y:69:12: note: in expansion of macro 'yylex'
 static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
^
/home/ig25/trunk/intl/plural.y:178:29: error: 'arg' undeclared (first use in
this function)
  ((struct parse_args *) arg)->res = $1;
 ^~~
/home/ig25/trunk/intl/plural.y:178:29: note: each undeclared identifier is
reported only once for each function it appears in
make[3]: *** [Makefile:133: plural.o] Error 1
make[3]: Leaving directory '/cygdrive/e/trunk-bin/intl'

[Bug fortran/92004] [10 Regression] Rejection of different ranks for dummy array argument where actual argument is an element

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92004

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-05
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/92004] New: [10 Regression] Rejection of different ranks for dummy array argument where actual argument is an element

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92004

Bug ID: 92004
   Summary: [10 Regression] Rejection of different ranks for dummy
array argument where actual argument is an element
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

From F18, 15.5.2.4 Ordinary dummy variables

14 If the actual argument is a noncoindexed scalar, the
corresponding dummy argument shall be scalar unless the actual
argument is default character, of type character with the
C character kind (18.2.2), or is an element or substring of an
element of an array that is not an assumed-shape, pointer, or
polymorphic array, the dummy argument has assumed-rank, or the
dummy argument is an assumed-type assumed-size array. 

So, this is actually legal:

subroutine baz
  real x(10,10)
  call bar(x(2,2))
  call bar(x)
end subroutine baz

[Bug fortran/92000] Fortran array passing optimization

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92000

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Thomas Koenig  ---
This would be invalid after all, storage association and all...

[Bug fortran/92000] Fortran array passing optimization

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92000

Thomas Koenig  changed:

   What|Removed |Added

Version|unknown |10.0
   Severity|normal  |enhancement

[Bug fortran/92000] New: Fortran array passing optimization

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92000

Bug ID: 92000
   Summary: Fortran array passing optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The following code

  program main
  integer :: a(2)
  a(1) = 1
  a(2) = 42
  call foo(a(1:1),1)
  if (a(2) .ne. 42) stop "bletchful"
  end

need not execute the check if a(2) is 42, and the call to
_gfortran_stop_string can be optimized away.

The same goes for

  program main
  integer :: a(2)
  a(1) = 1
  a(2) = 42
  call foo(a(1),1)
  if (a(2) .ne. 42) stop "bletchful"
  end

There is a lot of broken code which assumes that the check is necessary,
so we should probably do this optimization contingent only if
-fallow-argument-mismatch is not in effect.

[Bug libfortran/91543] [10 Regression] nf failure ( Handling stack overflow more sensibly

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543

Thomas Koenig  changed:

   What|Removed |Added

   Priority|P3  |P4
Version|unknown |10.0
   Target Milestone|--- |10.0
Summary|Handling stack overflow |[10 Regression] nf failure
   |more sensibly   |( Handling stack overflow
   ||more sensibly

--- Comment #4 from Thomas Koenig  ---
The nf failure is a regression in itself, so we should mark it as such,
and we should definitely try to fix this before gcc 10 comes out.

[Bug fortran/91984] New: Handling of __def_init_*

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91984

Bug ID: 91984
   Summary: Handling of __def_init_*
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

After r276506 (PR84487) the __def_init variables are no longer in
the read-only section, but in the BSS instead. This was done because they they
could become excessively large.  However, the current solution is not ideal:

- Not having them read-only forced an xfail on
gfortran.dg/typebound_call_22.f03
- Having a variable which is (in the test cases) never used, and has only
  zeros, is not the best design.

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

Thomas Koenig  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
Summary|[8/9/10 Regression] Large   |[8/9 Regression] Large
   |rodate section increase in  |rodate section increase in
   |465.tonto with r254427  |465.tonto with r254427

--- Comment #26 from Thomas Koenig  ---
Migitated on trunk so far.

[Bug fortran/91963] Logical function does not simplify

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963

--- Comment #9 from Thomas Koenig  ---

(In reply to Thomas Koenig from comment #6)
> Somewhat reduced:
> 
> program main
>   integer, dimension(2), parameter :: n=[1,4]
>   logical, parameter :: a = logical(.true.,minval([(n(i),i=1,4)]))
> end program main
> 
> Even more reduced, without LOGICAL:
> 
> program main
>   integer, dimension(2), parameter :: n=[1,4]
>   integer, parameter :: m = minval([(n(i),i=1,4)],1)
> end program main

Both of these test cases are wrong, of course; there is no
n(3), nor is there a n(4).

The error message is bogus (which had me confused), an out-of-bounds-error
should be reported.

[Bug fortran/84487] [8/9/10 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

--- Comment #25 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Oct  3 12:39:42 2019
New Revision: 276506

URL: https://gcc.gnu.org/viewcvs?rev=276506&root=gcc&view=rev
Log:
2019-10-03  Thomas Koenig 

PR fortran/84487
* trans-decl.c (gfc_get_symbol_decl): For __def_init, set
DECL_ARTIFICAL and do not set TREE_READONLY.

2019-10-03  Thomas Koenig 

PR fortran/84487
* gfortran.dg/typebound_call_22.f03: xfail.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_call_22.f03

[Bug fortran/91963] Logical function does not simplify

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-02
 Ever confirmed|0   |1

--- Comment #6 from Thomas Koenig  ---
Somewhat reduced:

program main
  integer, dimension(2), parameter :: n=[1,4]
  logical, parameter :: a = logical(.true.,minval([(n(i),i=1,4)]))
end program main

Even more reduced, without LOGICAL:

program main
  integer, dimension(2), parameter :: n=[1,4]
  integer, parameter :: m = minval([(n(i),i=1,4)],1)
end program main

log.f90:3:27:

3 |   integer, parameter :: m = minval([(n(i),i=1,4)],1)
  |   1
Error: transformational intrinsic 'minval' at (1) is not permitted in an
initialization expression

You're right, Steve, the problem lies in the simplification
of the implied DO loop (the error message is a catch-all
which is somewhat misleading here).

[Bug fortran/91963] Logical function does not simplify

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963

--- Comment #2 from Thomas Koenig  ---
(In reply to Richard Biener from comment #1)
> But is it valid fortran?

I had to check, but yes.

LOGICAL is an elemental type conversion function, which has only constant
arguments, so it should be simplified.

There are also simpler cases where this works as expected:

program main
  logical, parameter :: l1 = .true.
  logical, parameter :: l4 = logical(l1, 4)
end program main

As does this:

program main
  integer, parameter, dimension(1) :: ar = [4]
  logical, parameter :: l1 = .true.
  logical, parameter :: l4 = logical(l1, ar(1))
end program main

[Bug fortran/91963] New: Logical function does not simplify

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963

Bug ID: 91963
   Summary: Logical function does not simplify
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The following program

module logmod
   use ISO_C_BINDING
   use ISO_FORTRAN_ENV
   implicit none
   private
   integer i
   integer, parameter, public :: minkind = LOGICAL_KINDS(minloc( &
!  [(C_SIZEOF(LOGICAL(.FALSE.,LOGICAL_KINDS(i))), &
  [(SIZE(TRANSFER(LOGICAL(.FALSE.,LOGICAL_KINDS(i)),[0_INT8])), &
  i=1,size(LOGICAL_KINDS))],1))
end module logmod

program start
   use logmod
   implicit none
   write(*,'(*(g0))') minkind
end program start

(due to James van Buskirk) does not compile:

x.f90:9:38:

9 |   [(SIZE(TRANSFER(LOGICAL(.FALSE.,LOGICAL_KINDS(i)),[0_INT8])), &
  |  1
Error: Invalid kind for LOGICAL at (1)
x.f90:14:7:

   14 |use logmod
  |   1
Fatal Error: Cannot open module file 'logmod.mod' for reading at (1): No such
file or directory

This would actually be useful to select the kind of the smallest
LOGICAL in a portable fashion :-)

[Bug fortran/91801] ICE in gfc_simplify_reshape, at fortran/simplify.c:6733

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91801

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-19
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Should be easy to fix.

[Bug tree-optimization/88713] Vectorized code slow vs. flang

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713

--- Comment #55 from Thomas Koenig  ---
(In reply to H.J. Lu from comment #45)
> Created attachment 45510 [details]
> An updated patch

HJ, do you plan on committing these?

[Bug fortran/48419] [ABI cleanup] Reduce gfortran stack usage for procedures doing IO

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||tkoenig at gcc dot gnu.org
Summary|Reduce gfortran stack usage |[ABI cleanup] Reduce
   |for procedures doing IO |gfortran stack usage for
   ||procedures doing IO

--- Comment #6 from Thomas Koenig  ---
We could do this if we clean up the ABI.  If we do that, we could also
revisit PR 45715 :-)

Is there an ABI cleanup PR somewhere?

[Bug fortran/81651] Enhancement request: have f951 print out fully qualified module file name

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81651

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |NEW

[Bug fortran/48303] [Legacy] Support Character constants in DATA statement for non-character variables

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48303

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||documentation
 Status|WAITING |NEW
 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #4)
> No activity since more than two years. IMO this should go under the section
> 
> 6.2 Extensions not implemented in GNU Fortran
> 
> of the manual. I can submit a draft patch for this PR if someone is will to
> fix
> my Frenglish and formatting issues and do the commit.

Hi,

just going through some WAITING bugs... do you still plan to do this?
If not, I can also do this.

[Bug fortran/69815] Don't always use BLOCKS for front-end optimization variables

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69815

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug fortran/91550] [8/9 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91550

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Thomas Koenig  ---
Fixed. Thanks for the bug report!

[Bug fortran/91550] [8/9 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91550

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Sep 18 17:39:33 2019
New Revision: 275892

URL: https://gcc.gnu.org/viewcvs?rev=275892&root=gcc&view=rev
Log:
2019-09-18  Thomas Koenig  

Backport from trunk
PR fortran/91550
* frontend-passes.c (do_subscript): If step equals
zero, a previuos error has been reported; do nothing
in this case.
* resolve.c (gfc_resolve_iterator): Move error checking
after type conversion.

2019-09-18  Thomas Koenig  

Backport from trunk
PR fortran/91550
* gfortran.dg/do_subscript_6.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/do_subscript_6.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/frontend-passes.c
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/91550] [8/9 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91550

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Sep 18 17:32:08 2019
New Revision: 275891

URL: https://gcc.gnu.org/viewcvs?rev=275891&root=gcc&view=rev
Log:
2019-09-18  Thomas Koenig  

Backport from trunk
PR fortran/91550
* frontend-passes.c (do_subscript): If step equals
zero, a previuos error has been reported; do nothing
in this case.
* resolve.c (gfc_resolve_iterator): Move error checking
after type conversion.

2019-09-18  Thomas Koenig  

Backport from trunk
PR fortran/91550
* gfortran.dg/do_subscript_6.f90: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/do_subscript_6.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/frontend-passes.c
branches/gcc-9-branch/gcc/fortran/resolve.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91778] gfortran GCC9 optimizer bug

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91778

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2019-09-16 00:00:00 |
 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
(In reply to Mark Wieczorek from comment #0)
> I am writing about a possible bug in the gfortran GCC9 optimizer on macOS
> (installed via brew).
> 
> Before going into the details, I note that my code (SHTOOLS/pyshtools) is
> widely used on many platforms and compilers. My code works with GCC8
> compiled with optimizations "-O" or "-O3", and it works fine with GCC9 when
> compiled _without_ optimizations. I was able to "fix" my code to work with
> GCC9, but I feel that what I am doing is avoiding a bug in the GCC9
> optimizer, and that I am not in fact "fixing" my code (perhaps I am
> wrong...).
> 
> The problem is related to using the FFTW3 library, which is the most widely
> used FFT library for scientific computing. If this is a bug, then others
> will probably encounter similar problems. As my code is somewhat long (and
> given the lack of time I have now), I will just give you a summary of two
> problems. If necessary, I could try to write a "small" example that
> reproduces these problems when I have more free time later.

If it turns out that this is needed, please do.  However...

> I start by describing how FFTW routines are use. First, you initialize the
> FFT operation and get pointers to all the input and output arrays, which are
> stored in the variable "plan":
> 
> call dfftw_plan_dft_c2r_1d(plan, nlong, coef, grid)

This sounds very suspicious. According to the Fortran standard, you
cannot stash away a pointer to a Fortran array unless that array
is marked as TARGET. Well, you can, but it's liable to break any time,
and apparently it did.

Can you show the declaration of dfftw_plan_dft_c2r_1d ?

> Then you perform the FFT simply by calling
> 
> call dfftw_execute(plan)
> 
> The first problem boils down to this:
> 
> call dfftw_plan_dft_c2r_1d(plan, nlong, coef, grid)
> 
> coef(1) = dcmplx(coef0,0.0d0) ! A
> coef(2:lmax_comp+1) = coef(2:lmax_comp+1) / 2.0d0
> 
> call dfftw_execute(plan) ! AA
> gridglq(i,1:nlong) = grid(1:nlong)
> 
> coef(1) = dcmplx(coef0s,0.0d0) ! B
> coef(2:lmax_comp+1) = coefs(2:lmax_comp+1)/2.0d0
> 
> call dfftw_execute(plan) ! BB
> gridglq(i_s,1:nlong) = grid(1:nlong)
> 
> 
> The problem is that the optimizer thinks the line A is redundant with line B
> (the same variable is being defined twice).

And that is correct behavior.

Try marking coef as TARGET or VOLATILE, this should inhibit this
optimization.


> The second problem I encountered is a little more mysterious. These are the
> _last_ 4 lines of the subroutine:
> 
> coef(lmax_comp+1) = coef(lmax_comp+1) + cilm(1,lmax_comp+1,lmax_comp+1)
> coef(nlong-(lmax_comp-1)) = coef(nlong-(lmax_comp-1)) &
> + cilm(2,lmax_comp+1,lmax_comp+1)
> 
> call dfftw_execute(plan)
> 
> griddh(i_eq,1:nlong) = grid(1:nlong)
> 
> The problem is that the optimizer ignores the first two lines. The reason
> for this is probably because (1) the variable coef is not explicitly noted
> in the fftw call, and (2) the variable coef is not output in the subroutine.
> Thus, the optimizer probably thinks that it doesn't need to compute the
> first two lines 

Sounds reasonable.

> So, in summary, I believe that the GCC9 optimizer is not working correctly
> because it doesn't realize that the function call dfftw_execute(plan)
> actually depends on the variables coef and grid. Given that my code has
> worked well with all other versions of GCC, I suspect that there has been a
> change in how the optimizer works.

I assume that your program was always non-conforming, and that gcc
has simply gotten better at finding optimization opportunities.

[Bug fortran/87797] Enhancement: Warning for potential name clash of variables/intrinsics...

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87797

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-16
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Confirmed.

[Bug fortran/91557] [7/8/9 Regression] Bogus warning about unused dummy argument _formal_*

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Thomas Koenig  ---
Fixed on all affected branches.

Thanks a lot for the bug report!

[Bug fortran/91557] [7/8/9 Regression] Bogus warning about unused dummy argument _formal_*

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep 15 22:35:40 2019
New Revision: 275737

URL: https://gcc.gnu.org/viewcvs?rev=275737&root=gcc&view=rev
Log:
2019-09-15  Thomas Koenig  

Backport from trunk
PR fortran/91557
* trans-decl.c (generate_local_decl): Do not warn if the symbol
is artificial.
* trans-types.c (get_formal_from_actual_arglist): Set artificial
attribute on dummy arguments.

2019-09-15  Thomas Koenig  

Backport from trunk
PR fortran/91557
* gfortran.dg/warn_unused_dummy_argument_5.f90: New test.


Added:
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_5.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-decl.c
branches/gcc-7-branch/gcc/fortran/trans-types.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/91557] [7/8/9 Regression] Bogus warning about unused dummy argument _formal_*

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep 15 20:01:44 2019
New Revision: 275734

URL: https://gcc.gnu.org/viewcvs?rev=275734&root=gcc&view=rev
Log:
2019-09-15  Thomas Koenig  

Backport from trunk
PR fortran/91557
* trans-decl.c (generate_local_decl): Do not warn if the symbol
is artificial.
* trans-types.c (get_formal_from_actual_arglist): Set artificial
attribute on dummy arguments.

2019-09-15  Thomas Koenig  

Backport from trunk
PR fortran/91557
* gfortran.dg/warn_unused_dummy_argument_5.f90: New test.


Added:
   
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_5.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/fortran/trans-types.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/91557] [7/8/9 Regression] Bogus warning about unused dummy argument _formal_*

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep 15 19:48:41 2019
New Revision: 275733

URL: https://gcc.gnu.org/viewcvs?rev=275733&root=gcc&view=rev
Log:
2019-09-15  Thomas Koenig  

Backport from trunk
PR fortran/91557
* trans-decl.c (generate_local_decl): Do not warn if the symbol
is artificial.
* trans-types.c (get_formal_from_actual_arglist): Set artificial
attribute on dummy arguments.

2019-09-15  Thomas Koenig  

Backport from trunk
PR fortran/91557
* gfortran.dg/warn_unused_dummy_argument_5.f90: New test.


Added:
   
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_5.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-decl.c
branches/gcc-9-branch/gcc/fortran/trans-types.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91550] [8/9 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91550

Thomas Koenig  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |do_subscript, at|do_subscript, at
   |fortran/frontend-passes.c:2 |fortran/frontend-passes.c:2
   |652 |652

--- Comment #2 from Thomas Koenig  ---
Fixed on trunk, backports pending.

[Bug fortran/91550] [8/9/10 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91550

--- Comment #1 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep 15 14:57:48 2019
New Revision: 275729

URL: https://gcc.gnu.org/viewcvs?rev=275729&root=gcc&view=rev
Log:
2019-09-15  Thomas Koenig  

PR fortran/91550
* frontend-passes.c (do_subscript): If step equals
zero, a previuos error has been reported; do nothing
in this case.
* resolve.c (gfc_resolve_iterator): Move error checking
after type conversion.

2019-09-15  Thomas Koenig  

PR fortran/91550
* gfortran.dg/do_subscript_6.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/do_subscript_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84487] [8/9/10 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #23 from Thomas Koenig  ---
I don't really have an idea where to start working on this...

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

--- Comment #30 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Sep 15 08:43:42 2019
New Revision: 275726

URL: https://gcc.gnu.org/viewcvs?rev=275726&root=gcc&view=rev
Log:
2019-09-15  Thomas Koenig  

PR fortran/91556
* gfortran.dg/warn_argument_mismatch_1.f90: Remove.


Removed:
trunk/gcc/testsuite/gfortran.dg/warn_argument_mismatch_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #29 from Thomas Koenig  ---
I think this is resolved now.

[Bug fortran/91557] [7/8/9/10 Regression] Bogus warning about unused dummy argument _formal_*

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557

--- Comment #1 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Sep 14 20:40:55 2019
New Revision: 275719

URL: https://gcc.gnu.org/viewcvs?rev=275719&root=gcc&view=rev
Log:
2019-09-14  Thomas Koenig  

PR fortran/91557
PR fortran/91556
* frontend-passes.c (check_externals_procedure): Reformat argument
list. Use gfc_compare_actual_formal instead of gfc_procedure_use.
* gfortran.h (gfc_symbol): Add flag error.
* interface.c (gfc_compare_interfaces): Reformat.
(argument_rank_mismatch): Add where_formal argument. If it is
present, note that the error is between different calls.
(compare_parameter): Change warnings that previously dependended
on -Wargument-mismatch to unconditional.  Issue an error / warning
on type mismatch only once.  Pass where_formal to
argument_rank_mismatch for artificial variables.
(compare_actual_formal): Change warnings that previously
dependeded on -Wargument-mismatch to unconditional.
(gfc_check_typebound_override): Likewise.
(gfc_get_formal_from_actual_arglist): Set declared_at for
artificial symbol.
* invoke.texi: Extend description of -fallow-argument-mismatch.
Delete -Wargument-mismatch.
* lang.opt: Change -Wargument-mismatch to do-nothing option.
* resolve.c (resolve_structure_cons): Change warnings that
previously depended on -Wargument-mismatch to unconditional.
* trans-decl.c (generate_local_decl): Do not warn if the symbol is
artificial.

2019-09-14  Thomas Koenig  

PR fortran/91557
PR fortran/91556
* gfortran.dg/argument_checking_20.f90: New test.
* gfortran.dg/argument_checking_21.f90: New test.
* gfortran.dg/argument_checking_22.f90: New test.
* gfortran.dg/argument_checking_23.f90: New test.
* gfortran.dg/warn_unused_dummy_argument_5.f90: New test.
* gfortran.dg/bessel_3.f90: Add pattern for type mismatch.
* gfortran.dg/g77/20010519-1.f: Adjust dg-warning messages to new
handling.
* gfortran.dg/pr24823.f: Likewise.
* gfortran.dg/pr39937.f: Likewise.


Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_20.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_21.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_22.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_23.f90
trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_3.f90
trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f
trunk/gcc/testsuite/gfortran.dg/pr24823.f
trunk/gcc/testsuite/gfortran.dg/pr39937.f

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

--- Comment #28 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Sep 14 20:40:55 2019
New Revision: 275719

URL: https://gcc.gnu.org/viewcvs?rev=275719&root=gcc&view=rev
Log:
2019-09-14  Thomas Koenig  

PR fortran/91557
PR fortran/91556
* frontend-passes.c (check_externals_procedure): Reformat argument
list. Use gfc_compare_actual_formal instead of gfc_procedure_use.
* gfortran.h (gfc_symbol): Add flag error.
* interface.c (gfc_compare_interfaces): Reformat.
(argument_rank_mismatch): Add where_formal argument. If it is
present, note that the error is between different calls.
(compare_parameter): Change warnings that previously dependended
on -Wargument-mismatch to unconditional.  Issue an error / warning
on type mismatch only once.  Pass where_formal to
argument_rank_mismatch for artificial variables.
(compare_actual_formal): Change warnings that previously
dependeded on -Wargument-mismatch to unconditional.
(gfc_check_typebound_override): Likewise.
(gfc_get_formal_from_actual_arglist): Set declared_at for
artificial symbol.
* invoke.texi: Extend description of -fallow-argument-mismatch.
Delete -Wargument-mismatch.
* lang.opt: Change -Wargument-mismatch to do-nothing option.
* resolve.c (resolve_structure_cons): Change warnings that
previously depended on -Wargument-mismatch to unconditional.
* trans-decl.c (generate_local_decl): Do not warn if the symbol is
artificial.

2019-09-14  Thomas Koenig  

PR fortran/91557
PR fortran/91556
* gfortran.dg/argument_checking_20.f90: New test.
* gfortran.dg/argument_checking_21.f90: New test.
* gfortran.dg/argument_checking_22.f90: New test.
* gfortran.dg/argument_checking_23.f90: New test.
* gfortran.dg/warn_unused_dummy_argument_5.f90: New test.
* gfortran.dg/bessel_3.f90: Add pattern for type mismatch.
* gfortran.dg/g77/20010519-1.f: Adjust dg-warning messages to new
handling.
* gfortran.dg/pr24823.f: Likewise.
* gfortran.dg/pr39937.f: Likewise.


Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_20.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_21.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_22.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_23.f90
trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_3.f90
trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f
trunk/gcc/testsuite/gfortran.dg/pr24823.f
trunk/gcc/testsuite/gfortran.dg/pr39937.f

[Bug libfortran/91543] Handling stack overflow more sensibly

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543

--- Comment #3 from Thomas Koenig  ---
We could look at https://www.gnu.org/software/libsigsegv/ how to
do this, or maybe even include this as a prerequisite for libgfortran.

Haven't looked in detail yet...

[Bug fortran/91557] [7/8/9/10 Regression] Bogus warning about unused dummy argument _formal_*

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-12
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

Thomas Koenig  changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #27 from Thomas Koenig  ---
*** Bug 91731 has been marked as a duplicate of this bug. ***

[Bug fortran/91731] Configure error on building MPICH

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Thomas Koenig  ---
See PR 91556.  In the meantime, use -fallow-argument-mismatch .

I am working on a better error message.

*** This bug has been marked as a duplicate of bug 91556 ***

[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91668

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
Is this actually required?  My feeling would be that is is not, but I may well
be mistaken.

Does somebody have chapter & verse on this? And what do other compilers do?

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91646

Thomas Koenig  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
Paul, you probably know more about this than anybody else.

[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593

Thomas Koenig  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
Jerry, I am away from my computer at the moment.

Does zhis ring a bell?

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog

--- Comment #19 from Thomas Koenig  ---
As a workaround, you could compile with -Os.

Apart from that, 10 gig also seems excessive for compiling.

However, without a test case this is not a valid bug report :-| and
trying stabs in the dark like comment#17 is not likely to succeed.

Is there and way you can reduce this to something you could post?
I will omit my standard rant about closed-source benchmarks for
a change.

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

--- Comment #22 from Thomas Koenig  ---
A problem with such code is that type violations like that are likely to cause
actual wrong code issues because much of the aliasing analysis is type based...

What I could do is to

a) restrict the number of warnings for each routine to one (put a flag
   Into the gsym)

b) try to figure something out to make this harmless to the middle end... like
   passing a void* instead of a reference.

If we just continue to ignore this error, is is going to bite people sooner or
later. And wehn somevody finds that a complex  MPI code no longer works, I want
to have that warning in the build log.

Also, this sort of code is a major obstacle for LTO, If we do not fix this,
then
I might as well give up on making gfortran LTO clean.

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

--- Comment #18 from Thomas Koenig  ---
(In reply to anlauf from comment #14)
> The current solution is a bit annoying for implicitly-derived interfaces.
> 
> Consider a code like:
> 
> module foo
>   implicit none
>   type t1
>  integer :: i = 1
>   end type t1
>   type t2
>  integer :: j = 2
>   end type t2
> contains
>   subroutine s1 (x)
> type(t1) :: x
> call my_mpi_bcast_wrapper (x, storage_size (x)/8)
>   end subroutine s1
>   subroutine s2 (y)
> type(t2) :: y
> call my_mpi_bcast_wrapper (y, storage_size (y)/8)
>   end subroutine s2
> end module foo
> 
> That's perfectly legal,

This is illegal, as far as I know. The type names are different,
which makes them different types.

To quote 7.5.2.4  Determination of derived types

Two data entities have the same type if they are declared with reference to the
same derived-type definition. Data
entities also have the same type if they are declared with reference to
different derived-type definitions that specify
the same type name, all have the SEQUENCE attribute or all have the BIND
attribute, have no components
with PRIVATE accessibility, and have components that agree in order, name, and
attributes. Otherwise, they
are of different derived types.[...]

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

--- Comment #12 from Thomas Koenig  ---
(In reply to Steve Kargl from comment #11)

> Error: Type mismatch between actual argument at (1) and actual
> argument at (2) (REAL(8)/REAL(16))

That sounds _much_ better (and is also shorter). When I am back again, I will
use this and extend it to the other cases (rank, character length and maybe
others as well).

If you feel that this should be done earlier and would like to do this
yourself, that is also no problem :-)

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

--- Comment #10 from Thomas Koenig  ---
Created attachment 46776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46776&action=edit
Concept patch

Here's what a patch could look like.

With the test case, it yields

multi.f90:2186:23:

 2186 |call evolvePDF (x(0), q, f)
  |   1
..
 2362 | call evolvePDF (momentum_fraction, GeV_scale, sea_pdf)
  |2   
Error: Type mismatch between argument passed at (1) and previous call at (2)
(REAL(8)/REAL(16))
multi.f90:2192:26:

 2192 |   call evolvePDF (x(1), q, f)
  |  1
..
 2362 | call evolvePDF (momentum_fraction, GeV_scale, sea_pdf)
  |2  
Error: Type mismatch between argument passed at (1) and previous call at (2)
(REAL(8)/REAL(16))
multi.f90:2199:23:

 2199 |call evolvePDF (x(1), q, f)
  |   1
..
 2362 | call evolvePDF (momentum_fraction, GeV_scale, sea_pdf)
  |2   
Error: Type mismatch between argument passed at (1) and previous call at (2)
(REAL(8)/REAL(16))

I suppose this would be a bit more helpful.

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-27
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #9 from Thomas Koenig  ---
After r274937, the new flag -fallow-argument-mismatch can also be used.

Now, I agree that the error message can be improved - the _formal_...
argument names can be improved, it would probably a better idea
to refer to the place that the declaration came from in that case.

I'll do this, but it will probably be a couple of weeks until I can
come up with something - too many things happening in Real Life (TM)
at the moment.

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Thomas Koenig  ---
OK, I think we can mark this as fixed.

Thanks for the report!  I wasn't aware that this would open such
a can of worms...

[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
Bug 40976 depends on bug 91390, which changed state.

Bug 91390 Summary: treatment of extra parameter in a subroutine call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug libgomp/91473] Test case libgomp.fortran/appendix-a/a.28.5.f90 is invalid

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Aug 26 20:05:32 2019
New Revision: 274937

URL: https://gcc.gnu.org/viewcvs?rev=274937&root=gcc&view=rev
Log:
2019-08-26  Thomas Koenig  

PR fortran/91390
PR fortran/91473
* frontend-passes.c (gfc_check_externals): Make
gfc_errors_to_warnings conditional on -fallow-argument-mismatch.
* invoke.texi: Document -fallow-argument-mismatch.
* lang.opt: Add -fallow-argument-mismatch.

2019-08-26  Thomas Koenig  

PR fortran/91390
PR fortran/91473
* gfortran.dg/used_before_typed_4.f90: Change warning to error.
* gfortran.dg/argument_checking_20.f90: New test.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/used_before_typed_4.f90

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Aug 26 20:05:32 2019
New Revision: 274937

URL: https://gcc.gnu.org/viewcvs?rev=274937&root=gcc&view=rev
Log:
2019-08-26  Thomas Koenig  

PR fortran/91390
PR fortran/91473
* frontend-passes.c (gfc_check_externals): Make
gfc_errors_to_warnings conditional on -fallow-argument-mismatch.
* invoke.texi: Document -fallow-argument-mismatch.
* lang.opt: Add -fallow-argument-mismatch.

2019-08-26  Thomas Koenig  

PR fortran/91390
PR fortran/91473
* gfortran.dg/used_before_typed_4.f90: Change warning to error.
* gfortran.dg/argument_checking_20.f90: New test.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/used_before_typed_4.f90

[Bug fortran/91550] [8/9/10 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91550

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-26
 CC||tkoenig at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug libfortran/91543] Handling stack overflow more sensibly

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543

--- Comment #2 from Thomas Koenig  ---
(In reply to Richard Biener from comment #1)
> Did you try if -fstack-clash-protection provides a better failure mode?  It
> might be required to reliably detect that "end of the stack" case.

No, just a SIGSEGV.

[Bug libfortran/91543] New: Handling stack overflow more sensibly

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543

Bug ID: 91543
   Summary: Handling stack overflow more sensibly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

I've just been bitten by a strange segfault, which turned out to be
due to insufficient stack space with -Ofast (running nf from the
Polyhedron benchmarks).

We really need a sensible error message when that happens.
"Insufficient stack space, aborting\n" would already be enough.

Of course, not every segmentation violation is a stack overflow :-|

So, a strategy could be:

On startup, prepare a heap buffer with a sensible error message.
Also, stash away the starting address of the stack, its size and
other pertinent information, and set up a signal handler for SIGSEGV
using sigalstack().

On receiving a SIGSEGV, we could check if the segfaulting address
is indeed near the end of the stack, and if that is the case,
just do a write(2,...) with our prepared error message and exit.
Otherwise, just do the normal thing (usually, abort).

We could also increase the stack size, to avoid hitting that
particular error too soon.

What do people think?

[Bug fortran/30609] Calculating masks twice

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609

--- Comment #5 from Thomas Koenig  ---
The problem with the test case is that both sum and count
are transformational functions, i.e. they reduce the
rank.

So, ideally this would be translated into

real sum = 0.;

int count = 0;
for (i=0; i 0) {
count ++;
sum += a[i];
}
}

return sum / count;

but the scalarizer does not do that (currently), and neither
does the middle end.  It would require loop fusion.

So, it is probably not useful to do common subexpression
elimination for rank>0 expressions if they are the arguments
of transformational functions.

[Bug fortran/30609] Calculating masks twice

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #4 from Thomas Koenig  ---
Let's see.

We could do this like the function elimination pass, making
a list of eligible gfc_expr *, and then iterating over it
to find duplicates.

If we put in the gfc_expr * from top to bottom, this should
also make sure that we find any bigger expressions before
smaller expressions.

[Bug fortran/91519] [10 Regression] ICE error in 521.wrf_r

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Thomas Koenig  ---
https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg02751.html shows that
521.wrf_r is no longer failing.

Closing as fixed.

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Aug 24 21:12:45 2019
New Revision: 274902

URL: https://gcc.gnu.org/viewcvs?rev=274902&root=gcc&view=rev
Log:
2019-08-24  Thomas Koenig  

PR fortran/91390
PR fortran/91519
* frontend-passes.c (check_externals_procedure): New
function. If a procedure is not in the translation unit, create
an "interface" for it, including its formal arguments.
(check_externals_code): Use check_externals_procedure for common
code with check_externals_expr.
(check_externals_expr): Vice versa.
* gfortran.h (gfc_get_formal_from_actual-arglist): New prototype.
(gfc_compare_actual_formal): New prototype.
* interface.c (compare_actual_formal): Rename to
(gfc_compare_actual_formal): New function, make global.
(gfc_get_formal_from_actual_arglist): Make global, and move here from
* trans-types.c (get_formal_from_actual_arglist): Remove here.
(gfc_get_function_type): Use gfc_get_formal_from_actual_arglist.

2019-08-24  Thomas Koenig  

PR fortran/91390
PR fortran/91519
* gfortran.dg/bessel_3.f90: Add type mismatch errors.
* gfortran.dg/coarray_7.f90: Rename subroutines to avoid
additional errors.
* gfortran.dg/g77/20010519-1.f: Add -std=legacy. Remove
warnings for ASSIGN. Add warnings for type mismatch.
* gfortran.dg/goacc/acc_on_device-1.f95: Add -std=legacy.
Add catch-all warning.
* gfortran.dg/internal_pack_9.f90: Rename subroutine to
avoid type error.
* gfortran.dg/internal_pack_9.f90: Add -std=legacy. Add
warnings for type mismatch.
* gfortran.dg/pr39937.f: Add -std=legacy and type warnings. Move
here from
* gfortran.fortran-torture/compile/pr39937.f: Move to
gfortran.dg.


Added:
trunk/gcc/testsuite/gfortran.dg/pr39937.f
Removed:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr39937.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_3.f90
trunk/gcc/testsuite/gfortran.dg/coarray_7.f90
trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f
trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95
trunk/gcc/testsuite/gfortran.dg/internal_pack_9.f90
trunk/gcc/testsuite/gfortran.dg/pr24823.f

[Bug fortran/91519] [10 Regression] ICE error in 521.wrf_r

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519

--- Comment #11 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Aug 24 21:12:45 2019
New Revision: 274902

URL: https://gcc.gnu.org/viewcvs?rev=274902&root=gcc&view=rev
Log:
2019-08-24  Thomas Koenig  

PR fortran/91390
PR fortran/91519
* frontend-passes.c (check_externals_procedure): New
function. If a procedure is not in the translation unit, create
an "interface" for it, including its formal arguments.
(check_externals_code): Use check_externals_procedure for common
code with check_externals_expr.
(check_externals_expr): Vice versa.
* gfortran.h (gfc_get_formal_from_actual-arglist): New prototype.
(gfc_compare_actual_formal): New prototype.
* interface.c (compare_actual_formal): Rename to
(gfc_compare_actual_formal): New function, make global.
(gfc_get_formal_from_actual_arglist): Make global, and move here from
* trans-types.c (get_formal_from_actual_arglist): Remove here.
(gfc_get_function_type): Use gfc_get_formal_from_actual_arglist.

2019-08-24  Thomas Koenig  

PR fortran/91390
PR fortran/91519
* gfortran.dg/bessel_3.f90: Add type mismatch errors.
* gfortran.dg/coarray_7.f90: Rename subroutines to avoid
additional errors.
* gfortran.dg/g77/20010519-1.f: Add -std=legacy. Remove
warnings for ASSIGN. Add warnings for type mismatch.
* gfortran.dg/goacc/acc_on_device-1.f95: Add -std=legacy.
Add catch-all warning.
* gfortran.dg/internal_pack_9.f90: Rename subroutine to
avoid type error.
* gfortran.dg/internal_pack_9.f90: Add -std=legacy. Add
warnings for type mismatch.
* gfortran.dg/pr39937.f: Add -std=legacy and type warnings. Move
here from
* gfortran.fortran-torture/compile/pr39937.f: Move to
gfortran.dg.


Added:
trunk/gcc/testsuite/gfortran.dg/pr39937.f
Removed:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr39937.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_3.f90
trunk/gcc/testsuite/gfortran.dg/coarray_7.f90
trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f
trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95
trunk/gcc/testsuite/gfortran.dg/internal_pack_9.f90
trunk/gcc/testsuite/gfortran.dg/pr24823.f

[Bug fortran/91537] Memory leak involving nested allocatable derived types

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91537

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||9.2.0
 Resolution|--- |FIXED
  Known to fail||8.2.1

--- Comment #2 from Thomas Koenig  ---
I can confirm the failure with gfortran 8, by the way.

[Bug fortran/91537] Memory leak involving nested allocatable derived types

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91537

--- Comment #1 from Thomas Koenig  ---
Comment on attachment 46748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46748
Leak demonstration program

Here's the output on current trunk:

  862548
  872548
  882548
  892548
  902548
  912548
  922548
  932548
  942548
  952548
  962548
  972548
  982548
  992548
 1002548

Same output with gcc 9.

So, I think the advice would be to upgrade to gcc 9.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #17 from Thomas Koenig  ---
Simply passing on a huge number of arguments is not enough to trigger this.

Here's a perl script to generate test cases:

while ($n=shift)
{
open FOO, ">foo-$n.f90";

print FOO <

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519

--- Comment #9 from Thomas Koenig  ---
(In reply to kargl from comment #7)

> The function check_externals_expr
> is somewhat odd.  It is declared to return int, but all return
> statements are 'return 0'.  This suggests to me that proper
> declaration for this function is void.

It's a callback function for the expression walker. A non-zero
return value would mean an immediate return. From frontend-passes.c:

#define WALK_SUBEXPR(NODE) \
  do\
{   \
  result = gfc_expr_walker (&(NODE), exprfn, data); \
  if (result)   \
return result;  \
}   \
  while (0)

[Bug fortran/91519] [regression]ICE error in 521.wrf_r

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519

--- Comment #8 from Thomas Koenig  ---
Yes, the treatment of namespaces was dogdgy.

This is fixed in https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01438.html (not
yet reviewed).

HJ, does this patch also fix the original test case?

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #12 from Thomas Koenig  ---
(In reply to rguent...@suse.de from comment #11)

> > One or two dimensional?
> 
> Two or three dimensional.  I didn't review all callees and
> arguments but there seems to be a 1:1 match, so both
> callers and callees have matching argument specifications
> dimension(ims:ime,jms:jme).

Can you isolate an example where packing or unpacking occurs, but
should not? Maybe the analysis of what is contiguous and what
is not could be improved to fix this.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #10 from Thomas Koenig  ---

> Yes, but in the WRF file I see no assumed-shape arrays but all
> appear to be of dimension(low:high,...) style.

One or two dimensional?

Code like

  subroutine foo(a)
  real, intent(in), dimension(*) :: a
  end subroutine foo

  real, dimension(n,m) :: a
  call foo(a(low:high,low2,high2))

will also trigger a repack, because foo expects
a contiguous memory argument.

Code like

  real, dimension(10) :: a
  call foo(a(from:to))

should not repack, because the memory is contiguous.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #8 from Thomas Koenig  ---
This should be exposed by

module y
contains
  subroutine bar(a,n)
real, dimension(n), intent(inout) :: a
a = a + 1.0
  end subroutine bar
end module y

module x
  use y
contains
  subroutine foo(a)
real, dimension(:), intent(inout) :: a
call bar (a,size(a))
  end subroutine foo
end module x

The subroutine foo takes a descriptor, and it needs to repack
the data for passing it as a reference to bar.  The reason is
that somebody may call foo with a non-uniform stride, as in

program main
  use x
  real, dimension(10) :: a
  call random_number(a)
  call foo(a(1:10:2))
  print *,a
end program main

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-22
 CC||marxin at gcc dot gnu.org
  Component|fortran |middle-end
 Blocks||26163
 Ever confirmed|0   |1

--- Comment #5 from Thomas Koenig  ---
Well I hope somebody with access to the sources can say anything about it.

None of the gfortran maintainers has access to SPEC, so WAITING for more info.
Martin, you helped a lot in debugging PR 90539, maybe you can say if you see
the same effect?

In the meantime, the time is spent in the middle end, so I am resetting the
component.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug fortran/91512] [10 Regression] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
Summary|Fortran compile time|[10 Regression] Fortran
   |regression. |compile time regression.

--- Comment #3 from Thomas Koenig  ---
(In reply to Sunil Pandey from comment #2)

>  phase opt and generate :  47.72 ( 97%)   0.24 ( 77%)  48.04 (
> 96%)  118205 kB ( 89%)

So, phase_opt_and_generate appears to be something strange.

What the patch did was to change the way for subarrays that are
packed because they are passed to an old-style argument, like this:

module x
  implicit none
contains
  subroutine bar(a, n)
integer, intent(in) :: n
integer, intent(in), dimension(n) :: a
print *,a
  end subroutine bar
end module x

program main
  use x
  implicit none
  integer, parameter :: n = 10
  integer, dimension(n) :: a
  integer :: i
  a = [(i,i=1,n)]
  call bar(a(n:1:-1),n)
end program main

After the patch, the packing is done in the front end, which
means that the optimizers can see through it and possibly inline
the procedures, or do other optimizations.  If these optimizations
hit some quadratic (or worse) behavior, this could lead to long
compilation times.

I would assume that your code has a lot of places where code like
the above occurs, is that the case?

[Bug fortran/91512] Fortran compile time regression.

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512

--- Comment #1 from Thomas Koenig  ---
Can you show the output of your compilation when adding -ftime-report
to the options?  This will give us an idea of where the CPU cycles
are burned.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481

--- Comment #4 from Thomas Koenig  ---
Look in the gcc sources, under gcc/config/rs6000/rs6000.c .

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

--- Comment #5 from Thomas Koenig  ---
(In reply to Steve Kargl from comment #4)

> This diff will silence warnings for explicit conversion
> using REAL() and INT() for the -Wconversion option.  It
> does not silence warnings for -Wconversion-extra.

This approcach looks very good.  It might make sense to also extend it
to -Wconversion-extra.

Do you plan to commit?  If you do, this patch is OK (we can discuss
-Wconversion-extra later).

[Bug fortran/91426] Different colors for errors with multiple locations

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426

--- Comment #5 from Thomas Koenig  ---
(In reply to David Malcolm from comment #4)

> The patch I've just attached ought to do this (though it's just a crude
> prototype - it only works for the gfc_error_opt case).
> 
> With that caveat, how does the output look?

Looks _very_ good to me.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
See also https://xkcd.com/221/

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

--- Comment #6 from Thomas Koenig  ---
Created attachment 46726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46726&action=edit
Much better patch

It a) does not try to do two things at once, and b) has passed
regression-testing at least once.

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

--- Comment #5 from Thomas Koenig  ---
Created attachment 46724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46724&action=edit
Something that sort of works...

and also extends the error message with a reference to where the
mismatching procedure is defined.

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

Thomas Koenig  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
I'm currently working on this... finding a lot of interesting
cases in the test suite, in particular one where I am not sure
what to do.

The test case is gfortran.dg/goacc/acc_on_device-1.f95 , and the code is

! Have to enable optimizations, as otherwise builtins won't be expanded.
! { dg-additional-options "-O -fdump-rtl-expand" }

logical function f ()
  implicit none

  external acc_on_device
  logical (4) acc_on_device

  f = .false.
  f = f .or. acc_on_device ()
  f = f .or. acc_on_device (1, 2)
  f = f .or. acc_on_device (3.14)
  f = f .or. acc_on_device ("hello")

  return
end function f

! Unsuitable to be handled as a builtin, so we're expecting four calls.
! { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 4
"expand" } }

With my current patch, this would result in

/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:12:12:

   11 |   f = f .or. acc_on_device ()
  |2
   12 |   f = f .or. acc_on_device (1, 2)
  |1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:13:12:

   11 |   f = f .or. acc_on_device ()
  |2
   12 |   f = f .or. acc_on_device (1, 2)
   13 |   f = f .or. acc_on_device (3.14)
  |1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:14:12:

   11 |   f = f .or. acc_on_device ()
  |2
..
   14 |   f = f .or. acc_on_device ("hello")
  |1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)

where the warnings could be mitigated to a warning using -std=legacy.

Now, needless to say, this is illegal Fortran. Is the test case actually
a valid use case?  Wouldn't it be better to make this into an intrinsic
with -fopenacc? Would it be acceptable to have to set -std=legacy on that
particular use case?

[Bug fortran/91426] Different colors for errors with multiple locations

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426

--- Comment #2 from Thomas Koenig  ---
Having had occasion to look at a few hundred multi-line error messages
today, I have now changed my mind on what I would consider best :-)

I now think different colors for primary and secondary error message
(if we stick with a maximum of two) is actually quite good.

What would help a lot if the markers (1) and (2) in

Error: Duplicate statement label 10 at (1) and (2)

were also colored the same as the two markers under the
text of the program.

Would this be doable / would others also find that useful?

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390
Bug 91390 depends on bug 91443, which changed state.

Bug 91443 Summary: -Wargument-mismatch does not catch mismatch for global 
procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/91443] -Wargument-mismatch does not catch mismatch for global procedure

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Thomas Koenig  ---
Fixed on trunk.

Next step: PR 91390.

[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
Bug 40976 depends on bug 91443, which changed state.

Bug 91443 Summary: -Wargument-mismatch does not catch mismatch for global 
procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug libgomp/91473] Test case libgomp.fortran/appendix-a/a.28.5.f90 is invalid

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-17
 CC||jakub at gcc dot gnu.org
  Component|fortran |libgomp
   Target Milestone|--- |10.0
Summary|[10 regression] test case   |Test case
   |libgomp.fortran/appendix-a/ |libgomp.fortran/appendix-a/
   |a.28.5.f90 fails starting   |a.28.5.f90 is invalid
   |with r274551|
 Ever confirmed|0   |1

--- Comment #7 from Thomas Koenig  ---
The test case is "fixed".  Removed regression marker. Somebody who
knows more about OMP than I do can figure out what this test is
actually testing, and how to make it valid (if that is possible).

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Aug 17 11:57:25 2019
New Revision: 274602

URL: https://gcc.gnu.org/viewcvs?rev=274602&root=gcc&view=rev
Log:
2019-08-17  Thomas Koenig  

PR fortran/91473
* testsuite/libgomp.fortran/appendix-a/a.28.5.f90: Add
-std=legacy so invalid code in the test case is accepted.


Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.fortran/appendix-a/a.28.5.f90

[Bug fortran/91443] -Wargument-mismatch does not catch mismatch for global procedure

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443

--- Comment #4 from Thomas Koenig  ---
(In reply to Janne Blomqvist from comment #3)
> I'm seeing a failure in the testcase libgomp.fortran/appendix-a/a.28.5.f90
> which looks like it might(?) be caused by this:
> 
> $ gfortran a.28.5.f90 
> a.28.5.f90:29:20:
> 
>29 |   CALL SUB1(A)
>   |1
> Error: Rank mismatch in argument ‘x’ at (1) (rank-1 and scalar)
> 
> Or is this something else?

Yep, that's PR 91473.

I think I will just commit that one with -std=legacy...

[Bug fortran/91473] [10 regression] test case libgomp.fortran/appendix-a/a.28.5.f90 fails starting with r274551

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

--- Comment #4 from Thomas Koenig  ---
(In reply to seurer from comment #0)
> make -k check-target-libgomp
> RUNTESTFLAGS=fortran.exp=libgomp.fortran/appendix-a/a.28.5.f90
> 
> FAIL: libgomp.fortran/appendix-a/a.28.5.f90   -O  (test for excess errors)

Easy enough to "fix" with

Index: testsuite/libgomp.fortran/appendix-a/a.28.5.f90  
=== 
--- testsuite/libgomp.fortran/appendix-a/a.28.5.f90 (Revision 274370)   
+++ testsuite/libgomp.fortran/appendix-a/a.28.5.f90 (Arbeitskopie)  
@@ -1,5 +1,5 @@ 
 ! { dg-do compile }
-! { dg-options "-w" }  
+! { dg-options "-w -std=legacy" }  
 !  
 ! "-w" added as libgomp/testsuite seemingly cannot parse with  
 ! dg-warning Fortran's output. Fortran warns for "call sub1(a)" 

but the real problem is that this is illegal Fortran. You cannot have
mismatching ranks in an argument, even if it "happens" to work.

Same thing with the SPEC code, I suppose.

[Bug fortran/91443] -Wargument-mismatch does not catch mismatch for global procedure

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Aug 15 22:52:40 2019
New Revision: 274551

URL: https://gcc.gnu.org/viewcvs?rev=274551&root=gcc&view=rev
Log:
2019-08-15  Thomas Koenig  

PR fortran/91443
* frontend-passes.c (check_externals_expr): New function.
(check_externals_code): New function.
(gfc_check_externals): New function.
* gfortran.h (debug): Add prototypes for gfc_symbol * and
gfc_expr *.
(gfc_check_externals): Add prototype.
* interface.c (compare_actual_formal): Do not complain about
alternate returns if the formal argument is optional.
(gfc_procedure_use): Handle cases when an error has been issued
previously.  Break long line.
* parse.c (gfc_parse_file): Call gfc_check_externals for all
external procedures.
* resolve.c (resolve_global_procedure): Remove checking of
argument list.

2019-08-15  Thomas Koenig  

PR fortran/91443
* gfortran.dg/argument_checking_19.f90: New test.
* gfortran.dg/altreturn_10.f90: Change dg-warning to dg-error.
* gfortran.dg/dec_union_11.f90: Add -std=legacy.
* gfortran.dg/hollerith8.f90: Likewise. Remove warning for
Hollerith constant.
* gfortran.dg/integer_exponentiation_2.f90: New subroutine gee_i8;
use it to avoid type mismatches.
* gfortran.dg/pr41011.f: Add -std=legacy.
* gfortran.dg/whole_file_1.f90: Change warnings to errors.
* gfortran.dg/whole_file_2.f90: Likewise.


Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_19.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/altreturn_10.f90
trunk/gcc/testsuite/gfortran.dg/dec_union_11.f90
trunk/gcc/testsuite/gfortran.dg/hollerith8.f90
trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_2.f90
trunk/gcc/testsuite/gfortran.dg/pr41011.f
trunk/gcc/testsuite/gfortran.dg/whole_file_1.f90
trunk/gcc/testsuite/gfortran.dg/whole_file_2.f90

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Blocks||40976
 Depends on||91443
 Resolution|DUPLICATE   |---
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #3 from Thomas Koenig  ---
Changed my mind :-)

It's the next logical step after the fix for 91443 goes in.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
[Bug 40976] Merge DECL of procedure call with DECL of gfc_get_function_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443
[Bug 91443] -Wargument-mismatch does not catch mismatch for global procedure

[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
Bug 40976 depends on bug 91390, which changed state.

Bug 91390 Summary: treatment of extra parameter in a subroutine call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|DUPLICATE   |---

[Bug fortran/91443] -Wargument-mismatch does not catch mismatch for global procedure

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-14
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Created attachment 46712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46712&action=edit
Concept  patch

Here's a concept patch. It still causes a few regressions; I am currently not
sure if these point to problems with the patch or only require a few tweaks to
the testsuite.

[Bug fortran/91443] New: -Wargument-mismatch does not catch mismatch for global procedure

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443

Bug ID: 91443
   Summary: -Wargument-mismatch does not catch mismatch for global
procedure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The argument mismatch for this code

module x
contains
  subroutine a
call foo(1)
  end subroutine a
end module x

subroutine foo(a)
  real :: a
  print *,a
end subroutine foo

program main
  use x
  call a
end program main

is not caught; for this

subroutine foo(a)
  real :: a
  print *,a
end subroutine foo

module x
contains
  subroutine a
call foo(1)
  end subroutine a
end module x

program main
  use x
  call a
end program main

it is.  The problem is that, during resolution of the module, the
subroutine foo has not even been parsed yet.  Also, the global
symbol for foo is not updated during parsing / resolution.

We need to solve this if we ever want to get rid of the double
declaration problem, see PR 40976 and friends.

The best way would probably be to add a "global symbol fixup" pass
after everything in the translation unit has been resolved. Warnings
about mismatching arguments could also be done then, when we have
all the information.

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Thomas Koenig  ---
Any solution for 40976 will also fix this one.

*** This bug has been marked as a duplicate of bug 40976 ***

[Bug fortran/40976] Merge DECL of procedure call with DECL of gfc_get_function_type

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976

Thomas Koenig  changed:

   What|Removed |Added

 CC||valera.veryazov at teokem dot 
lu.s
   ||e

--- Comment #7 from Thomas Koenig  ---
*** Bug 91390 has been marked as a duplicate of this bug. ***

[Bug fortran/42122] [F03] -fdump-tree-original shows wrong static decl for functions with procptr argument

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42122

--- Comment #6 from Thomas Koenig  ---
Also crashes with -fdump-global-original:

MAIN__ setpointer main==4365== Invalid read of size 8
==4365==at 0x8F8B0D: gfc_traverse_gsymbol(gfc_gsymbol*, void
(*)(gfc_gsymbol*, void*), void*) (symbol.c:4365)
==4365==by 0x8BDAB1: gfc_parse_file() (parse.c:6374)
==4365==by 0x906D4F: gfc_be_parse_file() (f95-lang.c:204)
==4365==by 0xE35CBF: compile_file() (toplev.c:456)
==4365==by 0x829190: do_compile (toplev.c:2190)
==4365==by 0x829190: toplev::main(int, char**) (toplev.c:2325)
==4365==by 0x82CCBE: main (main.c:39)
==4365==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==4365== 
decl.f90:6:0:

6 |   end subroutine
  | 
interner Compiler-Fehler: Speicherzugriffsfehler
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode, wenn es dienlich ist.
Weitere Hinweise finden Sie unter »«.
==4365==