[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'

[mathias at gaunard dot com]

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

Mathias Gaunard  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Mathias Gaunard  ---
Works with 8.3, was apparently fixed at some point.

[Bug libfortran/77278] Use LTO for libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #21 from Thomas Koenig  ---
(In reply to Jan Hubicka from comment #20)
> OK, the mismatched declaration types are:
> void  (struct array01_integer(kind=4) &, float & restrict,
> logical(kind=4) *)
> and
> void  (struct gfc_array_i4 * restrict, struct gfc_array_r4 * restrict,
> GFC_LOGICAL_4)
> 
> The mismatch happens in the last parameter that is logical(kind=4) and
> GFC_LOGICAL_4.

Thanks for looking into this.

One question: What do I have to do to get at this type of information,
and the following tree type dump?  What exactly would I have to
run?  (I looked around, but could not find any info).


> So mixing up enum and pointer to enum.

> Fixing C source to expect pointer to enum makes warning to go away, but
> looking at the gimple produced, it really just seems in bug in fortran FE
> declaring the function incorrectly? It seems to really just pass 0 instead
> of pointer to 0:
> _gfortran_minloc0_4_r4 (, _40, 0);


It was certainly the inention to pass a value.

However, I tried doing this with this little patchlet

Index: intrinsic.c
===
--- intrinsic.c (Revision 271843)
+++ intrinsic.c (Arbeitskopie)
@@ -2614,6 +2614,8 @@ add_functions (void)
   msk, BT_LOGICAL, dl, OPTIONAL, kind, BT_INTEGER, di, OPTIONAL,
   bck, BT_LOGICAL, dl, OPTIONAL);

+  set_attr_value (5, false, false, false, false, true);
+
   make_generic ("minloc", GFC_ISYM_MINLOC, GFC_STD_F95);

   add_sym_3red ("minval", GFC_ISYM_MINVAL, CLASS_TRANSFORMATIONAL, ACTUAL_NO,
BT_REAL, dr, GFC_STD_F95,

and ended up with

minloc.f90:5: warning: type of '_gfortran_minloc0_4_r4' does not match original
declaration [-Wlto-type-mismatch]
5 |   m1 = minloc(a)
  | 
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: type mismatch
in parameter 3
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: type
'GFC_LOGICAL_4' should match type 'logical(kind=4)'
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: 'minloc0_4_r4'
was previously declared here
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: code may be
misoptimized unless '-fno-strict-aliasing' is used

Now, currently GFC_LOGICAL_4 is just a typedef for GFC_INTEGER_4, which
in turn is just a typedef for int.  Could this be the source of the
trouble here?  And what could we do about a GFC_LOGICAL_2 and so on?

[Bug c++/79917] Internal compiler error with variadic template and concepts, internal compiler error: in tsubst_constraint, at cp/constraint.cc:1956

[david at doublewise dot net]

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

David Stone  changed:

   What|Removed |Added

 CC||david at doublewise dot net

--- Comment #1 from David Stone  ---
Reconfirmed for 9.1. Updated reproduction:

template
concept bool C = true;

struct S {
template
static void f() {
}
};

void foo() {
S::f();
}





: In substitution of 'template  requires  C... static
void S::f() [with c = {}]':

:11:10:   required from here

:6:14: internal compiler error: in tsubst_constraint, at
cp/constraint.cc:1948

6 |  static void f() {

  |  ^






See it live: https://godbolt.org/z/cSCotJ

[Bug c++/68812] [concepts] bogus mismatched argument pack lengths

[david at doublewise dot net]

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

David Stone  changed:

   What|Removed |Added

 CC||david at doublewise dot net

--- Comment #1 from David Stone  ---
Reconfirmed on 9.1. This bug manifests even if you change the member function
from a constructor to anything else. The bug does not show up if you pass a
single template argument to the type, but does show up if you pass 0 arguments
or more than 1 argument.

Slightly simplified reproducing:

template
struct S {
template requires(... and (s == f))
static void F() {
}
};

void foo(S<>) {}




See it live: https://godbolt.org/z/SlmBEp

[Bug c/90751] -fpatchtable-function-entry broken on hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Created attachment 46453
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46453=edit
Patch

Testsuite change.

[Bug c/90751] -fpatchtable-function-entry broken on hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #3 from John David Anglin  ---
Created attachment 46452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46452=edit
Patch

Backend change.

[Bug tree-optimization/90753] New: missing -Warray-bounds with an extern index in out-of-bounds range

[msebor at gcc dot gnu.org]

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

Bug ID: 90753
   Summary: missing -Warray-bounds with an extern index in
out-of-bounds range
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Only the out-of-bounds access in f() below is diagnosed.  The same invalid
access in g() is not.  The 

$ cat a.c && gcc -O2 -S -Wall -Wextra a.c
extern char a[4];

int f (int i)
{
  if (i < 9 || 99 < i)
i = 9;

  return a[i];
}

int g (void)
{
  extern int i;

  if (i < 9 || 99 < i)
i = 9;

  return a[i];
}
a.c: In function ‘f’:
a.c:8:11: warning: array subscript 9 is above array bounds of ‘char[4]’
[-Warray-bounds]
8 |   return a[i];
  |  ~^~~
a.c:1:13: note: while referencing ‘a’
1 | extern char a[4];
  | ^

The VRP dump for f shows

i_4: int [9, 99]
...
 [local count: 1073741824]:
# i_4 = PHI <9(2), i_5(D)(3)>
_3 = a[i_4];
_7 = (int) _3;
return _7;
  }

while the same dump for g:

i.3_4: VARYING
...
 [local count: 1073741824]:
i.3_4 = i;
_5 = a[i.3_4];
_9 = (int) _5;
return _9;
  }

For some reason the range for the index is not available in g.

[Bug target/78263] Compile failure with AltiVec library on PPC64le and -std=c++11 flag

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #12 from Bill Schmidt  ---
Fixed.

[Bug target/78263] Compile failure with AltiVec library on PPC64le and -std=c++11 flag

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Jun  4 21:52:32 2019
New Revision: 271927

URL: https://gcc.gnu.org/viewcvs?rev=271927=gcc=rev
Log:
[gcc]

2019-06-04  Bill Schmidt  

PR target/78263
* config/rs6000/altivec.h: Don't #define vector, pixel, bool for
C++ with strict ANSI requirements.

[gcc/testsuite]

2019-06-04  Bill Schmidt  

PR target/78263
* g++.target/powerpc: New directory.
* g++.target/powerpc/powerpc.exp: New test driver.
* g++.target/powerpc/undef-bool-3.C: New.


Added:
trunk/gcc/testsuite/g++.target/powerpc/
trunk/gcc/testsuite/g++.target/powerpc/powerpc.exp
trunk/gcc/testsuite/g++.target/powerpc/undef-bool-3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/63149] wrong auto deduction from braced-init-list

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch
 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00194.html

[Bug c++/90750] [9/10 Regression] ICE in cp_default_conversion, at cp/typeck.c:2162

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-04
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r268851.

[Bug c++/90749] [8/9/10 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r260972.

[Bug c++/90748] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:15564

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-04
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r266224.

[Bug c++/85577] list-initialization chooses initializer-list constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dushistov at mail dot ru

--- Comment #7 from Jonathan Wakely  ---
*** Bug 71205 has been marked as a duplicate of this bug. ***

[Bug c++/71205] c++14 wrong constructor resolution

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Yes, this is another case where GCC is doing what the resolution of DR 2137
says to do, and nobody likes it.

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

[Bug tree-optimization/90752] missing -Warray-bounds accessing the result of string functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-04
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/90752] New: missing -Warray-bounds accessing the result of string functions

[msebor at gcc dot gnu.org]

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

Bug ID: 90752
   Summary: missing -Warray-bounds accessing the result of string
functions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC doesn't diagnose any of the out-of-bounds accesses in the functions below
or any others like it that involved string built-ins.  The VRP pass has
sufficient information to issue -Warray-bounds, it simply doesn't consider
these cases.  They can be easily detected by extending
vrp_prop::check_mem_ref() to consider the first argument of each built-in call.
 (For bounded functions like stpncpy that return a pointer to the last copied
character, it should also consider the bound.)

extern char a[4];

int f (const void *s, unsigned n)
{
  char *p = __builtin_memcpy (a, s, n);
  return p[-1];   // missing -Warray-bounds
}

int g (const char *s)
{
  char *p = __builtin_stpcpy (a, s);
  return p[-5];   // missing -Warray-bounds
}

int h (const char *s)
{
  char *p = __builtin_strcpy (a, s);
  return p[4];   // missing -Warray-bounds
}

[Bug target/51654] C++ preprocessor bug with -maltivec and typedefs involving 'vector'

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #7 from Segher Boessenkool  ---
Is this still an issue?

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89260,
   ||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=24567

