[Bug tree-optimization/95570] New: ICE: Segmentation fault in vect_loop_versioning

[felix.yang at huawei dot com]

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

Bug ID: 95570
   Summary: ICE: Segmentation fault in vect_loop_versioning
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.yang at huawei dot com
  Target Milestone: ---
Target: aarch64

foo.c:
int x[8][32];

void
foo (int start)
{
  for (int i = start; i < start + 16; i++)
x[start][i] = i;
}

$ gcc -S -O2 -ftree-loop-vectorize -march=armv8.2-a+sve -msve-vector-bits=256
-fno-vect-cost-model -fwrapv -mstrict-align foo.c
during GIMPLE pass: vect
foo.c: In function ‘foo’:
foo.c:4:1: internal compiler error: Segmentation fault
4 | foo (int start)
  | ^~~
0x12bb79b crash_signal
../../gcc-git/gcc/toplev.c:328
0x94cc4c contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-git/gcc/tree.h:3665
0x9893db wi::extended_tree<576>::extended_tree(tree_node const*)
../../gcc-git/gcc/tree.h:5922
0x987e9b generic_wide_int >::generic_wide_int(tree_node const* const&)
../../gcc-git/gcc/wide-int.h:782
0x98796f wi::to_widest(tree_node const*)
../../gcc-git/gcc/tree.h:5849
0xa84e13 tree_int_cst_compare(tree_node const*, tree_node const*)
../../gcc-git/gcc/tree.h:6121
0x16911bb vect_create_cond_for_align_checks
../../gcc-git/gcc/tree-vect-loop-manip.c:3055
0x1691a1f vect_loop_versioning(_loop_vec_info*, gimple*)
../../gcc-git/gcc/tree-vect-loop-manip.c:3263
0x167ffbb vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc-git/gcc/tree-vect-loop.c:8691
0x16ac56b try_vectorize_loop_1
../../gcc-git/gcc/tree-vectorizer.c:989
0x16ac7e7 try_vectorize_loop
../../gcc-git/gcc/tree-vectorizer.c:1046
0x16ac997 vectorize_loops()
../../gcc-git/gcc/tree-vectorizer.c:1125
0x1507e2b execute
../../gcc-git/gcc/tree-ssa-loop.c:414

Here, we are doing loop versionging for alignment.
The only dr here is a gather-statter operation: x[start][i].
Scalar evolution analysis for this dr failed, so DR_STEP is NULL_TREE, which
leads to the segfault.
But scatter-gather operation should be filtered out in
vect_enhance_data_refs_alignment.
Like:
@@ -2206,6 +2228,12 @@ vect_enhance_data_refs_alignment (loop_vec_info
loop_vinfo)
  && DR_GROUP_FIRST_ELEMENT (stmt_info) != stmt_info))
continue;

