[Bug tree-optimization/95396] GCC produces incorrect code with -O3 for loops

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Target||x86_64-*-*
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-29
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
> ./xgcc -B. t.C -O2 -fopt-info -ftree-vectorize
t.C:11:20: optimized:  Inlining int c(int, int)/15 into void test()/16.
t.C:11:37: optimized: loop vectorized using 16 byte vectors
t.C:10:6: optimized: loop with 1 iterations completely unrolled (header
execution count 70866959)

caused/triggered by vectorization.

[Bug rtl-optimization/95394] [11 Regression] ICE in emit_move_insn, at expr.c:3814

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/95393] Failure to optimize loop condition arithmetic for mismatched types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-29
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Looks like phiopt fails to fold the generated MAX_EXPR.

[Bug tree-optimization/95391] [11 regression] ICE in gcc.dg/vshift-5.c since r11-689

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.0
   Last reconfirmed||2020-05-29

--- Comment #2 from Richard Biener  ---
Probably the same as the re-opened PR95356.  Two patches of mine crossed.

[Bug c++/95386] [10/11 Regression] ICE: in satisfaction_value, while compiling function with a requires clause since r10-3735-gcb57504a55015891

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

--- Comment #5 from Richard Biener  ---
Did it work with GCC 9 or why is this marked as regression?

[Bug c++/95385] GCC stop detect UBs after a divide by zero in for statement

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
We likely eliminate the dead 0/0 and 0/b instructions but fail for the one in
the loop at -O0.  As soon as the actual instruction is carried out the program
traps and obviously further runtime messages are no longer emitted.

There's no bug here.

[Bug rtl-optimization/95382] [haifa-sched][DO_PREDICATION] execution test: wrong scheduling result.

[xuemaosheng at huawei dot com]

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