--- Comment #7 from Eric Gallager  ---
(In reply to ohaiziejohwahkeezuoz from comment #5)
> Since the assertion is in `ld`, I've also reported the issue with some new
> details here https://sourceware.org/bugzilla/show_bug.cgi?id=24567

This was fixed.

[Bug fortran/89531] Possible memory corruption in the gfortran front-end

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
Does this still fail?

[Bug target/90639] [10 Regression] Boostrap failure with recent trunk

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Fixed.  This won't need backporting; it's not necessary without the -many
removal patch, and that won't be backported.

[Bug c/90751] -fpatchtable-function-entry broken on hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc

[svens at stackframe dot org]

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

--- Comment #1 from Sven Schnelle  ---
John David Anglin  can provide a fix for this issue.

[Bug c/90751] -fpatchtable-function-entry broken on hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc

[svens at stackframe dot org]

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

--- Comment #2 from Sven Schnelle  ---
John David Anglin  can provide a fix for this issue.

[Bug c/90751] New: -fpatchtable-function-entry broken on hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc

[svens at stackframe dot org]

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

Bug ID: 90751
   Summary: -fpatchtable-function-entry  broken on
hppa-linux-gnu-gcc/hppa64-linux-gnu-gcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: svens at stackframe dot org
  Target Milestone: ---

$ hppa64-linux-gnu-gcc  -fpatchable-function-entry=6,3 test.c -c -o /tmp/test.o

The disassembly shows that it ignores the second argument, and places the
function label wrong:

$ hppa-linux-gnu-objdump -d /tmp/test.o

/tmp/test.o: file format elf32-hppa-linux


Disassembly of section .text:

 :
   0:   08 00 02 40 nop
   4:   08 00 02 40 nop
   8:   08 00 02 40 nop
   c:   08 00 02 40 nop
  10:   08 00 02 40 nop
  14:   08 00 02 40 nop

0018 :
  18:   6b c2 3f d9 stw rp,-14(sp)
  1c:   08 03 02 41 copy r3,r1
  20:   08 1e 02 43 copy sp,r3
  24:   6f c1 01 00 stw,ma r1,80(sp)
  28:   34 18 00 20 ldi 10,r24

$ hppa-linux-gnu-gcc -v   
Using built-in specs.
COLLECT_GCC=hppa-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/hppa-linux-gnu/10/lto-wrapper
Target: hppa-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-4'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c
--prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libssp
--disable-libitm --disable-libsanitizer --disable-libquadmath
--disable-libquadmath-support --enable-plugin --with-system-zlib
--disable-libphobos --enable-multiarch --disable-werror --disable-libstdcxx-pch
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=hppa-linux-gnu --program-prefix=hppa-linux-gnu-
--includedir=/usr/hppa-linux-gnu/include : (reconfigured) ../src/configure -v
--enable-languages=c --prefix=/usr --with-gcc-major-version-only
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libssp --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-multiarch
--disable-werror --disable-libstdcxx-pch --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=hppa-linux-gnu
--program-prefix=hppa-linux-gnu- --includedir=/usr/hppa-linux-gnu/include :
(reconfigured) ../src/configure -v --prefix=/usr --with-gcc-major-version-only
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libssp --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-multiarch
--disable-werror --disable-libstdcxx-pch --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=hppa-linux-gnu
--program-prefix=hppa-linux-gnu- --includedir=/usr/hppa-linux-gnu/include
build_alias=x86_64-linux-gnu host_alias=x86_64-linux-gnu
target_alias=hppa-linux-gnu --enable-languages=c,lto --no-create --no-recursion
Thread model: posix
gcc version 10.0.0 20190604 (experimental) (GCC)

[Bug c++/90747] [8/9/10 Regression] Internal compiler error: Error reporting routines re-entered.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|--- |8.4
Summary|Internal compiler error:|[8/9/10 Regression]
   |Error reporting routines|Internal compiler error:
   |re-entered. |Error reporting routines
   ||re-entered.

[Bug c++/90747] Internal compiler error: Error reporting routines re-entered.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.

With -Wreturn-type, started with r253600.  Before:

90747.C: In instantiation of ‘decltype (e((* f))) e(b) [with
 = a; d = int; decltype (e((* f))) = int]’:
90747.C:5:28:   required from here
90747.C:4:73: warning: no return statement in function returning non-void
[-Wreturn-type]
 template  auto e(b f) -> decltype(e(*f)) {}
 ^

[Bug c++/90750] New: [9/10 Regression] ICE in cp_default_conversion, at cp/typeck.c:2162

[gs...@t-online.de]

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

Bug ID: 90750
   Summary: [9/10 Regression] ICE in cp_default_conversion, at
cp/typeck.c:2162
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190210 and 20190217 :


$ cat z1.cc
template  struct S;
template  struct T
{
  using A = S;
  using A::b;
  char* __attribute__((aligned(b))) c;
};


$ g++-10-20190602 -c z1.cc
z1.cc:6:37: internal compiler error: Segmentation fault
6 |   char* __attribute__((aligned(b))) c;
  | ^
0xb917ef crash_signal
../../gcc/toplev.c:326
0x733bce cp_default_conversion
../../gcc/cp/typeck.c:2162
0x79c064 common_handle_aligned_attribute
../../gcc/c-family/c-attribs.c:2006
0x7485f7 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:719
0x63bcac grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:11302
0x651d2d grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/cp/decl2.c:823
0x6ca5e9 cp_parser_member_declaration
../../gcc/cp/parser.c:24774
0x6a831a cp_parser_member_specification_opt
../../gcc/cp/parser.c:24247
0x6a831a cp_parser_class_specifier_1
../../gcc/cp/parser.c:23388
0x6a9f11 cp_parser_class_specifier
../../gcc/cp/parser.c:23650
0x6a9f11 cp_parser_type_specifier
../../gcc/cp/parser.c:17412
0x6aaaf4 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14108
0x6c88b5 cp_parser_single_declaration
../../gcc/cp/parser.c:28153
0x6c8c3c cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:27834
0x6c9247 cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:28082
0x6c9247 cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:28101
0x6cbdb9 cp_parser_declaration
../../gcc/cp/parser.c:13171
0x6cc401 cp_parser_translation_unit
../../gcc/cp/parser.c:4690
0x6cc401 c_parse_file()
../../gcc/cp/parser.c:41176
0x78a7a0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156

[Bug c++/90749] New: [8/9/10 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462

[gs...@t-online.de]

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

Bug ID: 90749
   Summary: [8/9/10 Regression] ICE in enclosing_instantiation_of,
at cp/pt.c:13462
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180525 and 20180615 :


$ cat z1.cc
template 
void foo ()
{
  static int i {100};
  struct { int a {i++}; } b {};
}
int main ()
{
  foo<0> ();
}


$ g++-7 -c z1.cc
$
$ g++-10-20190602 -c z1.cc
z1.cc: In instantiation of 'void foo() [with int n = 0]':
z1.cc:9:11:   required from here
z1.cc:4:14: internal compiler error: in enclosing_instantiation_of, at
cp/pt.c:13462
4 |   static int i {100};
  |  ^
0x6d2f1d enclosing_instantiation_of
../../gcc/cp/pt.c:13462
0x6ee2e7 tsubst_decl
../../gcc/cp/pt.c:13825
0x6ed64c tsubst_copy
../../gcc/cp/pt.c:15681
0x6dfdde tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19474
0x6e17d9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19597
0x6e0032 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18455
0x6e1806 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19413
0x6699d5 get_nsdmi(tree_node*, bool, int)
../../gcc/cp/init.c:604
0x7427a0 process_init_constructor_record
../../gcc/cp/typeck2.c:1584
0x7427a0 process_init_constructor
../../gcc/cp/typeck2.c:1841
0x7427a0 digest_init_r
../../gcc/cp/typeck2.c:1239
0x7437c0 digest_init_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/typeck2.c:1284
0x7437c0 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:824
0x64750d check_initializer
../../gcc/cp/decl.c:6568
0x648812 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7242
0x6eb412 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17173
0x6e8da1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17036
0x6e9a11 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17330
0x6e7cfc instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24769
0x6fd48b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24885

[Bug c++/90748] New: [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:15564

[gs...@t-online.de]

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

Bug ID: 90748
   Summary: [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:15564
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 2018 and 20181118 :
(gcc-6 silently accepts it)


$ cat z1.cc
template  class A
{
  void e ();
  bool f (int() noexcept(e)) { return 0; }
};
A<> b;


$ g++-10-20190602 -c z1.cc
z1.cc: In instantiation of 'class A<>':
z1.cc:6:5:   required from here
z1.cc:4:26: internal compiler error: in tsubst_copy, at cp/pt.c:15564
4 |   bool f (int() noexcept(e)) { return 0; }
  |  ^
0x6ed7d2 tsubst_copy
../../gcc/cp/pt.c:15564
0x6dfdde tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19474
0x6e00ea tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18369
0x6e0531 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18347
0x6dfe42 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19253
0x6f011c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18247
0x6f011c tsubst_exception_specification
../../gcc/cp/pt.c:14298
0x6e3d55 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14952
0x6e4251 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14463
0x6e3129 tsubst_arg_types
../../gcc/cp/pt.c:14061
0x6e31d7 tsubst_arg_types
../../gcc/vec.h:989
0x6e31d7 tsubst_arg_types
../../gcc/cp/pt.c:14030
0x6e3565 tsubst_arg_types
../../gcc/cp/pt.c:14027
0x6e3565 tsubst_function_type
../../gcc/cp/pt.c:14202
0x6e3d29 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14947
0x6f32c7 tsubst_function_decl
../../gcc/cp/pt.c:13052
0x6ed919 tsubst_decl
../../gcc/cp/pt.c:13489
0x6e4107 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14390
0x6fc4e8 instantiate_class_template_1
../../gcc/cp/pt.c:11229
0x6fc4e8 instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:11534

[Bug c++/90747] Internal compiler error: Error reporting routines re-entered.

[mbelivea at redhat dot com]

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

--- Comment #1 from Matthew Beliveau  ---
Adding missing return on line 4 lets it compile.

[Bug c++/90747] New: Internal compiler error: Error reporting routines re-entered.

[mbelivea at redhat dot com]

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

Bug ID: 90747
   Summary: Internal compiler error: Error reporting routines
re-entered.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mbelivea at redhat dot com
  Target Milestone: ---

struct a {};
template  struct b { a operator*(); };
template  c e(d);
template  auto e(b f) -> decltype(e(*f)) {}
void blah() { e(b{}); }

$ ./cc1plus -quiet f.ii
‘
Internal compiler error: Error reporting routines re-entered.
0x9d0882 push_tinst_level_loc
/home/mbelivea/src/gcc/gcc/cp/pt.c:10258
0x9d09e1 push_tinst_level
/home/mbelivea/src/gcc/gcc/cp/pt.c:10301
0xa02c62 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/mbelivea/src/gcc/gcc/cp/pt.c:20200
0x850f06 add_template_candidate_real
/home/mbelivea/src/gcc/gcc/cp/call.c:3315
0x85188c add_template_candidate
/home/mbelivea/src/gcc/gcc/cp/call.c:3400
0x85188c add_candidates
/home/mbelivea/src/gcc/gcc/cp/call.c:5724
0x856ea7 add_candidates
/home/mbelivea/src/gcc/gcc/cp/call.c:4388
0x856ea7 perform_overload_resolution
/home/mbelivea/src/gcc/gcc/cp/call.c:4396
0x85a245 build_new_function_call(tree_node*, vec**, int)
/home/mbelivea/src/gcc/gcc/cp/call.c:4470
0xa44a2d finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mbelivea/src/gcc/gcc/cp/semantics.c:2584
0x9fd7bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mbelivea/src/gcc/gcc/cp/pt.c:19093
0x9e8091 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mbelivea/src/gcc/gcc/cp/pt.c:15140
0x9e3f50 tsubst_function_type
/home/mbelivea/src/gcc/gcc/cp/pt.c:14167
0x9e7337 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mbelivea/src/gcc/gcc/cp/pt.c:14947
0xa02d0a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/mbelivea/src/gcc/gcc/cp/pt.c:20212
0x850f06 add_template_candidate_real
/home/mbelivea/src/gcc/gcc/cp/call.c:3315
0x85188c add_template_candidate
/home/mbelivea/src/gcc/gcc/cp/call.c:3400
0x85188c add_candidates
/home/mbelivea/src/gcc/gcc/cp/call.c:5724
0x856ea7 add_candidates
/home/mbelivea/src/gcc/gcc/cp/call.c:4388
0x856ea7 perform_overload_resolution
/home/mbelivea/src/gcc/gcc/cp/call.c:4396
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ ./cc1plus -quiet f.ii
‘
Internal compiler error: Error reporting routines re-entered.
0x9d0882 push_tinst_level_loc
/home/mbelivea/src/gcc/gcc/cp/pt.c:10258
0x9d09e1 push_tinst_level
/home/mbelivea/src/gcc/gcc/cp/pt.c:10301
0xa02c62 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/mbelivea/src/gcc/gcc/cp/pt.c:20200
0x850f06 add_template_candidate_real
/home/mbelivea/src/gcc/gcc/cp/call.c:3315
0x85188c add_template_candidate
/home/mbelivea/src/gcc/gcc/cp/call.c:3400
0x85188c add_candidates
/home/mbelivea/src/gcc/gcc/cp/call.c:5724
0x856ea7 add_candidates
/home/mbelivea/src/gcc/gcc/cp/call.c:4388
0x856ea7 perform_overload_resolution
/home/mbelivea/src/gcc/gcc/cp/call.c:4396
0x85a245 build_new_function_call(tree_node*, vec**, int)
/home/mbelivea/src/gcc/gcc/cp/call.c:4470
0xa44a2d finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mbelivea/src/gcc/gcc/cp/semantics.c:2584
0x9fd7bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mbelivea/src/gcc/gcc/cp/pt.c:19093
0x9e8091 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mbelivea/src/gcc/gcc/cp/pt.c:15140
0x9e3f50 tsubst_function_type
/home/mbelivea/src/gcc/gcc/cp/pt.c:14167
0x9e7337 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mbelivea/src/gcc/gcc/cp/pt.c:14947
0xa02d0a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/mbelivea/src/gcc/gcc/cp/pt.c:20212
0x850f06 add_template_candidate_real
/home/mbelivea/src/gcc/gcc/cp/call.c:3315
0x85188c add_template_candidate
/home/mbelivea/src/gcc/gcc/cp/call.c:3400
0x85188c add_candidates
/home/mbelivea/src/gcc/gcc/cp/call.c:5724
0x856ea7 add_candidates
/home/mbelivea/src/gcc/gcc/cp/call.c:4388
0x856ea7 perform_overload_resolution

[Bug libfortran/77278] Use LTO for libgfortran

[hubicka at gcc dot gnu.org]

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

--- Comment #20 from Jan Hubicka  ---
OK, the mismatched declaration types are:
void  (struct array01_integer(kind=4) &, float & restrict,
logical(kind=4) *)
and
void  (struct gfc_array_i4 * restrict, struct gfc_array_r4 * restrict,
GFC_LOGICAL_4)

The mismatch happens in the last parameter that is logical(kind=4) and
GFC_LOGICAL_4.

 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76616c78 precision:1 min  max 
pointer_to_this >
unsigned DI
size  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set 3 structural-equality>


  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76821690 precision:32 min  max  context 
pointer_to_this >

So mixing up enum and pointer to enum.
Fixing C source to expect pointer to enum makes warning to go away, but looking
at the gimple produced, it really just seems in bug in fortran FE declaring the
function incorrectly? It seems to really just pass 0 instead of pointer to 0:
_gfortran_minloc0_4_r4 (, _40, 0);

Honza

[Bug fortran/90741] Unreachable second '__builtin_malloc' for scalar 'allocatable'

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> The first malloc call is from expansion of allocate statement, while the
> second one is for the a = 50 assignment which must allocate on the
> assignment if not allocated already.  I don't see any bug.

Jakub is correct here.  Fortran has (re)allocation on assignment.
You can disable the (re)allocation with the -fno-realloc-lhs option.

This simple code

% cat a.f90
program foo
   integer, allocatable :: i
   allocate(i)
   i = 42
end program foo

compiled with

%  gfcx -c -fdump-tree-original -fno-realloc-lhs a.f90

yields (shortening error messages for brevity)

{
  integer(kind=4) * i;

  i = 0B;
  if (i != 0B)
{
  _gfortran_runtime_error_at ("Attempting to allocate ...");
}
  else
{
  i = (integer(kind=4) *) __builtin_malloc (4);
  if (i == 0B)
{
  _gfortran_os_error ("exceed memory limit");
}
}
  *i = 42;
}

[Bug libfortran/77278] Use LTO for libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #19 from Thomas Koenig  ---
(In reply to rguent...@suse.de from comment #15)
  Btw, I wonder what happens at
> the call boundary inside a single fortran module where
> the caller passes a dim[2] array to a subroutine
> handling arbitrary dimension arrays?  I suspect the
> IL would have the very same TBAA issue.  Can you produce
> a fortran testcase that exposes such a case so we can have a
> look into the details?

Here is a test case:

module x
  implicit none
contains
  subroutine foo(a)
real, dimension(..) :: a
print *,shape(a)
  end subroutine foo
  subroutine bar
real, dimension(2,2) :: a
real, dimension(3,3,3) :: b
call foo(a)
call foo(b)
  end subroutine bar
end module x

program main
  use x
  call bar
end program main

Looking at the *.original tree dump, we have

bar ()
{
  real(kind=4) a[4];
  real(kind=4) b[27];

  {
struct array02_real(kind=4) parm.0;

[...]

foo ();
  }

  {
struct array03_real(kind=4) parm.1;

[...]

foo ();
  }

and

foo (struct array15_real(kind=4) & restrict a)
{
  {
struct __st_parameter_dt dt_parm.2;

This does not really look very healthy (but it is not warned about).

[Bug libfortran/77278] Use LTO for libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #18 from Thomas Koenig  ---
Created attachment 46451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46451=edit
Preprocessed source of library file for LTO mismatch

Hi,

here is a test case (preprocessed source from libgfortran).  To reproduce,
use the test program

$ cat minloc.f90
program main
  real, dimension(10,10) :: a
  integer, dimension(2) :: m1
  call random_number(a)
  m1 = minloc(a)
  print *,m1
end program main

and compile/link with

$ gfortran -static-libgfortran -flto -O3 minloc.f90 minloc0_4_r4.i 
minloc.f90:5: warning: type of '_gfortran_minloc0_4_r4' does not match original
declaration [-Wlto-type-mismatch]
5 |   m1 = minloc(a)
  | 
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: type mismatch
in parameter 3
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: 'minloc0_4_r4'
was previously declared here
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: code may be
misoptimized unless '-fno-strict-aliasing' is used

[Bug target/57309] Spill code degrades vectorized loop for 437.leslie3d on PPC64

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Bill Schmidt  ---
Closing this as we're not too fussed about 4.9 anymore.

[Bug sanitizer/90746] New: __sanitizer_cov_trace_pc should not be tail called

[dvyukov at google dot com]

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

Bug ID: 90746
   Summary: __sanitizer_cov_trace_pc should not be tail called
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dvyukov at google dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

-fsanitize-coverage=trace-pc emits calls to __sanitizer_cov_trace_pc into every
basic block. This function is meant to use __builtin_return_address to get
caller PC and trace them. However, with -O2 __sanitizer_cov_trace_pc calls are
tailcall-optimized, instead of callq __sanitizer_cov_trace_pc we get jmpq
__sanitizer_cov_trace_pc, as the result __builtin_return_address returns
caller-caller PC instead of caller PC. This leads to 2 problems:
1. The executed basic block is not traced.
2. When we generate coverage reports we used to assume that we will trace only
PCs that point to callq __sanitizer_cov_trace_pc. It makes it easy to (1)
pre-symbolize all possible PCs and (2) calculate coverage percent as the ratio
of covered call sites to all call sites. But these assumptions break when the
callback is tail called.

Here is a repro:

// test.c
#include 
#include 

__attribute__((noinline)) void foo()
{
if (!rand()) {
printf("%s\n", __func__);
return;
}
}

int main()
{
foo();
}

// cov.c
#include 

void __sanitizer_cov_trace_pc()
{
printf("0x%lx\n", __builtin_return_address(0) - 5);
}

Then run:
gcc test.c -O2 -g -fsanitize-coverage=trace-pc -c && gcc cov.c test.o &&
./a.out | addr2line -fae a.out

0x004004a4
main
test.c:14
0x004005c4
foo
test.c:6
0x004004ab
main
test.c:14

vs:
gcc test.c -O2 -fno-optimize-sibling-calls -g -fsanitize-coverage=trace-pc -c
&& gcc cov.c test.o && ./a.out | addr2line -fae a.out

0x004004a4
main
test.c:14
0x004005c4
foo
test.c:6
0x004005d2
foo
test.c:6

In the first invocation the second basic block of foo is not traced.

I've found this piece of code which looks relevant:

// tree-tailcall.c
static void
find_tail_calls (basic_block bb, struct tailcall **ret)
...
  /* We found the call, check whether it is suitable.  */
  tail_recursion = false;
  func = gimple_call_fndecl (call);
  if (func
  && !fndecl_built_in_p (func)
  && recursive_call_p (current_function_decl, func))
{
...
tail_recursion = true;
}

But I am not sure what's the right way to change it. __sanitizer_cov_trace_pc
is kinda builtin, but not exactly.

"noreturn" attribute should prevent tail calls, but we can't mark
__sanitizer_cov_trace_pc as noreturn. Is there a special bit for just tail
calls?

[Bug libstdc++/90745] [9/10 Regression] std::tuple::operator= parameter causes error outside immediate context

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-04
  Known to work||8.3.1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |9.2
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0

[Bug libstdc++/90745] New: [9/10 Regression] std::tuple::operator= parameter causes error outside immediate context

[redi at gcc dot gnu.org]

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

Bug ID: 90745
   Summary: [9/10 Regression] std::tuple::operator= parameter
causes error outside immediate context
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This compiled with gcc 8, but fails with 9 and trunk:


#include 

template 
struct Expr
{
Op op;
std::tuple t;

using R = decltype(op(*(std::get<0>(t).p), *(std::get<1>(t).p)));
operator R() { return op(*(std::get<0>(t).p), *(std::get<1>(t).p)); }
};

template  inline auto
expr(Op && op, P0 && p0, P1 && p1)
{
return Expr { op, { p0, p1 } };
}

template  inline void
for_each(Op && op, P0 && p0, P1 && p1)
{
expr(op, p0, p1);
}

template 
struct cell
{
typename V::value_type * p;

cell(typename V::value_type * p_): p { p_ } {}

template  decltype(auto) operator =(X && x)
{
for_each([](auto && y, auto && x)
 {
 y = x;
 },
*this, x);
}
};

template 
struct view
{
T * p;
using value_type = T;
cell> iter() { return p; }
cell> iter() const { return p; }
view(T * p_): p(p_) {}
};

/*
/opt/gcc-9.1/bin/g++ -o mem-fn.o -c -std=c++17 -Wall -Werror
-ftemplate-backtrace-limit=0 mem-fn.C
/opt/gcc-8.3/bin/g++ -o mem-fn.o -c -std=c++17 -Wall -Werror
-ftemplate-backtrace-limit=0 mem-fn.C
*/

int main()
{
{
int cdata[3] = {44, 44, 44};
int ndata[3] = {77, 77, 77};
view const c {cdata}; // 8.3 - 9.1 case [const or not]
view n {ndata};
for_each([](auto && n, auto && c) { n = c; }, n.iter(), c.iter());
}
}


e.cc: In instantiation of 'cell::operator=(X&&) [with X = cell >&; V = view]:: [with auto:1 =
const int&; auto:2 = const int&]':
e.cc:10:11:   required from 'struct Expr::operator=(X&&) [with X =
cell >&; V = view]::&,
cell >&, cell >&>'
e.cc:17:46:   required from 'auto expr(Op&&, P0&&, P1&&) [with Op =
cell::operator=(X&&) [with X = cell >&; V = view]::&; P0 = cell >&; P1 =
cell >&]'
e.cc:23:9:   required from 'void for_each(Op&&, P0&&, P1&&) [with Op =
cell::operator=(X&&) [with X = cell >&; V = view]::; P0 = cell >&; P1 =
cell >&]'
e.cc:35:17:   required from 'decltype(auto) cell::operator=(X&&) [with X =
cell >&; V = view]'
/home/jwakely/gcc/9/include/c++/9.1.1/type_traits:1017:12:   [ skipping 2
instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ]
/home/jwakely/gcc/9/include/c++/9.1.1/tuple:901:31:   required from 'static
constexpr bool std::tuple<_T1, _T2>::__assignable() [with _U1 = cell
>&; _U2 = cell >&; _T1 = cell >&; _T2 =
cell >&]'
/home/jwakely/gcc/9/include/c++/9.1.1/tuple:1205:74:   required from 'class
std::tuple >&, cell >&>'
e.cc:8:24:   required from 'struct Expr&,
cell >&, cell >&>'
e.cc:17:46:   required from 'auto expr(Op&&, P0&&, P1&&) [with Op =
main()::&; P0 = cell >&; P1 =
cell >&]'
e.cc:23:9:   required from 'void for_each(Op&&, P0&&, P1&&) [with Op =
main()::; P0 = cell >; P1 =
cell >]'
e.cc:65:73:   required from here
e.cc:37:24: error: assignment of read-only reference 'y'
   37 |  y = x;
  |  ~~^~~



I think the problem is the assignment operator, which gets errors outside the
immediate context. The problem almost certainly started with r263625

[Bug target/78263] Compile failure with AltiVec library on PPC64le and -std=c++11 flag

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Patch (finally) submitted here: 
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00184.html

[Bug c++/90736] [9/10 Regression] Bogus error with alignas

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Plain int is enough:

constexpr int fn(const int b) { return b; }
constexpr int c = fn(alignof(int));
alignas(c) char d;

We have an INTEGER_CST with const int type; that doesn't seem entirely correct.
 Maybe adjust_temp_type or cp_fold_convert should be tweaked not to produce
cv-qualified _CSTs.

[Bug c++/60531] template function not resolved when comparing functions

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Jun  4 14:48:38 2019
New Revision: 271910

URL: https://gcc.gnu.org/viewcvs?rev=271910=gcc=rev
Log:
PR c++/60531 - Wrong error about unresolved overloaded function

For PR60531, GCC wrongly rejects function templates with explicitly
specified template arguments as overloaded. They are resolved by
resolve_nondeduced_context, which is normally called by
cp_default_conversion through decay_conversion, but the latter have
extra effects making them unusable here. Calling the former directly
does work.

* typeck.c (cp_build_binary_op): See if overload can be resolved.
(cp_build_unary_op): Ditto.

* g++.dg/template/operator15.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/operator15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug debug/90733] [8/9/10 Regression] ICE in simplify_subreg, at simplify-rtx.c:6440

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 46450
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46450=edit
gcc10-pr90733.patch

