[Bug fortran/89647] New: Host associated procedure unable to be used as binding target

[ian_harvey at bigpond dot com]

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

Bug ID: 89647
   Summary: Host associated procedure unable to be used as binding
target
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian_harvey at bigpond dot com
  Target Milestone: ---

The following example:

  MODULE m1
IMPLICIT NONE
PUBLIC :: False
PUBLIC :: True
  CONTAINS
FUNCTION False() RESULT(b)
  LOGICAL :: b
  b = .FALSE.
END FUNCTION False

FUNCTION True() RESULT(b)
  LOGICAL :: b
  b = .TRUE.
END FUNCTION True
  END MODULE m1

  MODULE m2
USE m1
IMPLICIT NONE
TYPE, ABSTRACT :: t_parent
CONTAINS
  PROCEDURE(False), DEFERRED, NOPASS :: Binding
END TYPE t_parent
  CONTAINS
SUBROUTINE s
  TYPE, EXTENDS(t_parent) :: t_extension
  CONTAINS
PROCEDURE, NOPASS :: Binding => True
  END TYPE t_extension
END SUBROUTINE s
  END MODULE m2

when compiled with recent trunk (r269545) results in the error:

  binding.f90:28:15:

 28 |   PROCEDURE, NOPASS :: Binding => True
|   1
  Error: ‘true’ must be a module procedure or an external procedure with an
explicit interface at (1)

`True` is a module procedure, and it is available within the scope of the
subroutine by host association.

[Bug fortran/89645] No IMPLICIT type error with: ASSOCIATE( X => function() )

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #12 from janus at gcc dot gnu.org ---
It seems that not only the ICE, but also the "already declared as
EXTERNAL-PROC" errors are caused by r258347 (which has been backported to the 6
and 7 branches, unfortunately):

2018-03-07  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 10 09:34:46 2019
New Revision: 269547

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

PR fortran/87734
* symbol.c (gfc_add_procedure): Only throw an error if the
procedure has not been declared either PUBLIC or PRIVATE.

2019-03-10  Thomas Koenig  

PR fortran/87734
* gfortran.dg/public_private_module_10.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/public_private_module_10.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[Bug target/89627] Miscompiled constructor call

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
Here are the test results with the patch:
.

[Bug fortran/87734] [7/8 Regression] ICE in is_illegal_recursion check for character len= parameter

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
Summary|[7/8/9 Regression] ICE in   |[7/8 Regression] ICE in
   |is_illegal_recursion check  |is_illegal_recursion check
   |for character len=  |for character len=
   |parameter   |parameter

--- Comment #14 from Thomas Koenig  ---
Assigning to myself so I don't forget the backport.

[Bug fortran/87734] [7/8 Regression] ICE in is_illegal_recursion check for character len= parameter

[tkoenig at gcc dot gnu.org]

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

--- Comment #15 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 10 10:28:14 2019
New Revision: 269548

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

PR fortran/87734
Backort from trunk
* symbol.c (gfc_add_procedure): Only throw an error if the
procedure has not been declared either PUBLIC or PRIVATE.
* resolve.c (is_illegal_recursion): Remove an assert().

2019-03-10  Thomas Koenig  

PR fortran/87734
Backport from trunk
* gfortran.dg/public_private_module_10.f90: New test.


Added:
   
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/public_private_module_10.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/symbol.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/66089] [7/8/9 Regression] elemental dependency mishandling when class array are involved

[tkoenig at gcc dot gnu.org]

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

--- Comment #35 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 10 10:42:23 2019
New Revision: 269549

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

PR fortran/66089
* trans-array.c (gfc_scalar_elemental_arg_saved_as_reference):
Return false if a scalar tempoary is needed.
(gfc_walk_variable_expr): Fix up class refs.

2019-03-10  Thomas Koenig  

PR fortran/66089
* gfortran.dg/dependency_53.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/dependency_53.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87734] [7/8 Regression] ICE in is_illegal_recursion check for character len= parameter

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 10 11:09:30 2019
New Revision: 269550

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

PR fortran/87734
Backort from trunk
* symbol.c (gfc_add_procedure): Only throw an error if the
procedure has not been declared either PUBLIC or PRIVATE.
* resolve.c (is_illegal_recursion): Remove an assert().

2019-03-10  Thomas Koenig  

PR fortran/87734
Backport from trunk
* gfortran.dg/public_private_module_10.f90: New test.


Added:
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/public_private_module_10.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/symbol.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/87734] [7/8 Regression] ICE in is_illegal_recursion check for character len= parameter

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #17 from Thomas Koenig  ---
Fixed on all open branches, closing.

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[tkoenig at gcc dot gnu.org]

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

--- Comment #15 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 10 11:19:58 2019
New Revision: 269551

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