--- Comment #2 from otcmaf  ---
(In reply to Richard Biener from comment #1)
> You'll likely get more help when asking on the mailing list.  Bugzilla is
> not well suited to get attention to custom modified ports.

Ok,thanks.  Do you know who is the maintainer of the DO_PREDICATION attribute
in haifa-sched.  Last time I asked on the mailing list about other issue, but I
also
got noting atterntion.

[Bug c++/95383] Poor codegen when constructing a trivial Optional

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Keywords||missed-optimization
   Last reconfirmed||2020-05-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I see the cited -O3 code-gen with -O2 on trunk.  We expand from

foo (bool b)
{
  struct Optional D.2251;
  unsigned char _7;

   [local count: 1073741824]:
  if (b_2(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  D.2251.D.2152.value = 42;

   [local count: 1073741824]:
  # _7 = PHI <1(3), 0(2)>
  MEM  [(struct Optional *)&D.2251 + 4B] = _7;
  return D.2251;

where the main issue is likely we fail to elide D.2251 because of the
aggregate return (and us not exposing the ABI, etc.).

Note above D.2251 is partly initialized which makes it a bit more difficult
to optimize.  SRA might try to handle these cases by rematerializing the
aggregate just before the return.  We can then hope for RTL expansion
to do "magic".

[Bug rtl-optimization/95382] [haifa-sched][DO_PREDICATION] execution test: wrong scheduling result.

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
You'll likely get more help when asking on the mailing list.  Bugzilla is not
well suited to get attention to custom modified ports.

[Bug tree-optimization/95401] New: GCC produces incorrect instruction with -O3 for skylake-avx512

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 95401
   Summary: GCC produces incorrect instruction with -O3 for
skylake-avx512
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

GCC produces incorrect instruction with -O3 for skylake-avx512 (also for
icelake-server and tigerlake).

Error:
>$ g++ -O3 func.cpp driver.cpp -march=skylake-avx512 && sde -skx -- ./a.out 
SDE ERROR:  TID: 0 executed instruction with an unaligned memory reference to
address 0x404064 INSTR: 0x000401201: IFORM: VMOVDQA_MEMdq_XMMdq :: vmovdqa
xmmword ptr [rcx*4+0x404060], xmm0
IMAGE:   
/home/vlivinsk/workspace/yarpgen/bugs/may-28/gcc-miscompile/reduce/a.out
FUNCTION: _Z4testv
FUNCTION ADDR: 0x000401120

Reproducer:
driver.cpp
int var_9 = 1693986256, var_14;
int arr_16[11];
void test();
int main() { test(); }

func.cpp
extern int var_9;
extern unsigned var_14;
extern int arr_16[];
#include 
void test() {
  for (short a = 0; a < (short)var_9; a += 12140)
for (short b = 0; b < 8; b++)
  if (std::max(var_14, 1U))
arr_16[a + b] = 0;
}

GCC version: 11.0.0 (5c715e6a2990cfb6c15acc1ee14219523534ec69)

[Bug c++/95400] New: -march=native and -march=icelake-client produce different results on icelake client

[travis.downs at gmail dot com]

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

Bug ID: 95400
   Summary: -march=native and -march=icelake-client produce
different results on icelake client
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: travis.downs at gmail dot com
  Target Milestone: ---

On an Ice Lake client machine, using -O3 -march=native produces 512-bit AVX-512
instructions, whereas -O3 -march=icelake-client produces 256-bit instructions.

Since this machine *is* Ice Lake client, I would expect both options to do the
same thing.

[Bug target/95399] New: [ARM, AArch64] 32/64-bit vcvtnq_* functions are missing

[e...@coeus-group.com]

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

Bug ID: 95399
   Summary: [ARM, AArch64] 32/64-bit vcvtnq_* functions are
missing
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Documentation:
https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics?search=vcvtnq

Clang supports them: https://godbolt.org/z/xsMfSz

It looks like vcvtnq_s32_f32, vcvtnq_u32_f32, vcvtnq_s64_f64, and
vcvtnq_u64_f64 are all missing, though vcvtnq_s16_f16 and vcvtnq_u16_f16 are
present.

[Bug fortran/95090] ICE: identifier overflow: 129

[manfred99 at gmx dot ch]

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

--- Comment #8 from Manfred Schwarb  ---
I even tried "char tmp[2*GFC_MAX_SYMBOL_LEN+800];" but it
still fails.

[Bug preprocessor/94657] [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly.

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

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

--- Comment #4 from Sergei Trofimovich  ---
On #gcc Tobias pointed out that similar patch was merged a few days ago:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=731c4ce0e93065fb70db5faa2bd6c9c6bad56738

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546337.html

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[AsDaGo at posteo dot net]

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

--- Comment #13 from Asher Gordon  ---
Do you think that it would be possible to add something like Sparse's
-Wno-universal-initializer and use it by default? As Linus says here[1], Sparse
defaults tend to be kernel-centric, but I don't think there's any reason for
GCC to have the same defaults.

[1]  https://bugzilla.kernel.org/show_bug.cgi?id=207959#c4

[Bug c++/95328] structured binding of template type inside template function is reported as "incomplete class type"

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:3d8d5ddb539a5254c7ef83414377f4c74c7701d4

commit r11-706-g3d8d5ddb539a5254c7ef83414377f4c74c7701d4
Author: Jakub Jelinek 
Date:   Thu May 28 23:40:54 2020 +0200

c++: Try to complete decomp types [PR95328]

Two years ago Paolo has added the
  else if (processing_template_decl && !COMPLETE_TYPE_P (type))
pedwarn (...);
lines into cp_finish_decomp.  For type dependent decl we punt much earlier,
but even for types which aren't type dependent COMPLETE_TYPE_P might be
false as this testcase shows, so this patch tries to complete_type first
(the reason for writing it that way is that it is then followed by another
else if and if complete_type returns error_mark_node, we shouldn't report
anything, as a bug should have been reported already.

2020-05-28  Jakub Jelinek  

PR c++/95328
* decl.c (cp_finish_decomp): Call complete_type before checking
COMPLETE_TYPE_P.

* g++.dg/cpp1z/decomp53.C: New test.

[Bug fortran/95398] ICE on invalid code

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #1 from Steve Kargl  ---
On Thu, May 28, 2020 at 09:33:08PM +, kargl at gcc dot gnu.org wrote:
> 
> Code posted at 
> 
> https://groups.google.com/forum/#!topic/comp.lang.fortran/mW1gV6tyxXk

Here's the code

   implicit none

   type :: t1
 integer :: i
   end type

   type, extends(t1) :: t2
   end type

   class(t1), allocatable :: array1(:,:)
   class(t2), allocatable :: array2(:,:)

   allocate(array1(3,3))
   allocate(array2(3,3))

   select type(b => foo(1))
  type is (t1)
 b%i = 1 !VDC
  type is (t2)
 call sub_with_in_and_inout_param(b,b) !VDC
   end select

   contains

 function foo(i)
   integer :: U(2)
   integer :: i
   class(t1), POINTER :: foo(:)
   ALLOCATE(FOO(2))
   U = (/ 1,2 /)
   if (i>0) then
 foo => array1(2,U)
   else
 foo => array2(2,U)
   end if
 end function

 subroutine sub_with_in_and_inout_param(y, z)
type(t2), INTENT(IN) :: y(:)
class(t2), INTENT(INOUT) :: z(:)
z%i = 10
 end subroutine

end

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #2)
> (In reply to Richard Biener from comment #1)
> > can we have a backtrace?
> 
> Working on it.

I'm at the point now where I can invoke the command which provokes the crash:

(sid-m68k-sbuild)root@epyc:/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/gcc#
/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/./gcc/xgcc
-B/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/./gcc/ -xc++
-nostdinc /dev/null -S -o /dev/null
-fself-test=../../src/gcc/testsuite/selftests
cc1plus: internal compiler error: in operator[], at vec.h:867
mmap: Bad file descriptor
close: Bad file descriptor
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
(sid-m68k-sbuild)root@epyc:/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/gcc#

What kind of backtrace are you looking for? Through GDB?

[Bug fortran/95398] New: ICE on invalid code

[kargl at gcc dot gnu.org]

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

Bug ID: 95398
   Summary: ICE on invalid code
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Code posted at 

https://groups.google.com/forum/#!topic/comp.lang.fortran/mW1gV6tyxXk

leads to

% gfcx -c a.f90
a.f90:32:16:

   32 |  foo => array1(2,U)
  |1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
a.f90:34:16:

   34 |  foo => array2(2,U)
  |1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
f951: internal compiler error: Segmentation fault
0xdf6e3a crash_signal
../../gccx/gcc/toplev.c:328
0x83fb5c resolve_select_type
../../gccx/gcc/fortran/resolve.c:9169
0x83c9a4 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gccx/gcc/fortran/resolve.c:11908
0x840f78 resolve_codes
../../gccx/gcc/fortran/resolve.c:17197
0x82ba33 gfc_resolve(gfc_namespace*)
../../gccx/gcc/fortran/resolve.c:17232
0x82ba33 gfc_resolve(gfc_namespace*)
../../gccx/gcc/fortran/resolve.c:17211
0x81de68 resolve_all_program_units
../../gccx/gcc/fortran/parse.c:6241
0x81de68 gfc_parse_file()
../../gccx/gcc/fortran/parse.c:6488
0x871858 gfc_be_parse_file
../../gccx/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This patch fixes the ICE. Do with it what you want.


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
s@@ -9166,7 +9172,9 @@ resolve_select_type (gfc_code *code, gfc_namespace *ol
  selector_type = CLASS_DATA (code->expr2)->ts.u.derived;
}

-  if (code->expr2->rank && CLASS_DATA (code->expr1)->as)
+  if (code->expr2->rank
+ && code->expr1->ts.type == BT_CLASS
+ && CLASS_DATA (code->expr1)->as)
CLASS_DATA (code->expr1)->as->rank = code->expr2->rank;

   /* F2008: C803 The selector expression must not be coindexed.  */

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[AsDaGo at posteo dot net]

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

--- Comment #12 from Asher Gordon  ---
(In reply to Luc Van Oostenryck from comment #11)
> Sparse already has this option. Also, I don't think it would help here since
> from I understand the OP want these warnings but not if they're caused by
> using '{ 0 }'.

That is correct. I want what is provided by '-Wdesignated-init
-Wno-universal-initializer'.

[Bug fortran/95397] New: [Fortran/OpenACC] Wrong results with 'loop vector' inside 'routine'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 95397
   Summary: [Fortran/OpenACC] Wrong results with 'loop vector'
inside 'routine'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48631&action=edit
'openacc-github-302-2_.f90'

See attached.  This is a simplified version of
,
'openacc-github-302-2.f90.txt'.  With nvptx offloading:

$ ./a.out
   0   0   0   0   0   0   
   0   0   0   0

Expected:

$ ACC_DEVICE_TYPE=host ./a.out
   1   2   3   4   5   6   
   7   8   9  10

Is something wrong with my Fortran/OpenACC, or with GCC's Fortran/OpenACC?

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[luc.vanoostenryck at gmail dot com]

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

--- Comment #11 from Luc Van Oostenryck  ---
(In reply to Andrew Pinski from comment #10)
> GCC uses -Wno-designated-init to disable the warning (this option has been
> there included for a while)?  Do you think sparse could add/use the same
> option?

Sparse already has this option. Also, I don't think it would help here since
from I understand the OP want these warnings but not if they're caused by using
'{ 0 }'.

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Luc Van Oostenryck from comment #9)
> In fact, sparse already support the suppression of the warning via the
> option '-Wno-universal-initializer'.
> 
> It's really very recent and thus only in the mainline tree, not in a release
> (and it was introduced for another warning but the result is the same).

GCC uses -Wno-designated-init to disable the warning (this option has been
there included for a while)?  Do you think sparse could add/use the same
option?

[Bug tree-optimization/95396] New: GCC produces incorrect code with -O3 for loops

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 95396
   Summary: GCC produces incorrect code with -O3 for loops
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Error:
>$ g++ -O0 small.cpp && ./a.out 
42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 0 0 0 
>$ g++ -O3 small.cpp && ./a.out 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 42 0 0 0 

Reproducer:
>$ cat small.cpp 
#include 

unsigned short arr_26 [20];
signed char arr_25 [2000];

unsigned char b;

int c(int d, int f) { return d > f ? d : f; }

void test() { 
for (char e = c(b, 241) + 15; e < 17; e += 1)
arr_26[e] = 42;
}

int main() {
test();
for (size_t i_0 = 0; i_0 < 20; ++i_0)
printf("%d ", arr_26 [i_0]);
printf("\n");
}

GCC version:
11.0.0 (1852a26b925970f64f8d31518ba732fe9c3ade23)

[Bug c++/95369] braced-init-list with designated initializers as template-argument rejected

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-28
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #4 from Marek Polacek  ---
I think I have a patch.

[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-May/546
   ||522.html

--- Comment #3 from H.J. Lu  ---
The current patch is at

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546522.html

[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Taking.

Fixed on master for gcc-11.

[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:5c715e6a2990cfb6c15acc1ee14219523534ec69

commit r11-705-g5c715e6a2990cfb6c15acc1ee14219523534ec69
Author: Harald Anlauf 
Date:   Thu May 28 22:28:08 2020 +0200

PR fortran/95373 - ICE in build_reference_type, at tree.c:7942

The use of KIND, LEN, RE, and IM inquiry references for applicable
intrinsic
types is valid only for suffienctly new Fortran standards.  Add appropriate
check.

2020-05-28  Harald Anlauf  

gcc/fortran/
PR fortran/95373
* primary.c (is_inquiry_ref): Check validity of inquiry
references against selected Fortran standard.

gcc/testsuite/
PR fortran/95373
* gfortran.dg/pr95373_1.f90: New test.
* gfortran.dg/pr95373_2.f90: New test.

[Bug tree-optimization/95393] Failure to optimize loop condition arithmetic for mismatched types

[gabravier at gmail dot com]

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

--- Comment #2 from Gabriel Ravier  ---
Hm, I've just done some further testing and it appears that it only occurs for
me on x86 when I have `-msse4.1` on the command line, in which case it doesn't
optimize it to `return s;`, but instead does a compare beforehand.

[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #17 from anlauf at gcc dot gnu.org ---
Should be fixed now.

Thanks, Rainer, for precisely pointing at the latent issue.

[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0d607ecbf125551513e182a181ca9c6e25dc7609

commit r9-8633-g0d607ecbf125551513e182a181ca9c6e25dc7609
Author: Harald Anlauf 
Date:   Thu May 28 21:53:17 2020 +0200

PR fortran/95104 - Segfault on a legal WAIT statement

The initial commit for this PR uncovered a latent issue with unit locking
in the Fortran run-time library.  Add check for valid unit.

2020-05-28  Harald Anlauf  

libgfortran/
PR libfortran/95104
* io/unit.c (unlock_unit): Guard by check for NULL pointer.

(cherry picked from commit 6ce3d791dfcba469e709935aba5743640f7d4959)

[Bug middle-end/95395] gcc.dg/builtin-bswap-11.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Rainer Orth  ---
The new gcc.dg/builtin-bswap-11.c test FAILs on 64-bit SPARC:

+FAIL: gcc.dg/builtin-bswap-11.c (internal compiler error)
+FAIL: gcc.dg/builtin-bswap-11.c (test for excess errors)
+UNRESOLVED: gcc.dg/builtin-bswap-11.c compilation failed to produce executable

Excess errors:
during RTL pass: expand
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/builtin-bswap-11.c:47:9:
internal compiler error: in expand_builtin_bswap, at builtins.c:5890
0x6371c3 expand_builtin_bswap
/vol/gcc/src/hg/master/local/gcc/builtins.c:5890
0x6539f3 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/vol/gcc/src/hg/master/local/gcc/builtins.c:7992
0x7f042b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/vol/gcc/src/hg/master/local/gcc/expr.c:11132
0x7fd97f store_expr(tree_node*, rtx_def*, int, bool, bool)
/vol/gcc/src/hg/master/local/gcc/expr.c:5752
0x800867 expand_assignment(tree_node*, tree_node*, bool)
/vol/gcc/src/hg/master/local/gcc/expr.c:5514
0x68ad8b expand_call_stmt
/vol/gcc/src/hg/master/local/gcc/cfgexpand.c:2701
0x68ad8b expand_gimple_stmt_1
/vol/gcc/src/hg/master/local/gcc/cfgexpand.c:3682
0x68ad8b expand_gimple_stmt
/vol/gcc/src/hg/master/local/gcc/cfgexpand.c:3847
0x68c7a3 expand_gimple_basic_block
/vol/gcc/src/hg/master/local/gcc/cfgexpand.c:5887
0x68f677 execute
/vol/gcc/src/hg/master/local/gcc/cfgexpand.c:6571

[Bug middle-end/95395] New: gcc.dg/builtin-bswap-11.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 95395
   Summary: gcc.dg/builtin-bswap-11.c FAILs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

[Bug tree-optimization/95353] [10/11 Regression] spurious -Wstringop-overflow writing to a trailing array plus offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.0
Summary|[10/11 Regression] GCC  |[10/11 Regression] spurious
   |can't build binutils|-Wstringop-overflow writing
   ||to a trailing array plus
   ||offset

--- Comment #8 from Martin Sebor  ---
Adjust Summary to more accurately reflect the problem.

[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:e1396ee72e68cc8fba99ce986f2910cd39e335b8

commit r10-8202-ge1396ee72e68cc8fba99ce986f2910cd39e335b8
Author: Harald Anlauf 
Date:   Thu May 28 21:53:17 2020 +0200

PR fortran/95104 - Segfault on a legal WAIT statement

The initial commit for this PR uncovered a latent issue with unit locking
in the Fortran run-time library.  Add check for valid unit.

2020-05-28  Harald Anlauf  

libgfortran/
PR libfortran/95104
* io/unit.c (unlock_unit): Guard by check for NULL pointer.

(cherry picked from commit 6ce3d791dfcba469e709935aba5743640f7d4959)

[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:6ce3d791dfcba469e709935aba5743640f7d4959

commit r11-704-g6ce3d791dfcba469e709935aba5743640f7d4959
Author: Harald Anlauf 
Date:   Thu May 28 21:53:17 2020 +0200

PR fortran/95104 - Segfault on a legal WAIT statement

The initial commit for this PR uncovered a latent issue with unit locking
in the Fortran run-time library.  Add check for valid unit.

2020-05-28  Harald Anlauf  

libgfortran/
PR libfortran/95104
* io/unit.c (unlock_unit): Guard by check for NULL pointer.

[Bug go/95389] Kubernetes build fails because of mangled PkgPath

[ulrich.teichert at gmx dot de]

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

--- Comment #2 from Ulrich Teichert  ---
Yes, the string "vendor/k8s.x2eio/code-generator/pkg/util" is the content of
the PkgPath() from "vendor/k8s.io/code-generator/pkg/util".

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[luc.vanoostenryck at gmail dot com]

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

Luc Van Oostenryck  changed:

   What|Removed |Added

 CC||luc.vanoostenryck at gmail dot 
com

--- Comment #9 from Luc Van Oostenryck  ---
In fact, sparse already support the suppression of the warning via the option
'-Wno-universal-initializer'.

It's really very recent and thus only in the mainline tree, not in a release
(and it was introduced for another warning but the result is the same).

[Bug c++/94926] [9/10/11 regression] invalid use of incomplete type not recogniced for static self reference of templated struct since r9-297-g683be2f77b3ce4db

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|9.4 |11.0
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 11.  Since this is accepts-invalid I'm not going to backport to
GCC 9, but I could be convinced to backport to 10.2.

[Bug c++/94926] [9/10/11 regression] invalid use of incomplete type not recogniced for static self reference of templated struct since r9-297-g683be2f77b3ce4db

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:7b599b9f9a1e036ff75a4daa06ac7036c6ebbe01

commit r11-703-g7b599b9f9a1e036ff75a4daa06ac7036c6ebbe01
Author: Jason Merrill 
Date:   Thu May 28 00:35:56 2020 -0400

c++: Immediately deduce auto member [PR94926].

In r9-297 I was trying to be more flexible and treat static data members of
class templates more like variable templates, where the type need not be
determined until the variable is instantiated, but I suppose that in a
class
the types of all the non-template members need to be determined at the time
of class instantiation.

gcc/cp/ChangeLog:

PR c++/94926
* decl.c (cp_finish_decl): Revert r9-297 change.
(check_static_variable_definition): Likewise.
* constexpr.c (ensure_literal_type_for_constexpr_object): Likewise.
* pt.c (instantiate_decl): Return early on type error.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/pr86648.C: Expect error.
* g++.dg/cpp1z/static2.C: Expect error.
* g++.dg/cpp0x/nsdmi16.C: New test.

[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()

[daniel.kruegler at googlemail dot com]

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

--- Comment #12 from Daniel Krügler  ---
(In reply to Daniel Krügler from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > A new LWG issue has been submitted, and there is a suggested resolution.
> 
> Will take care and inform in this issue here.

The new LWG issue exists now:

https://cplusplus.github.io/LWG/issue3448

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from anlauf at gcc dot gnu.org ---
Reopening.

[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore

[wilson at gcc dot gnu.org]

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

--- Comment #7 from Jim Wilson  ---
I've got 3 new g++ testsuite failures.  So we might still need an exact list of
USEs.  I hadn't thought about RVE.  That will have to be checked also. 
RV32/RV64 shouldn't matter, as the mode in the USEs doesn't matter.  Unless
maybe you want to use a multi-word load to match multiple registers with a
single USE to reduce the size of the patterns, in which case it would need to
be different for rv32 and rv64.  If we do need an exact list of USEs, maybe we
can use a match_parallel to simplify the patterns.

[Bug tree-optimization/95391] [11 regression] ICE in gcc.dg/vshift-5.c since r11-689

[seurer at linux dot vnet.ibm.com]

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

--- Comment #1 from Bill Seurer  ---
Also causes gcc.dg/vect/pr46126.c to ICE in the same spot.

[Bug target/95361] Segfault when generating an epilogue for a partly-shrinked-wrapped SVE frame

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:c082cb8a2523d8c5afe5710e265bc72dd71aa60b

commit r10-8201-gc082cb8a2523d8c5afe5710e265bc72dd71aa60b
Author: Richard Sandiford 
Date:   Thu May 28 19:03:46 2020 +0100

aarch64: Fix segfault in aarch64_expand_epilogue [PR95361]

The stack frame for the function in the testcase consisted of two
SVE save slots.  Both saves had been shrink-wrapped, but for different
blocks, meaning that the stack allocation and deallocation were
separate from the saves themselves.  Before emitting the deallocation,
we tried to attach a REG_CFA_DEF_CFA note to the preceding instruction,
to redefine the CFA in terms of the stack pointer.  But in this case
there was no preceding instruction.

This in practice only happens for SVE because:

(a) We don't try to shrink-wrap wb_candidate* registers even when
we've decided to treat them as normal saves and restores.
I have a fix for that.

(b) Even with (a) fixed, we're (almost?) guaranteed to emit
a stack tie for frames that are 64k or larger, so we end
up hanging the REG_CFA_DEF_CFA note on that instead.

We should only need to redefine the CFA if it was previously
defined in terms of the frame pointer.  In other cases the CFA
should already be defined in terms of the stack pointer,
so redefining it is unnecessary but usually harmless.

2020-05-28  Richard Sandiford  

gcc/
PR testsuite/95361
* config/aarch64/aarch64.c (aarch64_expand_epilogue): Only
redefine the CFA if we have CFI operations.

gcc/testsuite/
PR testsuite/95361
* gcc.target/aarch64/sve/pr95361.c: New test.

[Bug go/95389] Kubernetes build fails because of mangled PkgPath

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
To be clear, are you seeing this in the value returned by
reflect.Type.PkgPath()?  Or is it showing up somewhere else?  Thanks.

[Bug tree-optimization/95393] Failure to optimize loop condition arithmetic for mismatched types

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
It does optimize for me with -O2 or -O3. It could optimize earlier though, by
the end of gimple, we are still trying to return max(s,0).

[Bug libstdc++/95392] [11 Regression] Build failure on MinGW

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug libstdc++/95392] [11 Regression] Build failure on MinGW

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
Summary|Build failure on MinGW  |[11 Regression] Build
   ||failure on MinGW
  Known to work||10.1.0
   Last reconfirmed||2020-05-28
  Known to fail||11.0
   Keywords||build
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Oops, I meant to check it on mingw-w64 before pushing that commit.

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Manfred Schwarb from comment #5)
> gdb shows:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6
> #0  0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6
> #1  0x083e6def in get_unique_hashed_string(char*, gfc_symbol*) ()

Can you please try the following patch for me?

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 9aa3eb7282c..065cd691a73 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -501,7 +501,8 @@ get_unique_type_string (char *string, gfc_symbol *derived)
 static void
 get_unique_hashed_string (char *string, gfc_symbol *derived)
 {
-  char tmp[2*GFC_MAX_SYMBOL_LEN+2];
+  /* Provide sufficient space to hold "symbol_Pdtsymbol".  */
+  char tmp[2*GFC_MAX_SYMBOL_LEN+5];
   get_unique_type_string (&tmp[0], derived);
   /* If string is too long, use hash value in hex representation (allow for
  extra decoration, cf. gfc_build_class_symbol & gfc_find_derived_vtab).

Thanks.

[Bug target/95256] [11 Regression] ICE in convert_move, at expr.c:278 since r11-263-g7c355156aa20eaec

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
Is there some further work pending, or should this PR be closed now?

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[asolokha at gmx dot com]

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

--- Comment #8 from Arseny Solokha  ---
Is there some further work pending, or should this PR be closed now?

[Bug rtl-optimization/95394] New: [11 Regression] ICE in emit_move_insn, at expr.c:3814

[asolokha at gmx dot com]

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

Bug ID: 95394
   Summary: [11 Regression] ICE in emit_move_insn, at expr.c:3814
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu-gcc

gcc-11.0.0-alpha20200524 snapshot (g:d176184d98a00ab379ae5959aed1908a79995e6b)
ICEs when compiling the following testcase w/ -O1:

void
ri (__int128 *z8, int x8)
{
  int es;
  int *kx = &es;

  while (x8 != 1)
while (kx < (int *) 2)
  {
z8 = (__int128 *) &x8;
*z8 /= 3;
  }
}

% x86_64-unknown-linux-gnu-gcc-11.0.0 -O1 -c h9pqh5we.c
during RTL pass: subreg3
h9pqh5we.c: In function 'ri':
h9pqh5we.c:13:1: internal compiler error: in emit_move_insn, at expr.c:3814
   13 | }
  | ^
0x622b77 emit_move_insn(rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/expr.c:3814
0x17647f4 resolve_simple_move
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/lower-subreg.c:1090
0x1765919 decompose_multiword_subregs
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/lower-subreg.c:1648
0x17662ad execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/lower-subreg.c:1812

[Bug libfortran/95390] _gfortran_{,m,s}findloc[01]_c10 not exported from libgfortran.so.5

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug libstdc++/95392] New: Build failure on MinGW

[markus.boeck02 at gmail dot com]

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

Bug ID: 95392
   Summary: Build failure on MinGW
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Current trunk version of GCC (tested with HEAD at
4833c1adc3c7b125bf1c59e8bd8d802ac3b0d205) fails to build using MinGW. The
compiler error is as follows:

In file included from
/mnt/c/GCC-Build/gcc/build/x86_64-w64-mingw32/libstdc++-v3/include/filesystem:45,
 from ../../../../../libstdc++-v3/src/c++17/fs_ops.cc:32,
 from ../../../../../libstdc++-v3/src/c++17/cow-fs_ops.cc:26:
/mnt/c/GCC-Build/gcc/build/x86_64-w64-mingw32/libstdc++-v3/include/bits/fs_path.h:
In function 'std::filesystem::path std::filesystem::u8path(const _Source&)':
/mnt/c/GCC-Build/gcc/build/x86_64-w64-mingw32/libstdc++-v3/include/bits/fs_path.h:789:32:
error: '_S_string_from_iter' is not a member of 'std::filesystem::path'
  789 |std::string __s = path::_S_string_from_iter(__source);
  |  

The change that introduced the breakage is
584d52b088f9fcf78704b504c3f1f07e17c1cded. Reverting this commit makes the build
succeed

[Bug tree-optimization/95393] New: Failure to optimize loop condition arithmetic for mismatched types

[gabravier at gmail dot com]

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

Bug ID: 95393
   Summary: Failure to optimize loop condition arithmetic for
mismatched types
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(unsigned s)
{
int i;
for (i = 0; i < s; ++i)
;

return i;
}

This can be optimized to `return s;`. LLVM does this transformation, but GCC
does not.

[Bug c++/95368] gcc things that a lambda capture is both const and mutable

[rafael at espindo dot la]

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

--- Comment #2 from Rafael Avila de Espindola  ---
I just tested a few compilers with the testcase from comment 1:

* clang version 11.0.0 (https://github.com/llvm/llvm-project.git
0796b170fb3bf38e6cc4e59746120b37c9a9cd9f):
  Accepts it.

* g++ (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1):
  Rejects it:
  test.cc:17:14: error: passing ‘const foo’ as ‘this’ argument discards
qualifiers [-fpermissive]

* gcc (GCC) 9.3.1 20200528
  Rejects it:
  test.cc:17:14: error: passing ‘const foo’ as ‘this’ argument discards
qualifiers

[Bug c++/93698] ICE on concept using generic lambda

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||10.0, 11.0
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2020-05-28
 CC||ppalka at gcc dot gnu.org

[Bug c++/92652] function call to lambda expression that return true does not satisfy the constraint in requires-clause if using return type deduction

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/95391] New: [11 regression] ICE in gcc.dg/vshift-5.c since r11-689

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95391
   Summary: [11 regression] ICE in gcc.dg/vshift-5.c since r11-689
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:e31cd607e999ca6ab47b7e65a7045b1594e4fba4, r11-689

make -k check-gcc RUNTESTFLAGS=dg.exp=gcc.dg/vshift-5.c

FAIL: gcc.dg/vshift-5.c (internal compiler error)
FAIL: gcc.dg/vshift-5.c (test for excess errors)

# of unexpected failures2
# of unresolved testcases   1


Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -O3  -lm  -o
./vshift-5.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3 -lm -o ./vshift-5.exe
during GIMPLE pass: slp
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c: In function
'f1':
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c:8:1: internal
compiler error: in vect_create_constant_vectors, at tree-vect-slp.c:3680
0x10ee4e8b vect_create_constant_vectors
/home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:3680
0x10ee4e8b vect_schedule_slp_instance
/home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:4072
0x10ee401f vect_schedule_slp_instance
/home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:4077
0x10ee401f vect_schedule_slp_instance
/home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:4077
0x10eed443 vect_schedule_slp(vec_info*)
/home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:4309
0x10ef0e83 vect_slp_bb_region
/home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:3348
0x10ef0e83 vect_slp_bb(basic_block_def*)
/home/seurer/gcc/git/gcc-test2/gcc/tree-vect-slp.c:3471
0x10ef31bb execute
/home/seurer/gcc/git/gcc-test2/gcc/tree-vectorizer.c:1320

[Bug libfortran/95390] _gfortran_{,m,s}findloc[01]_c10 not exported from libgfortran.so.5

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2020-05-28
 Ever confirmed|0   |1

[Bug libfortran/95390] New: _gfortran_{,m,s}findloc[01]_c10 not exported from libgfortran.so.5

[jakub at gcc dot gnu.org]

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

Bug ID: 95390
   Summary: _gfortran_{,m,s}findloc[01]_c10 not exported from
libgfortran.so.5
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

complex(kind=10) :: a(6), b, d(2,2)
  logical :: m(6), n, o(2,2)
  integer :: c(1), e(2)
  a = (/ 1., 2., 17., 2., 2., 6. /)
  b = 17.
  c = findloc (a, b)
  if (c(1) /= 3) stop 1
  m = (/ .true., .false., .true., .true., .true., .true. /)
  n = .true.
  b = 2.
  c = findloc (a, b, m)
  if (c(1) /= 4) stop 2
  c = findloc (a, b, n)
  if (c(1) /= 2) stop 3
  d = reshape((/ 1., 2., 2., 3. /), (/ 2, 2 /))
  e = findloc (d, b, 1)
  if (e(1) /= 2 .or. e(2) /= 1) stop 4
  o = reshape((/ .true., .false., .true., .true. /), (/ 2, 2 /))
  e = findloc (d, b, 1, o)
  if (e(1) /= 0 .or. e(2) /= 1) stop 5
  e = findloc (d, b, 1, n)
  if (e(1) /= 2 .or. e(2) /= 1) stop 6
  n = .false.
  e = findloc (d, b, 1, n)
  if (e(1) /= 0 .or. e(2) /= 0) stop 7
end

does not link due to that.

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[AsDaGo at posteo dot net]

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

--- Comment #8 from Asher Gordon  ---
(In reply to Tom Tromey from comment #7)
> The feature was added specifically to mimic what sparse does.
> If sparse changes, I think changing gcc would be appropriate.

I just report a bug to Sparse here:
https://bugzilla.kernel.org/show_bug.cgi?id=207959

Let's see what they have to say.

[Bug go/95389] New: Kubernetes build fails because of mangled PkgPath

[ulrich.teichert at gmx dot de]

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

Bug ID: 95389
   Summary: Kubernetes build fails because of mangled PkgPath
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ulrich.teichert at gmx dot de
CC: cmang at google dot com
  Target Milestone: ---

Hi,

while trying to build Kubernetes on sparc64 (yes, this is a currently
unsupported platform as far as Kubernetes is concerned), I stumbled over a
PkgPath issue. Kubernetes uses (among a multitude of others) a packages path
as:

vendor/k8s.io/code-generator/pkg/util

>From the path specifications of golang, I think that k8s.io is a legal package
part, as long as the dot is not used as first character in a path component.

gccgo is turning this into the PgkPath:

vendor/k8s.x2eio/code-generator/pkg/util

Which seems to be a result of a path mangling by the go frontend method
go_mangle_pkgpath in gcc/go/gofrontend/go-encode-id.cc, which encodes the dot
to the string ".x2e". This would be perfectly OK, if the PkgPath in golang
would be used unmangled, but the dot encoding slips through.

I admit that I didn't find the point where the dot unmangling should be
inserted, sorry.

[Bug c++/95386] [10/11 Regression] ICE: in satisfaction_value, while compiling function with a requires clause since r10-3735-gcb57504a55015891

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|internal compiler error: in |[10/11 Regression] ICE: in
   |satisfaction_value, while   |satisfaction_value, while
   |compiling function with a   |compiling function with a
   |requires clause |requires clause since
   ||r10-3735-gcb57504a55015891
 Status|WAITING |NEW
 CC||jason at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Reduced test-case:

$ cat pr95386.ii
namespace std {
template  struct A {
  typedef bool value_type;
  constexpr operator value_type() { return __v; }
};
template  struct is_lvalue_reference : A {};
} // namespace std
template  void fn1(T) requires !std::is_lvalue_reference();
template  void fn1(T);
void fn2() { fn1(fn2); }

[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
Unassigning myself due to the issue described in

  https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546308.html

which my initial patch attempt fails to address.

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[tromey at gcc dot gnu.org]

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

--- Comment #7 from Tom Tromey  ---
(In reply to Asher Gordon from comment #6)
> (In reply to Tom Tromey from comment #5)
> > Since this warning is intended to work like sparse, introducing
> > a divergence here would seem to make the feature less useful,
> > in fact subverting the point of having it.
> 
> How does diverging from Sparse make the feature less useful? If this is the
> case, perhaps Sparse's behavior should be changed as well.

The feature was added specifically to mimic what sparse does.
If sparse changes, I think changing gcc would be appropriate.

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[AsDaGo at posteo dot net]

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

--- Comment #6 from Asher Gordon  ---
(In reply to Tom Tromey from comment #5)
> Since this warning is intended to work like sparse, introducing
> a divergence here would seem to make the feature less useful,
> in fact subverting the point of having it.

How does diverging from Sparse make the feature less useful? If this is the
case, perhaps Sparse's behavior should be changed as well.

[Bug tree-optimization/95353] [10/11 Regression] GCC can't build binutils

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
I test my warning changes with binutils and --enable-targets=all.  But that
apparently doesn't compile all source files, and I don't have a cross-build
setup in place (or the resources to do it).  If someone who already does
cross-builds could periodically post results to gcc-testresults (or report
bugs), or if we could get these going in Jeff's buildbot, that would help catch
the problems in those before either package is released.

[Bug c++/95388] New: C++20 & 17 Lambda capture of *this by Value causes ICE "in tsubst_decl at cp/pt.c"

[eng.amehra at gmail dot com]

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

Bug ID: 95388
   Summary: C++20 & 17 Lambda capture of *this by Value causes ICE
"in tsubst_decl at cp/pt.c"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eng.amehra at gmail dot com
  Target Milestone: ---

1. While using lambda capture by value, cause ICE with gcc 11.0.0. I tried with
both  -std=c++17 & then with -std=c++20. Both give same error.

Short Error: internal compiler error: in tsubst_decl, at cp/pt.c:14637

What works:
1. On this online gcc comiler, it works for gcc10.1, but fails for trunk. Code
Code fails to compile on this link when compiler is set to gcc trunk -
https://godbolt.org/z/PNxfQc
Same code compiles on this link when compiler is set to gcc10.1 -
https://godbolt.org/z/izPfY_

2. It works fine with GCC 7.5.0 with compiler flag -std=c++17 on my machine.
(See machine details below)

My local machine details:
   Linux DESKTOP-SHA8RMO 4.4.0-18362-Microsoft #836-Microsoft
x86_64x86_64 x86_64 GNU/Linux
   OS:
   "Ubuntu 18.04.4 LTS (Bionic Beaver)".

Code sample which causes error: 

#include 
#include 
#include 

class FeatureLambdaCaptureThis
{
private:
  int addend;

public:
  FeatureLambdaCaptureThis(int value) : addend{value}
  {
  }
  void DemoLambdaCapture_ThisByValue()
  {
std::vector values{1, 3, 5, 7, 9, 11, 13, 15};

std::for_each(values.begin(), values.end(), [=, *this](auto &value) mutable
{
value += addend;
addend++;
 });
std::cout << "\n" ;
for (auto &value : values)
{
  std::cout << " " << value;
}
std::cout << std::endl;
  }
};


int main(int argc, char *argv[])
{
  std::cout << "__cplusplus:" << __cplusplus << std::endl;
  FeatureLambdaCaptureThis obj{2};
  obj.DemoLambdaCapture_ThisByValue();
}

Detailed error log from my local machine:

51 | std::for_each(values.begin(), values.end(), [=, *this](auto value) {
[build]   |
 ^
[build] 0x69059f tsubst_decl
[build] ../../gcc/cp/pt.c:14637
[build] 0xa2c8eb tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc/cp/pt.c:17934
[build] 0xa2b96a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc/cp/pt.c:17832
[build] 0xa29d14 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc/cp/pt.c:18151
[build] 0xa27c91 instantiate_decl(tree_node*, bool, bool)
[build] ../../gcc/cp/pt.c:25622
[build] 0x95ce6a maybe_instantiate_decl
[build] ../../gcc/cp/decl2.c:5377
[build] 0x95f520 maybe_instantiate_decl
[build] ../../gcc/tree.h:3411
[build] 0x95f520 mark_used(tree_node*, int)
[build] ../../gcc/cp/decl2.c:5573
[build] 0x8b3385 build_over_call
[build] ../../gcc/cp/call.c:9082
[build] 0x8b8141 build_op_call_1
[build] ../../gcc/cp/call.c:4889
[build] 0x8b8141 build_op_call(tree_node*, vec**,
int)
[build] ../../gcc/cp/call.c:4918
[build] 0xa6f3ee finish_call_expr(tree_node*, vec**, bool, bool, int)
[build] ../../gcc/cp/semantics.c:2692
[build] 0xa39bdd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*,
bool, bool)
[build] ../../gcc/cp/pt.c:20017
[build] 0xa28439 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc/cp/pt.c:18750
[build] 0xa2a963 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc/cp/pt.c:17862
[build] 0xa2a3c3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc/cp/pt.c:18061
[build] 0xa2b96a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc/cp/pt.c:17832
[build] 0xa29d14 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
[build] ../../gcc/cp/pt.c:18151
[build] 0xa27c91 instantiate_decl(tree_node*, bool, bool)
[build] ../../gcc/cp/pt.c:25622
[build] 0x8dab1e instantiate_cx_fn_r
[build] ../../gcc/cp/constexpr.c:6549
[build] Please submit a full bug report,
[build] with preprocessed source if appropriate.
[build] Please include the complete backtrace with any bug report.
[build] See  for instructions.

[Bug c++/95386] internal compiler error: in satisfaction_value, while compiling function with a requires clause

[jpalecek at web dot de]

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

--- Comment #3 from Jiří Paleček  ---
Created attachment 48629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48629&action=edit
Original code which fails to compile

[Bug c++/95386] internal compiler error: in satisfaction_value, while compiling function with a requires clause

[jpalecek at web dot de]

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

--- Comment #2 from Jiří Paleček  ---
(In reply to Martin Liška from comment #1)
> Was the original code a valid code?
> It seems the reduced code is invalid.

Yes at least I believe so. I will attach the original code, it is not big.

Note that you must compile (both versions) with -fconcepts.

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from markeggleston at gcc dot gnu.org ---
committed to master and backported

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:e211b3da3899b3496add56ba45acb07569e7c15a

commit r9-8632-ge211b3da3899b3496add56ba45acb07569e7c15a
Author: Mark Eggleston 
Date:   Wed Apr 1 09:52:41 2020 +0100

Fortran  : "type is( real(kind(1.)) )" spurious syntax error PR94397

Based on a patch in the comments of the PR. That patch fixed this
problem but caused the test cases for PR93484 to fail. It has been
changed to reduce initialisation expressions if the expression is
not EXPR_VARIABLE and not EXPR_CONSTANT.

2020-05-28  Steven G. Kargl  
Mark Eggleston  

gcc/fortran/

PR fortran/94397
* match.c (gfc_match_type_spec): New variable ok initialised
to true. Set ok with the return value of gfc_reduce_init_expr
called only if the expression is not EXPR_CONSTANT and is not
EXPR_VARIABLE. Add !ok to the check for type not being integer
or the rank being greater than zero.

2020-05-28  Mark Eggleston  

gcc/testsuite/

PR fortran/94397
* gfortran.dg/pr94397.F90: New test.

(cherry picked from commit 3ea6977d0f1813d982743a09660eec1760e981ec)

[Bug c++/95386] internal compiler error: in satisfaction_value, while compiling function with a requires clause

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-05-28
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Was the original code a valid code?
It seems the reduced code is invalid.

[Bug debug/95387] New: inconsistent behaviors at -Os

[yangyibiao at hust dot edu.cn]

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

Bug ID: 95387
   Summary: inconsistent behaviors at -Os
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
  Target Milestone: ---

Created attachment 48628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48628&action=edit
a.out

$ gdb --version
GNU gdb (GDB) 10.0.50.20200517-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ gcc --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Consider test case:

$ cat small.c
#include 

int main () {
  char a1[4] = {1, 2, 3, 4};
  char a2[4] = {1, 2, 3, 4};
  int res = memcmp(a1, a2, 4);
  return res;
}


/**when using stepping using stepi, Line 5 is hit after line 6. /

$ gcc -Os -g small.c; gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x401040: file small.c, line 4.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:4
4 char a1[4] = {1, 2, 3, 4};
(gdb) si
0x00401044  6 int res = memcmp(a1, a2, 4);
(gdb) si
0x00401049  6 int res = memcmp(a1, a2, 4);
(gdb) si
0x0040104e  6 int res = memcmp(a1, a2, 4);
(gdb) si
0x00401053  4 char a1[4] = {1, 2, 3, 4};
(gdb) si
5 char a2[4] = {1, 2, 3, 4};
(gdb) si
6 int res = memcmp(a1, a2, 4);
(gdb)


/** when setting breakpoint, we can found that line 5 is hit before line 6
***/

$ gcc -Os -g small.c; gdb -q a.out
Reading symbols from a.out...
(gdb) b 5
Breakpoint 1 at 0x40105b: file small.c, line 5.
(gdb) b 6
Breakpoint 2 at 0x401063: file small.c, line 6.
(gdb) r
Starting program: /home/yibiao/Debugger/a.out 

Breakpoint 1, main () at small.c:5
5 char a2[4] = {1, 2, 3, 4};
(gdb) c
Continuing.

Breakpoint 2, main () at small.c:6
6 int res = memcmp(a1, a2, 4);
(gdb)

[Bug fortran/80361] [5/6/7/8 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[antoine.lemo...@bordeaux-inp.fr]

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

Antoine Lemoine  changed:

   What|Removed |Added

 CC||antoine.lemoine@bordeaux-in
   ||p.fr

--- Comment #28 from Antoine Lemoine  ---
I was able to reproduce the runtime error with gfortran 9.3.0 and 10.1.0 using
the following code:

program test_recursive_call 
   implicit none

   type t_tree_node
  type(t_tree_node), dimension(:), allocatable :: child
   end type

   type t_tree
  type(t_tree_node), allocatable :: root
   end type

   type(t_tree), allocatable :: tree

   allocate(tree)
   allocate(tree%root)
   allocate(tree%root%child(1))
   ! If the line below is removed, the code works fine. 
   allocate(tree%root%child(1)%child(1))
   deallocate(tree)
end program

Command line to compile the code:
gfortran -g -fcheck=recursion -o tree tree.f90

I obtain the following runtime error:

At line 1 of file tree.f90
Fortran runtime error: Recursive call to nonrecursive procedure
'__deallocate_test_recursive_call_T_tree_node'

Error termination. Backtrace:
#0  0x5623824511fb in __deallocate_test_recursive_call_T_tree_node
at /home//fortran/test_gcc_ice2/tree.f90:1
#1  0x562382451302 in __deallocate_test_recursive_call_T_tree_node
at /home//fortran/test_gcc_ice2/tree.f90:1
#2  0x562382451b95 in test_recursive_call
at /home//fortran/test_gcc_ice2/tree.f90:18
#3  0x562382452230 in main
at /home//fortran/test_gcc_ice2/tree.f90:19

It works fine without -fcheck=recursion.

[Bug c++/95386] New: internal compiler error: in satisfaction_value, while compiling function with a requires clause

[jpalecek at web dot de]

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

Bug ID: 95386
   Summary: internal compiler error: in satisfaction_value, while
compiling function with a requires clause
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpalecek at web dot de
  Target Milestone: ---

Created attachment 48627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48627&action=edit
C-reduced code reproducing the problem

Hello,

while trying to call a function with this signature

template 
void g(T&& a) requires !std::is_lvalue_reference()

I get an internal compiler error:


rref-test.cpp:48:6: internal compiler error: in satisfaction_value, at
cp/constraint.cc:2503
   48 |   g(a);

This doesn't happen if I don't use the implicit conversion to bool in the
requires clause:

template 
void g(T&& a) requires !std::is_lvalue_reference::value

is OK.

The minimized (C-reduced) reproducing code is in the attachment. It is a bit
funny as it is not syntactically a complete program, but does reproduce the
problem anyway.

[Bug c++/95384] Poor codegen cause by using base class instead of member for Optional construction

[barry.revzin at gmail dot com]

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

--- Comment #1 from Barry Revzin  ---
Here's a simpler example: https://godbolt.org/z/FD7uEQ

If the engaged member is an int instead of a bool (to remove the tail padding),
gcc generates better code.

This follows up on "PR 95383"

[Bug c++/95385] GCC stop detect UBs after a divide by zero in for statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-28
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Note that clang has the same limitation:

clang++ pr95384.C -fsanitize=undefined && ./a.out 
pr95384.C:11:7: warning: expression result unused [-Wunused-value]
0 / 0;
~ ^ ~
pr95384.C:11:7: warning: division by zero is undefined [-Wdivision-by-zero]
0 / 0;
  ^ ~
2 warnings generated.
pr95384.C:6:11: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior pr95384.C:6:11 in 
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==27328==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address
0x00425cdc (pc 0x00425cdc bp 0x7fffe2d0 sp 0x7fffe280 T27328)
#0 0x425cdc in main (/home/marxin/Programming/testcases/a.out+0x425cdc)
#1 0x77a7ccea in __libc_start_main
/usr/src/debug/glibc-2.31-5.1.x86_64/csu/../csu/libc-start.c:308:16
#2 0x4043a9 in _start
/home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:120

UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: FPE
(/home/marxin/Programming/testcases/a.out+0x425cdc) in main
==27328==ABORTING

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to qinzhao from comment #5)
> (In reply to Martin Liška from comment #4)> 
> > Can you please share some statistics how big are the files and how many 
> > runs do you merge?
> 
>   There were on the order of 10,000 processes. Source code coverage 
>   approximately 20%. Size of the profiling data gathered in the vicinity of
> 1TB.

Which means one run takes 100MB is size, right? As you mentioned, having 1000
.gcda files, it means that one takes 0.1MB?

> 
> > Would it be possible to share 'gcov-dump -l' for all your .gcda files?
> 
> It is impossible since too many .gdca files, each process has one directory,
> there are over 10,000 directories and under each directory, there are over
> thousand .gdca files. 
> 
> the situation is similar as the small testing case I added in the first
> comment. the functions and modules that do not execute have records in the
> .gdca file with zero counts.

Can you please provide dump of one directory? At least for portion of .gcda
files?
How is it common that an entire module is empty?

[Bug c++/95385] New: GCC stop detect UBs after a divide by zero in for statement

[haoxintu at gmail dot com]

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

Bug ID: 95385
   Summary: GCC stop detect UBs after a divide by zero in for
statement
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code test1.cc

#include
int main () {
int a = 1;
for (int i = 0; i < 10; ++i) {
a /= i; // Error: division by zero on the first iteration
}

int b = 0;
int bb = 0 / b;
0 / 0;
std::cout << "ok" << std::endl;
return 0;
}

$./g++ -w -fsanitize=integer-divide-by-zero test1.cc ; ./a.out 
test.cc:5:11: runtime error: division by zero
Floating point exception (core dumped)

GCC only detects one runtime error in for statement but leaves out detecting
the statements following ones.

In test2.cc

#include
int main () {
/*
int a = 1;
for (int i = 0; i < 10; ++i) {
a /= i; // Error: division by zero on the first iteration
}
*/

int b = 0;
int bb = 0 / b;
0 / 0;
std::cout << "ok" << std::endl;
return 0;
}
$./g++ -w -fsanitize=integer-divide-by-zero test2.cc ; ./a.out 
test.cc:11:16: runtime error: division by zero
test.cc:12:7: runtime error: division by zero
ok

Should the main function return from "return 0" rather than exit directly from
the for statement?

[Bug c++/95384] New: Poor codegen cause by using base class instead of member for Optional construction

[barry.revzin at gmail dot com]

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

Bug ID: 95384
   Summary: Poor codegen cause by using base class instead of
member for Optional construction
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Following up on #95383:

struct nullopt_t {} inline constexpr nullopt{};

template 
struct OptionalStorage {
struct Empty { };
union {
Empty _;
T value;
};
bool engaged;

OptionalStorage(nullopt_t) : _(), engaged(false) { }
OptionalStorage(T v) : value(v), engaged(true) { }
};

template 
struct OptionalWithBase : OptionalStorage {
using OptionalStorage::OptionalStorage;
};

template 
struct OptionalWithMember {
OptionalStorage o;
OptionalWithMember(nullopt_t) : o(nullopt) { }
OptionalWithMember(T v) : o(v) { }
};

OptionalWithBase foo_with_base(bool b) {
if (b) {
return 42;
}
return nullopt;
}

OptionalWithMember foo_with_member(bool b) {
if (b) {
return 42;
}
return nullopt;
}

OptionalWithBase and OptionalWithMember should be the same thing. It's
just that one inherits from its storage and the other has it as a member. But
the codegen is very different (https://godbolt.org/z/j8m68Y), probably
something to do with tail padding?

gcc 10.1 -O2:

foo_with_base(bool):
testdil, dil
je  .L2
mov DWORD PTR [rsp-8], 42
mov BYTE PTR [rsp-4], 1
mov rax, QWORD PTR [rsp-8]
ret
.L2:
mov BYTE PTR [rsp-4], 0
mov rax, QWORD PTR [rsp-8]
ret
foo_with_member(bool):
testdil, dil
mov eax, 0
movabs  rdx, 4294967338
cmovne  rax, rdx
ret

gcc 10.2 -O3 or gcc trunk -O2:

foo_with_base(bool):
xor eax, eax
testdil, dil
je  .L2
mov DWORD PTR [rsp-8], 42
mov eax, 1
.L2:
mov BYTE PTR [rsp-4], al
mov rax, QWORD PTR [rsp-8]
ret
foo_with_member(bool):
xor edx, edx
mov ecx, 42
testdil, dil
cmovne  rax, rcx
mov ecx, 1
cmovne  rdx, rcx
movabs  rcx, -1095216660481
and rax, rcx
sal rdx, 32
or  rax, rdx
ret

clang 10, -O2 or -O3:

foo_with_base(bool): # @foo_with_base(bool)
shl rdi, 32
lea rax, [rdi + 42]
ret
foo_with_member(bool):   # @foo_with_member(bool)
shl rdi, 32
lea rax, [rdi + 42]
ret

[Bug c++/93698] ICE on concept using generic lambda

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ivan.pogrebnyak at gmail dot 
com

--- Comment #1 from Patrick Palka  ---
*** Bug 95324 has been marked as a duplicate of this bug. ***

[Bug c++/95324] Segmentation fault when using variadic lambda template in concept definition

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
This seems to be a dup of PR93698.

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

[Bug c++/95383] New: Poor codegen when constructing a trivial Optional

[barry.revzin at gmail dot com]

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

Bug ID: 95383
   Summary: Poor codegen when constructing a trivial Optional
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Here is a complete example:

struct nullopt_t {} inline constexpr nullopt{};

template 
struct Optional {
struct Empty { };
union {
Empty _;
T value;
};
bool engaged;

Optional(nullopt_t) : _(), engaged(false) { }
Optional(T v) : value(v), engaged(true) { }
};

Optional foo(bool b) {
if (b) {
return 42;
}
return nullopt;
}

Optional here is a valid implementation strategy for trivial types, like int.
You can see some codegen examples here: https://godbolt.org/z/KwuWzB

gcc 10.1 -O2 emits:

foo(bool):
testdil, dil
mov eax, 0
movabs  rdx, 4294967338
cmovne  rax, rdx
ret

gcc 10.1 -O3 is worse:

foo(bool):
xor eax, eax
mov ecx, 42
testdil, dil
cmovne  rdx, rcx
mov ecx, 1
cmovne  rax, rcx
movabs  rcx, -1095216660481
and rdx, rcx
sal rax, 32
or  rax, rdx
ret

gcc trunk (as of today) -O2 is the same as this bad -O3 version.

clang 10, on the other hand, on -O2 or -O3, emits:

foo(bool):# @foo(bool)
shl rdi, 32
lea rax, [rdi + 42]
ret

which is much better. 

Using std::optional instead of this Optional (https://godbolt.org/z/By-fYx) for
comparison, clang emits the same code as above. gcc 10 -O3 emits a branch:

foo(bool):
xor eax, eax
testdil, dil
je  .L2
mov DWORD PTR [rsp-8], 42
mov eax, 1
.L2:
mov BYTE PTR [rsp-4], al
mov rax, QWORD PTR [rsp-8]
ret

[Bug c++/94128] ICE on C++20 "requires requires" with lambda

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:f2fe2ad8d379297dcf571b2b9c46200c5ae5391f

commit r10-8200-gf2fe2ad8d379297dcf571b2b9c46200c5ae5391f
Author: Mark Eggleston 
Date:   Wed Apr 1 09:52:41 2020 +0100

Fortran  : "type is( real(kind(1.)) )" spurious syntax error PR94397

Based on a patch in the comments of the PR. That patch fixed this
problem but caused the test cases for PR93484 to fail. It has been
changed to reduce initialisation expressions if the expression is
not EXPR_VARIABLE and not EXPR_CONSTANT.

2020-05-28  Steven G. Kargl  
Mark Eggleston  

gcc/fortran/

PR fortran/94397
* match.c (gfc_match_type_spec): New variable ok initialised
to true. Set ok with the return value of gfc_reduce_init_expr
called only if the expression is not EXPR_CONSTANT and is not
EXPR_VARIABLE. Add !ok to the check for type not being integer
or the rank being greater than zero.

2020-05-28  Mark Eggleston  

gcc/testsuite/

PR fortran/94397
* gfortran.dg/pr94397.F90: New test.

(cherry picked from commit 3ea6977d0f1813d982743a09660eec1760e981ec)

[Bug target/95285] AArch64:aarch64 medium code model proposal

[wilco at gcc dot gnu.org]

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

--- Comment #15 from Wilco  ---
(In reply to Bu Le from comment #14)
> > > Anyway, my point is that the size of single data does't affact the fact 
> > > that
> > > medium code model is missing in aarch64 and aarch64 is lack of PIC large
> > > code model.
> > 
> > What is missing is efficient support for >4GB of data, right? How that is
> > implemented is a different question - my point is that it does not require a
> > new code model. It would be much better if it just worked without users even
> > needing to think about code models.
> > 
> > Also, what is the purpose of a large fpic model? Are there any applications
> > that use shared libraries larger than 4GB?
> 
> Yes, I understand, and I am grateful for you suggestion. I have to say it is
> not a critical problem. After all, most applications works fine with
> curreent code modes. 
> 
> But there are some cases, like CESM with certain configuration, or my test
> case, which cannot be compiled with current gcc compiler on aarch64.
> Unfortunately, applications that large than 4GB is quiet normal in HPC
> feild. In the meantime, x86 and llvm-aarch64 can compile it, with medium or
> large-pic code model. That is the purpose I am proposing it. By adding this
> feature, we can make a step forward for aarch64 gcc compiler, making it more
> powerful and robust.
> 
> Clear enough for your concern? 

Yes but such a feature needs to be defined in an ABI and well specified. This
is why I'm trying to get the underlying requirements first. Note that while
LLVM allows -fpic in large model, it doesn't correctly implement it. The large
model shouldn't ever be needed by actual applications.

> And for the implementation you suggested, I believe it is a promissing plan.
> I would like to try to implement it first. Might take weeks of development.
> I will see what I can get. I will give you update with progress.
> 
> Thanks for the suggestion again.

As discussed, there are many different ways of supporting the requirement of
>4GB of data, so I wouldn't start on the implementation before there is a good
specification. GCC and LLVM would need to implement it in the same way after
all.

[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #5 from Tom Tromey  ---
(In reply to Asher Gordon from comment #3)

> It seems that Sparse's behavior is the same as GCC's. It warns on '{ 0 }'.
> (Note that in Sparse, the attribute must be specified after the closing
> brace.)

Since this warning is intended to work like sparse, introducing
a divergence here would seem to make the feature less useful,
in fact subverting the point of having it.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #1)
> can we have a backtrace?

Working on it.

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[wilco at gcc dot gnu.org]

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

--- Comment #34 from Wilco  ---
(In reply to Jiu Fu Guo from comment #33)
> It would be relatively easy if the target supports unaligned access.  like
> read64ne in
> https://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/common/memcmplen.h
> Then the alignment issue is relaxed.   It may be safer if we can
> prove/assume the underlying buffer is enough, like array accessing or
> pointer+index accessing in a loop.

Yes, without unaligned support you can't use a wider access.

If we can't prove the buffer bounds then we'd have to use a page cross check
before every unaligned access.

[Bug debug/95343] IPA-SRA can result in wrong debug info about removed function arguments

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
I have proposed a patch series on the mailing list to address PR 93385 and the
last patch in it also addresses this issue and allows gdb to print the correct
value of the removed parameter:

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546705.html

[Bug tree-optimization/95113] [10/11 Regression] Wrong code w/ -O2 -fexceptions -fnon-call-exceptions

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
(In reply to Arseny Solokha from comment #3)
> 
> Indeed, -fno-ipa-sra fixes it. So, a duplicate of PR93385?

Similar, but not quite the same.  I have proposed a fix on the mailing
list: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546703.html

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 Target||m68k
   Last reconfirmed||2020-05-28
   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
can we have a backtrace?

[Bug rtl-optimization/95382] New: [haifa-sched][DO_PREDICATION] execution test: wrong scheduling result.

[xuemaosheng at huawei dot com]

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

Bug ID: 95382
   Summary: [haifa-sched][DO_PREDICATION] execution test: wrong
scheduling result.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xuemaosheng at huawei dot com
  Target Milestone: ---

Created attachment 48626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48626&action=edit
the source file

After we enable the schedule DO_PREDICATION, we get wrong scheduling result in
sched2 pass.
The key dump is shown as following：

...(Unimportant things)

;;  |   93 |   15 | a20=sxn([a19]) 
;;  |   94 |   10 | t2=a20==0 
;;  |   95 |9 | pc={(t2!=0)?L107:pc}jump_insn1  
;;  |  159 |   10 | a21=0x8000  
;;  |   98 |9 | t0=a23!=a21 
;;  |   99 |8 | pc={(t0==0)?L173:pc}jump_insn2  
;;  |  105 |7 | a22=a23/a20 div_insn   
;;  |  106 |1 | a23=sxn(a22)  

...(Unimportant things)

;;   --- EBB Dependences --- from bb4 to bb6 
;;  insn  codebb   dep  prio  cost   reservation

...(Unimportant things)

;;   9394 4 415 1   : 105(t,1) 99(a,0) 94(t,5)  
;;   94  1645 4 110 1   : 106(t,1) 95(t,1)   
;;   95   139 413 9 1   : 106(c,1) 99(a,1)nm 
;;  159   129 5 010 1   : 98(t,1)
;;   98  1650 5 2 9 1   : 105(t,1) 106(t,1)m 99(t,1)
;;   99   139 515 8 1   : 105(c,1) 106(c,1)  
;;  10537 6 4 7 1   : 106(t,6)m  
;;  10694 6 6 1 1   :  

...(Unimportant things) 

When we enable the schedule DO_PREDICATION, we can produce conditional 
execution insn.

Since insn 98(t0=a23!=a21) doesn't have dependence with jump_insn1 95
(pc={(t2!=0)?L107:pc}), so insn 98 can issue before jump_insn1 95.
And insn 93 (a20=sxn([a19])) can also issue before jump_insn1 95.
After that, insn 105(a22=a23/a20) can become conditional execution insn shown 
as following dump:

;;   51--> 93 a20=sxn([a19])  : 
rescanning insn with uid = 105. 
;;  dependencies resolved: insn105 predicated   
;;  Ready-->Q: insn105: queued for 1 cycles (change queue
index).
;;  tick updated: insn105 into queue with cost=1  

After  predicating, insn 105 have become : [t0]a22=a23/a20

;;   52-->105 (t0) a22=a23/a20:   
;;  Ready list (t =  52):

...(Unimportant things) 

;;  Ready list (t =  56):94:50:prio=10  
[52;56]:94  
;;   56--> 94 t2=a20==0   : 

...(Unimportant things)
;;  Ready list (t =  57):95:51:prio=9   
[56;57]:95  
;;   57--> 95 pc={(t2!=0)?L107:pc}:


finally, insn 105([t0]a22=a23/a20) is issued before insn 95
(pc={(t2!=0)?L107:pc}).
However, insn 95 has decided reg a20 is valid not.
In this case, a20 is 0, so we get division by 0 error.

The scheduling result is shown as the following:

tstneq@ags  t0, a23, a21   # [28]   # 98

l16si@agl   a20, a19, 0# [51]   # 93

[t0] quos@sau   a22, a23, a20  # [52]   # 105
tsteqi@sau  t2, a20, 0 # [53]   # 94
[t2] b@pcu  .L5, 1 # [54]   # 95
[!t0] b@pcu .L28, 0# [55]   # 99
..

Insn 105 (div_insn)should not be issued before insn 95(jump_insn1).
Note： This ebb is 3 basic-blocks.

Since supporting DO_PREDICATION target is little, it's difficult to recurrent
in other target.

How can we solve the problem?

[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jamborm at gcc dot gnu.org]

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

--- Comment #35 from Martin Jambor  ---
I have proposed a patch series that deals with this issue, including proper
adjustments to debug info, on the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546702.html

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:3ea6977d0f1813d982743a09660eec1760e981ec

commit r11-693-g3ea6977d0f1813d982743a09660eec1760e981ec
Author: Mark Eggleston 
Date:   Wed Apr 1 09:52:41 2020 +0100

Fortran  : "type is( real(kind(1.)) )" spurious syntax error PR94397

Based on a patch in the comments of the PR. That patch fixed this
problem but caused the test cases for PR93484 to fail. It has been
changed to reduce initialisation expressions if the expression is
not EXPR_VARIABLE and not EXPR_CONSTANT.

2020-05-28  Steven G. Kargl  
Mark Eggleston  

gcc/fortran/

PR fortran/94397
* match.c (gfc_match_type_spec): New variable ok initialised
to true. Set ok with the return value of gfc_reduce_init_expr
called only if the expression is not EXPR_CONSTANT and is not
EXPR_VARIABLE. Add !ok to the check for type not being integer
or the rank being greater than zero.

2020-05-28  Mark Eggleston  

gcc/testsuite/

PR fortran/94397
* gfortran.dg/pr94397.F90: New test.

[Bug tree-optimization/95356] [11 Regression] ICE in vect_get_constant_vectors, at tree-vect-slp.c:3635 since r11-564-g79f0451c67e8ed56

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
OK, so vectorizable_shift doing

  else if (dt[1] == vect_constant_def)
{
  /* Convert the scalar constant shift amounts in-place.  */
  slp_tree shift = SLP_TREE_CHILDREN (slp_node)[1];
  gcc_assert (SLP_TREE_DEF_TYPE (shift) == vect_constant_def);
  for (unsigned i = 0;
   i < SLP_TREE_SCALAR_OPS (shift).length (); ++i)
{
  SLP_TREE_SCALAR_OPS (shift)[i]
  = fold_convert (TREE_TYPE (vectype),
  SLP_TREE_SCALAR_OPS (shift)[i]);
  gcc_assert ((TREE_CODE (SLP_TREE_SCALAR_OPS (shift)[i])
   == INTEGER_CST));
}

no longer works because we already tried code-generating it.  The above would
need to happen at analysis time (ensuring the node is not shared - which would
be a problem for the above code as well).

[Bug tree-optimization/95356] [11 Regression] ICE in vect_get_constant_vectors, at tree-vect-slp.c:3635 since r11-564-g79f0451c67e8ed56

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Reopening as the following is ICEing:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr95356.c -c
-O3 -mavx512dq
during GIMPLE pass: slp
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr95356.c: In
function ‘f1’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr95356.c:8:1:
internal compiler error: in vect_create_constant_vectors, at
tree-vect-slp.c:3674
8 | f1 (void)
  | ^~
0x769846 vect_create_constant_vectors
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3674
0x769846 vect_schedule_slp_instance
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4066
0x10d3508 vect_schedule_slp_instance
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4071
0x10d3508 vect_schedule_slp_instance
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4071
0x10d9552 vect_schedule_slp(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:4303
0x10dbffc vect_slp_bb_region
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3342
0x10dbffc vect_slp_bb(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:3465
0x10dd9ef execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:1320
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.