Untested fix.

[Bug driver/90730] -fdump-tree-gimple-optimized-... accepted

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 4 Jun 2019, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90730
> 
> Martin Sebor  changed:
> 
>What|Removed |Added
> 
>Keywords||documentation
>  Status|RESOLVED|UNCONFIRMED
>  Resolution|INVALID |---
> 
> --- Comment #3 from Martin Sebor  ---
> I see I missed that 'all' is also an 'option' in -fdump-tree- so all the
> examples I gave in comment #0 and comment #1 are actually valid.  Talk about
> confusing!  Even so, I don't think resolving this report as invalid is
> justified.
> 
> -fdump-tree- is documented to have the following forms:
> 
>   -fdump-tree-all
>   -fdump-tree-switch
>   -fdump-tree-switch-options
>   -fdump-tree-switch-options=filename
> 
> The 'switch' part is undocumented but it presumably corresponds to the name of
> the pass/dump (which does not include 'all').  The 'options' are documented 
> and
> include 'all'.  Given that, the following is invalid:
> 
>   -fdump-tree-all-optimized-all
> 
> because 'all' is not the name of a pass ('switch') and -fdump-tree-all doesn't
> take options.  So either it should be rejected or the documentation should be
> updated to mention that 'switch' can be 'all' or the name of a pass,
> analogously to what -fdump-lang-all documents.