PR fortran/71544
Backport from trunk
* trans-types.c (gfc_typenode_for_spec) Set ts->is_c_interop of
C_PTR and C_FUNPTR.
(create_fn_spec): Mark argument as escaping if ts->is_c_interop is set.

2019-03-10  Thomas Koenig  

PR fortran/71544
Backport from trunk
* gfortran.dg/c_ptr_tests_19.f90: New test.


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

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 10 11:26:25 2019
New Revision: 269552

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

PR fortran/71544
Backport from trunk
* trans-types.c (gfc_typenode_for_spec) Set ts->is_c_interop of
C_PTR and C_FUNPTR.
(create_fn_spec): Mark argument as escaping if ts->is_c_interop is set.

2019-03-10  Thomas Koenig  

PR fortran/71544
Backport from trunk
* gfortran.dg/c_ptr_tests_19.f90: New test.


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

[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #17 from Thomas Koenig  ---
Fixed on all open branches, closing.

[Bug fortran/89601] [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|[8/9 Regression] ICE:   |[8/9 Regression] [PDT] ICE:
   |Segmentation fault (in  |Segmentation fault (in
   |resolve_component)  |resolve_component)

--- Comment #2 from janus at gcc dot gnu.org ---
This is kind of a corner case: A PDT without parameters. Thus it should be
treated just like an ordinary derived type.

[Bug fortran/89601] [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from janus at gcc dot gnu.org ---
Draft patch to get rid of the ICE:

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 31c7fb6325c..ce9c1e1b090 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -10223,7 +10223,8 @@ gfc_match_derived_decl (void)
  gfc_error_recovery ();
  gfc_error_now ("Garbage after PARAMETERIZED TYPE declaration at %C");
}
-  sym->attr.pdt_template = 1;
+  if (sym->formal)
+sym->attr.pdt_template = 1;
 }

   if (extended && !sym->components)


With this patch one gets a (correct) error on the test case:

$ gfortran-9 c0.f90 
c0.f90:8:34:

8 |  procedure (ul), pointer :: pj
  |  1
Error: Argument ‘ki’ of ‘pj’ with PASS(ki) at (1) must be of the derived type
‘q8’

The test case can be cured by adding NOPASS to the PPC declaration.

[Bug other/82704] GCC fails to download prerequisites on busybox distro (unrecognized sha512sum --check)

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Sun Mar 10 12:49:13 2019
New Revision: 269553

URL: https://gcc.gnu.org/viewcvs?rev=269553&root=gcc&view=rev
Log:
2019-03-10  Tommy Nguyen  

PR contrib/82704
* download_prerequisites: Use -c instead of --check for sha512sum.

Modified:
trunk/contrib/ChangeLog
trunk/contrib/download_prerequisites

[Bug c++/89648] [9 Regression] rejects-valid error starting with r268850

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/89648] New: [9 Regression] rejects-valid error starting with r268850

[jakub at gcc dot gnu.org]

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

Bug ID: 89648
   Summary: [9 Regression] rejects-valid error starting with
r268850
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

template  struct A { static const T e = U; };
template  struct B;
template  struct C;
template  using E = typename C::k;
template  struct F {};
template  using G = F;
template  using H = F;
template  using I = G;
template  class J {};
template  struct B> : A {};
template 
struct C> : C> {};
template  struct C<0, J> { typedef T k; };
template  E> qux (J);
struct D { template  void foo (T) {} };
void bar (...);
struct K { void baz (int &); int l; D m; int *n, o; };
template 
void quux (int, int *, D x, int *, int, int, T, U, V y, H) {
  x.foo ([=] { bar (qux (y)...); });
}
void K::baz (int &x) {
  J p;
  int q, r;
  long s;
  quux (x, &l, m, n, o, r, s, q, p, I::e> ());
}

is rejected starting with r268850.

[Bug c++/89648] [9 Regression] rejects-valid error starting with r268850

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
pr89648.C: In instantiation of ‘void quux(int, int*, D, int*, int, int, T, U,
V, H) [with T = long int; U = int; V = J; long unsigned int
...W = {0, 1}; H = F]’:
pr89648.C:26:60:   required from here
pr89648.C:20:29: error: redeclaration of ‘const J y’
   20 |   x.foo ([=] { bar (qux (y)...); });
  | ^
pr89648.C:20:29: note: ‘const J y’ previously declared here
pr89648.C:20:10: error: designator order for field ‘quux(int, int*, D, int*,
int, int, T, U, V, H) [with T = long int; U = int; V = J; long
unsigned int ...W = {0, 1}; H = F]’ does not match declaration order in ‘quux(int,
int*, D, int*, int, int, T, U, V, H) [with T = long int; U = int; V =
J; long unsigned int ...W = {0, 1}; H = F]::’
   20 |   x.foo ([=] { bar (qux (y)...); });
  |  ^~~~