+ /* For scatter-gather or invariant accesses there is nothing
+to enhance.  */
+ if (STMT_VINFO_GATHER_SCATTER_P (stmt_info)
+   || integer_zerop (DR_STEP (dr)))
+   continue;
+
  if (STMT_VINFO_STRIDED_P (stmt_info))
{
  /* Strided loads perform only component accesses, alignment is

I also witnessed similar issues in vect_verify_datarefs_alignment,
vect_get_peeling_costs_all_drs and vect_peeling_supportable. Since the code is
similar, maybe we should propose a new funtion for that.  Suggestions?

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:635408da1eb1d441ef4d59fe00a038c920e51085

commit r11-1062-g635408da1eb1d441ef4d59fe00a038c920e51085
Author: Christophe Lyon 
Date:   Mon Jun 8 08:17:20 2020 +

[arm] Fix vfp_operand_register for VFP HI regs

While looking at PR target/94743 I noticed an ICE when I tried to save
all the FP registers: this was because all HI registers wouldn't match
vfp_register_operand.

gcc/ChangeLog:

* config/arm/predicates.md (vfp_register_operand): Use VFP_HI_REGS
instead of VFP_REGS.

[Bug lto/95572] New: lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:370

[sujian.liu at huawei dot com]

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

Bug ID: 95572
   Summary: lto1: internal compiler error: in lto_input_tree_ref,
at lto-streamer-in.c:370
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sujian.liu at huawei dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48700=edit
Test case

The version used by GCC is 7.3.0.
Only under the O0 option, ICE will appear, and O1+ will not report an error.

When I use the riscv compiler,the following ICE will be reported: 

riscv32-unknown-elf-gcc vla-16.c -lm -o ./vla-16.exe -flto

In function 'f5':
lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:370
0x55b22e6f8b48 ???
../sysdeps/x86_64/start.S:108
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: riscv32-unknown-elf-gcc returned 1 exit status
compilation terminated.
/home/lsj/0608/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

=

When I use the x86_64-linux-gnu compiler,the following ICE will be reported:

gcc vla-16.c -lm -o ./vla-16.exe -flto

In function ‘f3’:
lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:370
0x8431e8 lto_input_tree_ref(lto_input_block*, data_in*, function*, LTO_tags)
../../gcc/lto-streamer-in.c:370
0x84337d lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc/lto-streamer-in.c:1446
0x84363b lto_input_tree(lto_input_block*, data_in*)
../../gcc/lto-streamer-in.c:1492
0xaf96c5 lto_input_ts_exp_tree_pointers
../../gcc/tree-streamer-in.c:895
0xaf96c5 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
../../gcc/tree-streamer-in.c:1081
0x842caf lto_read_tree_1
../../gcc/lto-streamer-in.c:1333
0x8433c7 lto_read_tree
../../gcc/lto-streamer-in.c:1363
0x8433c7 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc/lto-streamer-in.c:1475
0x8435b2 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*)
../../gcc/lto-streamer-in.c:1387
0x843614 lto_input_tree(lto_input_block*, data_in*)
../../gcc/lto-streamer-in.c:1490
0x8443a9 input_struct_function_base
../../gcc/lto-streamer-in.c:987
0x8443a9 input_function
../../gcc/lto-streamer-in.c:1061
0x8443a9 lto_read_body_or_constructor
../../gcc/lto-streamer-in.c:1259
0x6213f4 cgraph_node::get_untransformed_body()
../../gcc/cgraph.c:3620
0x62b47e cgraph_node::expand()
../../gcc/cgraphunit.c:2012
0x62c0c7 output_in_order
../../gcc/cgraphunit.c:2285
0x62c4f3 symbol_table::compile()
../../gcc/cgraphunit.c:2530
0x5b8ac4 lto_main()
../../gcc/lto/lto.c:3334
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Attachment provides the test case.

[Bug target/95571] xtensa stack unwinding doesn't work well with asynchronous register spilling

[jcmvbkbc at gcc dot gnu.org]

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #48699|0   |1
is obsolete||

--- Comment #2 from jcmvbkbc at gcc dot gnu.org ---
Created attachment 48701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48701=edit
minimal reproducer

Correct reproducer version.

[Bug d/95573] New: [11 regression] gdc.test/runnable/lazy.d UNRESOLVED

[ro at gcc dot gnu.org]

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

Bug ID: 95573
   Summary: [11 regression] gdc.test/runnable/lazy.d UNRESOLVED
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11

Between 20200605 (6ea6c4978111d146db8d33c80d9da93d7bd2bc8d) and 20200607
(c3a2ba10b272fd9581560604284da2a6283bcde0), two gdc.test testcases started to
come up UNRESOLVE:

+UNRESOLVED: runnable/lazy.d   compilation failed to produce executable
+UNRESOLVED: runnable/lazy.d -O2   compilation failed to produce executable
+UNRESOLVED: runnable/lazy.d -O2 -frelease   compilation failed to produce
executable
+UNRESOLVED: runnable/lazy.d -O2 -frelease -g   compilation failed to produce
executable
+UNRESOLVED: runnable/lazy.d -O2 -frelease -g -shared-libphobos   compilation
failed to produce executable
+UNRESOLVED: runnable/lazy.d -O2 -frelease -shared-libphobos   compilation
failed to produce executable
+UNRESOLVED: runnable/lazy.d -O2 -g   compilation failed to produce executable
+UNRESOLVED: runnable/lazy.d -O2 -g -shared-libphobos   compilation failed to
produce executable
+UNRESOLVED: runnable/lazy.d -O2 -shared-libphobos   compilation failed to
produce executable
+UNRESOLVED: runnable/lazy.d -frelease   compilation failed to produce
executable
+UNRESOLVED: runnable/lazy.d -frelease -g   compilation failed to produce
executable
+UNRESOLVED: runnable/lazy.d -frelease -g -shared-libphobos   compilation
failed to produce executable
+UNRESOLVED: runnable/lazy.d -frelease -shared-libphobos   compilation failed
to produce executable
+UNRESOLVED: runnable/lazy.d -g   compilation failed to produce executable
+UNRESOLVED: runnable/lazy.d -g -shared-libphobos   compilation failed to
produce executable
+UNRESOLVED: runnable/lazy.d -shared-libphobos   compilation failed to produce
executable

runnable/lazy.d:70:13: error: function lazy.switcher (bool delegate()[]
cases...) is not callable using argument types (bool, bool, bool, bool)
runnable/lazy.d:205:9: error: function lazy.foo7 (long delegate()[] dg...) is
not callable using argument types (int, int)

+UNRESOLVED: runnable/nested.d   compilation failed to produce executable
+UNRESOLVED: runnable/nested.d -O2   compilation failed to produce executable
+UNRESOLVED: runnable/nested.d -O2 -frelease   compilation failed to produce
executable
+UNRESOLVED: runnable/nested.d -O2 -frelease -g   compilation failed to produce
executable
+UNRESOLVED: runnable/nested.d -O2 -frelease -g -shared-libphobos   compilation
failed to produce executable
+UNRESOLVED: runnable/nested.d -O2 -frelease -shared-libphobos   compilation
failed to produce executable
+UNRESOLVED: runnable/nested.d -O2 -g   compilation failed to produce
executable
+UNRESOLVED: runnable/nested.d -O2 -g -shared-libphobos   compilation failed to
produce executable
+UNRESOLVED: runnable/nested.d -O2 -shared-libphobos   compilation failed to
produce executable
+UNRESOLVED: runnable/nested.d -frelease   compilation failed to produce
executa
ble
+UNRESOLVED: runnable/nested.d -frelease -g   compilation failed to produce
executable
+UNRESOLVED: runnable/nested.d -frelease -g -shared-libphobos   compilation
failed to produce executable
+UNRESOLVED: runnable/nested.d -frelease -shared-libphobos   compilation failed
to produce executable
+UNRESOLVED: runnable/nested.d -g   compilation failed to produce executable
+UNRESOLVED: runnable/nested.d -g -shared-libphobos   compilation failed to
produce executable
+UNRESOLVED: runnable/nested.d -shared-libphobos   compilation failed to
produce executable

runnable/nested.d:1159:22: error: function nested.Foo44 (Comb delegate()[]
c...) is not callable using argument types (Comb)
null

I'm seeing this on 32 and 64-bit Solaris/SPARC and x86, but suspect it's
universal.

[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:296d644b9f526e44fbe574426f24799c1d545fd3

commit r11-1064-g296d644b9f526e44fbe574426f24799c1d545fd3
Author: Jakub Jelinek 
Date:   Mon Jun 8 10:30:48 2020 +0200

testsuite: Fix up pr95548.C testcase.

2020-06-08  Jakub Jelinek  

PR lto/95548
* g++.dg/torture/pr95548.C: Change from dg-do compile to dg-do
link,
add return type for main, for __SIZEOF_INT128__ test with
__uint128_t
enumerator constants and add a test with unsigned long long
enumerators for all targets.

[Bug target/95571] New: xtensa stack unwinding doesn't work well with asynchronous register spilling

[jcmvbkbc at gcc dot gnu.org]

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

Bug ID: 95571
   Summary: xtensa stack unwinding doesn't work well with
asynchronous register spilling
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

Xtensa architecture with variable register windows store registers of the
spilled register windows in two separate locations: registers a0-a3 of the
current function caller are stored right below the stack pointer of current
function in the location known as a base save area, and the registers a4-a7 (or
a4-a11) are stored in the top of the caller's stack frame in a location known
as an extra save area, right under the base save area of is own caller. To
spill or restore registers a4-a7/a11 of the function its caller stack pointer
is used to find its extra save area.

Interrupt handlers on bare metal xtensa targets spill registers of all active
register windows in the interrupted code except the current topmost window.

Stack unwinding code for xtensa copies base save area of the context being
installed into the base save area under the _Unwind_RaiseException stack
pointer so that return from _Unwind_RaiseException reload registers of that
context. However when it happens in a function called from
_Unwind_RaiseException an interrupt can spill registers of the
_Unwind_RaiseException to its extra save area. The location of this area is
lost once base save area under the _Unwind_RaiseException stack pointer is
overwritten resulting in bogus values being reloaded into registers a4-a7
usually resulting in a crash.

[Bug d/95573] [11 regression] gdc.test/runnable/lazy.d UNRESOLVED

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/95569] ICE in tmmark：verify_ssa failed

[qianchao9 at huawei dot com]

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

--- Comment #2 from Qian Chao  ---
Bootstrap and tested on aarch64 platform. No new regression witnessed.

[Bug tree-optimization/95569] ICE in tmmark：verify_ssa failed

[qianchao9 at huawei dot com]

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

--- Comment #1 from Qian Chao  ---
Bootstrap and tested on aarch64 platform. No new regression witnessed.

[Bug target/95571] xtensa stack unwinding doesn't work well with asynchronous register spilling

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
Created attachment 48699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48699=edit
minimal reproducer

Reproducer spills active register windows in a substitute memcpy as could be
done by an interrupt handler.

[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
The new testcase FAILs everywhere:

+FAIL: g++.dg/torture/pr95548.C   -O0  (test for excess errors)
+FAIL: g++.dg/torture/pr95548.C   -O1  (test for excess errors)
+FAIL: g++.dg/torture/pr95548.C   -O2  (test for excess errors)
+FAIL: g++.dg/torture/pr95548.C   -O2 -flto  (test for excess errors)
+FAIL: g++.dg/torture/pr95548.C   -O2 -flto -flto-partition=none  (test for
excess errors)
+FAIL: g++.dg/torture/pr95548.C   -O3 -g  (test for excess errors)
+FAIL: g++.dg/torture/pr95548.C   -Os  (test for excess errors)

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/torture/pr95548.C:6:1:
warning: ISO C++ forbids declaration of 'main' with no type [-Wreturn-type]

[Bug c++/95553] Incorrect/misspelled designators not triggering compilation error

[sergey at murzin dot pw]

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

Sergei Murzin  changed:

   What|Removed |Added

 CC||sergey at murzin dot pw

--- Comment #2 from Sergei Murzin  ---
(In reply to Marek Polacek from comment #1)
> We warn with -Wpedantic and error with -pedantic-errors.

That is warning for using designated initializers pre-C++20. With C++20 above
code compiles with -Wpedantic without error or warning.
The problem above though, is that the deisgnated intializer is successfully
constructing a string using non-existent designator.

[Bug c++/95050] coroutine: no "mandatory copy elision" for prvalue await_resume expression.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Sandoe  ---
fixed on master and for 10.2

[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations

[jules at gcc dot gnu.org]

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

--- Comment #7 from jules at gcc dot gnu.org ---
Test case & further discussion in:

https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547424.html

[Bug middle-end/95528] [10 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] internal |[10 Regression] internal
   |compiler error: in  |compiler error: in
   |emit_move_insn, at  |emit_move_insn, at
   |expr.c:3814 |expr.c:3814

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug fortran/92993] [8/9 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8263-ge4f719b4e1f14016dfc777227e42bd1080245248
Author: Mark Eggleston 
Date:   Thu Jun 4 05:53:31 2020 +0100

Fortran  : ICE in maybe_canonicalize_comparison_1 PR92993

This issue has been fixed by PR94090.  Add test case to ensure that
this does not re-occur.

2020-06-08  Mark Eggleston  

gcc/testsuite/

PR fortran/92993
* gfortran.dg/pr92993.f90: New test.

(cherry picked from commit 5dc3986103d8908c802e940dea8f2def3a6989c2)

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

  Attachment #48694|0   |1
is obsolete||

--- Comment #31 from David Malcolm  ---
Created attachment 48704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48704=edit
v4 of the patch

v4 patch, close to being finished (I hope)

Also uploaded to:
 
https://dmalcolm.fedorapeople.org/gcc/2020-06-08/0001-FIXME-WIP-on-extended-asm-support-v4.patch

C API docs:
 
https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/topics/asm.html
C++ API docs:
 
https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/cp/topics/asm.html

[Bug tree-optimization/95580] [11 Regression] ICE in tree_strip_any_location_wrapper at gcc/tree.h:4011 since r11-959-gb825a22890740f34

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||11.0
  Known to work||10.1.0
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
   Last reconfirmed||2020-06-08
 Status|UNCONFIRMED |NEW

[Bug gcov-profile/95494] [11 regression] Several -fprofile-use tests FAIL

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
> > --- Comment #3 from Martin Liška  ---
> > Is there a compile farm machine I can test it on?
> 
> Sure: gcc211 should do the trick.

Thanks.
Unfortunately, I can't build the current master due to switch to C++11:

../../gcc/expr.c: In function ‘rtx_insn* emit_move_insn(rtx, rtx)’:
../../gcc/expr.c:3830:3: warning: ‘auto’ changes meaning in C++11; please
remove it [-Wc++0x-compat]
   auto candidate_subreg_p = [&](rtx subreg) {
   ^
../../gcc/expr.c:3830:8: error: ‘candidate_subreg_p’ does not name a type
   auto candidate_subreg_p = [&](rtx subreg) {
^
../../gcc/expr.c:3838:3: warning: ‘auto’ changes meaning in C++11; please
remove it [-Wc++0x-compat]
   auto candidate_mem_p = [&](machine_mode innermode, rtx mem) {
   ^
../../gcc/expr.c:3838:8: error: ‘candidate_mem_p’ does not name a type
   auto candidate_mem_p = [&](machine_mode innermode, rtx mem) {
^
../../gcc/expr.c:3849:44: error: ‘candidate_subreg_p’ was not declared in this
scope
   if (SUBREG_P (x) && candidate_subreg_p (x))
^
../../gcc/expr.c:3852:44: error: ‘candidate_subreg_p’ was not declared in this
scope
   if (SUBREG_P (y) && candidate_subreg_p (y))
^
../../gcc/expr.c:3866:46: error: ‘candidate_mem_p’ was not declared in this
scope
 && candidate_mem_p (GET_MODE (x_inner), y))

Is there a compiler in /opt that can build current GCC?

> 
> > Btw. can you please make a brief analysis why it fails (valgrind)?
> 
> Unfortunately not: the Solaris/x86 valgrind port has been abandoned and
> doesn't do anything useful, and there never was a sparc port.

[Bug gcov-profile/93623] No need to dump gcdas when forking

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
(In reply to calixte from comment #11)
> Why did you remove __gcov_flush ?

It is not a supported __gcov_* library call:
https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html

You should rather call __gcov_dump and __gcov_reset functions.

> FYI, we use it in Firefox to dump counters on SIGUSR1:
> https://searchfox.org/mozilla-central/source/tools/code-coverage/
> CodeCoverageHandler.cpp#49

[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Fixed by r11-1067.

[Bug tree-optimization/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-08
 Status|UNCONFIRMED |NEW

[Bug testsuite/95577] New: Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 95577
   Summary: Tcl error with testsuite/gcc.misc-tests/outputs.exp on
darwin
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin*
Target: x86_64-apple-darwin*
 Build: x86_64-apple-darwin*

Running /opt/gcc/_clean/gcc/testsuite/gcc.misc-tests/outputs.exp ...
ERROR: tcl error sourcing
/opt/gcc/_clean/gcc/testsuite/gcc.misc-tests/outputs.exp.
ERROR: error deleting "a.out.dSYM": directory not empty
while executing
"file delete $f"
(procedure "outest" line 76)
invoked from within
"outest "$b exe auxdump unnamed1" $sing "-g -fdump-rtl-final -fstack-usage
$gsplit_dwarf $oaout" {} {{a--0.c.???r.final a--0.su a--0.dwo $aout}}"
(file "/opt/gcc/_clean/gcc/testsuite/gcc.misc-tests/outputs.exp" line 380)
invoked from within
"source /opt/gcc/_clean/gcc/testsuite/gcc.misc-tests/outputs.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /opt/gcc/_clean/gcc/testsuite/gcc.misc-tests/outputs.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""

[Bug lto/95572] lto1: internal compiler error: in lto_input_tree_ref, at lto-streamer-in.c:370

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-06-08
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Hello.
GCC 7.x is out of support, can you please test a newer release, ideally GCC
10.1 release?

[Bug c++/95579] internal compiler error: in sign_mask, at wide-int.h:855

[nmmm at nmmm dot nu]

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

--- Comment #1 from Nikolay Mihaylov  ---
Code compiles on 9.x

[Bug jit/87291] Add support for inline asm to libgccjit

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #30 from David Malcolm  ---
(In reply to Antoni from comment #29)
> asm(
> "add:\n"
> "movq %rdi, %rax\n"
> "add %rsi, %rax\n"
> "ret\n");

Thanks; I've updated the testcases and examples to use this.  I needed to
slightly tweak this to allow the dynamic linker to find it, to allow
gcc_jit_result_get_code to work.

[Bug jit/87291] Add support for inline asm to libgccjit

[bouanto at zoho dot com]

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

--- Comment #32 from Antoni  ---
Thanks; that looks really nice.

The function gcc_jit_context_add_top_level_asm might be missing a location
parameter.


(In reply to David Malcolm from comment #31)
> Created attachment 48704 [details]
> v4 of the patch
> 
> v4 patch, close to being finished (I hope)
> 
> Also uploaded to:
>  
> https://dmalcolm.fedorapeople.org/gcc/2020-06-08/0001-FIXME-WIP-on-extended-
> asm-support-v4.patch
> 
> C API docs:
>  
> https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/topics/asm.
> html
> C++ API docs:
>  
> https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/cp/topics/asm.
> html

[Bug gcov-profile/95494] [11 regression] Several -fprofile-use tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Martin Liška  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #4)
>> > --- Comment #3 from Martin Liška  ---
>> > Is there a compile farm machine I can test it on?
>> 
>> Sure: gcc211 should do the trick.
>
> Thanks.
> Unfortunately, I can't build the current master due to switch to C++11:
[...]
> Is there a compiler in /opt that can build current GCC?

Drats, this system (like several others in the cfarm) urgently needs
some love ;-)  I've placed the self-compiled gcc 8.1.0 which I'm using
all the time on my systems to bootstrap master into ~ro/gcc/8.

You will probably have to point configure at /opt/csw for sufficiently
recent gmp, mpfr, and mpc, though.

All this should live in /opt/cfarm/{gcc,gmp,mpfr,mpc}-latest, following
cfarm standards...

Rainer

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Target|x86_64-apple-darwin*|*-*-darwin*
   Host|x86_64-apple-darwin*|*-*-darwin*
  Build|x86_64-apple-darwin*|*-*-darwin*
   Target Milestone|--- |11.0

--- Comment #1 from Iain Sandoe  ---
Darwin always separates debug info into a separate package (this is a directory
structure named exe.dSYM, for an exe name exe) [somewhat like split-dwarf, but
not optional or controlled by any command line flag]

This output is produced by the debug linker (dsymutil) any time that there is a
debug option on the command line + a source file, for which the object would be
temporary.

the failure mentioned occurs because the debug files are not being checked for
or deleted (and they are directory packages so that we need to use a suitable
delete).

this (first Part of the ) problem is fixed by the fragment below (Dominque's
patch + a tweak from me).

This then reveals a second issue - which is that the LTO tests are witten to
assume that the target generates thin LTO objects by default (which is true for
Linux but not for Darwin).  

The second problem can be catered for with a much longer patch which
essentially repeats the LTO tests for targets with/without fat-lto-objects. 
This seems a bit clunky and maybe there can be a better solution (maybe there
should also be a token test or two for linux using -ffat-lto-objects).

--

diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index 06a32dbeb9e..b3a1913f96c 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -43,6 +43,7 @@ if ![check_no_compiler_messages gsplitdwarf object {
 # Check for -flto support.  We explicitly test the result to skip
 # tests that use -flto.
 set skip_lto ![check_effective_target_lto]
+set target_lto_linker_plugin [check_linker_plugin_available]

 # Prepare additional options to be used for linking.
 # We do not compile to an executable, because that requires naming an output.
@@ -105,8 +106,12 @@ proc outest { test sources opts dirs outputs } {
}
 }
 set options ""
+set saw_debug 0
 foreach opt [split $opts " "] {
append options " additional_flags=$opt"
+   if {[string match "-g*" "$opt"]} {
+   set saw_debug 1
+   }
 }
 # Add linker flags if we're linking
 if {![string match "* -\[ESc\] *" " $opts "]} {
@@ -143,6 +148,12 @@ proc outest { test sources opts dirs outputs } {
if { [file exists $d$o] } then {
pass "$test: $d$o"
file delete $d$o
+   if { $saw_debug && [file exists $d$o.dSYM]} {
+   # Darwin split debug directory packages, expected for
+   # any case where debug is enabled for a single-file
+   # test.
+   file delete -force $d$o.dSYM
+   }
} else {
set ogl [glob -nocomplain -path $d -- $o]
if { $ogl != {} } {

[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-1067-gc1057cc0a8ad972e0a2218ab74038a56e5514c39
Author: Martin Sebor 
Date:   Mon Jun 8 09:06:48 2020 -0600

PR bootstrap/9 - powepc64 bootstrap failure due to
-Wmaybe-uninitialized in reload_cse_simplify_operands

gcc/ChangeLog:

* postreload.c (reload_cse_simplify_operands): Clear first array
element
before using it.  Assert a precondition.

[Bug c++/95578] New: std::ranges::copy and std::views::take_while don't want to play together

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 95578
   Summary: std::ranges::copy and std::views::take_while don't
want to play together
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hi gcc-team,

the following code does not compile (10.1.0 and trunk)

```c++
#include 
#include 

int main()
{
std::vector v{};
// auto && rng = v; // does work
auto && rng = v | std::views::take_while([](auto &&){return true;}); //
does not work

std::vector rng_copy{};
std::ranges::copy(rng, std::back_inserter(rng_copy));
return 0;
}
```
https://godbolt.org/z/nmRQgo

[Bug c++/95579] New: internal compiler error: in sign_mask, at wide-int.h:855

[nmmm at nmmm dot nu]

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

Bug ID: 95579
   Summary: internal compiler error: in sign_mask, at
wide-int.h:855
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nmmm at nmmm dot nu
  Target Milestone: ---

https://gcc.godbolt.org/z/5Dfous

#include 

uint16_t byteswap(uint16_t const a){
constexpr uint8_t b[] = {
8 * (2 - 1)
};

auto const x =
(0x00ffULL & a) << b[0] |
(0xff00ULL & a) >> b[0]
;

return static_cast(x);
}


--

: In function 'uint16_t byteswap(uint16_t)':

:12:25: internal compiler error: in sign_mask, at wide-int.h:855

   12 |   (0xff00ULL & a) >> b[0]

  | ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Compiler returned: 1

[Bug tree-optimization/95580] New: [11 Regression] ICE in tree_strip_any_location_wrapper at gcc/tree.h:4011 since r11-959-gb825a22890740f34

[marxin at gcc dot gnu.org]

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

Bug ID: 95580
   Summary: [11 Regression] ICE in tree_strip_any_location_wrapper
at gcc/tree.h:4011 since r11-959-gb825a22890740f34
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

I see the following ICE:

$ cat ov.i
int main(int p1, char **p2) {
  long a = sizeof(void);
  if (__builtin_strcmp(p2[1], "")) {
void *p = __builtin_malloc(4);
((char *)p)[a] ^= 1;
  }
  if (__builtin_strcmp(p2[1], "quarantine"))
for (int i;; i++)
  ;
}

$ gcc ov.i -O1 -Wextra -fno-tree-dse -c
‘*(
during GIMPLE pass: uninit
In function ‘main’:
Segmentation fault
1 | int main(int p1, char **p2) {
  | ^~~~
0xdb19cf crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x778b852f ???
   
/usr/src/debug/glibc-2.31-5.9.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x105c38a location_wrapper_p(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.h:3999
0x105c38a tree_strip_any_location_wrapper(tree_node*)
/home/marxin/Programming/gcc/gcc/tree.h:4011
0x105c38a integer_onep(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:2573
0x8b5f22 c_pretty_printer::unary_expression(tree_node*)
/home/marxin/Programming/gcc/gcc/c-family/c-pretty-print.c:1792
0x821f7d c_tree_printer
/home/marxin/Programming/gcc/gcc/c/c-objc-common.c:317
0x821f7d c_tree_printer
/home/marxin/Programming/gcc/gcc/c/c-objc-common.c:254
0x18221ac pp_format(pretty_printer*, text_info*)
/home/marxin/Programming/gcc/gcc/pretty-print.c:1475
0x18073be diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1159
0x1809928 diagnostic_impl
/home/marxin/Programming/gcc/gcc/diagnostic.c:1309
0x1809928 warning_at(unsigned int, int, char const*, ...)
/home/marxin/Programming/gcc/gcc/diagnostic.c:1446
0xfb998c maybe_warn_operand
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:431
0xfbb666 warn_uninitialized_vars
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:640
0xfbfb72 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-uninit.c:2936
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/95581] New: [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[marxin at gcc dot gnu.org]

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

Bug ID: 95581
   Summary: [11 Regression] ICE in gimple_call_arg, at
gimple.h:3260 since
r11-959-gb825a22890740f341eae566af27e18e528cd29a7
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Since the revision I see:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr34458.c
-ftree-loop-vectorize -mno-allow-movmisalign -Wextra -O1 -mpower8-vector -S
during GIMPLE pass: uninit
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr34458.c: In
function ‘lint_operate’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr34458.c:9:6:
internal compiler error: in gimple_call_arg, at gimple.h:3260
9 | Lint lint_operate (Lint a, long long ammount)
  |  ^~~~
0x147f267 gimple_call_arg
/home/marxin/Programming/gcc2/gcc/gimple.h:3260
0x147f2bd gimple_call_arg
/home/marxin/Programming/gcc2/gcc/gimple.h:3268
0x1481038 maybe_warn_pass_by_reference
/home/marxin/Programming/gcc2/gcc/tree-ssa-uninit.c:517
0x14816ad warn_uninitialized_vars
/home/marxin/Programming/gcc2/gcc/tree-ssa-uninit.c:631
0x14863a3 execute
/home/marxin/Programming/gcc2/gcc/tree-ssa-uninit.c:2936
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8be374e02761c9d63d2753d71e4bd4874a1577b1

commit r11-1065-g8be374e02761c9d63d2753d71e4bd4874a1577b1
Author: Jakub Jelinek 
Date:   Mon Jun 8 11:05:10 2020 +0200

forwprop: Ignore scalar mode vectors in simplify_vector_constructor
[PR95528]

As mentioned in the PR, the problem is that at least the x86 backend asumes
that the vec_unpack* and vec_pack* optabs with integral modes are for the
AVX512-ish vector masks rather than for very small vectors done in GPRs.
The only other target that seems to have a scalar mode vec_{,un}pack* optab
is aarch64 as discussed in the PR, so there is also a condition for that.
All other targets have just vector mode optabs.

2020-06-08  Jakub Jelinek  

PR target/95528
* tree-ssa-forwprop.c (simplify_vector_constructor): Don't use
VEC_UNPACK*_EXPR or VEC_PACK_TRUNC_EXPR with scalar modes unless
the
type is vector boolean.

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

[Bug debug/95574] New: line table entry in sequence with address after sequence

[vries at gcc dot gnu.org]

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

Bug ID: 95574
   Summary: line table entry in sequence with address after
sequence
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When doing a build from current trunk, I get the following in the .debug_line
section of build/x86_64-pc-linux-gnu/libgcc/libgcc_s.so.1:
...
  [0x06f5]  Special opcode 75: advance Address by 5 to 0x2faa and Line by 0
to 246
  [0x06f6]  Advance PC by 0 to 0x2faa
  [0x06f8]  Extended opcode 1: End of Sequence
...

This is nonsensical dwarf: both the special opcode and the End-Of-Sequence
declare a row in the matrix, each with the same address.

The special opcode declares a target instruction at that address.

The End-of-Sequence declares that the sequence ends before that address.

It's a contradiction that the target instruction is both part of the sequence
(according to Copy) and not part of the sequence (according to
End-of-Sequence).

[ Relevant dwarf standard bits:

end_sequence:

A boolean indicating that the current address is that of the first byte
after the end of a sequence of target machine instructions. end_sequence
terminates a sequence of lines; therefore other information in the same
row is not meaningful.

Special Opcodes

Each ubyte special opcode has the following effect on the state machine:
1. Add a signed integer to the line register.
2. Modify the operation pointer by incrementing the address and op_index
registers as described below.
3. Append a row to the matrix using the current values of the state machine
registers.

DW_LNE_end_sequence:

The DW_LNE_end_sequence opcode takes no operands. It sets the
end_sequence register of the state machine to “true” and appends a row
to the matrix using the current values of the state-machine registers.
Then it resets the registers to the initial values specified above (see
Section 6.2.2). Every line number program sequence must end with a
DW_LNE_end_sequence instruction which creates a row whose address is
that of the byte after the last target machine instruction of the sequence.

]

[Bug d/95575] New: [10/11 regression] gdc.test testnames lost gdc.test prefix

[ro at gcc dot gnu.org]

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

Bug ID: 95575
   Summary: [10/11 regression] gdc.test testnames lost gdc.test
prefix
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

As originally reported here

  https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543045.html

this patch

commit c76df72f1a916d0482d15e43656ddff724352705
Author: Iain Buclaw 
Date:   Sat Mar 28 18:44:12 2020 +0100

testsuite: Split up gdc-test.exp into each subdirectory

again lost the gdc.test prefix in the testnames, as e.g. seen on Solaris:

-FAIL: gdc.test/runnable/eh.d -fPIC -shared-libphobos   execution test
-FAIL: gdc.test/runnable/eh.d -shared-libphobos   execution test
-FAIL: gdc.test/runnable/test42.d   execution test
-FAIL: gdc.test/runnable/test42.d -g   execution test
-FAIL: gdc.test/runnable/test42.d -g -shared-libphobos   execution test
-FAIL: gdc.test/runnable/test42.d -shared-libphobos   execution test
+FAIL: runnable/eh.d -fPIC -shared-libphobos   execution test
+FAIL: runnable/eh.d -shared-libphobos   execution test
+FAIL: runnable/test42.d   execution test
+FAIL: runnable/test42.d -g   execution test
+FAIL: runnable/test42.d -g -shared-libphobos   execution test
+FAIL: runnable/test42.d -shared-libphobos   execution test

The testnames are supposed to be relative to gcc/testsuite.

[Bug fortran/92993] [8/9 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1066-g5dc3986103d8908c802e940dea8f2def3a6989c2
Author: Mark Eggleston 
Date:   Thu Jun 4 05:53:31 2020 +0100

Fortran  : ICE in maybe_canonicalize_comparison_1 PR92993

This issue has been fixed by PR94090.  Add test case to ensure that
this does not re-occur.

2020-06-08  Mark Eggleston  

gcc/testsuite/

PR fortran/92993
* gfortran.dg/pr92993.f90: New test.

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

[wilco at gcc dot gnu.org]

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

--- Comment #40 from Wilco  ---
(In reply to Jiu Fu Guo from comment #39)
> I’m thinking to draft a patch for this optimization.  If any suggestions,
> please point out, thanks.

Which optimization to be precise? Besides unrolling I haven't seen a proposal
for an optimization which is both safe and generally applicable.

[Bug debug/95574] line table entry in sequence with address after sequence

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Created attachment 48702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48702=edit
_absvsi2_s.c

To reproduce:
...
$ gcc -O2 -g -fpic -mlong-double-80 -fcf-protection -mshstk -fbuilding-libgcc
-fno-stack-protector -o _absvsi2_s.o -c _absvsi2_s.c -save-temps
...

[Bug d/95575] [10/11 regression] gdc.test testnames lost gdc.test prefix

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

[Bug c/93432] variable is used uninitialized, but gcc shows no warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
It warns in gcc 10.1. It may good idea to add this one as a testcase, since it
seems it got fixed without noticing.

[Bug debug/95576] New: [11 Regression] -fcompare-debug failure with -O3 -fno-tree-forwprop -fvect-cost-model=unlimited

[zsojka at seznam dot cz]

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

Bug ID: 95576
   Summary: [11 Regression] -fcompare-debug failure with -O3
-fno-tree-forwprop -fvect-cost-model=unlimited
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 48703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48703=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-g++ -O3 -fno-tree-forwprop -fvect-cost-model=unlimited
-fcompare-debug testcase.C
x86_64-pc-linux-gnu-g++: error: testcase.C: '-fcompare-debug' failure

$ diff -u *gkd
--- a-testcase.C.gkd2020-06-08 13:05:48.719739159 +0200
+++ a-testcase.gk.C.gkd 2020-06-08 13:05:48.839739158 +0200
@@ -191,9 +191,9 @@
 3:   struct S * s;
 4:   int f;
 5:   void * d;
-1:   int (*) () * _vptr.S;
-2:   static int (*) () _ZTV1S[5] = <<< omitted >>>;
-0:   struct S D.;
+2:   int (*) () * _vptr.S;
+0:   static int (*) () _ZTV1S[5] = <<< omitted >>>;
+1:   struct S D.;

 ;; Function T::~T (_ZN1TD0Ev, funcdef_no=8, cgraph_uid=9, symbol_order=9)

$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-1029-20200608001623-g53d461e4e0f-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-1029-20200608001623-g53d461e4e0f-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200608 (experimental) (GCC)

[Bug middle-end/95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
See RFC patch at
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547500.html
→ Don't add read-only artificial variables to the offload table (no need to)

And see experimental (but not working) patch regarding the stream out, which
highlights a state issue regarding host vs. target:
→ LTO stream out (array still present) and
host part (array already gone with -O3)
→ https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547502.html

[Bug c++/67901] [concepts] overloading bug when considered more specialized vs more constrained

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
  Known to fail||11.0
   Last reconfirmed|2019-10-15 00:00:00 |2020-6-8

--- Comment #1 from Patrick Palka  ---
Reconfirmed on mainline.

[Bug fortran/93026] gfortran.dg/goacc/finalize-1.f – FAILs since r279626

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Fixed by the fix for PR94090.

New test case committed to master and backported to gcc-10.

[Bug debug/95574] line table entry in sequence with address after sequence

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||wrong-debug

--- Comment #1 from Tom de Vries  ---
I can track this down to build/x86_64-pc-linux-gnu/libgcc/_absvsi2_s.o
...
  [0x0116]  Special opcode 75: advance Address by 5 to 0xa and Line by 0 to
246
  [0x0117]  Advance PC by 0 to 0xa
  [0x0119]  Extended opcode 1: End of Sequence
...
and using -save-temps I get the corresponding .s file:
...
.section.text.unlikely
.cfi_startproc
.type   __absvsi2.cold, @function
__absvsi2.cold:
.LFSB26:
.L12:
.cfi_def_cfa_offset 16
.loc 1 246 5 is_stmt 1 view .LVU17
callabort@PLT
.LVL7:
.loc 1 246 5 is_stmt 0 view .LVU33
.cfi_endproc
.LFE26:
...

I think this is due to the last .loc.  I'm not sure if it makes sense to
declare a .loc after a non-returning insn.

[Bug debug/95574] line table entry in sequence with address after sequence

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Gdb currently silently ignores the offending entry.

I've filed a gdb PR, PR26092 - "Complain about contradictory
DW_LNE_end_sequence marker" to complain about this (
https://sourceware.org/bugzilla/show_bug.cgi?id=26092 ).

[Bug debug/95576] [11 Regression] -fcompare-debug failure with -O3 -fno-tree-forwprop -fvect-cost-model=unlimited

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r11-454-gcfaf0edbb123958e84d296354152294f167db9f3

[Bug debug/95576] [11 Regression] -fcompare-debug failure with -O3 -fno-tree-forwprop -fvect-cost-model=unlimited

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The important difference in *.slp2 dumps is:
@@ -188,14 +201,17 @@ T::~T (struct T * const this)
   _15 = VIEW_CONVERT_EXPR(  [(void
*)&_ZTV1T + 16B]);
   _14 = {_15};
   vect_cst__13 = _14;
-  vectp.24_16 = _2(D)->D.2378._vptr.S;
-  MEM[(int (*) () * *)vectp.24_16] = vect_cst__13;
   _18 = VIEW_CONVERT_EXPR(  [(void
*)&_ZTV1S + 16B]);
   _19 = {_18};
   vect_cst__20 = _19;
+  # DEBUG this => this_2(D)
+  vectp.24_16 = _2(D)->D.2378._vptr.S;
+  MEM[(int (*) () * *)vectp.24_16] = vect_cst__13;
   _4 = _2(D)->D.2378;
+  # DEBUG this => _4
   vectp.26_21 = &_4->_vptr.S;
   MEM[(int (*) () * *)vectp.26_21] = vect_cst__20;
+  # DEBUG BEGIN_STMT
   _5 = _4->s;
   if (_5 != 0B)
 goto ; [70.00%]
(the previous pass is ok and all other hunks are just about addition of # DEBUG
stmts).

[Bug fortran/92993] [8/9 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #9 from markeggleston at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #6)
> (In reply to anlauf from comment #4)
> > The testcase in comment#0 compiles for me with today's master.
> > Has this been fixed accidentally?  Maybe someone can bisect
> > so that one can identify the commit that might be backported
> > to fix the regression.
> 
> This probably was
> 
> https://gcc.gnu.org/g:2298af0800b292f028298c1eaec42fd3033c4b9b
> 
> the fix for PR94090.
> 
> I think this is something that could be backported.

I tried this see:

https://gcc.gnu.org/pipermail/fortran/2020-June/054462.html

It won't be backported to gcc-9 and gcc-8 see:

https://gcc.gnu.org/pipermail/fortran/2020-June/054469.html

[Bug c/95580] [11 Regression] ICE in tree_strip_any_location_wrapper at gcc/tree.h:4011 since r11-959-gb825a22890740f34

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/86577] non-ADL name lookup for operator<< at instantiation time?

[leni536 at gmail dot com]

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

Lénárd Szolnoki  changed:

   What|Removed |Added

 CC||leni536 at gmail dot com

--- Comment #1 from Lénárd Szolnoki  ---
Other operators seem to be affected as well. This lookup error can be escalated
from accepts-invalid to wrong-code:

#include 

void calls_templated();
void calls_nontemplated();

namespace a {
struct A {};
}

namespace {
template
std::enable_if_t, bool>
operator==(const T&, const T &) {
calls_templated();
return true;
}

template
bool test(const T, const T ) {
return t1==t2;
}

bool operator==(const a::A&, const a::A&) {
calls_nontemplated();
return true;
}
}

int main() {
const a::A a;
test(a, a);
}

gcc 10.1 compiles the code above and calls 'calls_nontemplated()'.

[Bug middle-end/95270] OpenACC 'enter data attach' looks up target memory object displaced by pointer size

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jules at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |10.0
Summary|OpenACC 'enter data |OpenACC 'enter data attach'
   |attach(data_p)' fails for   |looks up target memory
   |'int *data_p'   |object displaced by pointer
   ||size
   Last reconfirmed||2020-06-08
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
I just hit this one again, started to debug it once again (until I finally
remembered this existing issue...), and cried a little bit.  ;'-|

Julian, this is a bug, right?  During gimplification, or in the front end(s)? 
Please have a look.

This issue is also visible in the (current) 'omplower' tree dump scans in
'c-c++-common/goacc/mdc-1.c': expecting 'bias: 8'.  (Pointer size, by the way;
cross-checked with '-m32' where we get 'bias: 4'.)

I'd thought I remember that I may work around this by wrapping pointers as
'struct' members, which would then 'attach' correctly, without size/bias
confusion, but apparently that's not true; the attached 'mdc-2b_.c' fails in
the same way even if altered as follows:

-  int *data_p = 
+#if 0
+  int *data_p;
+#else
+  struct s {
+int *data_p;
+  } s;
+# define data_p s.data_p
+#endif
+  data_p = 

What you instead have to do is to make sure that your target memory object
(here: 'data') is bigger than the bias (pointer size):

-  int data;
+  struct { char d[sizeof (void *) + 1]; } data;

Then it works, in all variants I've now posted.

Execution test cases that would ("might") exercise/notice this behavior:

  - 'libgomp.oacc-c-c++-common/deep-copy-2.c' -- works despite the bug, because
the '#pragma acc data copy(s.a[0:10])' already synthesizes an implicit
'map(attach:s.a [bias: 0])' (correct) and thus the incorrect 'map(attach:s.a
[bias: 8])' synthesized for the inner '#pragma acc parallel loop attach(s.a)'
doesn't cause a problem, as 'bias' is only used in the first call of the
respective 'gomp_attach_pointer'.
  - 'libgomp.oacc-c-c++-common/deep-copy-4.c' -- works despite the bug, because
for a struct bigger than the bias ('struct node' here), a 'splay_tree_lookup'
with start offset by bias will then still look up the expected object,
apparently.  With the 'val'/'sum' business removed, this test case quickly
fails: 'libgomp: pointer target not mapped for attach'.
  - 'libgomp.oacc-fortran/deep-copy-6.f90' -- correctly synthesizes
'map(attach:var.a [bias: 0])' for '!$acc enter data attach(var%a)'.  However,
for the earlier '!$acc enter data copyin(var%a(5:n - 5), var%b(5:n - 5))'
synthesizes the two 'gomp_attach_pointer' calls both with 'bias = 16' -- seems
to work, but is that correct?
  - 'libgomp.oacc-fortran/deep-copy-8.f90' -- correctly synthesizes
'map(attach:var.a [bias: 0])' for '!$acc enter data attach(var%a)'.

That's all with an explicit 'attach' clause, folks.

[Bug libfortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8cd239614e43c9dcc0838845aec504e5eb938dbd

commit r11-1068-g8cd239614e43c9dcc0838845aec504e5eb938dbd
Author: Harald Anlauf 
Date:   Mon Jun 8 21:00:11 2020 +0200

PR fortran/95195 - Fortran testcase should clean up afterwards

Change testcase to check error message (iomsg) at runtime, rather than to
crash.

libgfortran/
PR fortran/95091
* io/transfer.c (finalize_transfer): Fix type in error message.

gcc/testsuite/
PR fortran/95195
* gfortran.dg/namelist_97.f90: Adjust testcase.

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8cd239614e43c9dcc0838845aec504e5eb938dbd

commit r11-1068-g8cd239614e43c9dcc0838845aec504e5eb938dbd
Author: Harald Anlauf 
Date:   Mon Jun 8 21:00:11 2020 +0200

PR fortran/95195 - Fortran testcase should clean up afterwards

Change testcase to check error message (iomsg) at runtime, rather than to
crash.

libgfortran/
PR fortran/95091
* io/transfer.c (finalize_transfer): Fix type in error message.

gcc/testsuite/
PR fortran/95195
* gfortran.dg/namelist_97.f90: Adjust testcase.

[Bug middle-end/95270] OpenACC 'enter data attach' looks up target memory object displaced by pointer size

[jules at gcc dot gnu.org]

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

--- Comment #2 from jules at gcc dot gnu.org ---
TBH I've suspected problems with misuse of the bias for attach/detach before,
but I've not come up with a test case. I'll have a look.

Thanks!

[Bug c++/86577] non-ADL name lookup for operator<< at instantiation time?

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Is this a dup of PR 51577 ?

[Bug c++/95589] New: missing warning initializing a reference with a dereferenced null

[msebor at gcc dot gnu.org]

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

Bug ID: 95589
   Summary: missing warning initializing a reference with a
dereferenced null
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Initializing a reference by dereferenced null pointer is not diagnosed but
should be because such a reference is invalid:

$ cat t.C && gcc -O2 -S -Wall -Wextra -Wnull-dereference
-fdump-tree-optimized=/dev/stdout t.C
void f (const int&);
void g ()
{
  int *p = 0;
  f (*p);
}

;; Function g (_Z1gv, funcdef_no=0, decl_uid=2330, cgraph_uid=1,
symbol_order=0)

g ()
{
   [local count: 1073741824]:
  f (0B); [tail call]
  return;

}

Clang doesn't diagnose it either unless --analyze is used:

$ clang -S -Wall -Wextra --analyze t.C
t.C:5:3: warning: Forming reference to null pointer
  f (*p);
  ^~
1 warning generated.

[Bug tree-optimization/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
BTW, this is a bootstrap break for powerpc-darwin9, it fires when building
libgfortran (OK it's an 'all languages' bootstrap break).

[Bug tree-optimization/95527] Failure to optimize __builtin_ffs == 0

[jakub at gcc dot gnu.org]

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

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

Untested fix for ffs.  Haven't touched others.  I think parity can't be
optimized that way, for ctz/clz we'd need to decide how do we deal with the
undefined at zero fact (vs. e.g. the aarch64 clz/ctz defined already at GIMPLE
to a particular value through *_DEFINED_VALUE_AT_ZERO giving 2).
__builtin_popcount (x) == 0 (and != 0) should be easy, but for that one not
sure if we can optimize much more than that.

[Bug middle-end/95583] New: [OpenMP] Offloading – Missed optimization / before LTO stream out, do more IPA optimizations affecting host←→target ABI

[burnus at gcc dot gnu.org]

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

Bug ID: 95583
   Summary: [OpenMP] Offloading – Missed optimization / before LTO
stream out, do more IPA optimizations affecting
host←→target ABI
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
Depends on: 95551
  Target Milestone: ---

Follow up to PR 95551 + PR 94848 and some other PRs.

Currently, the flow is:

1. ipa_passes (); → calls output_offload_tables, writes LTO for target lto1
   (with -flto, stop here and continue with host lto1).
On host compiler or host lto1 compiler – and on target lto1 compiler, do:
2. execute_ipa_pass_list (g->get_passes ()->all_late_ipa_passes);
3. omp_finish_file()

As all_late_ipa_passes runs after writing the output_offload_tables, function
arguments (→ PR92029), inlining, global variable elimination etc. cannot happen
if they affect the host←→target ABI. And adding libgomp calls (e.g. for global
variable mapping) hamper optimizations which could be done otherwise.

Hence, optimizations influencing the host←→target ABI need to be handled before
output_offload_tables.

An example is the test case of PR 95551, where -O3 eliminates the static,
read-only array variable created for a Fortran array constructor but one still
needs to keep it as it is referenced in the output_offload_tables. And as it is
referenced in a complicated way, the local-only variable cannot be eliminated
anymore on the device side either.

Another example is PR90591 where value propagation could be done (and mapping
could be optimized to avoid pointless copyin/copyout or ...).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
[Bug 95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable
fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:127bf4228d0cb21f28fd5ed4dd820fa4760fc771

commit r10-8264-g127bf4228d0cb21f28fd5ed4dd820fa4760fc771
Author: Martin Jambor 
Date:   Mon Jun 8 20:15:22 2020 +0200

ipa-sra: Do not remove statements necessary because of non-call EH (PR
95113)

PR 95113 revealed that when reasoning about which parameters are dead,
IPA-SRA does not perform the same check related to non-call exceptions
as tree DCE.  It most certainly should and so this patch moves the
condition used in tree-ssa-dce.c into a separate predicate (in
tree-eh.c) and uses it from both places.

gcc/ChangeLog:

2020-05-27  Martin Jambor  

PR ipa/95113
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Move non-call
exceptions check to...
* tree-eh.c (stmt_unremovable_because_of_non_call_eh_p): ...this
new function.
* tree-eh.h (stmt_unremovable_because_of_non_call_eh_p): Declare
it.
* ipa-sra.c (isra_track_scalar_value_uses): Use it.  New parameter
fun.

gcc/testsuite/ChangeLog:

2020-05-27  Martin Jambor  

PR ipa/95113
* gcc.dg/ipa/pr95113.c: New test.

(cherry picked from commit 1980ffec48c6fa41396bea66366f2e591798e1e1)

[Bug fortran/95587] New: ICE in gfc_target_encode_expr, at fortran/target-memory.c:362

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

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

Bug ID: 95587
   Summary: ICE in gfc_target_encode_expr, at
fortran/target-memory.c:362
   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: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   class(*), allocatable :: x, y
   equivalence (x, y)
end


$ cat z2.f90
program p
   type t
   end type
   class(t), allocatable :: x, y
   equivalence (x, y)
end


$ cat z0.f90   # ok, allocatable object or pointer not allowed
program p
   type t
   end type
   type(t), allocatable :: x, y
   equivalence (x, y)
end


$ gfortran-11-20200607 -c z1.f90
f951: internal compiler error: Invalid expression in gfc_target_encode_expr.
0x654af9 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x65621a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x6f3200 gfc_target_encode_expr(gfc_expr*, unsigned char*, unsigned long)
../../gcc/fortran/target-memory.c:362
0x6f32ff expr_to_char
../../gcc/fortran/target-memory.c:697
0x6f3dd0 gfc_merge_initializers(gfc_typespec, gfc_expr*, locus*, unsigned
char*, unsigned char*, unsigned long)
../../gcc/fortran/target-memory.c:735
0x71cc63 get_init_field
../../gcc/fortran/trans-common.c:544
0x71cc63 create_common
../../gcc/fortran/trans-common.c:633
0x71e111 finish_equivalences
../../gcc/fortran/trans-common.c:1326
0x71e111 gfc_trans_common(gfc_namespace*)
../../gcc/fortran/trans-common.c:1363
0x72b60f gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6764
0x6b3126 translate_all_program_units
../../gcc/fortran/parse.c:6306
0x6b3126 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x6feb3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug gcov-profile/95494] [11 regression] Several -fprofile-use tests FAIL

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #7 from Martin Liška  ---
Confirmed, I've got hopefully a patch candidate for it.

[Bug middle-end/77432] warn about null check after pointer dereference

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Last reconfirmed|2016-08-31 00:00:00 |2020-6-8
  Known to fail||10.1.0, 11.0, 7.3.0, 8.2.0,
   ||9.1.0

--- Comment #4 from Martin Sebor  ---
Reconfirming with GCC 11.  The if statement is simplified to if (1 != 0) by
EVRP:

Visiting stmt b_4 = *a_3(D);
Intersecting
  int * [1B, +INF]  EQUIVALENCES: { a_3(D) } (1 elements)
and
  int * VARYING
to
  int * [1B, +INF]  EQUIVALENCES: { a_3(D) } (1 elements)
pushing new range for a_3(D): int * [1B, +INF]  EQUIVALENCES: { a_3(D) } (1
elements)
Visiting stmt if (a_3(D) != 0B)

Visiting conditional with predicate: if (a_3(D) != 0B)

With known ranges
a_3(D): int * [1B, +INF]  EQUIVALENCES: { a_3(D) } (1 elements)

Predicate evaluates to: 1
gimple_simplified to if (1 != 0)

[Bug c++/95579] [10/11 Regression] internal compiler error: in sign_mask, at wide-int.h:855

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |10.2
 CC||jakub at gcc dot gnu.org
   Priority|P3  |P2
Summary|internal compiler error: in |[10/11 Regression] internal
   |sign_mask, at   |compiler error: in
   |wide-int.h:855  |sign_mask, at
   ||wide-int.h:855
   Last reconfirmed||2020-06-08
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jakub Jelinek  ---
Started with r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f
Reduced testcase:

unsigned short
foo (unsigned short a)
{
  constexpr unsigned char b[1] = { 15 };
  return (0x00ffU & a) << b[0] | (0xff00U & a) >> b[0];
}

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

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
Fixed.  Thanks for reporting.

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

[jamborm at gcc dot gnu.org]

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

Bug 95113 Summary: [10/11 Regression] Wrong code w/ -O2 -fexceptions 
-fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95113

   What|Removed |Added

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

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

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Jambor  ---
...and marking it as such.

[Bug fortran/95586] New: ICE in gfc_validate_kind, at fortran/trans-types.c:773

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

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

Bug ID: 95586
   Summary: ICE in gfc_validate_kind, at fortran/trans-types.c:773
   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: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   implicit type(t) (1)
   type t
   end type
end


$ cat z2.f90
program p
   integer n1
   parameter (n1 = 1)
   implicit type(t) (n1)
   type t
   end type
end


$ gfortran-11-20200607 -c z1.f90
f951: internal compiler error: gfc_validate_kind(): Got bad type
0x654af9 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x65621a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x77d9a7 gfc_validate_kind(bt, int, bool)
../../gcc/fortran/trans-types.c:773
0x63f621 gfc_match_kind_spec(gfc_typespec*, bool)
../../gcc/fortran/decl.c:3191
0x646967 gfc_match_implicit()
../../gcc/fortran/decl.c:4832
0x6a8191 match_word
../../gcc/fortran/parse.c:65
0x6ac309 decode_statement
../../gcc/fortran/parse.c:508
0x6acf5a next_free
../../gcc/fortran/parse.c:1279
0x6acf5a next_statement
../../gcc/fortran/parse.c:1511
0x6af304 parse_spec
../../gcc/fortran/parse.c:3738
0x6b137c parse_progunit
../../gcc/fortran/parse.c:5851
0x6b2a59 gfc_parse_file()
../../gcc/fortran/parse.c:6392
0x6feb3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c/95588] New: No warning in -Wformat for narrowing formats

[nhuck at google dot com]

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

Bug ID: 95588
   Summary: No warning in -Wformat for narrowing formats
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nhuck at google dot com
  Target Milestone: ---

When using formats that cause narrowing conversion gcc does not output any
warnings with -Wformat.

//No warning
#include 
void go(int x) {
printf("%hhx", x);
}

This seems like a valid case for a warning.

Discussion on related issues:
https://lkml.org/lkml/2019/4/11/639
https://github.com/ClangBuiltLinux/linux/issues/378

[Bug c++/86577] non-ADL name lookup for operator<< at instantiation time?

[leni536 at gmail dot com]

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

--- Comment #3 from Lénárd Szolnoki  ---
(In reply to Jonathan Wakely from comment #2)
> Is this a dup of PR 51577 ?

Yes, seems like it is.

[Bug bootstrap/95582] New: [11 Regression] LTO lean + PGO bootstrap is broken in Ada

[marxin at gcc dot gnu.org]

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

Bug ID: 95582
   Summary: [11 Regression] LTO lean + PGO bootstrap is broken in
Ada
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org
  Target Milestone: ---

Using:
../configure --enable-languages=c,c++,lto,ada --disable-multilib
--disable-libsanitizer --disable-werror --with-build-config=bootstrap-lto-lean
&& time nicem STAGE1_CFLAGS="-O2 -g" profiledbootstrap

I see the following ICE:

/home/mliska/Programming/gcc/objdir/./prev-gcc/lto1 -quiet -dumpbase
./gnatbind.ltrans2.ltrans -mtune=generic -march=x86-64 -g -g -g -O2 -O2 -O2
-Wextra -Wno-error=format-diag -Wpedantic -version -fno-openmp -fno-openacc
-fno-pie -fno-exceptions -fasynchronous-unwind-tables -fno-common -fprofile-use
-fltrans @/tmp/ccyXRzUi -o ./gnatbind.ltrans2.ltrans.s
GNU GIMPLE (GCC) version 11.0.0 20200608 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20200608 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 11.0.0 20200608 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20200608 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
during GIMPLE pass: slp
../../gcc/ada/libgnat/s-os_lib.adb: In function
‘system__os_lib__normalize_pathname__missed_drive_letter’:
../../gcc/ada/libgnat/s-os_lib.adb:2133:7: internal compiler error: in
vect_init_pattern_stmt, at tree-vect-patterns.c:115
 2133 |   function Missed_Drive_Letter (Name : String) return Boolean is
  |   ^
0x774560 vect_init_pattern_stmt
../../gcc/tree-vect-patterns.c:115
0x1669c73 vect_set_pattern_stmt
../../gcc/tree-vect-patterns.c:133
0x1669c73 vect_mark_pattern_stmts
../../gcc/tree-vect-patterns.c:5248
0x1669c73 vect_pattern_recog_1
../../gcc/tree-vect-patterns.c:5364
0x1678d11 vect_pattern_recog(vec_info*)
../../gcc/tree-vect-patterns.c:5502
0xf0dc2a vect_slp_analyze_bb_1
../../gcc/tree-vect-slp.c:3097
0xf0dc2a vect_slp_bb_region
../../gcc/tree-vect-slp.c:3210
0xf0dc2a vect_slp_bb(basic_block_def*)
../../gcc/tree-vect-slp.c:3345
0xf0f91e execute
../../gcc/tree-vectorizer.c:1320

[Bug testsuite/95416] Several gcc.misc-tests/outputs.exp tests FAIL

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-08
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #2 from Alexandre Oliva  ---
Created attachment 48706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48706=edit
patch that works around the problem

Does this help?

[Bug c++/95579] [10 Regression] internal compiler error: in sign_mask, at wide-int.h:855

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Summary|[10/11 Regression] internal |[10 Regression] internal
   |compiler error: in  |compiler error: in
   |sign_mask, at   |sign_mask, at
   |wide-int.h:855  |wide-int.h:855
 Resolution|--- |DUPLICATE

--- Comment #3 from Jakub Jelinek  ---
Ah, it has been fixed on the trunk already in
r11-474-g2d4e1e144c25e526e4f668be5a0bc10d0c1c738c

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

[Bug c++/94955] [10 Regression] ICE in to_wide

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||nmmm at nmmm dot nu

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

[Bug fortran/95584] New: ICE in generic_correspondence, at fortran/interface.c:1260

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

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

Bug ID: 95584
   Summary: ICE in generic_correspondence, at
fortran/interface.c:1260
   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: ---

Affects versions down to at least r5, with a doubled interface :


$ cat z1.f90
program p
   interface s
  subroutine g(x, *)
  end
  subroutine h(y, *)
  end
   end interface
end


$ gfortran-11-20200607 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbc593f crash_signal
../../gcc/toplev.c:328
0x662887 generic_correspondence
../../gcc/fortran/interface.c:1260
0x66379b gfc_compare_interfaces(gfc_symbol*, gfc_symbol*, char const*, int,
int, char*, int, char const*, char const*, bool*)
../../gcc/fortran/interface.c:1776
0x663f6c check_interface1
../../gcc/fortran/interface.c:1954
0x664163 check_sym_interfaces
../../gcc/fortran/interface.c:2012
0x6e9fc2 do_traverse_symtree
../../gcc/fortran/symbol.c:4150
0x6641e0 gfc_check_interfaces(gfc_namespace*)
../../gcc/fortran/interface.c:2104
0x6cf3ad resolve_types
../../gcc/fortran/resolve.c:17191
0x6ca98c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17290
0x6b2adc resolve_all_program_units
../../gcc/fortran/parse.c:6245
0x6b2adc gfc_parse_file()
../../gcc/fortran/parse.c:6492
0x6feb3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug tree-optimization/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
gimple_call_arg(stmt, 2) asserts for this GIMPLE_CALL statement:

  vect__5.6_24 = __builtin_altivec_mask_for_load (vectp_a.5_8);

The call is made with just one argument but the type of the function is
actually

 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777b22a0 precision:8 min  max
>
V16QI
size 
unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7787b000 nunits:16>
SI
size  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7789a888
arg-types 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777b2738 precision:64 min  max 
pointer_to_this >
chain 
chain >>>
pointer_to_this >

I couldn't found the function documented in the manual or exercised by the test
suite but I see it created in gcc/config/rs6000/rs6000-call.c:

  decl = add_builtin_function ("__builtin_altivec_mask_for_load",
   v16qi_ftype_long_pcvoid,
   ALTIVEC_BUILTIN_MASK_FOR_LOAD,
   BUILT_IN_MD, NULL, NULL_TREE);

Is it okay to call it with fewer arguments than its type indicates?

[Bug c++/95589] missing warning initializing a reference with a dereferenced null

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84316
 Blocks||86172
   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
I was about to classify this as an enhancement but after reading the
description of -Wnull-dereference in the manual ("compiler detects paths that
trigger erroneous or undefined behavior due to dereferencing a null pointer")
I'm inclined to view it as a bug.  The code is clearly in error, GCC just
doesn't detect it (even though the "doesn't detect it" part could be used to
argue the warning works strictly as documented).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
[Bug 86172] [meta-bug] issues with -Wnull-dereference

[Bug c++/93467] [concepts] getting "type constraint differs in template redeclaration" error after friend declaration in template

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c/95580] [11 Regression] ICE in tree_strip_any_location_wrapper at gcc/tree.h:4011 since r11-959-gb825a22890740f34

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|tree-optimization   |c

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:

/* PR 

void bar (void);

void
foo (int x)
{
  if (x == 0)
{
  void *p = __builtin_malloc (16);
  ((char *)p)[1] ^= 1;
}
  bar ();
}

[Bug fortran/95585] New: ICE in gfc_check_reshape, at fortran/check.c:4751

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

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

Bug ID: 95585
   Summary: ICE in gfc_check_reshape, at fortran/check.c:4751
   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: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   integer, parameter :: a(2) = reshape([1, 2], a)
end


$ gfortran-11-20200607 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbc593f crash_signal
../../gcc/toplev.c:328
0x62e589 gfc_check_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/check.c:4751
0x66a55c do_check
../../gcc/fortran/intrinsic.c:4737
0x66a55c check_specific
../../gcc/fortran/intrinsic.c:4750
0x674854 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4987
0x6c2733 resolve_unknown_f
../../gcc/fortran/resolve.c:2902
0x6c2733 resolve_function
../../gcc/fortran/resolve.c:3246
0x6c2733 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7040
0x65a154 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3085
0x65d3e0 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:3133
0x648c84 variable_decl
../../gcc/fortran/decl.c:2886
0x648c84 gfc_match_data_decl()
../../gcc/fortran/decl.c:6195
0x6ab513 match_word
../../gcc/fortran/parse.c:65
0x6ab513 decode_statement
../../gcc/fortran/parse.c:376
0x6acf5a next_free
../../gcc/fortran/parse.c:1279
0x6acf5a next_statement
../../gcc/fortran/parse.c:1511
0x6af304 parse_spec
../../gcc/fortran/parse.c:3738
0x6b137c parse_progunit
../../gcc/fortran/parse.c:5851
0x6b2a59 gfc_parse_file()
../../gcc/fortran/parse.c:6392
0x6feb3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug target/89788] trunk/liboffloadmic/runtime/emulator/coi_host.cpp:175]: (error) Null pointer dereference (missed -Wnull-dereference)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Blocks|86172   |

--- Comment #5 from Martin Sebor  ---
The code is still in liboffloadmic/runtime/emulator/coi_host.cpp but I wonder
why it isn't diagnosed.  Passing a null pointer of any other type but char* to
%s is diagnosed by -Wformat.  Usually only with optimization, passing a null
pointer to %s is then diagnosed by -Wformat-overflow.  A test case for the
latter is below.

Could something like -Wno-system-headers be somehow disablig it?

$ cat pr89788.c && gcc -O2 -S -Wall -Wextra pr89788.c
#include 
#include 

void f (const char *path)
{
  DIR *p = opendir (path);
  if (!p)
fprintf (stderr, "error: %s", (char*)p);
}
pr89788.c: In function ‘f’:
pr89788.c:8:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
8 | fprintf (stderr, "error: %s", (char*)p);
  | ^~~


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
[Bug 86172] [meta-bug] issues with -Wnull-dereference

[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Submitted for review here:

https://gcc.gnu.org/pipermail/fortran/2020-June/054499.html

[Bug d/95575] [10/11 regression] gdc.test testnames lost gdc.test prefix

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
Ah, for some reason I thought that moving the dejagnu .exp scripts from
top-level gdc.test to one per each subdirectory would remove the need for that.
 I'll revert that part of the change then.

[Bug gcov-profile/95365] [11 Regression] Broken gcov since r11-627-g1dedc12d186a1108

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #2 from Alexandre Oliva  ---
'fraid the change was intentional.  Different compilations of foo.c, with
different options, now get different gcda files, instead of one stepping on the
other's toes.

You have to separate compilation and linking to get foo.gc{da,no}, or use the
"-dumpbase ''" workaround to restore prior aux output naming conventions.

[Bug libstdc++/95592] Collision with struct _Cosh when Cross compiling libstdc++

[kevin at arilabs dot net]

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

--- Comment #2 from Kevin Stallard  ---
Please forgive the fat fingers.

gcc 7.5.0 on Ubuntu 18.04.4 is the host used to build the cross compiler.

(In reply to Kevin Stallard from comment #1)
> I should also add that this was build with gcc 7.5.0 on Ubuntu

[Bug d/95573] [11 regression] gdc.test/runnable/lazy.d UNRESOLVED

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Done.

[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Mon, Jun 08, 2020 at 08:02:48PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544
> 
> anlauf at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||anlauf at gcc dot gnu.org
> 
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> Created attachment 48708
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48708=edit
> Cleaned up patch
> 
> Hi Steve,
> 
> since there is already a function invalid_null_arg(), it can be reused.
> 
> If you do not object, I'll package it for you.
> 

No problem.  I was aware of invalid_null_arg(), but
simply copied a nearby gfc_error().

[Bug fortran/95584] ICE in generic_correspondence, at fortran/interface.c:1260

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 280157)
+++ gcc/fortran/interface.c (working copy)
@@ -1257,7 +1257,7 @@ generic_correspondence (gfc_formal_arglist *f1, gfc_fo

   while (f1)
 {
-  if (f1->sym->attr.optional)
+  if (!f1->sym || f1->sym->attr.optional)
goto next;

   if (p1 && strcmp (f1->sym->name, p1) == 0)

[Bug lto/94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:1c0fdaf79e3618fd7512608a2e5c62b6b306e9e8

commit r11-1075-g1c0fdaf79e3618fd7512608a2e5c62b6b306e9e8
Author: Tobias Burnus 
Date:   Mon Jun 8 23:24:57 2020 +0200

openmp: ensure variables in offload table are streamed out (PRs 94848 +
95551)

gcc/ChangeLog:

PR lto/94848
PR middle-end/95551
* omp-offload.c (add_decls_addresses_to_decl_constructor,
omp_finish_file): Skip removed items.
* lto-cgraph.c (output_offload_tables): Likewise; set force_output
to this node for variables and functions.

libgomp/ChangeLog:

PR lto/94848
PR middle-end/95551
* testsuite/libgomp.fortran/target-var.f90: New test.

[Bug tree-optimization/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I posted a patch to avoid the ICE but it's not clear to me that it's the right
fix: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547548.html

[Bug testsuite/95538] Unfinished cleanup in the test suite

[aoliva at gcc dot gnu.org]

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

--- Comment #2 from Alexandre Oliva  ---
More likely we've just always missed these lto dump files: IIRC they used to be
created in tmpdir, even during -save-temps builds.

[Bug fortran/95542] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1649

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Dominique d'Humieres  ---
Confirmed.

[Bug libstdc++/95592] New: Collision with struct _Cosh when Cross compiling libstdc++

[kevin at arilabs dot net]

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

Bug ID: 95592
   Summary: Collision with struct _Cosh when Cross compiling
libstdc++
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin at arilabs dot net
  Target Milestone: ---

I am cross compiling gcc 8.3.0 for QNX 6.6. While doing so,
libstdc++-v3/include/bits/valarray_after.h was having trouble with "struct
_Cosh" defined in valarray_before.h because it was colliding with the function
_Cosh() is defined in one of the target OS's headers.

Specifically it was having trouble with (around line 445 of valarray_after.h):

   _DEFINE_EXPR_UNARY_FUNCTION(cosh, _Cosh)

The compiler was using the function declaration of _Cosh instead of struct
_Cosh.

There were other _DEFINE_EXPR_UNARY_FUNCTION that had the same issue (I don't
remember which ones as I focused on _Cosh). 

Below is a patch to valarray_after.h that fixes the issue.  I'm pretty sure QNX
may be the only target OS with this problem, so I am content if this doesn't
make it in gcc, but thought that perhaps removing ambiguity from the preceding
template definitions wouldn't be bad.

I took a look at gcc 9 and 10 code base and the issue appears to exist there as
well.

Thanks
Kevin


Index: libstdc++-v3/include/bits/valarray_after.h
===
--- libstdc++-v3/include/bits/valarray_after.h  (revision 1469)
+++ libstdc++-v3/include/bits/valarray_after.h  (working copy)
@@ -422,20 +422,20 @@

 #define _DEFINE_EXPR_UNARY_FUNCTION(_Name, _UName)   \
   template   \
-inline _Expr<_UnClos<_UName, _Expr, _Dom>,   \
+inline _Expr<_UnClos, 
 \
  typename _Dom::value_type>  \
 _Name(const _Expr<_Dom, typename _Dom::value_type>& __e) \
 {\
   typedef typename _Dom::value_type _Tp; \
-  typedef _UnClos<_UName, _Expr, _Dom> _Closure; \
+  typedef _UnClos _Closure;   
 \
   return _Expr<_Closure, _Tp>(_Closure(__e()));  \
 }\
  \
   template \
-inline _Expr<_UnClos<_UName, _ValArray, _Tp>, _Tp>   \
+inline _Expr<_UnClos, _Tp> 
 \
 _Name(const valarray<_Tp>& __v)  \
 {\
-  typedef _UnClos<_UName, _ValArray, _Tp> _Closure;  \
+  typedef _UnClos _Closure;
 \
   return _Expr<_Closure, _Tp>(_Closure(__v));\
 }

[Bug d/95573] [11 regression] gdc.test/runnable/lazy.d UNRESOLVED

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r11-1070-g5fceefeee9a10cfba621d215f011a58badc246ad
Author: Iain Buclaw 
Date:   Mon Jun 8 22:11:00 2020 +0200

d: Fix regression caused by recent refactoring

gcc/d/ChangeLog:

PR d/95573
* dmd/MERGE: Merge upstream dmd 5041e56f1.

[Bug middle-end/95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:1c0fdaf79e3618fd7512608a2e5c62b6b306e9e8

commit r11-1075-g1c0fdaf79e3618fd7512608a2e5c62b6b306e9e8
Author: Tobias Burnus 
Date:   Mon Jun 8 23:24:57 2020 +0200

openmp: ensure variables in offload table are streamed out (PRs 94848 +
95551)

gcc/ChangeLog:

PR lto/94848
PR middle-end/95551
* omp-offload.c (add_decls_addresses_to_decl_constructor,
omp_finish_file): Skip removed items.
* lto-cgraph.c (output_offload_tables): Likewise; set force_output
to this node for variables and functions.

libgomp/ChangeLog:

PR lto/94848
PR middle-end/95551
* testsuite/libgomp.fortran/target-var.f90: New test.

[Bug lto/95224] -flto -save-temps uses very unusual name for resolution file, looks arbitrary

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
The changes to the handling of '%u' under -save-temps have probably fixed this.
 Previously, we'd use input_basename unconditionally.