The documentation should be adjusted if you think that's really necessary.

> Incidentally, -fdump-rtl-pass refers to a pass, while -fdump-tree-switch (and
> others) to a switch.  Besides inconsistent it's also confusing: unless there 
> is
> a difference between a 'pass' and a 'switch' here they should all use the same
> term.  That way, the term could also be documented in the same place for all
> these options (in a generic way).
> 
> On the subject of -fdump-rtl-all, these are also accepted:
> 
>   -fdump-rtl-all-all
>   -fdump-rtl-combine-all
>   -fdump-rtl-combine-details
> 
> but this gets a warning:
> 
>   -fdump-rtl-all-combine: warning: ignoring unknown option ‘combine’
> 
> The dump produced by -fdump-rtl-combine-all is more detailed so it looks like
> besides an RTL pass name, -fdump-rtl- also takes 'options' similarly to
> -fdump-tree-.  This should also be documented.

Yes.  Feel free to improve the documentation.  But functionality wise
everything works as designed.

[Bug driver/90730] -fdump-tree-gimple-optimized-... accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Martin Sebor  ---
I see I missed that 'all' is also an 'option' in -fdump-tree- so all the
examples I gave in comment #0 and comment #1 are actually valid.  Talk about
confusing!  Even so, I don't think resolving this report as invalid is
justified.