pr89648.C:15:39: error: ‘void D::foo(T) [with T = quux(int, int*, D, int*, int,
int, T, U, V, H) [with T = long int; U = int; V = J; long
unsigned int ...W = {0, 1}; H = F]::]’, declared using local type ‘quux(int, int*, D, int*, int,
int, T, U, V, H) [with T = long int; U = int; V = J; long
unsigned int ...W = {0, 1}; H = F]::’, is used but never defined [-fpermissive]
   15 | struct D { template  void foo (T) {} };
  |   ^~~

[Bug c++/89648] [9 Regression] rejects-valid error starting with r268850

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
But it got fixed already with r269265.  The corresponding testcase from that PR
is nowhere close to this one, the testcase doesn't even have any constexpr.  So
I'll commit the testcase and close this as fixed.

[Bug c++/89648] [9 Regression] rejects-valid error starting with r268850

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Reduced from webkitgtk-2.23.92.

[Bug c++/89648] [9 Regression] rejects-valid error starting with r268850

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sun Mar 10 13:02:48 2019
New Revision: 269554

URL: https://gcc.gnu.org/viewcvs?rev=269554&root=gcc&view=rev
Log:
PR c++/89648
* g++.dg/cpp0x/lambda/lambda-89648.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-89648.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/89648] [9 Regression] rejects-valid error starting with r268850

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Fixed with r269265 aka PR86969 fix.

