[Bug tree-optimization/95019] Optimizer produces suboptimal code related to -ftree-ivopts

[amker at gcc dot gnu.org]

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

--- Comment #3 from bin cheng  ---
(In reply to zhongyu...@tom.com from comment #2)
> It is a generic issue for all targets, such as x86, it also don't enpand
Yes, as said it's because SCEV currently doesn't model this, so it's not target
specific.

> IVOPTs as index is not used for DEST and Src directly. we may need expand
Yes, extending IVOPTs to handle this case (and cases from other PRs) seems
promising.
Anyway, patch is welcome, and I can do the review.

Thanks,
> IVOPTs, then different targets can select different one according their Cost
> model.
> Now, it seems ok for x86 as it have load/store insns folded the lshift
> operand, so it doesn't need separate lshift operand in loop body .
> 
> == base on the ARM gcc 9.2.1 on https://gcc.godbolt.org, You'll get
> separate lshift operand lsl in loop kernel, and ARM64 gcc 8.2 will use ldr  
> x3, [x1, x4, lsl 3] to avoid the separate lshift operand. so we can see all
> target dont select an IV with Step 8. 
> C0ADA(unsigned long long, long long*, long long*):
> push{r4, r5, r6, r7, lr}@
> mov r4, r0@ len, tmp135
> mov r5, r1@ len, tmp136
> orrsr1, r4, r5  @ tmp137, len
> beq .L1 @,
> mov r1, #0@ C05A1,
> .L3:
> lsl r0, r1, #3@ _2, C05A1,
> add ip, r2, r1, lsl #3@ tmp120, Src, C05A1,
> ldr lr, [r2, r0]  @ _4, *_3
> ldr ip, [ip, #4]  @ _4, *_3
> umull   r6, r7, lr, lr@ tmp125, _4, _4
> mul ip, lr, ip@ tmp122, _4, tmp122
> addsr1, r1, r4  @ C05A1, C05A1, len
> subsr4, r4, #1  @ len, len,
> sbc r5, r5, #0@ len, len,
> add r0, r3, r0@ tmp121, Dest, _2
> add r7, r7, ip, lsl #1@,, tmp122,
> orrslr, r4, r5  @ tmp138, len
> stm r0, {r6-r7}   @ *_5, tmp125
> bne .L3 @,
> .L1:
> pop {r4, r5, r6, r7, lr}  @
> bx  lr  @
> 
> Thanks for your notice.

[Bug tree-optimization/92177] [10 Regression] gcc.dg/vect/bb-slp-22.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Biener  ---
.

[Bug tree-optimization/92177] [10 Regression] gcc.dg/vect/bb-slp-22.c FAILs

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8140-gff9d4e09566e24d4dff10adeaef109823266c7bd
Author: Richard Biener 
Date:   Tue May 5 15:38:24 2020 +0200

testsuite/92177 - adjust expected patterns for gcc.dg/vect/bb-slp-22.c

We now always vectorize two BBs, adjust the selector to also scan
for integer multiplication vectorization explicitely.

2020-05-05  Richard Biener  

PR testsuite/92177
* gcc.dg/vect/bb-slp-22.c: Adjust.

[Bug ipa/94947] [8/9/10 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8142-ga68d4b47a6b5b23a5d7ab3b358f559f41568512f
Author: Richard Biener 
Date:   Thu May 7 14:06:02 2020 +0200

ipa/94947 - avoid using externally_visible_p ()

externally_visible_p wasn't the correct predicate to use (even if it
worked), instead we should use DECL_EXTERNAL || TREE_PUBLIC.

2020-05-07  Richard Biener  

PR ipa/94947
* tree-ssa-structalias.c (refered_from_nonlocal_fn): Use
DECL_EXTERNAL || TREE_PUBLIC instead of externally_visible.
(refered_from_nonlocal_var): Likewise.
(ipa_pta_execute): Likewise.

[Bug ipa/94947] [8/9/10 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:67d00c438285ecf9b8e96c12d1f6b05fd2ea3c21

commit r10-8141-g67d00c438285ecf9b8e96c12d1f6b05fd2ea3c21
Author: Richard Biener 
Date:   Tue May 5 13:09:50 2020 +0200

ipa/94947 - fix test for externally visible variables for IPA PTA

This fixes lack of an escape point of externally declared variables.

2020-05-05  Richard Biener  

PR ipa/94947
* tree-ssa-structalias.c (ipa_pta_execute): Use
varpool_node::externally_visible_p ().
(refered_from_nonlocal_var): Likewise.

* gcc.dg/torture/pr94947-1.c: New testcase.
* gcc.dg/torture/pr94947-2.c: Likewise.

[Bug libgcc/95099] New: Build a cross compiler for m32c on Windows (Cygwin)

[dj_adilovic at hotmail dot com]

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

Bug ID: 95099
   Summary: Build a cross compiler for m32c on Windows (Cygwin)
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dj_adilovic at hotmail dot com
  Target Milestone: ---

Hi Everybody,
i want to Build a cross compiler for the m32c-elf.
but i get a Error during make the newlib-3.1.0.
The error lock like:
during RTL pass: pro_and_epilogue
../../../../../../newlib-3.1.0/newlib/libc/argz/argz_add.c: In function
‘argz_add’:
../../../../../../newlib-3.1.0/newlib/libc/argz/argz_add.c:32:1: internal
compiler error: in leaf_function_p, at final.c:4473
   32 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [Makefile:399: lib_a-argz_add.o] Error 1
make[8]: Leaving directory
'/home/cross/m32c-newlib/m32c-elf/m32cm/newlib/libc/argz'
make[7]: *** [Makefile:683: all-recursive] Error 1
make[7]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/m32cm/newlib/libc'
make[6]: *** [Makefile:641: all-recursive] Error 1
make[6]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/m32cm/newlib'
make[5]: *** [Makefile:452: all] Error 2
make[5]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/m32cm/newlib'
make[4]: *** [Makefile:1260: multi-do] Error 1
make[4]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/newlib'
make[3]: *** [Makefile:1176: all-multi] Error 2
make[3]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/newlib'
make[2]: *** [Makefile:452: all] Error 2
make[2]: Leaving directory '/home/cross/m32c-newlib/m32c-elf/newlib'
make[1]: *** [Makefile:8496: all-target-newlib] Error 2
make[1]: Leaving directory '/home/cross/m32c-newlib'
make: *** [Makefile:883: all] Error 2

can somone help me.
Thank you

[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #42 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:883246530f1bb10d854f455e1c3d55b93675690a

commit r11-347-g883246530f1bb10d854f455e1c3d55b93675690a
Author: Alexandre Oliva 
Date:   Wed May 13 04:49:00 2020 -0300

x86-vxworks malloc aligns to 8 bytes like solaris

Vxworks 7's malloc, like Solaris', only ensures 8-byte alignment of
returned pointers on 32-bit x86, though GCC's stddef.h defines
max_align_t with 16-byte alignment for __float128.  This patch enables
on x86-vxworks the same memory_resource workaround used for x86-solaris.

The testsuite also had a workaround, defining BAD_MAX_ALIGN_T and
xfailing the test; extend those to x86-vxworks as well, and remove the
check for char-aligned requested allocation to be aligned like
max_align_t.  With that change, the test passes on x86-vxworks; I'm
guessing that's the same reason for the test not to pass on
x86-solaris (and on x86_64-solaris -m32), so with the fix, I'm
tentatively removing the xfail.


for libstdc++-v3/ChangeLog

PR libstdc++/77691
* include/experimental/memory_resource
(__resource_adaptor_imp::do_allocate): Handle max_align_t on
x86-vxworks as on x86-solaris.
(__resource_adaptor_imp::do_deallocate): Likewise.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Drop xfail.
(BAD_MAX_ALIGN_T): Define on x86-vxworks as on x86-solaris.
(test03): Drop max-align test for char-aligned alloc.

[Bug tree-optimization/95051] error: invalid RHS for gimple memory store:

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-348-g3d96f7b92415b7a277a87e7825efc958030e20b6
Author: Martin Liska 
Date:   Wed May 13 09:52:21 2020 +0200

Simplify test-case options.

PR sanitizer/95051
* gcc.dg/asan/pr95051.c: Simplify options as -fsanitize=address
and -O2 were enough to trigger the original ICE.

[Bug testsuite/95092] new test case gcc.dg/asan/pr95051.c fails

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Fixed now.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[tkoenig at gcc dot gnu.org]

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

--- Comment #29 from Thomas Koenig  ---
It is also interesting that this variant

--- a/libgfortran/generated/in_pack_i4.c
+++ b/libgfortran/generated/in_pack_i4.c
@@ -88,7 +88,7 @@ internal_pack_4 (gfc_array_i4 * source)
   count[0]++;
   /* Advance to the next source element.  */
   index_type n = 0;
-  while (count[n] == extent[n])
+  while (n < dim && count[n] == extent[n])
 {
   /* When we get to the end of a dimension, reset it and increment
  the next dimension.  */
@@ -100,7 +100,6 @@ internal_pack_4 (gfc_array_i4 * source)
   if (n == dim)
 {
   src = NULL;
-  break;
 }
   else
 {

does not get peeled.

[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r11-349-gf884bef2105d748fd7869cd641cbb4f6b6bb
Author: Tobias Burnus 
Date:   Wed May 13 10:06:45 2020 +0200

[Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690)

gcc/fortran/
2020-05-13  Tobias Burnus  

PR fortran/94690
* openmp.c (OMP_DISTRIBUTE_CLAUSES): Add OMP_CLAUSE_LASTPRIVATE.
(gfc_resolve_do_iterator): Skip the private handling for SIMD as
that is handled by ME code.
* trans-openmp.c (gfc_trans_omp_do): Don't add private/lastprivate
for dovar_found == 0, unless !simple.

libgomp/
2020-05-13  Tobias Burnus  

PR fortran/94690
* testsuite/libgomp.fortran/pr66199-3.f90: New.
* testsuite/libgomp.fortran/pr66199-4.f90: New.
* testsuite/libgomp.fortran/pr66199-5.f90: New.
* testsuite/libgomp.fortran/pr66199-6.f90: New.
* testsuite/libgomp.fortran/pr66199-7.f90: New.
* testsuite/libgomp.fortran/pr66199-8.f90: New.
* testsuite/libgomp.fortran/pr66199-9.f90: New.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[rguenth at gcc dot gnu.org]

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

--- Comment #30 from Richard Biener  ---
(In reply to Thomas Koenig from comment #29)
> It is also interesting that this variant
> 
> --- a/libgfortran/generated/in_pack_i4.c
> +++ b/libgfortran/generated/in_pack_i4.c
> @@ -88,7 +88,7 @@ internal_pack_4 (gfc_array_i4 * source)
>count[0]++;
>/* Advance to the next source element.  */
>index_type n = 0;
> -  while (count[n] == extent[n])
> +  while (n < dim && count[n] == extent[n])
>  {
>/* When we get to the end of a dimension, reset it and increment
>   the next dimension.  */
> @@ -100,7 +100,6 @@ internal_pack_4 (gfc_array_i4 * source)
>if (n == dim)
>  {
>src = NULL;
> -  break;
>  }
>else
>  {
> 
> does not get peeled.

More optimal would be

count[0]--;
>/* Advance to the next source element.  */
>index_type n = 0;
while (count[n] == 0)
  {
...
  }

note completely peeling the inner loop isn't as bad as it looks, it's
basically making the whole loop

  while (1)
{
  for (count[0] = 0; count[0] < extent[0]; ++count[0])
{
  /* Copy the data.  */
  *(dest++) = *src;
  /* Advance to the next element.  */
  src += stride0;
}
  if (dim == 1)
break;
  count[0] = 0;
  src -= stride[0] * extent[0];
  count[1]++;
  if (count[1] != extent[1])
continue;
  if (dim == 2)
break;
  count[1] = 0;
  src -= stride[1] * extent[1];
  count[2]++;
  if (count[2] != extent[2])
continue;
  if (dim == 3)
break;
...
}

which should be quite optimal for speed (branch-prediction wise).  One
might want to try to optimize code size a bit, sure.  Sacrifying a bit
of speed at the loop exit could be setting extent[n > dim] = 1 and
dropping the if (dim == N) break; checks, leaving just the last.
Likewise changing the iteration from extent[N] to zero might make
the tests smaller.  Then as commented in the code pre-computing the
products might help as well - you get one additional load of course.
Interleaving extent and the product data arrays would help cache
locality.

Note writing the loop as above will make GCC recognize it as a loop
nest.

[Bug c++/95100] New: xxx_view adaptors don't work with pipeline operator

[rhalbersma at gmail dot com]

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

Bug ID: 95100
   Summary:  xxx_view adaptors don't work with pipeline
operator
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhalbersma at gmail dot com
  Target Milestone: ---

Combining the std::ranges::xxx_view adaptors with the pipeline operator does
not compile, in contrast to the supposedly expression equivalent
std::ranges:views::xxx 

#include 
#include  
#include 

int main() {
auto v = std::vector { 1, 2, 3, 4, 5, 6 };

// OK
for (auto elem : std::ranges::views::reverse(v)) {
std::cout << elem << ',';
}

// OK
for (auto elem : std::ranges::reverse_view(v)) {
std::cout << elem << ',';
}

// OK
for (auto elem : v | std::ranges::views::reverse) {
std::cout << elem << ',';
}

// error: missing template arguments before ')' token
for (auto elem : v | std::ranges::reverse_view) {
std::cout << elem << ',';
}

// OK
for (auto elem : v | std::ranges::views::transform([](auto e) { return e +
1; })) {
std::cout << elem << ',';
}

// error: class template argument deduction failed:
for (auto elem : v | std::ranges::transform_view([](auto e) { return e + 1;
})) {
std::cout << elem << ',';
}
}

See online example on Wandbox here:
https://wandbox.org/permlink/E6ScFmm8DdmkFo74

Tested this also for drop_view, take_view, filter_view etc., with similar
results (not shown for brevity in the code snippet).

[Bug libfortran/95101] New: Optimize libgfortran library handling of arrays

[tkoenig at gcc dot gnu.org]

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

Bug ID: 95101
   Summary: Optimize libgfortran library handling of arrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Here are some ideas:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018#c30

[Bug libfortran/95101] Optimize libgfortran library handling of arrays

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93114

--- Comment #1 from Thomas Koenig  ---
Also make sure that span is handled directly by the library.

[Bug rtl-optimization/95102] New: missed if-conversion

[rguenth at gcc dot gnu.org]

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

Bug ID: 95102
   Summary: missed if-conversion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

If you rewrite gcc.target/i386/pr54855-9.c to a form GIMPLE looks like after
some PRE you end up with

typedef float vec __attribute__((vector_size(16)));

vec
foo (vec x, float a)
{
  if (!(x[0] < a))
x[0] = a;
  return x;
}

which is no longer recognized as the same and emits

foo:
.LFB0:
.cfi_startproc
comiss  %xmm0, %xmm1
ja  .L2
movss   %xmm1, %xmm0
.L2:
ret

instead of

foo:
.LFB1:  
.cfi_startproc
minss   %xmm1, %xmm0
ret

this is because RTL if-conversion does not recognize

7: r86:SF=vec_select(r84:V4SF,parallel)
8: flags:CCFP=cmp(r85:SF,r86:SF)
  REG_DEAD r86:SF
9: pc={(flags:CCFP>0)?L14:pc}
  REG_DEAD flags:CCFP
  REG_BR_PROB 536870916

   10: NOTE_INSN_BASIC_BLOCK 3
   12: r84:V4SF=vec_merge(vec_duplicate(r85:SF),r84:V4SF,0x1)
  REG_DEAD r85:SF

   14: L14:
   15: NOTE_INSN_BASIC_BLOCK 4
   20: xmm0:V4SF=r84:V4SF

the form it does recognize is

8: r82:SF=vec_select(r84:V4SF,parallel)
9: flags:CCFP=cmp(r85:SF,r82:SF)
   10: pc={(flags:CCFP>0)?L28:pc}
  REG_DEAD flags:CCFP
  REG_BR_PROB 536870916

   28: L28:
   14: NOTE_INSN_BASIC_BLOCK 3
5: r85:SF=r82:SF
  REG_DEAD r82:SF

   15: L15:
   16: NOTE_INSN_BASIC_BLOCK 4
   18: r87:V4SF=vec_merge(vec_duplicate(r85:SF),r84:V4SF,0x1)

[Bug rtl-optimization/95102] missed if-conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
OK, so one reason is that

  if (!can_conditionally_move_p (x_mode))
return FALSE;

returns false for E_V4SFmode on x86.  min/max detection is based
on fp_cmov expansion for scalar FP on x86 though (with its own
problems, see PR95083).

[Bug tree-optimization/95060] vfnmsub132ps is not generated with -ffast-math

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-350-gc0c39a765b0714aed36fced6fbba452a6619acb0
Author: Jakub Jelinek 
Date:   Wed May 13 11:21:02 2020 +0200

Fold single imm use of a FMA if it is a negation [PR95060]

match.pd already has simplifications for negation of a FMA (FMS, FNMA,
FNMS)
call if it is single use, but when the widening_mul pass discovers FMAs,
nothing folds the statements anymore.

So, the following patch adjusts the widening_mul pass to handle that.

I had to adjust quite a lot of tests, because they have in them nested FMAs
(one FMA feeding another one) and the patch results in some (equivalent)
changes
in the chosen instructions, previously the negation of one FMA's result
would result in the dependent FMA being adjusted for the negation, but now
instead the first FMA is adjusted.

2020-05-13  Jakub Jelinek  

PR tree-optimization/95060
* tree-ssa-math-opts.c (convert_mult_to_fma_1): Fold a NEGATE_EXPR
if it is the single use of the FMA internal builtin.

* gcc.target/i386/avx512f-pr95060.c: New test.
* gcc.target/i386/fma_double_1.c: Adjust expected insn counts.
* gcc.target/i386/fma_double_2.c: Likewise.
* gcc.target/i386/fma_double_3.c: Likewise.
* gcc.target/i386/fma_double_4.c: Likewise.
* gcc.target/i386/fma_double_5.c: Likewise.
* gcc.target/i386/fma_double_6.c: Likewise.
* gcc.target/i386/fma_float_1.c: Likewise.
* gcc.target/i386/fma_float_2.c: Likewise.
* gcc.target/i386/fma_float_3.c: Likewise.
* gcc.target/i386/fma_float_4.c: Likewise.
* gcc.target/i386/fma_float_5.c: Likewise.
* gcc.target/i386/fma_float_6.c: Likewise.
* gcc.target/i386/l_fma_double_1.c: Likewise.
* gcc.target/i386/l_fma_double_2.c: Likewise.
* gcc.target/i386/l_fma_double_3.c: Likewise.
* gcc.target/i386/l_fma_double_4.c: Likewise.
* gcc.target/i386/l_fma_double_5.c: Likewise.
* gcc.target/i386/l_fma_double_6.c: Likewise.
* gcc.target/i386/l_fma_float_1.c: Likewise.
* gcc.target/i386/l_fma_float_2.c: Likewise.
* gcc.target/i386/l_fma_float_3.c: Likewise.
* gcc.target/i386/l_fma_float_4.c: Likewise.
* gcc.target/i386/l_fma_float_5.c: Likewise.
* gcc.target/i386/l_fma_float_6.c: Likewise.

[Bug debug/95080] [10/11 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:18edc195442291525e04f0fa4d5ef972155117da

commit r11-351-g18edc195442291525e04f0fa4d5ef972155117da
Author: Jakub Jelinek 
Date:   Wed May 13 11:22:37 2020 +0200

Fix -fcompare-debug issue in purge_dead_edges [PR95080]

The following testcase fails with -fcompare-debug, the bug used to be
latent
since introduction of -fcompare-debug.
The loop at the start of purge_dead_edges behaves differently between -g0
and -g - if the last insn is a DEBUG_INSN, then it skips not just
DEBUG_INSNs but also NOTEs until it finds some other real insn (or bb
head),
while with -g0 it will not skip any NOTEs, so if we have
real_insn
note
debug_insn // not present with -g0
then with -g it might remove useless REG_EH_REGION from real_insn, while
with -g0 it will not.

Yet another option would be not skipping NOTE_P in the loop; I couldn't
find
in history rationale for why it is done.

2020-05-13  Jakub Jelinek  

PR debug/95080
* cfgrtl.c (purge_dead_edges): Skip over debug and note insns even
if the last insn is a note.

* g++.dg/opt/pr95080.C: New test.

[Bug tree-optimization/95060] vfnmsub132ps is not generated with -ffast-math

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug debug/95080] [10 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression]
   |-fcompare-debug failure |-fcompare-debug failure
   |(length) with -Og   |(length) with -Og
   |-fcse-follow-jumps  |-fcse-follow-jumps
   |-fnon-call-exceptions   |-fnon-call-exceptions

--- Comment #4 from Jakub Jelinek  ---
Fixed for 11+ so far.

[Bug middle-end/94874] [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified in enclosing ‘target’'

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   See Also||https://github.com/OpenMP/s
   ||pec/issues/2155

--- Comment #4 from Tobias Burnus  ---
See comments in https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545594.html

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #31 from Jiu Fu Guo  ---
(In reply to Richard Biener from comment #28)

> > For the loop which has multi-exits, it may not helpful to unroll it,
> > especially "complete unroll" may be not helpful. Like loop in in_pack_i4.c.
> > Since it would early exit, some iterations(may most iterations) were not
> > executed.
> > 
> > Is it a good idea to disable the GIMPLE cunroll for this kind of loop? RTL
> > unroll_stupid does not unroll this kind of loop either.
> 
> Well, GIMPLE cunroll specifically handles the situation of peeling such loops
> and has a separate --param to control how many extra branches it may
> introduce
> for those exits.  Generally disabling unrolling of such loops isn't a good
> idea,
> the reason for completely unrolling loops is abstraction removal and not
> necessarily producing more optimal loop kernels (the loop is gone
> afterwards).

I think, the --param, which you said, maybe param_max_peel_branches which
default is 31. 
And currently, param_max_completely_peel_times is default to 16.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[rguenth at gcc dot gnu.org]

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

--- Comment #32 from Richard Biener  ---
Note I don't think the unrolling is excessive - store motion then applying
to all count[] and all computations hoisted out of the loop may be a bit
too much for register pressure though, especially since we're using
flag-based store-motion.  But it causes the stores to be materialized
on all exits of the loop which means we end up with N*N conditional stores :/

I guess SM could be improved here.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #33 from Jiu Fu Guo  ---
(In reply to Richard Biener from comment #32)
> Note I don't think the unrolling is excessive - store motion then applying
> to all count[] and all computations hoisted out of the loop may be a bit
> too much for register pressure though, especially since we're using
> flag-based store-motion.  But it causes the stores to be materialized
> on all exits of the loop which means we end up with N*N conditional stores :/

In general, it may not very aggressive for param_max_peel_branches = 31,
param_max_completely_peel_times = 16. 
For in_pack_i4.c, the loop is at most 13+1 times and then be unrolled. While
for the loop, unrolling increases size and does not help performance.

> 
> I guess SM could be improved here.


Thanks all!

[Bug c++/95103] New: Unexpected -Wclobbered in bits/vector.tcc with -O2

[sbergman at redhat dot com]

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

Bug ID: 95103
   Summary: Unexpected -Wclobbered in bits/vector.tcc with -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I have seen this with at least some GCC 7, and still see it with GCC 10 and
with recent trunk:

> $ cat test.cc
> #include 
> #include 
> struct S {
> S(int);
> ~S();
> };
> void f1();
> bool f2(char const (& s)[3]) {
> for (int i = 0; i != 2; ++i) {
> if (s[i] != 'x') {
> return false;
> }
> }
> return true;
> }
> void f3() {
> std::vector v;
> for (int i = 0; i != 2; ++i) {
> if (!f2("xx")) f1();
> v.push_back(0);
> }
> std::jmp_buf b;
> setjmp(b);
> }

> $ g++ -Wclobbered -O2 -c test.cc
> In file included from /usr/include/c++/10/vector:72,
>  from test.cc:2:
> /usr/include/c++/10/bits/vector.tcc: In function ‘void f3()’:
> /usr/include/c++/10/bits/vector.tcc:441:15: warning: variable ‘__new_finish’ 
> might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
>   441 |   pointer __new_finish(__new_start);
>   |   ^~~~

[Bug target/95099] Build a cross compiler for m32c on Windows (Cygwin)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 83670.

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

[Bug target/83670] [8/9/10/11 Regression] m32c ICE in leaf_function_p, at final.c:4368

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
Summary|m32c ICE in |[8/9/10/11 Regression] m32c
   |leaf_function_p, at |ICE in leaf_function_p, at
   |final.c:4368|final.c:4368

[Bug target/83670] m32c ICE in leaf_function_p, at final.c:4368

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dj_adilovic at hotmail dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 95099 has been marked as a duplicate of this bug. ***

[Bug middle-end/95052] [9/10/11 Regression] Excess padding of partially initialized strings/char arrays

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
Summary|Excess padding of partially |[9/10/11 Regression] Excess
   |initialized strings/char|padding of partially
   |arrays  |initialized strings/char
   ||arrays

[Bug tree-optimization/95034] Failure to convert xor pattern (made out of or+and) to xor

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/95104] New: Segfault on a legal WAIT statement

[longb at cray dot com]

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

Bug ID: 95104
   Summary: Segfault on a legal WAIT statement
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
  program test
  wait (10, iostat=ios)
  print *, ios
  close (10)
  end program test


> gfortran test.f90
> ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f3f0334159f in ???
#1  0x4007f6 in ???
#2  0x4008c7 in ???
#3  0x7f3f0332c349 in ???
#4  0x4006f9 in ???
at ../sysdeps/x86_64/start.S:120
#5  0x in ???
Segmentation fault (core dumped)
longb@jupiter:/cray/css/users/longb/spr/jira/22703> gfortran --version
GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 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.

[Bug fortran/95104] Segfault on a legal WAIT statement

[longb at cray dot com]

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

--- Comment #1 from Bill Long  ---
The program appears to be legal and should execute and print 0.  

The last paragraph of 12.7.2 WAIT statement (current Fortran standard) is


Execution of a WAIT statement specifying a unit that does not exist, has no
file connected to it, or is not open for asynchronous input/output is
permitted, provided that the WAIT statement has no ID= specifier; such a WAIT
statement does not cause an error or end-of-file condition to occur.

[Bug fortran/91731] Configure error on building MPICH

[keroro.90 at hotmail dot it]

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

keroro.90 at hotmail dot it changed:

   What|Removed |Added

 CC||keroro.90 at hotmail dot it

--- Comment #8 from keroro.90 at hotmail dot it ---
Steve workaround also worked for me (Fedora 32 + MPICH).
I just had to replace setenv with export as follows:
export PATH="~/work/x/bin:$PATH"   
export FFLAGS="-w -fallow-argument-mismatch -O2"

Hope this helps.

[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Martin Liška  ---
I support the patch. Can you please send it to gcc-patches mailing list?

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #6)
> On Tue, 12 May 2020, hjl.tools at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
> > 
> > --- Comment #4 from H.J. Lu  ---
> > The problem is since df_lr_bb_local_compute has
> > 
> >/* If the def is to only part of the reg, it does
> >not kill the other defs that reach here.  */
> > if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL)))
> >   {
> > unsigned int dregno = DF_REF_REGNO (def);
> > bitmap_set_bit (&bb_info->def, dregno);
> > bitmap_clear_bit (&bb_info->use, dregno);
> >   }
> > 
> > it doesn't consider
> > 
> > (insn 40 39 25 3 (set (subreg:SI (reg/v:DI 85 [ target ]) 4)
> > (subreg:SI (reg:V2DI 90) 0)) "x.i":17:7 -1
> >  (nil))
> > 
> > as a def.
> 
> Which it isn't since it sets the upper half of reg:DI 85 only.

True.  But it is clearly incorrect that reg:DI 85 is live at function
entrance.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
(In reply to Myron Walker from comment #22)
> It does the same things a gcov and lcov  combined but in python.  It also
> does merging of data but in a different way than gcov-tool.  I might need to
> change that.

Yes, please use gcov-tool for the merging.

> Another part of it is to allow access to different types of
> resource location hinting.  so a gcov prefix for a source code might be a
> github url and token.  A gcno file hint might be a web url or sub or nfs
> share.  Like wise the data file hints might be http, smb or nfs prefixes.

That should be done by your script. I realized that for the JSON format you
only need to put together .gcda and .gcno files:

$ ls
tramp3d-v4.gcda  tramp3d-v4.gcno
$ gcov tramp3d-v4.gcda -i
...
$ gunzip tramp3d-v4.gcda.gcov.json.gz
$ cat tramp3d-v4.gcda.gcov.json | python -m json.tool | grep '"file"'
"file": "tramp3d-v4.cpp",
"file": "/usr/include/c++/6/ext/new_allocator.h",
"file": "/usr/include/c++/6/ext/aligned_buffer.h",
"file": "/usr/include/c++/6/bits/move.h",
"file": "/usr/include/c++/6/bits/alloc_traits.h",
"file": "/usr/include/c++/6/bits/stl_list.h",
"file": "/usr/include/c++/6/bits/allocator.h",
"file": "/usr/include/c++/6/bits/allocated_ptr.h",
"file": "/usr/include/c++/6/bits/stl_iterator.h",
"file": "/usr/include/c++/6/bits/list.tcc",
"file": "/usr/include/c++/6/bits/stl_vector.h",
"file": "/usr/include/c++/6/iostream",
"file": "/usr/include/c++/6/bits/stl_construct.h",
"file": "/usr/include/c++/6/bits/stl_uninitialized.h",
"file": "/usr/include/c++/6/bits/vector.tcc",
"file": "/usr/include/c++/6/bits/stl_algobase.h",
"file": "/usr/include/c++/6/bits/stl_pair.h",
"file": "/usr/include/c++/6/bits/cpp_type_traits.h",
"file": "/usr/include/c++/6/bits/stl_bvector.h",
"file": "/usr/include/c++/6/ext/alloc_traits.h",
"file": "/usr/include/c++/6/bits/predefined_ops.h",
"file": "/usr/include/c++/6/bits/stl_heap.h",
"file": "/usr/include/c++/6/bits/stl_iterator_base_funcs.h",
"file": "/usr/include/c++/6/bits/stl_iterator_base_types.h",
"file": "/usr/include/c++/6/bits/stl_tree.h",
"file": "/usr/include/c++/6/bits/stl_algo.h",
"file": "/usr/include/c++/6/ext/type_traits.h",
"file": "/usr/include/c++/6/bits/stl_function.h",
"file": "/usr/include/c++/6/bits/basic_string.tcc",
"file": "/usr/include/c++/6/bits/basic_string.h",
"file": "/usr/include/c++/6/bits/stl_map.h",
"file": "/usr/include/c++/6/iomanip",
"file": "/usr/include/c++/6/limits",
"file": "/usr/include/c++/6/new",
"file": "/usr/include/c++/6/bits/char_traits.h",
"file": "/usr/include/c++/6/cmath",

And now your script can find and get the corresponding source files.

> 
> https://github.com/myronww/pycover
> 
> Still a work in progress though.

[Bug c++/70642] Invalid alias template instantiation not rejected if previously used in SFINAE context

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-357-g6cc6b087c8cdfdf58a4bb166aa53950c4bfdef2d
Author: Patrick Palka 
Date:   Wed May 13 09:20:44 2020 -0400

c++: Add testcase for already-fixed PR [PR70642]

We correctly reject the testcase in this PR ever since commit r9-7046.

gcc/testsuite/ChangeLog:

PR c++/70642
* g++.dg/cpp0x/alias-decl-70.C: New test.

[Bug c++/70642] Invalid alias template instantiation not rejected if previously used in SFINAE context

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

  Known to work||10.0, 11.0, 9.0
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |11.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Patrick Palka  ---
This is fixed for GCC 9+ by r9-7046 aka the fix for PR90047.

[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-358-gf9f98e59a7f6663f31b671c44998190079097f97
Author: Mark Eggleston 
Date:   Thu May 7 08:29:14 2020 +0100

Fortran  : ICE in gfc_conv_array_constructor_expr PR93497

Invalid expressions, such as those involving array constructors,
used for the length of character types will cause an ICE.

2020-05-13  Steven G. Kargl  

gcc/fortran/

PR fortran/93497
* decl.c (char_len_param_value): Check whether character
length expression is of type EXPR_OP and if so simplify it.
* resolve.c (resolve_charlen): Reject length if it has a
rank.

2020-05-13  Mark Eggleston  

gcc/testsuite/

PR fortran/93497
* gfortran.dg/pr88025.f90: Change in wording of error.
* gfortran.dg/pr93497.f90: New test.
* gfortran.dg/pr93714_1.f90: Change in wording of errors.
* gfortran.dg/pr93714_2.f90: Change in wording of errors.

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
(In reply to Patrick Palka from comment #11)
> I posted a patch to enable sanitization for the spec_hasher tables for GCC
> 11 here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545525.html
> 
> With current trunk I wasn't able to reproduce any sanitization errors in the
> testsuite or in other libraries even with a debugging patch similar to
> Martin's (on x86_64-pc-linux-gnu).  I suspect they have been fixed by the
> patches for PR94454.

Cool! Thank you Patrick for working on that.

[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8143-gf2b77b928a54784d40faf1d86bd5b63f14756dc5
Author: Mark Eggleston 
Date:   Thu May 7 08:29:14 2020 +0100

Fortran  : ICE in gfc_conv_array_constructor_expr PR93497

Invalid expressions, such as those involving array constructors,
used for the length of character types will cause an ICE.

2020-05-11  Mark Eggleston  

Backported from master
2020-05-13  Steven G. Kargl  

gcc/fortran/

PR fortran/93497
* decl.c (char_len_param_value): Check whether character
length expression is of type EXPR_OP and if so simplify it.
* resolve.c (resolve_charlen): Reject length if it has a
rank.

2020-05-11  Mark Eggleston  

Backported from master
2020-05-13  Mark Eggleston  

gcc/testsuite/

PR fortran/93497
* gfortran.dg/pr88025.f90: Change in wording of error.
* gfortran.dg/pr93497.f90: New test.
* gfortran.dg/pr93714_1.f90: Change in wording of errors.
* gfortran.dg/pr93714_2.f90: Change in wording of errors.

[Bug target/95083] x86 fp_movcc expansion depends on real_cst sharing

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
It looks to me that a couple of (scalar) splitters are missing in sse.md.

There is vector

(define_insn_and_split "*_blendv_lt"

Defined as:

  [(set (match_operand:VF_128_256 0 "register_operand" "=Yr,*x,x")
(unspec:VF_128_256
  [(match_operand:VF_128_256 1 "register_operand" "0,0,x")
   (match_operand:VF_128_256 2 "vector_operand" "YrBm,*xBm,xm")
   (lt:VF_128_256
 (match_operand: 3 "register_operand" "Yz,Yz,x")
 (match_operand: 4 "const0_operand" "C,C,C"))]
  UNSPEC_BLENDV))]

(please note const0 operand 4).

Probably similar pattern is missing that would degrade to MIN/MAX, for vector
and scalar versions.

[Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it

[felix.von.s at posteo dot de]

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

felix  changed:

   What|Removed |Added

 CC||felix.von.s at posteo dot de

--- Comment #4 from felix  ---
Given the discussion above apparently ended with the conclusion that code which
performs misaligned accesses is ill-formed even on architectures that are
permissive of such accesses, would it not make sense to make -Wcast-align
synonymous to -Wcast-align=strict?

[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8590-gcf7a6070c3688db20447643c789e157f73fc178b
Author: Mark Eggleston 
Date:   Thu May 7 08:29:14 2020 +0100

Fortran  : ICE in gfc_conv_array_constructor_expr PR93497

Invalid expressions, such as those involving array constructors,
used for the length of character types will cause an ICE.

2020-05-11  Mark Eggleston  

Backported from master
2020-05-13  Steven G. Kargl  

gcc/fortran/

PR fortran/93497
* decl.c (char_len_param_value): Check whether character
length expression is of type EXPR_OP and if so simplify it.
* resolve.c (resolve_charlen): Reject length if it has a
rank.

2020-05-11  Mark Eggleston  

Backported from master
2020-05-13  Mark Eggleston  

gcc/testsuite/

PR fortran/93497
* gfortran.dg/pr88025.f90: Change in wording of error.
* gfortran.dg/pr93497.f90: New test.
* gfortran.dg/pr93714_1.f90: Change in wording of errors.
* gfortran.dg/pr93714_2.f90: Change in wording of errors.

[Bug c++/95094] alignof(reference_to_type) doesn't return alignof(referenced_type) as it should by the standard

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88362

--- Comment #4 from Martin Sebor  ---
See also pr88362 for a related report of an inconsistency in handling
alignas/alignof (both within GCC and between GCC and Clang).

[Bug target/95105] New: Bogus reference-compatibility error for arm_sve_vector_bits

[rsandifo at gcc dot gnu.org]

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

Bug ID: 95105
   Summary: Bogus reference-compatibility error for
arm_sve_vector_bits
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

Compiling this testcase with -march=armv8.2-a+sve
-msve-vector-bits=512:

--
typedef __SVFloat32_t foo;
typedef foo bar __attribute__((arm_sve_vector_bits(512)));
template struct s { T x; };
extern s a;
bar &b = a.x;
--

gives the bogus error:

error: cannot bind non-const lvalue reference of type ‘bar&’ {aka
‘__SVFloat32_t&’} to an rvalue of type ‘bar’ {aka ‘__SVFloat32_t’}
5 | bar &b = a.x;
  |  ~~^

The testcase works if the attribute is applied directly
to __SVFloat32_t.

The bug is in the target-specific handling of the attribute.

[Bug target/95105] Bogus reference-compatibility error for arm_sve_vector_bits

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |10.2
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
   Last reconfirmed||2020-05-13

[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Richard Biener  ---
[...]
> Hmm, OK looks like memcpy is not folded, likely because the source is
> not known to be appropriately aligned.
[...]
> should fix this.  Can you verify and if so, commit?  Thx.

Unfortunately, it doesn't.

[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #9 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc-10 and gcc-9.

[Bug target/94743] IRQ handler doesn't save scratch VFP registers

[clyon at gcc dot gnu.org]

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

--- Comment #17 from Christophe Lyon  ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > > My initial thoughts are along the lines of...
> > > Only try to save FP registers that this function directly clobbers.
> > What's the point of saving these if a callee clobbers other registers?
> > 
> 
> They need to be done early enough to ensure that any code in *this* function
> does not clobber them.  Any additional registers would have to be saved by a
> library call that does that.

So if this function clobbers, say d16-d17, but calls another function, do you
mean we should
vpush d16-d17
then call the new lib function which saves all the FP context (thus saving
d16-d17 twice)?

> 
> > Shouldn't that be something like save-nothing vs save-all-FP-regs if there
> > is a callee?
> > 
> > Do you mean save direct clobbers only when the handler is a leaf function?
> 
> Well, obviously if it's a leaf function, saving only the registers that are
> clobbered is enough, and the compiler can do the analysis to ensure that.

I'm working on this, and just realized that this also means saving FPSR. It
seems there's no support for that yet in arm.md (unlike aarch64.md), am I
missing something?

> 
> > 
> > > Provide libgcc routines to save/restore the FP context.
> > Do you mean such routines should push all FP regs+status regs?
> 
> All registers that are are call clobbered.  There's no need to do the
> call-saved registers as the compiler can do that on an as-needed case
> already.

[Bug c++/94983] Empty list initialization of aggregate class with deleted default ctor rejected in C++14 and C++17

[andrey.vihrov at gmail dot com]

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

--- Comment #3 from Andrey Vihrov  ---
Another sample, probably caused by the same underlying issue:

struct T
{
char a[3];
};

void bar()
{
T t{"x"};   // OK
T{"x"}; // OK
new T{"x"}; // error: could not convert '{"x"}' from
// '' to 'T'
}

[Bug middle-end/94703] Small-sized memcpy leading to unnecessary register spillage unless done through a dummy union

[pskocik at gmail dot com]

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

--- Comment #11 from pskocik at gmail dot com ---
Thanks for the shot at a fix, Richard Biener.

Since I have reported this, I think I should mentioned a related suboptimality
that should probably be getting fixed alongside with this (if this one is
getting fixed), namely that while


int64_t zextend_int_to_int64_nospill(int *X) 
{ 
union { int64_t _; } r = {0}; return memcpy(&r._,X,sizeof(*X)),r._;
}

(and hopefully later even 

int64_t zextend_int_to_int64_spill(int *X) { int64_t r = {0}; return
memcpy(&r,X,sizeof(*X)),r; }
)

generates, on x86_64, the optimal

zextend_int_to_int64_nospill:
mov eax, DWORD PTR [rdi]
ret

for zeroextending promotions of sub-int types, an extra xor instruction gets
generated, e.g.:


int64_t zextend_short_to_int64_nospill_but_suboptimal(short *X) 
{
union { int64_t _; } r ={0}; return memcpy(&r._,X,sizeof(*X)),r._;
}

=>

zextend_short_to_int64_nospill_but_suboptimal:
xor eax, eax
mov ax, WORD PTR [rdi]
ret

which was surprising to me because it doesn't happen with zero-extending
memcpy-based promotion from {,u}ints to larger types ({,u}{,l}longs).

https://gcc.godbolt.org/z/ZjXaCw

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[seurer at linux dot vnet.ibm.com]

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

--- Comment #17 from Bill Seurer  ---
he patch works and has no further fallout that I see.

I will still try to extract something small from that big fortran function but
as I have not written any fortran code in more than 35 years it may take a bit.

[Bug fortran/95104] Segfault on a legal WAIT statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
0x284321d9 in _gfortran_st_wait_async (wtp=0xffbfe488)
at ../../../gcc/libgfortran/io/transfer.c:4495
4495  if (ASYNC_IO && u->au)
(gdb) p u
$1 = (gfc_unit *) 0x0

[Bug fortran/95104] Segfault on a legal WAIT statement

[longb at cray dot com]

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

--- Comment #3 from Bill Long  ---
A comment from the original user:  gfortran 8.3.0 appears to do the right
thing. So perhaps a regression somewhere in the 9.x line?

[Bug fortran/95106] New: Bogus warning from module with long name and an equivalence

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

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

Bug ID: 95106
   Summary: Bogus warning from module with long name and an
equivalence
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Name length 59 ok, suspicious warning for 60..63 :


$ cat z1_59.f90
module m2345678901234567890123456789012345678901234567890123456789
   real :: a(4), u(3,2)
   real :: b(4), v(4,2)
   equivalence (a(1),u(1,1)), (b(1),v(1,1))
end


$ cat z1_60.f90
module m23456789012345678901234567890123456789012345678901234567890
   real :: a(4), u(3,2)
   real :: b(4), v(4,2)
   equivalence (a(1),u(1,1)), (b(1),v(1,1))
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   real :: a(4), u(3,2)
   real :: b(4), v(4,2)
   equivalence (a(1),u(1,1)), (b(1),v(1,1))
end


$ gfortran-11-20200510 -c z1_59.f90
$
$ gfortran-11-20200510 -c z1_60.f90
z1_60.f90:1:67:

1 | module m23456789012345678901234567890123456789012345678901234567890
  |   1
Warning: Named COMMON block
'm23456789012345678901234567890123456789012345678901234567890.eq.1' at (1)
shall be of the same size as elsewhere (24 vs 32 bytes)

[Bug fortran/95107] New: [10/11 Regression] ICE in hash_operand, at fold-const.c:3768

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

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

Bug ID: 95107
   Summary: [10/11 Regression] ICE in hash_operand, at
fold-const.c:3768
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20191110 and 20191117, with -fno-automatic at -O2+ :


$ cat z1.f90
program p
   type t
  real, pointer :: a => null()
   end type
   type t2
  type(t) :: b(1)
   end type
   type(t2) :: x
   associate (y => x%b)
   end associate
end


$ gfortran-9 -c z1.f90 -fno-automatic -O2
$
$ gfortran-11-20200510 -c z1.f90 -fno-automatic -O2
during IPA pass: icf
z1.f90:11:0:

   11 | end
  |
internal compiler error: in hash_operand, at fold-const.c:3768
0x8dfc2a operand_compare::hash_operand(tree_node const*, inchash::hash&,
unsigned int)
../../gcc/fold-const.c:3768
0x8e038c operand_compare::hash_operand(tree_node const*, inchash::hash&,
unsigned int)
../../gcc/fold-const.c:3858
0x8dffa2 operand_compare::hash_operand(tree_node const*, inchash::hash&,
unsigned int)
../../gcc/fold-const.c:3685
0x142c58f ipa_icf::sem_variable::init(ipa_icf_gimple::func_checker*)
../../gcc/ipa-icf.c:1909
0x14340ce ipa_icf::sem_variable::parse(varpool_node*, bitmap_obstack*,
ipa_icf_gimple::func_checker*)
../../gcc/ipa-icf.c:1889
0x143897d ipa_icf::sem_item_optimizer::parse_funcs_and_vars()
../../gcc/ipa-icf.c:2457
0xaf61ec execute_ipa_summary_passes(ipa_opt_pass_d*)
../../gcc/passes.c:2191
0x7fca29 ipa_passes
../../gcc/cgraphunit.c:2642
0x7fca29 symbol_table::compile()
../../gcc/cgraphunit.c:2752
0x7fe806 symbol_table::compile()
../../gcc/cgraphunit.c:3002
0x7fe806 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2999

[Bug c++/94553] Revise [basic.scope.declarative]/4.2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
A patch for DR 2289 posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545692.html

[Bug c/95108] New: [10/11 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

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

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

Bug ID: 95108
   Summary: [10/11 Regression] ICE in tree_fits_uhwi_p, at
tree.c:7292
   Product: gcc
   Version: 11.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 20190811 and 20190818, with -fno-tree-ccp :
(test case derived from pr88588.c)


$ cat z1.c
int *v;

#pragma omp declare simd
void
foo (int x)
{
  int *a = &x + 1;

  for (;;)
{
  *v = *a;
  a = v;
}
}


$ gcc-10-20190811 -c z1.c -O2 -fopenmp -fno-tree-ccp
$
$ gcc-11-20200510 -c z1.c -O2 -fopenmp -fno-tree-ccp
during GIMPLE pass: alias
z1.c: In function 'foo.simdclone.0':
z1.c:5:1: internal compiler error: Segmentation fault
5 | foo (int x)
  | ^~~
0xb0ed8f crash_signal
../../gcc/toplev.c:328
0xd62e47 tree_fits_uhwi_p(tree_node const*)
../../gcc/tree.c:7292
0xcb74ad create_variable_info_for_1
../../gcc/tree-ssa-structalias.c:6068
0xcb7c43 create_variable_info_for
../../gcc/tree-ssa-structalias.c:6251
0xcb7c43 get_vi_for_tree
../../gcc/tree-ssa-structalias.c:2939
0xcb839f get_constraint_for_ssa_var
../../gcc/tree-ssa-structalias.c:3031
0xcb8902 get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3611
0xcb97c4 get_constraint_for_ptr_offset
../../gcc/tree-ssa-structalias.c:3166
0xcb8939 get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3544
0xcb9172 get_constraint_for_address_of
../../gcc/tree-ssa-structalias.c:3462
0xcb8b6b get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3530
0xcbce95 find_func_aliases
../../gcc/tree-ssa-structalias.c:5017
0xcbdafe compute_points_to_sets
../../gcc/tree-ssa-structalias.c:7380
0xcbdafe compute_may_aliases()
../../gcc/tree-ssa-structalias.c:7861
0xa4524e execute_function_todo
../../gcc/passes.c:1957
0xa46192 execute_todo
../../gcc/passes.c:2039


A test version (configured with --enable-checking=yes)
does not need that extra option :

$ gcc-11-20200510-chk -c z1.c -O2 -fopenmp
z1.c: In function 'foo.simdclone.7':
z1.c:14:1: error: definition in block 6 follows the use
   14 | }
  | ^
for SSA_NAME: _8 in statement:
_9 = &MEM  [(void *)_8 + 4B];
during IPA pass: simdclone
z1.c:14:1: internal compiler error: verify_ssa failed
0xf3faab verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1208
0xbe8827 execute_function_todo
../../gcc/passes.c:1992
0xbe952d do_per_function
../../gcc/passes.c:1647
0xbe9592 execute_todo
../../gcc/passes.c:2039

[Bug fortran/95104] Segfault on a legal WAIT statement

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Bill Long from comment #3)
> A comment from the original user:  gfortran 8.3.0 appears to do the right
> thing. So perhaps a regression somewhere in the 9.x line?

A note of the gfortran  wiki says full asynchronous support became
available in 9.1.  SO, likely a bug introduced in 9.  This fixes 
the segfault as it is never correct to dereference a NULL pointer.

Index: libgfortran/io/transfer.c
===
--- libgfortran/io/transfer.c   (revision 280157)
+++ libgfortran/io/transfer.c   (working copy)
@@ -4492,7 +4492,7 @@ void
 st_wait_async (st_parameter_wait *wtp)
 {
   gfc_unit *u = find_unit (wtp->common.unit);
-  if (ASYNC_IO && u->au)
+  if (ASYNC_IO && u && u->au)
 {
   if (wtp->common.flags & IOPARM_WAIT_HAS_ID)
async_wait_id (&(wtp->common), u->au, *wtp->id);


With this patch, your program prints '0'.  Don't know if this
is the only thing that needs fixing.  Thanks for the bug report.

[Bug fortran/95104] Segfault on a legal WAIT statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/95109] New: [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95109
   Summary: [11 regression] ICE in gfortran.dg/gomp/target1.f90
after r11-349
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

git g:f884bef2105d748fd7869cd641cbb4f6b6bb, r11-349
make -k check-gcc RUNTESTFLAGS=gomp.exp=gfortran.dg/gomp/target1.f90

# of unexpected failures2

FAIL: gfortran.dg/gomp/target1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/gomp/target1.f90   -O  (test for excess errors)

FAIL: gfortran.dg/gomp/target1.f90   -O  (test for excess errors)
Excess errors:
during GIMPLE pass: omplower
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/gomp/target1.f90:318:0:
internal compiler error: in lookup_decl_in_outer_ctx, at omp-low.c:3967
0x10a156cb lookup_decl_in_outer_ctx
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:3967
0x10a44a7b lower_send_clauses
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:7290
0x10a44a7b lower_omp_taskreg
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:11295
0x10a2adc7 lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12878
0x10a2adc7 lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a467bb lower_omp_for
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:10564
0x10a2b147 lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12823
0x10a2b147 lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015
0x10a2a18b lower_omp_1
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:12807
0x10a2a18b lower_omp
/home/seurer/gcc/git/gcc-test2/gcc/omp-low.c:13015

[Bug c++/95003] coroutines: Wrong code for some reference capture cases.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Sandoe  ---
so fixed for master and 10.2

[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  ---
Created attachment 48522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48522&action=edit
Patch to add OpenMP 5 feature (private + lastprivate permitted for 'simd')

The patch solves an independent issue, required for the test case below
(namely, the "private(j)").

The *committed* patch causes gfortran.dg/gomp/target1.f90 to FAIL.

The problem shows up with the following test case (reduced but modified):
-
  subroutine foo ()
integer :: s, i, j
!$omp target teams
!$omp distribute parallel do default(shared) &
!$omp collapse (2) private(j) lastprivate (s)
  do i = 1, 10
do j = 1, 10
  s = i * 10 + j
end do
  end do
!$omp end target teams
  end subroutine
-

The problem is that this currently produces (-fdump-tree-original):
  #pragma omp teams private(i) private(j)

Which later causes problems as it doesn't add a  (last)private(i) when it
should 

(Search for "if (outer && lastprivate)" in gimplify_omp_for – and look through
the lines below. As "i" is present, omp_check_private() returns true and a
required omp_add_variable is not called. – Leading later to the ICE.)

That's solved by:

--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -5688,3 +5688,3 @@ gfc_resolve_do_iterator (gfc_code *code, gfc_symbol *sym,
bool add_clause)
   gfc_code *omp_code = omp_current_ctx->code->block;
-  for ( ; omp_code->next; omp_code = omp_code->next)
+  for ( ; omp_code; omp_code = omp_code->next)
switch (omp_code->op)

However, that leads to the odd result that:

  !$omp target teams
!$omp distribute parallel do default(shared) &  ! "do"
!$omp collapse (2) private(j) lastprivate (s)
...
!$omp distribute parallel do simd default(shared) & ! "do simd" (!)
!$omp collapse (2) private(j) lastprivate (s)
...

has "#pragma omp teams" [w/o private(i) private(j)]

While removing the "simd" from the code above leads to no "private(i)
private(j)", which does not make sense.

The code (openmp.c's gfc_do_resolve_do_iterator) is supposed to do:
  /* !$omp do and !$omp parallel do iteration variable is predetermined
 private just in the !$omp do resp. !$omp parallel do construct,
 with no implications for the outer parallel constructs.  */

But here it adds it to 'teams', which looks wrong/inconsistent.

[Bug testsuite/95110] New: new test case in r11-345 error: gcc.dg/tree-ssa/pr94969.c: dump file does not exist

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95110
   Summary: new test case in r11-345 error:
gcc.dg/tree-ssa/pr94969.c: dump file does not exist
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:f6e1a4cd83190746b6544917f7526fa480ca5f18, r11-345

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/tree-ssa/pr94969.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3
-fdump-tree-ldist-details -lm -o ./pr94969.exe
Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled23126.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -S -o
exceptions_enabled23126.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled23126.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -S -o
exceptions_enabled23126.s
exceptions_enabled23126.c: In function 'foo':
exceptions_enabled23126.c:4:7: error: 'throw' undeclared (first use in this
function)
exceptions_enabled23126.c:4:7: note: each undeclared identifier is reported
only once for each function it appears in
exceptions_enabled23126.c:4:12: error: expected ';' before numeric constant
compiler exited with status 1
PASS: gcc.dg/tree-ssa/pr94969.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-test2/gcc::/home/seurer/gcc/git/build/gcc-test2/gcc:/home/seurer/gcc/git/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./isl/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/tree-ssa/pr94969.c execution test
gcc.dg/tree-ssa/pr94969.c: dump file does not exist
UNRESOLVED: gcc.dg/tree-ssa/pr94969.c scan-tree-dump-not Loop 1 distributed:
split to 3 loops "ldist"

[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Confirmed – see PR 94690 comment 10.

[Bug testsuite/95110] new test case in r11-345 error: gcc.dg/tree-ssa/pr94969.c: dump file does not exist

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:287552950d56be47adb6b6bf2eae2d612233eaec

commit r11-361-g287552950d56be47adb6b6bf2eae2d612233eaec
Author: Jakub Jelinek 
Date:   Wed May 13 19:16:06 2020 +0200

testsuite: Fix up tree-ssa/pr94969.c testcase [PR95110]

2020-05-13  Jakub Jelinek  

PR testsuite/95110
* gcc.dg/tree-ssa/pr94969.c: Swap scan-tree-dump-not arguments.

[Bug go/95061] shared libgo library not found when running the testsuite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:702adbb2fff0cc043f9c4e1af890421cb238cd18

commit r11-362-g702adbb2fff0cc043f9c4e1af890421cb238cd18
Author: Ian Lance Taylor 
Date:   Wed May 13 10:18:45 2020 -0700

libbacktrace: treat EACCESS like ENOENT

libbacktrace/
PR go/95061
* posix.c (backtrace_open): Treat EACCESS like ENOENT.

[Bug c++/90320] [8/9 Regression] Explicit constructor called implicitly

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Actually, maybe not.  But it's fixed in GCC 10.  I can backport if anyone
thinks it's important.

[Bug c++/95111] New: coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

Bug ID: 95111
   Summary: coroutines use-after-free with lambdas
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

coroutines copy their input to the coroutine frame, so a coroutine like

future f(T x) {
co_await something();
co_return x;
}


will copy x back from the coroutine frame. However, lambdas are passed by
pointer, so something like


[x] () -> future {
co_await something();
co_return x;
}

will fail, it is translated as something like


struct lambda {
T x;
}

future lambda_operator_parens(const lambda* l) {
co_await something();
co_return l->x;
}

Since l is captured by value, *l is dangling and is leaked.


I think the following translation would be more useful:


future lambda_operator_parens_rref(const lambda l) {
co_await something();
co_return l.x;
}

l would be copied by value and would survive copying/moving into the coroutine
frame.

I don't know if the current behavior is mandated by the standard, but if it is,
it seems a serious defect.

[Bug target/95112] New: i386 procedures have prolog endbr32

[akobets at mail dot ru]

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

Bug ID: 95112
   Summary: i386 procedures have prolog endbr32
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akobets at mail dot ru
  Target Milestone: ---

gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu1)

Test file:
===
void test()
{
}
===

Buld:
i686-linux-gnu-gcc -c -fno-PIC -mno-mmx -mno-sse -O2 -fomit-frame-pointer
-ffreestanding -fno-stack-protector --no-exceptions test.c

Result:
i686-linux-gnu-objdump -d test.o

test.o: file format elf32-i386


disassembling section .text:

 :
   0:   f3 0f 1e fb endbr32 
   4:   c3  ret
==
Please help me find way to build clear code.
__attribute__((naked)) do not resolve problem.

[Bug c/95108] [9/10/11 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |9.4
 Status|UNCONFIRMED |NEW
Summary|[10/11 Regression] ICE in   |[9/10/11 Regression] ICE in
   |tree_fits_uhwi_p, at|tree_fits_uhwi_p, at
   |tree.c:7292 |tree.c:7292

--- Comment #1 from Jakub Jelinek  ---
Started with r9-6508-g33813f1d703c95d4fc87d16a17f6c834135ab209

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

[asolokha at gmx dot com]

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

Bug ID: 95113
   Summary: [10/11 Regression] Wrong code w/ -O2 -fexceptions
-fnon-call-exceptions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

The following program compiled w/ gcc-11.0.0-alpha20200510 snapshot
(g:13a46321516e2efd3bbb1f1899c539c6724240a9) w/ -O2 -fexceptions
-fnon-call-exceptions:

int p4, cd;

static long int
sg (long int kl, int mp)
{
  if (mp == 0)
return 0;

  if (kl == -1 && mp == -1)
return 0;

  return kl / mp;
}

static int
eo (int *yg)
{
  int du;

  du = sg (p4, 1) + *yg;
  (void) du;

  return cd;
}

int
main (void)
{
  int um = 0;

  cd = sg (1, 1);
  eo (&um);

  return 0;
}

% x86_64-unknown-linux-gnu-gcc-11.0.0 -O2 -fexceptions -Wuninitialized -o good
li6hfrrz.c
% ./good
% echo $?
0
% objdump --section=.text --disassemble=main good | tail -n6

04e0 :
 4e0:   c7 05 32 1b 00 00 01movl   $0x1,0x1b32(%rip)# 201c 
 4e7:   00 00 00
 4ea:   31 c0   xor%eax,%eax
 4ec:   c3  retq

% x86_64-unknown-linux-gnu-gcc-11.0.0 -O2 -fexceptions -fnon-call-exceptions
-Wuninitialized -o bad li6hfrrz.c
% ./bad
zsh: segmentation fault (core dumped)  ./bad
% objdump --section=.text --disassemble=main bad | tail -n6
04e0 :
 4e0:   c7 05 32 1b 00 00 01movl   $0x1,0x1b32(%rip)# 201c 
 4e7:   00 00 00
 4ea:   8b 04 25 00 00 00 00mov0x0,%eax
 4f1:   31 c0   xor%eax,%eax
 4f3:   c3  retq

https://gcc.godbolt.org/z/V4a-K7

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[jared.martinsen at fiserv dot com]

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

Jared  changed:

   What|Removed |Added

 CC||jared.martinsen at fiserv dot 
com

--- Comment #211 from Jared  ---
Are these errors the same as described above?

It give the following 2 errors:
ld: The value 0xfe38a260 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in
section index 222 of file
/library/home/build/tapecut5/code/lib/libsubo.a[file1.o]
ld: The value 0xfe587970 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x22 in
section index 2125 of file
/library/home/build/tapecut5/code/lib/libsubo.a[file2.o] 


Using gcc version 4.2.3.  On 64 bit HP-UX
Here is the raw command line.
/usr/local/bin/g++ /library/home/build/tapecut5/code/obj/ocu00.o -z
-L/usr/local/lib/hpux32 -lxerces-c -lxerces-depdom -
L/opt/eloquence/8.2/lib/hpux32 -leqdb -limage3k -lfwutil
-L/library/home/build/tapecut5/code/lib -lsubo -lsubr -L/librar
y/home/build/tapecut5/code/spx/lib -lspx -lm  -lcrypto -lssl -o
/library/home/build/tapecut5/code/bin/spectrum 

Is there a fix for this?  Newer compiler or an option?

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.2
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r10-3542-g0b92cf305dcf34387a8e2564e55ca8948df3b47a

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
int a, b;

static inline long int
foo (long int x, int y)
{
  if (y == 0)
return 0;

  if (x == -1 && y == -1)
return 0;

  return x / y;
}

static inline int
bar (int *p)
{
  int c = foo (a, 1) + *p;
  return b;
}

int
main ()
{
  int d = 0;
  b = foo (1, 1);
  bar (&d);
  return 0;
}

Guess dup of the other PR where the IPA opts assume DCE which doesn't really
happen (the *p load result is never used).

[Bug libfortran/95101] Optimize libgfortran library handling of arrays

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-05-13

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

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
(In reply to Jakub Jelinek from comment #2)
> Guess dup of the other PR where the IPA opts assume DCE which doesn't really
> happen (the *p load result is never used).

Indeed, -fno-ipa-sra fixes it. So, a duplicate of PR93385?

[Bug go/95061] shared libgo library not found when running the testsuite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-364-g0d5d880994660e231f82b7cb1dcfab744158f7e0
Author: Ian Lance Taylor 
Date:   Wed May 13 11:12:01 2020 -0700

libgo: build syscall test with -static

This avoids problems finding libgo.so when running the test as root,
which invokes the test as a child process in various limited environments.

Fixes PR go/95061

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/233897

[Bug go/95061] shared libgo library not found when running the testsuite

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Should be fixed now.

Note that this can only happen when running the tests as root.

[Bug middle-end/95108] [9/10/11 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/94024] Error message has misleading source location for constructor member initialisation.

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #212 from dave.anglin at bell dot net ---
On 2020-05-13 2:03 p.m., jared.martinsen at fiserv dot com wrote:
> --- Comment #211 from Jared  ---
> Are these errors the same as described above?
>
> It give the following 2 errors:
> ld: The value 0xfe38a260 does not fit when applying the relocation
> PCREL21B for symbol ".text" at offset 0x22 in
> section index 222 of file
> /library/home/build/tapecut5/code/lib/libsubo.a[file1.o]
> ld: The value 0xfe587970 does not fit when applying the relocation
> PCREL21B for symbol ".text" at offset 0x22 in
> section index 2125 of file
> /library/home/build/tapecut5/code/lib/libsubo.a[file2.o]
Yes.  Most likely these are references to weak symbols.  Compiling with -Os
might help.
>  
>
>
> Using gcc version 4.2.3.  On 64 bit HP-UX
> Here is the raw command line.
> /usr/local/bin/g++ /library/home/build/tapecut5/code/obj/ocu00.o -z
> -L/usr/local/lib/hpux32 -lxerces-c -lxerces-depdom -
> L/opt/eloquence/8.2/lib/hpux32 -leqdb -limage3k -lfwutil
> -L/library/home/build/tapecut5/code/lib -lsubo -lsubr -L/librar
> y/home/build/tapecut5/code/spx/lib -lspx -lm  -lcrypto -lssl -o
> /library/home/build/tapecut5/code/bin/spectrum 
>
> Is there a fix for this?  Newer compiler or an option?
>
No.  They block building latter versions of gcc that require g++.

[Bug middle-end/95114] New: [9/10/11 Regression] ICE in obj_type_ref_class for structural-equality types

[rsandifo at gcc dot gnu.org]

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

Bug ID: 95114
   Summary: [9/10/11 Regression] ICE in obj_type_ref_class for
structural-equality types
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

Since r9-5035-g4611c03d2b0edefc8d8e17872ef143428f56380b,
the following testcase has ICEd for aarch64, compiled at -O0:

---
template struct foo { virtual void f() = 0; };
extern foo<__Int8x8_t> &x;
void f() { x.f(); }
---

The exact ICE has changed over time, but the current form is:

---
during GIMPLE pass: *rebuild_cgraph_edges
foo.c: In function ‘void f()’:
foo.c:3:19: internal compiler error: Segmentation fault
3 | void f() { x.f(); }
  |   ^
0x16cfec1 crash_signal
src/gcc/gcc/toplev.c:328
0x129a4ca obj_type_ref_class(tree_node const*)
src/gcc/gcc/ipa-devirt.c:1915
0x1afe3d7 virtual_method_call_p(tree_node const*)
src/gcc/gcc/tree.c:12867
0xf1102b cgraph_node::create_indirect_edge(gcall*, int, profile_count, bool)
src/gcc/gcc/cgraph.c:990
0xf2113d cgraph_edge::rebuild_edges()
src/gcc/gcc/cgraphbuild.c:421
0xf214aa execute
src/gcc/gcc/cgraphbuild.c:490
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
---

This is because for structural-equality types we call
get_odr_type:

---
  if (!in_lto_p && !TYPE_STRUCTURAL_EQUALITY_P (ret))
ret = TYPE_CANONICAL (ret);
  else
ret = get_odr_type (ret)->type;
---

and the hash table is empty at this point.  (We did previously
have a hash entry for the type, but that was freed during
pass_ipa_free_lang_data.)

The test does pass at -O2, but fails with
-fdump-tree-all-details -O2:

---
foo.c: In function ‘void f()’:
foo.c:3:19: internal compiler error: Segmentation fault
3 | void f() { x.f(); }
  |   ^
0x16cfec1 crash_signal
src/gcc/gcc/toplev.c:328
0x12a20f8 hash_table::find_slot_with_hash(tree_node* const&, unsigned int,
insert_option)
src/gcc/gcc/hash-table.h:967
0x129a622 get_odr_type(tree_node*, bool)
src/gcc/gcc/ipa-devirt.c:1939
0x129a4c9 obj_type_ref_class(tree_node const*)
src/gcc/gcc/ipa-devirt.c:1915
0x1afe3d7 virtual_method_call_p(tree_node const*)
src/gcc/gcc/tree.c:12867
0x180f086 dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
src/gcc/gcc/tree-pretty-print.c:3125
...
---

I guess the fact that this routine is called by the dump routines
(which shouldn't affect codegen) suggests that we should cope
with null returns from get_odr_type, rather than passing "true"
as the insert parameter.  Is that right?

[Bug middle-end/95114] [9/10/11 Regression] ICE in obj_type_ref_class for structural-equality types

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |9.4
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
   Last reconfirmed||2020-05-13
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Testing a patch that tests for null returns.

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #1 from Iain Sandoe  ---
There are some gotchas with coroutines and references (both regular and
rvalue).

* there could still be a bug here, so I want to double-check.

Please could you expand your snippets of code into a small test-case that would
would expect to work?

(FWIW, in my original impl. I tried to be more defensive about lambda captures
- but that wasn't correct in the presence of a mutable lambda - and didn't
agree with other implementations - or the collective understanding of the
intent of the standard - so I backed that out).

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #2 from Avi Kivity  ---
Created attachment 48524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48524&action=edit
lame testcase

Lame testcase that shows that the lambda is passed as a pointer rather than by
value, leading to a leak if the coroutine is suspended.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #3 from Avi Kivity  ---
The test case I uploaded only shows the failure, it won't work if gcc worked as
I expect it. I'll try to get a better testcase, unfortunately a small coroutine
testcase is still some work.

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #3)
> The test case I uploaded only shows the failure, it won't work if gcc worked
> as I expect it. I'll try to get a better testcase, unfortunately a small
> coroutine testcase is still some work.

yeah, I have some boiler-plate code in headers in the GCC test-suite that can
help.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #5 from Avi Kivity  ---
This snippet from cppreference:

  If the coroutine is a non-static member function, such as task 
  my_class::method1(int x) const;, its Promise type is 
  std::coroutine_traits, const my_class&, int>::promise_type

implies that both gcc and my interpretation are wrong. gcc passes a pointer for
the lambda, and I'd like the lambda to be passed by value. The difference
between gcc and cppreference is trivial, and both of them make coroutine
lambdas unusable if they contain state and if the lambda is asynchronous.

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #5)
> This snippet from cppreference:
> 
>   If the coroutine is a non-static member function, such as task 
>   my_class::method1(int x) const;, its Promise type is 
>   std::coroutine_traits, const my_class&, int>::promise_type
> 
> implies that both gcc and my interpretation are wrong. gcc passes a pointer
> for the lambda, and I'd like the lambda to be passed by value. The
> difference between gcc and cppreference is trivial, and both of them make
> coroutine lambdas unusable if they contain state and if the lambda is
> asynchronous.

( assuming that this is the problem, I haven't yet had a chance to check *
could still be a bug ;) ).

I have a pending change to pass a reference to the lambda object to the traits,
promise preview and allocator lookups.

This was a source of considerable discussion amongst the implementors (GCC,
clang, MSVC) about how the std should be interpreted.  The change I mention
will make the lambda capture object pointer behave in the same manner as 'this'
(which was the intended behaviour as determined by the long discussion).  MSVC
implements this now, and clang will be changing to match it also.

That won't solve any lifetime issue with the capture object - you will still
need to ensure that it exists for the duration of the coroutine * as you would
for a class instance with a method coroutine *.

We (at least several of us) agree that this is a source of easy programming
errors - and I expect there to be some revisiting in c++23.  That's a
considerable challenge in the face of a mutable lambda - maybe (thinking aloud)
needs something like Apple blocks, but with an automatic promotion of the
closure to a heap object if it escapes the creating scope.

[Bug target/95115] New: [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[aurelien at aurel32 dot net]

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

Bug ID: 95115
   Summary: [10 Regression] RISC-V 64: inf/inf division optimized
out, invalid operation not raised
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: riscv64-unknown-linux-gnu
Target: riscv64-unknown-linux-gnu
 Build: riscv64-unknown-linux-gnu

Created attachment 48525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48525&action=edit
Testcase

On 64-bit RISC-V, the acos/asin tests from the glibc testsuite fails when it is
built with GCC 10, as the invalid operation flag is not raised for invalid
input values. The glibc code uses the following code to generate a NaN and
raise an invalid input [1]:

  else {
u.i[HIGH_HALF]=0x7ff0;
v.i[HIGH_HALF]=0x7ff0;
u.i[LOW_HALF]=0;
v.i[LOW_HALF]=0;
return u.x/v.x;
  }

With GCC 9, this results in the following code:
li  a1,2047
sllia1,a1,52
fmv.d.x fa5,a1
li  a0,16
fdiv.d  fs0,fa5,fa5

With GCC 10, the division is optimized out and the result is directly loaded as
a constant, causing the invalid operation not to be raised.

I have attached a small testcase to reproduce the issue.

[Bug c++/95116] New: [C++ 20] Accepts invalid code with decltype dependent type

[ojman101 at protonmail dot com]

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

Bug ID: 95116
   Summary: [C++ 20] Accepts invalid code with decltype dependent
type
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ojman101 at protonmail dot com
  Target Milestone: ---

The code below is invalid. The keyword "typename" needs to be inserted before
the decltype expression as "bar" is a dependent type (dependent on template
type T).

template 
struct Bar {
using bar_type = int;
};

template 
struct Foo {
Bar bar;

using foo_type = decltype(bar)::bar_type;
};

int main() {
// Instantiate Foo template
Foo foo;
}

The code successfully compiles with GCC 9.3.0 when running the command "g++
-std=c++2a main.cpp". Note that the "-std=c++2a" must be passed. When passing
"-std=c++17", GCC successfully detects the error and prints:

main.cpp:10:22: error: need 'typename' before 'decltype
(((Foo*)(void)0)->Foo::bar)::bar_type' because 'decltype
(((Foo*)(void)0)->Foo::bar)' is a dependent scope
   10 | using foo_type = decltype(bar)::bar_type;
  |  ^~~~
  |  typename

Running clang 10 with the command "clang++ -std=c++2a main.cpp" also
successfully detects the error and prints:

main.cpp:10:22: error: missing 'typename' prior to dependent type name
'decltype(bar)::bar_type'
using foo_type = decltype(bar)::bar_type;
 ^~~
 typename 
1 error generated.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #8 from Avi Kivity  ---
Created attachment 48526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48526&action=edit
less lame testcase

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #7 from Avi Kivity  ---
I have a simple reproducer. A lambda fails while a fake lambda using structs
passes. I don't think gcc is at fault, but the standard is problematic here
IMO.

[Bug c++/95116] [C++ 20] Accepts invalid code with decltype dependent type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Not a bug; this is valid C++20 code since we implement P0634R3, Down with
typename!.

[Bug c++/95111] coroutines use-after-free with lambdas

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

--- Comment #9 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #8)
> Created attachment 48526 [details]
> less lame testcase

thanks, it's in my queue to look at.

FWIW see the note in bullet 13 here:
http://eel.is/c++draft/dcl.fct.def.coroutine#13

consider also:
gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C

where, if the closure object were copied into the coroutine frame, the
operation would be incorrect.

[Bug lto/64636] LTO PGO bootstrap fails on linux-sparc64 in stream_out_histogram_value

[ostash at ostash dot kiev.ua]

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

Viktor Ostashevskyi  changed:

   What|Removed |Added

 CC||ostash at ostash dot kiev.ua

--- Comment #10 from Viktor Ostashevskyi  ---
Hello,

During GCC 10.1.0 bootstrap in LTO+PGO mode, configured as:

Configured with: ../gcc-10.1.0/configure --disable-multiarch
--disable-libquadmath --disable-libquadmath-support --disable-libssp
--disable-libstdcxx-pch --disable-multilib --disable-nls
--enable-checking=release --enable-__cxa_atexit --enable-languages=c,c++
--enable-libstdcxx-debug --enable-lto --enable-plugin --enable-threads=posix
--enable-tls --with-build-config=bootstrap-lto
--with-default-libstdcxx-abi=gcc4-compatible --with-linker-hash-style=gnu
--with-system-zlib --with-zstd=no --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu

I got following ICE:

/ostash/buildtc10/gcc-10.1.0-build/./prev-gcc/xgcc
-B/ostash/buildtc10/gcc-10.1.0-build/./prev-gcc/
-B/ostash/tc10/x86_64-pc-linux-gnu/bin/ -B/ostash/tc10/x86_64-pc-linux-gnu/bin/
-B/ostash/tc10/x86_64-pc-linux-gnu/lib/ -isystem
/ostash/tc10/x86_64-pc-linux-gnu/include -isystem
/ostash/tc10/x86_64-pc-linux-gnu/sys-include-c -DHAVE_CONFIG_H
-fprofile-use -flto=jobserver -frandom-seed=1  -I.
-I../../gcc-10.1.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE -fcf-protection
../../gcc-10.1.0/libiberty/hashtab.c -o hashtab.o
during IPA pass: fnsummary
../../gcc-10.1.0/libiberty/hashtab.c:997:1: internal compiler error: in
stream_out_histogram_value, at value-prof.c:338
  997 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [hashtab.o] Error 1
make[3]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build/libiberty'
make[2]: *** [all-stagefeedback-libiberty] Error 2
make[2]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build'
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory `/ostash/buildtc10/gcc-10.1.0-build'
make: *** [profiledbootstrap] Error 2


I can provide gcda files if needed.

[Bug c++/95111] coroutines use-after-free with lambdas

[a...@cloudius-systems.com]

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

--- Comment #10 from Avi Kivity  ---
Well, the standard is useless here.

In

[foo] () -> lazy { co_return foo; } ()

a temporary is clearly passed to the lambda body, yet the standard mandates
that we capture it by reference. As a result, a use-after-free is guaranteed.