-fdump-tree- is documented to have the following forms:

  -fdump-tree-all
  -fdump-tree-switch
  -fdump-tree-switch-options
  -fdump-tree-switch-options=filename

The 'switch' part is undocumented but it presumably corresponds to the name of
the pass/dump (which does not include 'all').  The 'options' are documented and
include 'all'.  Given that, the following is invalid:

  -fdump-tree-all-optimized-all

because 'all' is not the name of a pass ('switch') and -fdump-tree-all doesn't
take options.  So either it should be rejected or the documentation should be
updated to mention that 'switch' can be 'all' or the name of a pass,
analogously to what -fdump-lang-all documents.

Incidentally, -fdump-rtl-pass refers to a pass, while -fdump-tree-switch (and
others) to a switch.  Besides inconsistent it's also confusing: unless there is
a difference between a 'pass' and a 'switch' here they should all use the same
term.  That way, the term could also be documented in the same place for all
these options (in a generic way).

On the subject of -fdump-rtl-all, these are also accepted:

  -fdump-rtl-all-all
  -fdump-rtl-combine-all
  -fdump-rtl-combine-details

but this gets a warning:

  -fdump-rtl-all-combine: warning: ignoring unknown option ‘combine’

The dump produced by -fdump-rtl-combine-all is more detailed so it looks like
besides an RTL pass name, -fdump-rtl- also takes 'options' similarly to
-fdump-tree-.  This should also be documented.

[Bug fortran/90744] New: [9/10 Regression] Bogus length for character temporaries passed to external procedures since r268992

[trnka at scm dot com]

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

Bug ID: 90744
   Summary: [9/10 Regression] Bogus length for character
temporaries passed to external procedures since
r268992
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trnka at scm dot com
  Target Milestone: ---

The fix for PR87689 in r268992 broke some of our code that passes character
temporaries as actual arguments to external procedures. The length of the
string is not passed correctly, leading to segfaults once the external
procedure touches the string.

To reproduce, compile the following two files (gfortran -g concat-length.f90
convrs.f90) and see a segfault in convrs(). (I couldn't reduce this further.
For example, the seemingly useless "if" in DoTest() is important, convrs() has
to be called from both branches or the issue won't appear. I'd guess it's due
to some CSE/redundancy elimination, but the issue also occurs at -O0.)

external-char-length.f90

module StringModule
   implicit none

contains
   function getstr()
  character(:), allocatable :: getstr

  getstr = 'OK'
   end function
end module
module TestModule
   use StringModule
   implicit none

contains
   subroutine DoTest()
  if (.false.) then
 call convrs('A',getstr())
  else
 call convrs('B',getstr())
  end if
   end subroutine
end module
program external_char_length
   use TestModule

   implicit none

   call DoTest()
end program


convrs.f90

subroutine convrs(quanty,fromto)
   implicit none

   character(*), intent(in) :: quanty,fromto

   write(*,*) fromto
end subroutine


Comparing the dumps from a good and bad gfortran, it's evident that "slen.2" is
being passed incorrectly by reference:

--- good-85bbaeac3dd/external-char-length.f90.004t.original2019-06-04
15:39:28.440490081 +0200
+++ bad-d50eaffb899/external-char-length.f90.004t.original 2019-06-04
15:28:39.410192786 +0200
@@ -51,7 +51,7 @@
 pstr.3 = 0B;
 slen.2 = 0;
 getstr (, );
-convrs (&"B"[1]{lb: 1 sz: 1}, pstr.3, 1, slen.2);
+convrs (&"B"[1]{lb: 1 sz: 1}, pstr.3, 1, );
 __builtin_free ((void *) pstr.3);
   }
   L.3:;

[Bug fortran/90743] Device-side 'malloc' for Fortran 'allocatable' scalar

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
I don't understand how you could do that and why.
Unless you perform a whole function optimization, gimplification and omp
lowering and expansion etc. work on individual statements, there is no analysis
on what happens before or after, that is done in subsequent passes, say SRA or
FRE and others.  The code in the region could deallocate (c) or do similar
stuff, and while that might be undefined with some offloading specs under some
conditions, there are many cases where it must be valid.

[Bug fortran/90743] New: Device-side 'malloc' for Fortran 'allocatable' scalar

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90743
   Summary: Device-side 'malloc' for Fortran 'allocatable' scalar
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As '-fdump-tree-original' shows, for:

program main
  implicit none
  integer, allocatable :: c

  allocate (c)

  c = 25

  !$omp target map(from: c)
  !$acc parallel copyout(c)
  c = 52
  !$acc end parallel
  !$omp end target

  if (c /= 52) stop 2

  deallocate (c)
end program main

... we currently generate code as follows:

[...]
  *c = 25;
  #pragma omp target map(from:*c) map(alloc:c [pointer assign, bias: 0])
{
  {
{
  if (c != 0B) goto L.3;
  c = (integer(kind=4) *) __builtin_malloc (4);
  L.3:;
  *c = 52;
}
  }
}
[...]

Same for OpenACC.

At least in the case of nvptx offloading that I just tried, we're not actually
executing that 'malloc' on the device.  Will this always be the case?  Could
code generation then be changed to turn this into an 'abort', to make this less
surprising for the human reader?

---

I just saw Jakub's Comment 1 in PR90741, so I suppose the 'c = 52' assignment
is where this device-side 'malloc' is coming from.

[Bug fortran/90742] New: OpenACC/OpenMP target offloading: Fortran 'allocatable' scalars in 'firstprivate' clauses

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90742
   Summary: OpenACC/OpenMP target offloading: Fortran
'allocatable' scalars in 'firstprivate' clauses
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46449=edit
libgomp.oacc-fortran/allocatable-scalar-1.f90

For OpenACC/OpenMP target offloading, Fortran 'allocatable' scalars in
'firstprivate' clauses don't work, with nvptx offloading: "libgomp:
cuStreamSynchronize error: unspecified launch failure (perhaps abort was
called)"; see the first half of the attached test case.  Should they not work
in the same way as they do for regular data clauses; see the second half of the
attached test case?


Submitted originally as part of

"[gomp4] add support for allocatable scalars in OpenACC declare constructs"
(which in turn depends on

"[gomp4] add support for fortran allocate support with declare create", and the
patches to enable 'GOMP_MAP_FIRSTPRIVATE_INT' for OpenACC 'firstprivate'), and
recently re-submitted as part of
 '[PATCH,
OpenACC] Fortran "declare create"/allocate support for OpenACC', Cesar also
once singled out the changes to make this work (but for OpenACC only):

"[PATCH][OpenACC] Add support for firstprivate Fortran allocatable scalars".

The latter patch still applies, and makes the OpenACC (but not OpenMP) case
work by means of the following '-fdump-tree-omplower' changes:

[...]
-.omp_data_arr.28.a = 
+a.32 = a;
+.omp_data_arr.28.a = a.32;
 .omp_data_arr.28.b = 
 #pragma omp target oacc_parallel firstprivate(a) map(from:b [len:
4]) [child fn: MAIN__._omp_fn.0 (.omp_data_arr.28, .omp_data_sizes.29,
.omp_data_kinds.30)]
   {
 .omp_data_i = (const struct .omp_data_t.25 & restrict)
&.omp_data_arr.28;
 D.3974 = .omp_data_i->a;
 a.27 = *D.3974;
-a = a.27;
+a.28 = a.27;
+a = 
 a.5 = a;
 b.6 = *a.5;
[...]

I'm currently working on figuring out if that's correct (OpenACC/OpenMP
standards, and then the GCC implementation), but will appreciate any insights.  

(The old code version cited above shows what likely causes the 'SIGSEGV' on the
device: dereferencing a host pointer.)


Also need to look up how that relates to the changes done for PR77371
(),
and PR85879
(),
where the latter's commit r261025 subsumed the former's changes.

[Bug c++/87234] GCC should warn if template parameter redefines default argument

[ghleclerc at gmail dot com]

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

--- Comment #2 from Ghyslain Leclerc  ---
I wanted to add that on top of not complaining about the default parameter
redefinition, when the default parameter is provided in the definition only
(not the declaration of the template), the compilation fails.

Here is the snippet of code I used to have the bug.  Since it does not contain
any includes and the preprocessed file is basically the same, I think it's OK
to just have the code here.


template< typename T, unsigned int TSz >
T mul( T num );

template< typename T, unsigned int TSz = sizeof( T ) >
T mul( T num ) {
  return num * TSz;
}

int main() {
  return mul( 5 );
}


Given this code, the compiler fails to compile and outputs an error.  I have
done as recommended on the bug reporting page and gotten all the output.  I
will attach the files to this bug report.  Hoping it's OK.  It seems like the
two bugs might be the same or at least related.

[Bug c++/87234] GCC should warn if template parameter redefines default argument

[ghleclerc at gmail dot com]

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

Ghyslain Leclerc  changed:

   What|Removed |Added

 CC||ghleclerc at gmail dot com

--- Comment #1 from Ghyslain Leclerc  ---
Created attachment 46448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46448=edit
Output from g++ command.

Compiler output with the command
   g++-mp-9 -v -save-temps -std=c++11 bug.cpp 2> out.txt

[Bug tree-optimization/90715] ICE: tree check: expected private or shared or firstprivate or lastprivate or reduction or task_reduction or in_reduction or copyin or copyprivate or linear, have gt_expr

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I believe the 
* cp-tree.h (CP_OMP_CLAUSE_INFO): Allow for any clauses up to _condvar_ 
instead of only up to linear.   
hunk of r271907 should have fixed this.

[Bug fortran/90741] Unreachable second '__builtin_malloc' for scalar 'allocatable'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The first malloc call is from expansion of allocate statement, while the second
one is for the a = 50 assignment which must allocate on the assignment if not
allocated already.  I don't see any bug.

[Bug fortran/90741] New: Unreachable second '__builtin_malloc' for scalar 'allocatable'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 90741
   Summary: Unreachable second '__builtin_malloc' for scalar
'allocatable'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Based on trunk r271854, I noticed that for the following simple Fortran code:

program main
  implicit none
  integer, allocatable :: a

  allocate (a)

  a = 50

  deallocate (a)
end program main

... the following appears in the '-fdump-tree-original' dump:

[...]
  a = (integer(kind=4) *) __builtin_malloc (4);
  if (a == 0B)
{ 
  _gfortran_os_error (&"Allocation would exceed memory
limit"[1]{lb: 1 sz: 1});
}
}
  if (a != 0B) goto L.1;
  a = (integer(kind=4) *) __builtin_malloc (4);
  L.1:;
  *a = 50;
  if (a == 0B)
{ 
  _gfortran_runtime_error_at (&"At line 9 of file [...]"[1]{lb: 1 sz:
1}, &"Attempt to DEALLOCATE unallocated \'%s\'"[1]{lb: 1 sz: 1}, &"a"[1]{lb: 1
sz: 1});
}
  else
{ 
  __builtin_free ((void *) a);
}
  a = 0B;
}

I have not looked up where/why that second '__builtin_malloc' is emitted.  At
least in this simple case, it's unreachable, so it's not a memory leak.

[Bug libfortran/77278] Use LTO for libgfortran

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
A small self-contained example would be welcome, I can take a look why aliasing
oracle does not mess things up.

Concerning the warning, those are quite hard to do - the line information
should point to mismatched declarations, but does not since libgfortran is no
longer on the expected path.

Dumping actual type will get it output in C-like syntax which is probably not
very useful except for debugging reasons...

[Bug tree-optimization/90715] ICE: tree check: expected private or shared or firstprivate or lastprivate or reduction or task_reduction or in_reduction or copyin or copyprivate or linear, have gt_expr

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-04
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r271825, before the code was rejected:

/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/vect-simd-6.c: In
function ‘int foo(int*)’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/vect-simd-6.c:12:46:
sorry, unimplemented: ‘conditional’ modifier on ‘lastprivate’ clause not
supported yet
   12 |   #pragma omp simd lastprivate (conditional: x)
  |  ^
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/vect-simd-6.c: In
function ‘int bar(int*, int*)’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/vect-simd-6.c:23:49:
sorry, unimplemented: ‘conditional’ modifier on ‘lastprivate’ clause not
supported yet
   23 |   #pragma omp simd lastprivate (conditional: x, v)
  | ^
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/vect-simd-6.c:23:46:
sorry, unimplemented: ‘conditional’ modifier on ‘lastprivate’ clause not
supported yet
   23 |   #pragma omp simd lastprivate (conditional: x, v)
  |  ^

[Bug c++/90732] [9/10 Regression] ICE with std::apply after variable length array

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-04
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r269292.

[Bug middle-end/90733] [8/9/10 Regression] ICE in simplify_subreg, at simplify-rtx.c:6440

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-04
 CC||aoliva at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.0, 9.1.0

--- Comment #1 from Martin Liška  ---
Started with r255568.

[Bug libfortran/77278] Use LTO for libgfortran

[mjambor at suse dot cz]

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

--- Comment #16 from Martin Jambor  ---
Hi,

On Tue, Jun 04 2019, Jan Hubicka wrote:
>> 
>> Yeah, I do remember this.  I think we settled on the above
>> (previously you had dim[7] in the library I think) to be
>> compatible.  Still a C simple testcase complains:
>> 
>> typedef struct { int ndim; int dim[]; } *descp;
>> void foo (descp d);
>> 
>> void bar()
>> {
>>   struct { int ndim; int dim[2]; } desc;
>>   desc.ndim = 2;
>>   foo ();
>> }
>> 
>> t2.c: In function ‘bar’:
>> t2.c:8:8: warning: passing argument 1 of ‘foo’ from incompatible pointer 
>> type [-Wincompatible-pointer-types]
>>foo ();
>> ^
>> t2.c:2:17: note: expected ‘descp’ {aka ‘struct  *’} but 
>> argument is of type ‘struct  *’
>>  void foo (descp d);
>>~~^
>> 
>> and we probably assign different alias sets to both.
>
> Curiously enough in C version of the LTO testcase I get no warning now
> since we simplify function type and thus both pointers are turned into
> incomplete pointers and considered TBAA compatible.
> After lunch I will check why the warning triggers here.
>
> Still the alias set is different, so I think we more or less get lucky
> by using base+offset tests first since array descriptors are accessed
> directly after constant propagation of poointers.
>> 
>> Now to make aliasing happy both the Frontend and LTO have to
>> compute the same TYPE_CANONICAL for _all_ of the array
>> descriptor types.  You can either go and allocate
>> dim always to the max size statically or in the Fortran
>> FE use self-referential types (not sure if you then can
>> statically instantiate an object of such type...) or
>> rewrite all accesses to the fixed-dimension statically
>> allocated array descriptors to go via the dim[] type
>> (I think I suggested the latter elsewhere).
>> 
>> So instantiate my_descriptor and then store for further
>> use VIEW_CONVERT_EXPR  (my_descriptor).
>> 
>> I hope that doesn't defeat [IPA] optimization ...
> I think Martin's code generally gives up on type mismaches so it
> is quite possible it gives up already.

I guess I'm missing some context here (and the example above does not
contain t1.c?).  But I quickly grepped for typec_compatible_p and
useless_type_conversion_p in ipa-prop.c (and ipa-cp.c) and the code
tries to resolve issues with inserting V_C_E rather than giving up
straight away.

Martin

[Bug libfortran/77278] Use LTO for libgfortran

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Tue, 4 Jun 2019, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
> 
> --- Comment #14 from Jan Hubicka  ---
> > 
> > Yeah, I do remember this.  I think we settled on the above
> > (previously you had dim[7] in the library I think) to be
> > compatible.  Still a C simple testcase complains:
> > 
> > typedef struct { int ndim; int dim[]; } *descp;
> > void foo (descp d);
> > 
> > void bar()
> > {
> >   struct { int ndim; int dim[2]; } desc;
> >   desc.ndim = 2;
> >   foo ();
> > }
> > 
> > t2.c: In function ‘bar’:
> > t2.c:8:8: warning: passing argument 1 of ‘foo’ from incompatible pointer 
> > type [-Wincompatible-pointer-types]
> >foo ();
> > ^
> > t2.c:2:17: note: expected ‘descp’ {aka ‘struct  *’} but 
> > argument is of type ‘struct  *’
> >  void foo (descp d);
> >~~^
> > 
> > and we probably assign different alias sets to both.
> 
> Curiously enough in C version of the LTO testcase I get no warning now
> since we simplify function type and thus both pointers are turned into
> incomplete pointers and considered TBAA compatible.
> After lunch I will check why the warning triggers here.
> 
> Still the alias set is different, so I think we more or less get lucky
> by using base+offset tests first since array descriptors are accessed
> directly after constant propagation of poointers.
> > 
> > Now to make aliasing happy both the Frontend and LTO have to
> > compute the same TYPE_CANONICAL for _all_ of the array
> > descriptor types.  You can either go and allocate
> > dim always to the max size statically or in the Fortran
> > FE use self-referential types (not sure if you then can
> > statically instantiate an object of such type...) or
> > rewrite all accesses to the fixed-dimension statically
> > allocated array descriptors to go via the dim[] type
> > (I think I suggested the latter elsewhere).
> > 
> > So instantiate my_descriptor and then store for further
> > use VIEW_CONVERT_EXPR  (my_descriptor).
> > 
> > I hope that doesn't defeat [IPA] optimization ...
> I think Martin's code generally gives up on type mismaches so it
> is quite possible it gives up already.
> 
> An option would be also to teach LTO that array descriptors are
> special types aliasing with each other but not aliasing with
> anything else.