[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Running f951 under valgrind, we get with current trunk (r269549):

==27666== Memcheck, a memory error detector
==27666== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27666== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==27666== Command: /home/ig25/lib/gcc/x86_64-pc-linux-gnu/9.0.1/f951 big.f90
==27666== 
==27666== Conditional jump or move depends on uninitialised value(s)
==27666==at 0x84A598: gfc_match_decl_type_spec(gfc_typespec*, int)
(decl.c:4047)
==27666==by 0x84BA2C: gfc_match_data_decl() (decl.c:5950)
==27666==by 0x8AA8D0: match_word (parse.c:65)
==27666==by 0x8AA8D0: decode_statement() (parse.c:376)
==27666==by 0x8AE374: next_free (parse.c:1241)
==27666==by 0x8AE374: next_statement() (parse.c:1473)
==27666==by 0x8B04A4: parse_spec(gfc_statement) (parse.c:3681)
==27666==by 0x8B220C: parse_progunit(gfc_statement) (parse.c:5680)
==27666==by 0x8B25AD: parse_contained(int) (parse.c:5581)
==27666==by 0x8B329E: parse_module() (parse.c:5953)
==27666==by 0x8B36EB: gfc_parse_file() (parse.c:6256)
==27666==by 0x8FCDCF: gfc_be_parse_file() (f95-lang.c:204)
==27666==by 0xE2234F: compile_file() (toplev.c:456)
==27666==by 0x81F907: do_compile (toplev.c:2204)
==27666==by 0x81F907: toplev::main(int, char**) (toplev.c:2339)
==27666== 
==27666== Invalid read of size 1
==27666==at 0x8BC9DE: resolve_elemental_actual(gfc_expr*, gfc_code*)
(resolve.c:2160)
==27666==by 0x8CC2B2: resolve_function (resolve.c:3228)
==27666==by 0x8CC2B2: gfc_resolve_expr(gfc_expr*) (resolve.c:6866)
==27666==by 0x8CFACB: resolve_charlen(gfc_charlen*) [clone .part.0]
(resolve.c:11943)
==27666==by 0x8C09A8: resolve_charlen (resolve.c:11934)
==27666==by 0x8C09A8: resolve_types(gfc_namespace*) (resolve.c:16727)
==27666==by 0x8C0A63: resolve_types(gfc_namespace*) (resolve.c:16740)
==27666==by 0x8C5DDC: gfc_resolve(gfc_namespace*) [clone .part.0]
(resolve.c:16843)
==27666==by 0x8B3706: gfc_parse_file() (parse.c:6275)
==27666==by 0x8FCDCF: gfc_be_parse_file() (f95-lang.c:204)
==27666==by 0xE2234F: compile_file() (toplev.c:456)
==27666==by 0x81F907: do_compile (toplev.c:2204)
==27666==by 0x81F907: toplev::main(int, char**) (toplev.c:2339)
==27666==by 0x8233BE: main (main.c:39)

[...]

so I suspect that this is where the problem comes from.

[Bug fortran/89646] Spurious actual argument might interfere warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-10
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Dominique d'Humieres  ---
Started with GCC5 (no warning with 4.8 or 4.9) up to trunk (9.0).

If you ask for warnings, don't complain about false positive nor missed ones!-(

[Bug fortran/89601] [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
On second thought, the test case is probably invalid. Fortran 2018 has:

R727 derived-type-stmt is TYPE [ [ , type-attr-spec-list ] :: ] type-name [ (
type-param-name-list ) ]

Note that once the parentheses after the type name appear, the
type-param-name-list is non-optional (and cannot be empty, I guess).

This is in contrast to e.g. a SUBROUTINE declaration, where the dummy-arg-list
inside the paranthesis is optional:

R1535 subroutine-stmt is [ prefix ] SUBROUTINE subroutine-name [ ( [
dummy-arg-list ] ) [ proc-language-binding-spec ] ]

[Bug fortran/66089] [7/8 Regression] elemental dependency mishandling when class array are involved

[dominiq at lps dot ens.fr]

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

--- Comment #36 from Dominique d'Humieres  ---
Revision r269549 causes

FAIL: gfortran.dg/assumed_type_2.f90   -O0   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/assumed_type_2.f90   -O0   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/assumed_type_2.f90   -O1   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/assumed_type_2.f90   -O1   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/assumed_type_2.f90   -O2   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/assumed_type_2.f90   -O2   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/assumed_type_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/assumed_type_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/assumed_type_2.f90   -O3 -g   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/assumed_type_2.f90   -O3 -g   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/assumed_type_2.f90   -Os   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/assumed_type_2.f90   -Os   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/no_arg_check_2.f90   -O0   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/no_arg_check_2.f90   -O0   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/no_arg_check_2.f90   -O1   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/no_arg_check_2.f90   -O1   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/no_arg_check_2.f90   -O2   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/no_arg_check_2.f90   -O2   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/no_arg_check_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/no_arg_check_2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/no_arg_check_2.f90   -O3 -g   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/no_arg_check_2.f90   -O3 -g   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1
FAIL: gfortran.dg/no_arg_check_2.f90   -Os   scan-tree-dump-times original
"sub_array_assumed (D" 3
FAIL: gfortran.dg/no_arg_check_2.f90   -Os   scan-tree-dump-times original
"sub_array_assumed ((struct t1.0:. .)
array_class_t1_ptr._data.data);" 1

(see, e.g., https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg01393.html).

the 'struct t1.0' instance is replaced with a 'D' one.

I have sent yesterday a mail to the gfortran list, but my mailer is down!-(

[Bug fortran/54687] Use gcc option machinery for gfortran

[egallager at gcc dot gnu.org]

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

--- Comment #18 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #17)
> Let me have a deeper look at what can be done.

How has that deeper look been going?

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[egallager at gcc dot gnu.org]

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

--- Comment #7 from Eric Gallager  ---
(In reply to Vincent Lefèvre from comment #6)
> But this cannot apply to projects that use GNU Automake, which does not
> generate such rules. And with Automake, things are more complex in practice,
> because in the rules, there are additional options for dependency tracking.

you can still add handwritten rules in Automake Makefiles to be used alongside
the Automake-generated rules.

[Bug fortran/89647] Host associated procedure unable to be used as binding target

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-10
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

From 6 down to 4.8, the compiler emit a second error

pr89647.f90:28:44:

 PROCEDURE, NOPASS :: Binding => True
1
Error: Symbol 'true' at (1) has no IMPLICIT type

[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-03-10
 Ever confirmed|0   |1

--- Comment #7 from Dominique d'Humieres  ---
Is it fixed by r269527 or not?

[Bug fortran/66089] [7/8 Regression] elemental dependency mishandling when class array are involved

[tkoenig at gcc dot gnu.org]

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

--- Comment #37 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Mar 10 14:21:34 2019
New Revision: 269555

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

PR fortran/66089
* gfortran.dg/assumed_type_2.f90: Adapted tree dumps.
* gfortran.dg/no_arg_check_2.f90: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/assumed_type_2.f90
trunk/gcc/testsuite/gfortran.dg/no_arg_check_2.f90

[Bug fortran/66089] [7/8 Regression] elemental dependency mishandling when class array are involved

[tkoenig at gcc dot gnu.org]

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

--- Comment #38 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #36)
> Revision r269549 causes
> 
> FAIL: gfortran.dg/assumed_type_2.f90   -O0   scan-tree-dump-times original
> "sub_array_assumed (D" 3
> the 'struct t1.0' instance is repl
aced with a 'D' one.
> 
> I have sent yesterday a mail to the gfortran list, but my mailer is down!-(

Fixed now.  I'm not sure how I missed that one...

Thanks for the heads-up!

I will definitely wait for a week or two before backporting,
to allow for any other bugs introduced by r269549 to crawl out
of the woodwork...

[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 2019-03-10 10:15 a.m., dominiq at lps dot ens.fr wrote:
> Is it fixed by r269527 or not?
It's not a good fix.  r269527 simply avoids the problem on hppa-linux.

[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Dominique d'Humieres  ---
> > Is it fixed by r269527 or not?
>
> It's not a good fix.  r269527 simply avoids the problem on hppa-linux.

So let move the status to NEW.

[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
A better traceback. Part of this seems to be a use after free
problem:

=5863== Invalid read of size 1
==5863==at 0x8FEEB4: resolve_elemental_actual(gfc_expr*, gfc_code*)
(resolve.c:2160)
==5863==by 0x90160F: resolve_function(gfc_expr*) (resolve.c:3228)
==5863==by 0x909ECE: gfc_resolve_expr(gfc_expr*) (resolve.c:6866)
==5863==by 0x915AC6: resolve_charlen(gfc_charlen*) (resolve.c:11943)
==5863==by 0x921D66: resolve_types(gfc_namespace*) (resolve.c:16727)
==5863==by 0x921E24: resolve_types(gfc_namespace*) (resolve.c:16740)
==5863==by 0x92221F: gfc_resolve(gfc_namespace*) (resolve.c:16843)
==5863==by 0x8F1D04: gfc_parse_file() (parse.c:6275)
==5863==by 0x95177B: gfc_be_parse_file() (f95-lang.c:204)
==5863==by 0xED717F: compile_file() (toplev.c:456)
==5863==by 0x81F707: do_compile (toplev.c:2204)
==5863==by 0x81F707: toplev::main(int, char**) (toplev.c:2339)
==5863==by 0x8231BE: main (main.c:39)
==5863==  Address 0x58b1dc7 is 87 bytes inside a block of size 344 free'd
==5863==at 0x4C2B390: free (vg_replace_malloc.c:530)
==5863==by 0x9448FF: gfc_free_symbol(gfc_symbol*) (symbol.c:3087)
==5863==by 0x9449EE: gfc_release_symbol(gfc_symbol*) (symbol.c:3114)
==5863==by 0x8F05E0: gfc_fixup_sibling_symbols(gfc_symbol*, gfc_namespace*)
(parse.c:5492)
==5863==by 0x8F088A: parse_contained(int) (parse.c:5584)
==5863==by 0x8F126C: parse_module() (parse.c:5953)
==5863==by 0x8F1C36: gfc_parse_file() (parse.c:6248)
==5863==by 0x95177B: gfc_be_parse_file() (f95-lang.c:204)
==5863==by 0xED717F: compile_file() (toplev.c:456)
==5863==by 0x81F707: do_compile (toplev.c:2204)
==5863==by 0x81F707: toplev::main(int, char**) (toplev.c:2339)
==5863==by 0x8231BE: main (main.c:39)
==5863==  Block was alloc'd at
==5863==at 0x4C2C432: calloc (vg_replace_malloc.c:752)
==5863==by 0x189EC60: xcalloc (xmalloc.c:162)
==5863==by 0x944A15: gfc_new_symbol(char const*, gfc_namespace*)
(symbol.c:3125)
==5863==by 0x9450BA: gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) (symbol.c:3375)
==5863==by 0x94539C: gfc_get_ha_sym_tree(char const*, gfc_symtree**)
(symbol.c:3468)
==5863==by 0x8F8677: gfc_match_rvalue(gfc_expr**) (primary.c:3349)
==5863==by 0x8BCC54: match_primary(gfc_expr**) (matchexp.c:157)
==5863==by 0x8BCD67: match_level_1(gfc_expr**) (matchexp.c:211)
==5863==by 0x8BCE29: match_mult_operand(gfc_expr**) (matchexp.c:267)
==5863==by 0x8BD034: match_add_operand(gfc_expr**) (matchexp.c:356)
==5863==by 0x8BD2F4: match_level_2(gfc_expr**) (matchexp.c:480)
==5863==by 0x8BD486: match_level_3(gfc_expr**) (matchexp.c:551)
==5863==

[Bug c++/88102] Implement P0542R5, C++20 contracts

[emsr at gcc dot gnu.org]

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

--- Comment #1 from emsr at gcc dot gnu.org ---
I saw this through reddit:

https://gitlab.com/lock3/gcc-new.git branch origin/contracts-jac-kona

This user has several interesting branches of contracts and concepts!

Wiki: http://gummif.github.io/blog/contract_code_gen.html

[Bug c++/88102] Implement P0542R5, C++20 contracts

[emsr at gcc dot gnu.org]

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

--- Comment #2 from emsr at gcc dot gnu.org ---
The Wiki I noted was a 3rd party one.
This is the wiki connected to the repo:

https://gitlab.com/lock3/gcc-new/wikis/contract-assertions

[Bug tree-optimization/85459] [8/9 Regression] Larger code generated from GMP template meta-programming

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Author: jamborm
Date: Sun Mar 10 16:20:06 2019
New Revision: 269556

URL: https://gcc.gnu.org/viewcvs?rev=269556&root=gcc&view=rev
Log:
Make SRA less strict with memcpy performing MEM_REFs

2019-03-10  Martin Jambor  

PR tree-optimization/85762
PR tree-optimization/87008
PR tree-optimization/85459
* tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool
it points to if there is a type changing MEM_REF.  Adjust all callers.
(build_accesses_from_assign): Disable total scalarization if
contains_vce_or_bfcref_p returns true through the new parameter, for
both rhs and lhs.

testsuite/
* g++.dg/tree-ssa/pr87008.C: New test.
* gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere.


Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr87008.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/guality/pr54970.c
trunk/gcc/tree-sra.c

[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Author: jamborm
Date: Sun Mar 10 16:20:06 2019
New Revision: 269556

URL: https://gcc.gnu.org/viewcvs?rev=269556&root=gcc&view=rev
Log:
Make SRA less strict with memcpy performing MEM_REFs

2019-03-10  Martin Jambor  

PR tree-optimization/85762
PR tree-optimization/87008
PR tree-optimization/85459
* tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool
it points to if there is a type changing MEM_REF.  Adjust all callers.
(build_accesses_from_assign): Disable total scalarization if
contains_vce_or_bfcref_p returns true through the new parameter, for
both rhs and lhs.

testsuite/
* g++.dg/tree-ssa/pr87008.C: New test.
* gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere.


Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr87008.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/guality/pr54970.c
trunk/gcc/tree-sra.c

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Sun Mar 10 16:20:06 2019
New Revision: 269556

URL: https://gcc.gnu.org/viewcvs?rev=269556&root=gcc&view=rev
Log:
Make SRA less strict with memcpy performing MEM_REFs

2019-03-10  Martin Jambor  

PR tree-optimization/85762
PR tree-optimization/87008
PR tree-optimization/85459
* tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool
it points to if there is a type changing MEM_REF.  Adjust all callers.
(build_accesses_from_assign): Disable total scalarization if
contains_vce_or_bfcref_p returns true through the new parameter, for
both rhs and lhs.

testsuite/
* g++.dg/tree-ssa/pr87008.C: New test.
* gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere.


Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr87008.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/guality/pr54970.c
trunk/gcc/tree-sra.c

[Bug tree-optimization/89649] New: [9 Regression] r269458 FAILs g++.dg/pr80481.C, scan-assembler-not vmovaps

[ubizjak at gmail dot com]

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

Bug ID: 89649
   Summary: [9 Regression] r269458 FAILs g++.dg/pr80481.C,
scan-assembler-not vmovaps
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Release r269458:

2019-04-07  Richard Biener  

PR middle-end/89618
* cfgloopmanip.c (copy_loop_info): Copy forgotten fields.
* tree-inline.c (copy_loops): Simplify.

* gcc.target/i386/pr89618.c: New testcase.

regressed g++.dg/pr80481.C, scan-assembler-not vmovaps

[Bug d/88958] ICE in walk_aliased_vdefs_1, at tree-ssa-alias.c:2887

[ibuclaw at gcc dot gnu.org]

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

--- Comment #5 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Sun Mar 10 16:29:48 2019
New Revision: 269557

URL: https://gcc.gnu.org/viewcvs?rev=269557&root=gcc&view=rev
Log:
PR d/88958
d/dmd: Merge upstream dmd 0fc786f49

Backport fix to disallow passing functions as parameters.

Fixes https://gcc.gnu.org/PR88958

Reviewed-on: https://github.com/dlang/dmd/pull/9437

Added:
trunk/gcc/testsuite/gdc.test/fail_compilation/test19608.d
Modified:
trunk/gcc/d/dmd/MERGE
trunk/gcc/d/dmd/expressionsem.c

[Bug d/88958] ICE in walk_aliased_vdefs_1, at tree-ssa-alias.c:2887

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Buclaw  ---
Fixed in r269557.

[Bug tree-optimization/89649] [9 Regression] r269458 FAILs g++.dg/pr80481.C, scan-assembler-not vmovaps

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
CCs added.

[Bug d/89016] ICE in ArrayLiteralExp::toStringExp, at d/dmd/expression.c:3873

[ibuclaw at gcc dot gnu.org]

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

--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Sun Mar 10 17:25:18 2019
New Revision: 269560

URL: https://gcc.gnu.org/viewcvs?rev=269560&root=gcc&view=rev
Log:
PR d/89016
d/dmd: Merge upstream dmd da26db819

Backports supplementary fix for ICE on importing deprecated modules.

Updates https://gcc.gnu.org/PR89016

Reviewed-on: https://github.com/dlang/dmd/pull/9436

Added:
trunk/gcc/testsuite/gdc.test/fail_compilation/imports/fail19609d.d
Modified:
trunk/gcc/d/dmd/MERGE
trunk/gcc/d/dmd/dimport.c
trunk/gcc/testsuite/gdc.test/fail_compilation/fail19609.d

[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Trying some bisection.

r257267 was ok, r258291 showed the is_illegal_recursion bug and
also shows the error with that removed.

To be continued...

[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> Trying some bisection.
>
> r257267 was ok, r258291 showed the is_illegal_recursion bug and
> also shows the error with that removed.
>
> To be continued...

No ICE with r257407+2 patches (2018-02-06), ICE with r257500+3 patches
(2018-02-08).

[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---

> No ICE with r257407+2 patches (2018-02-06), ICE with r257500+3 patches
> (2018-02-08).

Bisection shows that r257459 fails, r257458 works. This also
makes sense because r257459 deals with that general area.

[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
This "fixes" this PR, of course bringing back
the original problem (PR82049).

Index: match.c
===
--- match.c (Revision 269552)
+++ match.c (Arbeitskopie)
@@ -2122,8 +2122,10 @@
   ts->type = BT_CHARACTER;

   m = gfc_match_char_spec (ts);
+#if 0
   if (ts->u.cl && ts->u.cl->length)
gfc_resolve_expr (ts->u.cl->length);
+#endif

   if (m == MATCH_NO)
m = MATCH_YES;

Next, to see what gfc_resolve_expr is doing wrong here.

[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #10 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #9)
> This "fixes" this PR, of course bringing back
> the original problem (PR82049).

Or rather, not bringing it back.  I assume that
one of Harald's patches fixed this another way in
the meantime.

[Bug ipa/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
(In reply to Martin Liška from comment #8)
> (In reply to David Malcolm from comment #7)
> > (In reply to Martin Liška from comment #6)
> > > David: Are you planning to send for it?
> > I'm not sure what you mean by this, sorry.
> 
> I'm sorry for bad formulation. I was asking whether you're planning to send
> a patch candidate that you presented in #c4?

Sorry, no; I'd prefer to leave this to someone more familiar with the cgraph
code.

[Bug target/89650] New: [9 Regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:1055 since r269119

[marxin at gcc dot gnu.org]

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

Bug ID: 89650
   Summary: [9 Regression] ICE in pre_and_rev_post_order_compute,
at cfganal.c:1055 since r269119
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE:

$ cat partial.ii
int d, e;
struct g {
  float f;
  g(float h) : f(h + d) {}
  ~g() {}
};
struct i {
  int a;
  int b : 4;
  int &c;
  i(int h) : a(), b(), c(h) {}
};
int main() {
  i j(e);
  g k[]{1, 2};
}

$ g++ -Werror partial.ii -fnon-call-exceptions -flive-range-shrinkage -fno-dce
-O2 -fno-tree-dce -mavx512vbmi
during RTL pass: lr_shrinkage
partial.ii: In function ‘int main()’:
partial.ii:16:1: internal compiler error: in pre_and_rev_post_order_compute, at
cfganal.c:1055
   16 | }
  | ^
0x6b3f68 pre_and_rev_post_order_compute(int*, int*, bool)
/home/marxin/Programming/gcc/gcc/cfganal.c:1054
0xac856c init_alias_analysis()
/home/marxin/Programming/gcc/gcc/alias.c:3321
0x1778e91 sched_init()
/home/marxin/Programming/gcc/gcc/haifa-sched.c:7315
0x177a5fd haifa_sched_init()
/home/marxin/Programming/gcc/gcc/haifa-sched.c:7352
0xee4c1a schedule_insns()
/home/marxin/Programming/gcc/gcc/sched-rgn.c:3507
0xee532b schedule_insns()
/home/marxin/Programming/gcc/gcc/sched-rgn.c:3501
0xee532b rest_of_handle_live_range_shrinkage
/home/marxin/Programming/gcc/gcc/sched-rgn.c:3703
0xee532b execute
/home/marxin/Programming/gcc/gcc/sched-rgn.c:3790
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/89650] [9 Regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:1055 since r269119

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2019-3-10
 CC||hjl at gcc dot gnu.org
  Known to work||8.3.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug c++/88475] -E -fdirectives-only clashes with raw strings

[mail at milianw dot de]

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

Milian Wolff  changed:

   What|Removed |Added

 CC||mail at milianw dot de

--- Comment #4 from Milian Wolff  ---
this breaks distributed compilation with icecream, cf.:
https://github.com/icecc/icecream/issues/451

[Bug c++/88475] -E -fdirectives-only clashes with raw strings

[linux at carewolf dot com]

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

--- Comment #5 from Allan Jensen  ---
Note, you can fix the conflict with icecc by setting ICEC_REMOTE_CPP=0

Icecc will only do this to enable the remote cpp feature.

[Bug libstdc++/89641] std::atomic no longer works

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45929&action=edit
gcc9-pr89641.patch

I think the following patch should fix it, but if these issues didn't show up
(for all the changed spots) in some test when libstdc++ is tested in c++2a
mode, then we need better testsuite coverage for this.

[Bug c++/89074] valid pointer equality constexpr comparison rejected

[jbassett271 at gmail dot com]

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

Justin Bassett  changed:

   What|Removed |Added

 CC||jbassett271 at gmail dot com

--- Comment #2 from Justin Bassett  ---
I also hit this bug: https://godbolt.org/z/EAinjd

template 
struct foo {
static inline constexpr bool bar = {};
};

namespace {
constexpr bool const* asdf1 = &foo::bar;
constexpr bool const* asdf2 = &foo::bar;
}

static_assert(asdf1 != asdf2);

[Bug fortran/87045] pointer to array of character

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch that moves the check submitted:

https://gcc.gnu.org/ml/fortran/2019-03/msg00050.html

[Bug d/87824] x86_64-linux multilib issues

[ibuclaw at gcc dot gnu.org]

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

--- Comment #24 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Sun Mar 10 21:55:30 2019
New Revision: 269561

URL: https://gcc.gnu.org/viewcvs?rev=269561&root=gcc&view=rev
Log:
PR d/87824
d/dmd: Merge upstream dmd fcc235e8e

Associative arrays are value types, which are not covariant with the
pointer type typeof(null).

Updates https://gcc.gnu.org/PR87824

Reviewed-on: https://github.com/dlang/dmd/pull/9435

Modified:
trunk/gcc/d/dmd/MERGE
trunk/gcc/d/dmd/mtype.c
trunk/gcc/testsuite/gdc.test/runnable/nulltype.d

[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
gfc_verify_binding_labels seems strange.

First, I am not sure what to make of

/* Verify that any binding labels used in a given namespace do not collide
   with the names or binding labels of any global symbols.

As far as I read the standard, there is no harm in names
colliding - binding labels have their separate namespace.

The logic follows from the comment. 

For the subroutine s()  bind(C, name="f")

this

  gsym = gfc_find_case_gsymbol (gfc_gsym_root, sym->binding_label);

looks for a name, and

  if (!gsym)
gsym = gfc_get_gsymbol (sym->binding_label);

creates it.

We would probably be better off putting the C binding
labels into a separate space.

[Bug target/68924] No intrinsic for x86 `MOVQ m64, %xmm` in 32bit mode.

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Mar 10 22:59:31 2019
New Revision: 269562

URL: https://gcc.gnu.org/viewcvs?rev=269562&root=gcc&view=rev
Log:
PR target/68924
* config/i386/sse.md (*vec_extractv2di_0_sse):
Add (=r,x) alternative and corresponding splitter.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug target/68924] No intrinsic for x86 `MOVQ m64, %xmm` in 32bit mode.

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #6)
> Please report this problem in the another PR (it is the case of missing v->r
> alternative in *vec_extractv2di_0_sse pattern for SSE4+, where we can split
> directly to movd/pextrd).

Also fixed for gcc-9.

[Bug tree-optimization/88283] ICE in try_improve_iv_set, at tree-ssa-loop-ivopts.c:6677

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
It is not target-specific. I can reproduce it for powerpc w/ -m32 -O3
-floop-parallelize-all -fno-tree-dominator-opts -mcpu=power6 --param
loop-max-datarefs-for-datadeps=60 --param max-completely-peeled-insns=200
--param sccvn-max-alias-queries-per-access=10 w/ at least gcc 9.0 and 8.2.

[Bug fortran/89651] New: OpenMP private array uninitialized warning with -O flag

[jfeng33 at hotmail dot com]

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

Bug ID: 89651
   Summary: OpenMP private array uninitialized warning with -O
flag
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jfeng33 at hotmail dot com
  Target Milestone: ---

A private array variable generates an uninitialized warning when compiled with
-O, -O1, -O2, -O3. Without optimization flag, no error.
==
program omp_array_private
  use omp_lib

  integer ::  n
  real, allocatable :: t(:)
  real :: s

  n=10
  allocate(t(n),source=0.0)

!$omp parallel private(t)

s=sum(t)

!$omp end parallel

end program omp_array_private
==

compile flag : gfortran -O3 -fopenmp   -Wall

++
Results:


Warning: ‘t.dim[0].lbound’ may be used uninitialized in this function
[-Wmaybe-uninitialized]

Warning: ‘t.dim[0].ubound’ may be used uninitialized in this function
[-Wmaybe-uninitialized]


Warning: ‘t.offset’ may be used uninitialized in this function
[-Wmaybe-uninitialized]

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #8 from Vincent Lefèvre  ---
(In reply to Eric Gallager from comment #7)
> you can still add handwritten rules in Automake Makefiles to be used
> alongside the Automake-generated rules.

But if the goal is to replace the compilation lines, this is not possible.