I'd rather not do that ;)  Btw, I wonder what happens at
the call boundary inside a single fortran module where
the caller passes a dim[2] array to a subroutine
handling arbitrary dimension arrays?  I suspect the
IL would have the very same TBAA issue.  Can you produce
a fortran testcase that exposes such a case so we can have a
look into the details?

[Bug c++/90740] [9/10 Regression] VLA with lamba causes an incorrect unitialized in this function warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-04
  Known to work||8.3.0
   Target Milestone|--- |9.2
Summary|VLA with lamba causes an|[9/10 Regression] VLA with
   |incorrect unitialized in|lamba causes an incorrect
   |this function warning   |unitialized in this
   ||function warning
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Hmm, plain 9.1.0 ICEs for me at -O0

t.C: In lambda function:
t.C:14:59: warning: fold-expressions only available with ‘-std=c++17’ or
‘-std=gnu++17’
   14 | bar([, ](auto&... column) { (doit(column), ...); },
out...);
  |   ^~~
during RTL pass: expand
t.C: In lambda function:
t.C:14:9: internal compiler error: in expand_expr_real_1, at expr.c:10012
   14 | bar([, ](auto&... column) { (doit(column), ...); },
out...);
  | ^
v0x5c58c8 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)

Confirmed with -O2 -Wall.  Note with checking enabled on the branch we ICE
also with -O2 -Wall:

t.C: In instantiation of ‘read(Vs& ...) [with Vs = {int}]:: [with auto:1 = {int}]’:
t.C:3:6:   required from ‘void bar(T, U ...) [with T = read(Vs& ...) [with Vs =
{int}]::; U = {int}]’
t.C:14:8:   required from ‘void read(Vs& ...) [with Vs = {int}]’
t.C:19:12:   required from here
t.C:13:10: internal compiler error: in tsubst_copy, at cp/pt.c:16185
   13 | char buf[SIZE];
  |  ^~~
0xafa361 tsubst_copy
   /space/rguenther/src/svn/gcc-9-branch/gcc/cp/pt.c:16185
0xb0df7b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   /space/rguenther/src/svn/gcc-9-branch/gcc/cp/pt.c:19612

default:
  /* We shouldn't get here, but keep going if !flag_checking.  */
  if (flag_checking)
gcc_unreachable ();

and that likely is the reason for the breakage.  The gimple dump already
shows:

read(Vs& ...) [with Vs = {int}]operator() (const
struct __lambda1 * const this, int & column#0)
{
  sizetype D.2163;
  bitsizetype D.2164;
  sizetype D.2165;
  int & out#0 [value-expr: ((const struct __lambda1 *) this)->__out#0];
  char[0:D.2163] & buf [value-expr: ((const struct __lambda1 *) this)->__buf];

  _1 = D.2153 + -1;
  D.2163 = (sizetype) _1;
  _3 = (sizetype) D.2153;
  _4 = (bitsizetype) _3;
  D.2164 = _4 * 8;
  D.2165 = (sizetype) D.2153;
  {
_7 = *column#0;
doit (_7);
  }
}

see how D.2153 is never initialized, so this is also wrong-code with
-fno-checking (and we shouldn't have this kind of continue-if-not-checking...).
ICEs are better than silent wrong-code.

We don't handle

SAVE_EXPR <(ssizetype) SIZE + -1>

not sure why.

[Bug c/90737] [8/9/10 Regression] inconsistent address of a local converted to intptr_t between callee and caller

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug c++/90736] [9/10 Regression] Bogus error with alignas

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||8.3.0
Version|unknown |9.1.0
   Target Milestone|8.4 |9.2

[Bug middle-end/90733] [8/9/10 Regression] ICE in simplify_subreg, at simplify-rtx.c:6440

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|c   |middle-end
   Target Milestone|--- |8.4

[Bug c++/90732] [9/10 Regression] ICE with std::apply after variable length array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||8.3.0
   Target Milestone|--- |9.2
Summary|[9/10 Regression - ICE with |[9/10 Regression] ICE with
   |std::apply after variable   |std::apply after variable
   |length array|length array

[Bug c++/90731] [9/10 Regression] noexcept broken for forward declarations with decltype

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||8.3.0
   Target Milestone|--- |9.2
Summary|regression - noexcept   |[9/10 Regression] noexcept
   |broken for forward  |broken for forward
   |declarations with decltype  |declarations with decltype

[Bug driver/90730] -fdump-tree-gimple-optimized-... accepted

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rguenth at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
-optimized is a valid modifier, it dumps -fopt-report-optimized into the dump
file.

I don't think anything in -all-details is ignored, you can do -details-alias
for example.

[Bug libfortran/77278] Use LTO for libgfortran

[hubicka at ucw dot cz]

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

--- Comment #14 from Jan Hubicka  ---
> 
> Yeah, I do remember this.  I think we settled on the above
> (previously you had dim[7] in the library I think) to be
> compatible.  Still a C simple testcase complains:
> 
> typedef struct { int ndim; int dim[]; } *descp;
> void foo (descp d);
> 
> void bar()
> {
>   struct { int ndim; int dim[2]; } desc;
>   desc.ndim = 2;
>   foo ();
> }
> 
> t2.c: In function ‘bar’:
> t2.c:8:8: warning: passing argument 1 of ‘foo’ from incompatible pointer 
> type [-Wincompatible-pointer-types]
>foo ();
> ^
> t2.c:2:17: note: expected ‘descp’ {aka ‘struct  *’} but 
> argument is of type ‘struct  *’
>  void foo (descp d);
>~~^
> 
> and we probably assign different alias sets to both.

Curiously enough in C version of the LTO testcase I get no warning now
since we simplify function type and thus both pointers are turned into
incomplete pointers and considered TBAA compatible.
After lunch I will check why the warning triggers here.

Still the alias set is different, so I think we more or less get lucky
by using base+offset tests first since array descriptors are accessed
directly after constant propagation of poointers.
> 
> Now to make aliasing happy both the Frontend and LTO have to
> compute the same TYPE_CANONICAL for _all_ of the array
> descriptor types.  You can either go and allocate
> dim always to the max size statically or in the Fortran
> FE use self-referential types (not sure if you then can
> statically instantiate an object of such type...) or
> rewrite all accesses to the fixed-dimension statically
> allocated array descriptors to go via the dim[] type
> (I think I suggested the latter elsewhere).
> 
> So instantiate my_descriptor and then store for further
> use VIEW_CONVERT_EXPR  (my_descriptor).
> 
> I hope that doesn't defeat [IPA] optimization ...
I think Martin's code generally gives up on type mismaches so it
is quite possible it gives up already.

An option would be also to teach LTO that array descriptors are
special types aliasing with each other but not aliasing with
anything else.

Honza

[Bug middle-end/90726] exponential behavior on SCEV results everywhere

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  4 09:05:10 2019
New Revision: 271903

URL: https://gcc.gnu.org/viewcvs?rev=271903=gcc=rev
Log:
2019-06-04  Richard Biener  

PR middle-end/90726
* tree-chrec.c (chrec_contains_symbols): Add to visited.
(tree_contains_chrecs): Likewise.
(chrec_contains_symbols_defined_in_loop): Move here and avoid
exponential behaivor from ...
* tree-scalar-evolution.c (chrec_contains_symbols_defined_in_loop):
... here.
(expression_expensive_p): Avoid exponential behavior and compute
expanded size, rejecting any expansion.
* tree-ssa-loop-ivopts.c (abnormal_ssa_name_p): Remove.
(idx_contains_abnormal_ssa_name_p): Likewise.
(contains_abnormal_ssa_name_p_1): New helper for walk_tree.
(contains_abnormal_ssa_name_p): Simplify and use
walk_tree_without_duplicates.

* gcc.dg/pr90726.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr90726.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chrec.c
trunk/gcc/tree-scalar-evolution.c
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug c++/90728] False positive Wmemset-elt-size with zero size array

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I think it's [0, -1] but eventually using an unsigned type for the domain. 
IIRC we have "pattern matching" for this in stor-layout.c

[Bug middle-end/88784] Middle end is missing some optimizations about unsigned

[ffengqi at gcc dot gnu.org]

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

--- Comment #22 from Qi Feng  ---
Two more similar ones:

x <= y  &&  x == ( 0 or XXX_MIN ) -->  x == ( 0 or XXX_MIN )
x >= y  &&  x == ( UXXX_MAX or XXX_MAX )  -->  x == ( UXXX_MAX or XXX_MAX )

[Bug d/89823] Composed message only partially translatable

[goeran at uddeborg dot se]

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

Göran Uddeborg  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Göran Uddeborg  ---
The message is removed.

[Bug libfortran/77278] Use LTO for libgfortran

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Tue, 4 Jun 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
> 
> --- Comment #12 from Thomas Koenig  ---
> In libgfortran, we have
> 
> #define GFC_ARRAY_DESCRIPTOR(type) \
> struct {\
>   type *base_addr;\
>   size_t offset;\
>   dtype_type dtype;\
>   index_type span;\
>   descriptor_dimension dim[];\
> }
> 
> and then later
> 
> typedef GFC_ARRAY_DESCRIPTOR (GFC_INTEGER_4) gfc_array_i4;
> 
> so the array descriptors expected by the libgfotran routines
> have a flexible array members.
> 
> If, in the front end, we have the equivalent of (the type name
> isn't exactly what the front end generates)
> 
> typedef struct {
>   GFC_INTEGER_4 *base_addr;\
>   size_t offset;\
>   dtype_type dtype;\
>   index_type span;\
>   descriptor_dimension dim[3];\
> } _array03_integer_4_descriptor;
> 
> _array03_integer_4_descriptor my_descriptor;

Yeah, I do remember this.  I think we settled on the above
(previously you had dim[7] in the library I think) to be
compatible.  Still a C simple testcase complains:

typedef struct { int ndim; int dim[]; } *descp;
void foo (descp d);

void bar()
{
  struct { int ndim; int dim[2]; } desc;
  desc.ndim = 2;
  foo ();
}

t2.c: In function ‘bar’:
t2.c:8:8: warning: passing argument 1 of ‘foo’ from incompatible pointer 
type [-Wincompatible-pointer-types]
   foo ();
^
t2.c:2:17: note: expected ‘descp’ {aka ‘struct  *’} but 
argument is of type ‘struct  *’
 void foo (descp d);
   ~~^

and we probably assign different alias sets to both.

Now to make aliasing happy both the Frontend and LTO have to
compute the same TYPE_CANONICAL for _all_ of the array
descriptor types.  You can either go and allocate
dim always to the max size statically or in the Fortran
FE use self-referential types (not sure if you then can
statically instantiate an object of such type...) or
rewrite all accesses to the fixed-dimension statically
allocated array descriptors to go via the dim[] type
(I think I suggested the latter elsewhere).

So instantiate my_descriptor and then store for further
use VIEW_CONVERT_EXPR  (my_descriptor).

I hope that doesn't defeat [IPA] optimization ...

> and a pointer type that corresponds to what the library
> expects, we should then be able to call
> 
> minloc_... ((gfc_array_i4 *) _descriptor, ..)
> 
> right?
> 
> I think this should probably be restricted to calling the
> library, I would feel nervous touching use code with this.

While that might silence the warning it doesn't solve the
TBAA issue that is indeed present -- the populating of
the descriptor on the fortran caller side would not
alias with reads from the passed descriptor done via
the C routine and its descriptor type.  In practice we
probably see the must-alias relationship and let the
TBAA disambiguation possibility unused but I guess we'll
quickly get less lucky...

[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  4 08:09:16 2019
New Revision: 271902

URL: https://gcc.gnu.org/viewcvs?rev=271902=gcc=rev
Log:
2019-06-04  Richard Biener  

PR tree-optimization/90738
Revert
2019-06-03  Richard Biener  

* tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Get original
full reference tree and record in ref->ref.
(vn_reference_lookup_3): Pass in original ref to
ao_ref_init_from_vn_reference.
(vn_reference_lookup): Likewise.
* tree-ssa-sccvn.h (ao_ref_init_from_vn_reference): Adjust prototype.
* tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p):
Handle non-decl bases in the original reference.

* gcc.dg/tree-ssa/alias-access-path-1.c: Scan fre1.

* gcc.dg/torture/pr90738.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr90738.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-1.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-sccvn.h

[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
OK, so this goes wrong in the sense that aliasing_component_refs_p sees
*int[] vs int[][1] but the int[][1] access has the actual reference tree
(un-valueized) int[][i].  Then we go

  if (same_p2 == 1)
{   
  poly_int64 offadj, sztmp, msztmp;
  bool reverse;
  get_ref_base_and_extent (*refp, , , , );
  offset2 -= offadj;
  get_ref_base_and_extent (base1, , , , );
  offset1 -= offadj;
  if (ranges_maybe_overlap_p (offset1, max_size1, offset2, max_size2))
{

where *refp is that variable array-ref, computing offadj == 0.  But we're
comparing apples and oranges then since msztmp != max_size2.  The above
adjustment assumes that offset/max_size correspond to the ref tree 1:1 but
they do not thus this kind of adjustment is not possible.

I guess mixing both valueized and not valueized ref isn't really possible
and we'd have to do two separate oracle queries.  At least it seems to be
a can of worms.

I'm going to revert the patch.

[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #3 from Christophe Lyon  ---
Seeing this on arm and aarch64 too.

It appeared between r271857 and r271861.

[Bug libfortran/77278] Use LTO for libgfortran

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
In libgfortran, we have

#define GFC_ARRAY_DESCRIPTOR(type) \
struct {\
  type *base_addr;\
  size_t offset;\
  dtype_type dtype;\
  index_type span;\
  descriptor_dimension dim[];\
}

and then later

typedef GFC_ARRAY_DESCRIPTOR (GFC_INTEGER_4) gfc_array_i4;

so the array descriptors expected by the libgfotran routines
have a flexible array members.

If, in the front end, we have the equivalent of (the type name
isn't exactly what the front end generates)

typedef struct {
  GFC_INTEGER_4 *base_addr;\
  size_t offset;\
  dtype_type dtype;\
  index_type span;\
  descriptor_dimension dim[3];\
} _array03_integer_4_descriptor;

_array03_integer_4_descriptor my_descriptor;

and a pointer type that corresponds to what the library
expects, we should then be able to call

minloc_... ((gfc_array_i4 *) _descriptor, ..)

right?

I think this should probably be restricted to calling the
library, I would feel nervous touching use code with this.

[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-04
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Investigating.

[Bug c++/90740] VLA with lamba causes an incorrect unitialized in this function warning

[v at vsamko dot com]

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

--- Comment #3 from Valentine  ---
Yep, it uses GCC extension.

Interesting observation that it complains about the size of buffer, that looks
to be correct as if I change to
===
char buf[SIZE];
char* pbuf = buf;
bar([pbuf, ](auto&... column) { (doit(column), ...); }, out...);
===
then warning goes away.

The warning is still erroneous, and shouldn't be there.

[Bug c++/90740] VLA with lamba causes an incorrect unitialized in this function warning

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
>Also, why does the warning refers to the variable as "" when it 
>clearly has a name?

Because it is most likely not buf but rather the size of buf that is
complaining about.

[Bug c++/90740] VLA with lamba causes an incorrect unitialized in this function warning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|diagnostic  |
  Component|middle-end  |c++
Summary|regression - Incorrect  |VLA with lamba causes an
   |warning (is used|incorrect unitialized in
   |uninitialized in this   |this function warning
   |function)   |

--- Comment #1 from Andrew Pinski  ---
Note this code uses a GCC extension of VLAs.  This is why converting SIZE to be
a const variable works and does not show the warning.  Adding const changes buf
to being a normal array definition away from VLAs.

[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
*** Bug 90544 has been marked as a duplicate of this bug. ***

[Bug bootstrap/90544] Build failure on MINGW for gcc-9.1.0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Dup.

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

[Bug c++/90740] New: regression - Incorrect warning (is used uninitialized in this function)

[v at vsamko dot com]

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

Bug ID: 90740
   Summary: regression - Incorrect warning (is used uninitialized
in this function)
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v at vsamko dot com
  Target Milestone: ---

We are not "using" `buf` there. We are passing it by reference, which is a
valid code and it shouldn't raise any warnings (for example, it can be a buffer
pointer that we pass as a destination to memcpy, and it does not need to be
initialised).

If we replace "int SIZE = 100" with "constexpr int SIZE = 100" then the warning
goes away, which doesn't make any sense.

g++ 7 and 8 don't show this warning on this code.

Also, why does the warning refers to the variable as "" when it
clearly has a name?

=
template
void bar(T t, U... u) {
t(u...);
}

template
void doit(T) {}

int SIZE = 100;

template
void read(Vs & ...out) {
char buf[SIZE];
bar([, ](auto&... column) { (doit(column), ...); }, out...);
}

int main() {
int x1;
read(x1);
}
=


source>: In lambda function:

:14:9: warning: '' is used uninitialized in this function
[-Wuninitialized]

   14 | bar([, ](auto&... column) { (doit(column), ...); },
out...);

  | ^

:13:10: note: '' was declared here

   13 | char buf[SIZE];

  |  ^~~

Compiler returned: 0

[Bug c++/90732] regression - ICE with std::apply after variable length array

[v at vsamko dot com]

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

--- Comment #1 from Valentine  ---
Simpler example without any include's:

===
volatile int SIZE = 100;

template
void bar(T t, U... u) {
t(u...);
}

template
void foo(Ts&... out) {
char buf[SIZE];
bar([, ](auto&... x) { (x, ...); }, out...);
}

int main() {
int x1;
foo(x1);
}
===

results in:

g++ test.cpp -std=c++17 -O0 
during RTL pass: expand
test.cpp: In lambda function:
test.cpp:11:9: internal compiler error: in expand_expr_real_1, at expr.c:10012
   11 | bar([, ](auto&... x) { (x, ...); }, out...);
  | ^
0x79d4d9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-9.1.0/gcc/expr.c:10012
0x1236818 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-9.1.0/gcc/expr.c:8275
0x1236818 expand_expr
../../gcc-9.1.0/gcc/expr.h:279
0x1236818 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../gcc-9.1.0/gcc/expr.c:7873
0x123082a expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-9.1.0/gcc/expr.c:8733
0x115d279 expand_gimple_stmt_1
../../gcc-9.1.0/gcc/cfgexpand.c:3789
0x115d279 expand_gimple_stmt
../../gcc-9.1.0/gcc/cfgexpand.c:3850
0x11579de expand_gimple_basic_block
../../gcc-9.1.0/gcc/cfgexpand.c:5886
0x11579de execute
../../gcc-9.1.0/gcc/cfgexpand.c:6509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libfortran/77278] Use LTO for libgfortran

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #11 from Richard Biener  ---
Honza can probably suggest ways to make the warning more to the point and how
to show the missing information (the actual argument type vs. the declared
one).