[Bug c++/91002] ICE in make_ssa_name_fn, at tree-ssanames.c:271 with VLA type in reinterpret_cast

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |c++
 Depends on||16994
Summary|ICE in make_ssa_name_fn, at |ICE in make_ssa_name_fn, at
   |tree-ssanames.c:271 |tree-ssanames.c:271 with
   ||VLA type in
   ||reinterpret_cast

--- Comment #1 from Andrew Pinski  ---
char(*)[foo()] is a VLA type which is a GCC extension.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
[Bug 16994] [meta-bug] VLA and C++

[Bug target/62147] missed loop counter based optimization

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #8 from Kewen Lin  ---
The fix has been checked in, please verify it.

[Bug target/62147] missed loop counter based optimization

[linkw at gcc dot gnu.org]

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

--- Comment #7 from Kewen Lin  ---
Author: linkw
Date: Thu Jun 27 05:33:15 2019
New Revision: 272732

URL: https://gcc.gnu.org/viewcvs?rev=272732=gcc=rev
Log:
One line change onto r272731

PR target/62147
* gcc/loop-iv.c (find_simple_exit)

-  if (single_exit (loop) && finite_loop_p (loop))
+  if (desc->infinite && single_exit (loop) && finite_loop_p (loop))


Modified:
trunk/gcc/loop-iv.c

[Bug c++/91011] New: g++ -Q --help=warning,c++ outputs from C point of view

[adam.f.badura at gmail dot com]

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

Bug ID: 91011
   Summary: g++ -Q --help=warning,c++ outputs from C point of view
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam.f.badura at gmail dot com
  Target Milestone: ---

My g++ -v outputs
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/opt/gcc/x86_64/7.3.0a-1/libexec/gcc/x86_64-redhat-linux/7.3.0/lto-wrapper
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/opt/gcc/x86_64/7.3.0a-1 
> --exec-prefix=/opt/gcc/x86_64/7.3.0a-1 --bindir=/opt/gcc/x86_64/7.3.0a-1/bin 
> --sbindir=/opt/gcc/x86_64/7.3.0a-1/sbin 
> --sysconfdir=/opt/gcc/x86_64/7.3.0a-1/etc 
> --datadir=/opt/gcc/x86_64/7.3.0a-1/share 
> --includedir=/opt/gcc/x86_64/7.3.0a-1/include 
> --libdir=/opt/gcc/x86_64/7.3.0a-1/lib 
> --libexecdir=/opt/gcc/x86_64/7.3.0a-1/libexec --localstatedir=/var 
> --sharedstatedir=/var/lib --mandir=/opt/gcc/x86_64/7.3.0a-1/man 
> --infodir=/opt/gcc/x86_64/7.3.0a-1/info 
> --with-docdir=/opt/gcc/x86_64/7.3.0a-1/doc --enable-shared 
> --enable-languages=c,c++ --enable-threads=posix --enable-checking=release 
> --with-system-zlib --disable-libunwind-exceptions --enable-libssp 
> --enable-lto --with-gnu-ld --verbose --disable-gtktest 
> --target=x86_64-redhat-linux --build=x86_64-redhat-linux 
> --host=x86_64-redhat-linux --enable-__cxa_atexit
> Thread model: posix
> gcc version 7.3.0 (GCC)
however, I have seen this issue also with other versions as well.

The problem is that the command
> g++ -Q --help=warning,c++
outputs warnings from the C point of view rather than C++ point of view.

So, executing the:
> g++ -Wnon-virtual-dtor -Q --help=warning,c++
will output to the standard error stream a message
> cc1: warning: command line option ‘-Wnon-virtual-dtor’ is valid for 
> C++/ObjC++ but not for C
while the warning will still show as disabled on the output:
>   -Wnon-virtual-dtor[disabled]

Using -x option:
> g++ -Wnon-virtual-dtor -Q --help=warning,c++ -x c++
doesn't help.

Exploring various versions of GCC on the Compiler Explorer
(https://godbolt.org/) it seems this behavior applies to all newer versions up
to 9.1 (top at the moment) and all older versions down to 5.1 and perhaps even
older (I didn't check them).

However, as it comes to trunk version a workaround exists. If a C++ source file
is added to the command like this:
> touch dummy.cpp
> g++ -Wnon-virtual-dtor -Q --help=warning,c++ dummy.cpp
or this:
> touch dummy.whatever
> g++ -Wnon-virtual-dtor -Q --help=warning,c++ -x c++ dummy.whatever
it enforces C++ language perspective and the problem disappears.

Sadly, the file must exist even though it is not really used for anything. If
the file doesn't exist we only get:
> g++: error: dummy.cc: No such file or directory

Is there any workaround for versions older than trunk?

[Bug target/62147] missed loop counter based optimization

[linkw at gcc dot gnu.org]

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

--- Comment #6 from Kewen Lin  ---
Author: linkw
Date: Thu Jun 27 05:24:00 2019
New Revision: 272731

URL: https://gcc.gnu.org/viewcvs?rev=272731=gcc=rev
Log:

Call finite_loop_p in RTL to get better finiteness information.

gcc/ChangeLog

2019-06-27  Kewen Lin  

PR target/62147
* gcc/loop-iv.c (find_simple_exit): Call finite_loop_p to update
finiteness.

gcc/testsuite/ChangeLog

2019-06-27  Kewen Lin  

PR target/62147
* gcc.target/powerpc/pr62147.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr62147.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-iv.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/59552] Warning when non-trivial type parameter is passed by value but not changed in function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Blocks||87403

--- Comment #4 from Eric Gallager  ---
Presumably this warning would go under a new flag, so making it block the
new-warning meta-bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c++/47342] misleading diagnostic for member of undeclared class template partial specialization

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Thu Jun 27 02:42:30 2019
New Revision: 272726

URL: https://gcc.gnu.org/viewcvs?rev=272726=gcc=rev
Log:
PR tree-optimization/90883
* tree-ssa-dse.c (delete_dead_or_redundant_call): Fix signature.
(delete_dead_or_redundant_assignment): Likewise.

Modified:
trunk/gcc/tree-ssa-dse.c

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[law at gcc dot gnu.org]

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

--- Comment #11 from Jeffrey A. Law  ---
Author: law
Date: Thu Jun 27 02:41:27 2019
New Revision: 272725

URL: https://gcc.gnu.org/viewcvs?rev=272725=gcc=rev
Log:
PR tree-optimization/90883
* tree-ssa-dse.c (delete_dead_or_redundant_call): Fix signature.
(delete_dead_or_redundant_assignment): Likewise.

Modified:
trunk/gcc/ChangeLog

[Bug tree-optimization/91010] New: ICE: Segmentation fault (in location_wrapper_p)

[asolokha at gmx dot com]

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

Bug ID: 91010
   Summary: ICE: Segmentation fault (in location_wrapper_p)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

g++-10.0.0-alpha20190623 snapshot (r272608) ICEs when compiling the following
testcase reduced from gcc/testsuite/g++.dg/vect/simd-5.cc at any optimization
level except -Og and w/ -fopenmp -fno-tree-forwprop:

struct ug {
  ug &
  operator= (const ug )
  {
gj = je.gj;
return *this;
  }

  int gj;
};

#pragma omp declare reduction (+ : ug : omp_out.gj += omp_in.gj)
void
i0 (ug )
{
  int mv;

#pragma omp simd reduction (inscan, + : hf)
  for (mv = 0; mv < 2; ++mv)
{
  ;
#pragma omp scan inclusive (hf)
  ;
}
}

% x86_64-pc-linux-gnu-g++-10.0.0-alpha20190623 -O1 -fopenmp -fno-tree-forwprop
-c arijcgdh.cc
during GIMPLE pass: vect
arijcgdh.cc: In function 'void i0(ug&)':
arijcgdh.cc:14:1: internal compiler error: Segmentation fault
   14 | i0 (ug )
  | ^~
0xf6b3e8 crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/toplev.c:326
0xc72515 location_wrapper_p(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree.h:3845
0xc72515 tree_strip_any_location_wrapper(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree.h:3857
0xc72515 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/fold-const.c:2967
0xc746b1 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/fold-const.c:2950
0x118e6e7 scan_operand_equal_p
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-stmts.c:6351
0x11af386 check_scan_store
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-stmts.c:6734
0x11af386 vectorizable_store
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-stmts.c:7315
0x11b0115 vect_analyze_stmt(_stmt_vec_info*, bool*, _slp_tree*, _slp_instance*,
vec*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-stmts.c:10566
0x11c9182 vect_analyze_loop_operations
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-loop.c:1631
0x11c9182 vect_analyze_loop_2
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-loop.c:2077
0x11c9182 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-loop.c:2380
0x11e39e5 try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vectorizer.c:886
0x11e468f vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vectorizer.c:1114

[Bug rtl-optimization/90976] A suspicious code in lra.c since r177852

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
(In reply to Jeffrey A. Law from comment #1)
> Agreed, looks suspicious.  From my reading of the code, I think using
> "constraints" rather than "recog_data.constraints" is correct.
> 
> The  prior call to decode_asm_operands should have set up the constraint
> strings into "constraints".  I don't think "recog_data.constraints" will
> necessarily have the right bits because the insn was not recognized (it's an
> asm after all :-)
> 
> So I think the obvious (and pre-approved) change here is to just eliminate
> the initializer for p which uses recog_data.constraints.

I did some investigation.  The dead initializer was a part of initial LRA
commit (in gcc-4.8). Probably it is some leftover from experimental LRA code
which was changed very actively during its initial development.

I am agree the dead initializer should be removed.

[Bug target/91009] Bug with future PowerPC patches with lfiwax/lfiwzx (related to PR 90822)

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Wed Jun 26 23:02:47 2019
New Revision: 272719

URL: https://gcc.gnu.org/viewcvs?rev=272719=gcc=rev
Log:
PR 91009

Modified:
branches/ibm/pcrel-trunk/gcc/ChangeLog.meissner
branches/ibm/pcrel-trunk/gcc/config/rs6000/rs6000.md

[Bug tree-optimization/90328] [7/8 Regression] Wrong loop distribution with aliasing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

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

[Bug libstdc++/91007] stable_sort segfaults on -O3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||needs-bisection, wrong-code
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
The crash started with r260383:

Aliasing 'this' in a C++ constructor

2018-05-18  Marc Glisse  

PR c++/82899
gcc/
* tree-ssa-structalias.c (create_variable_info_for_1): Extra
argument.
(intra_create_variable_infos): Handle C++ constructors.

gcc/testsuite/
* g++.dg/pr82899.C: New testcase.


And was fixed on trunk by r270906

PR tree-optimization/90328
* tree-data-ref.h (dr_may_alias_p): Pass in the actual loop nest.
* tree-data-ref.c (dr_may_alias_p): Check whether the clique
is valid in the loop nest before using it.
(initialize_data_dependence_relation): Adjust.
* graphite-scop-detection.c (build_alias_set): Pass the SCOP
enclosing
loop as loop-nest to dr_may_alias_p.

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

It's also fixed on gcc-9-branch, presumably by the backport of that patch, as
r271995 (although I didn't verify that explicitly).

So this is a dup of PR 90328.

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

[Bug middle-end/90963] [10 Regression] FAIL: gcc.c-torture/execute/built-in-setjmp.c execution test

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2019-06-24 12:59 p.m., wilco at gcc dot gnu.org wrote:
> Looking into this, pa.md is one of a few targets which defines 
> builtin_longjmp.
> This subtracts 8 from the loaded frame pointer, but that's now wrong since the
> hard frame pointer is store. So this also needs to be updated like
> nonlocal_goto:
>
> --- a/gcc/config/pa/pa.md
> +++ b/gcc/config/pa/pa.md
> @@ -8713,7 +8710,7 @@ add,l %2,%3,%3\;bv,n %%r0(%3)"
>emit_insn (gen_blockage ());
>emit_clobber (hard_frame_pointer_rtx);
>emit_clobber (frame_pointer_rtx);
> -  emit_move_insn (hard_frame_pointer_rtx, plus_constant (Pmode, fp, -8));
> +  emit_move_insn (hard_frame_pointer_rtx, fp);
>
>emit_use (hard_frame_pointer_rtx);
>emit_use (stack_pointer_rtx);
>
> After this setjmp-1.c looks correct:
>
> sub2:
> .PROC
> .CALLINFO FRAME=64,NO_CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=3
> .ENTRY
> copy %r3,%r1
> stw %r2,-20(%r30)
> copy %r30,%r3
> stwm %r1,64(%r30)
> addil LR'buf-$global$,%r27
> ldo RR'buf-$global$(%r1),%r28
> ldw 0(%r28),%r19  // load hard frame pointer
> ldw 4(%r28),%r1
> ldw 8(%r28),%r30
> copy %r19,%r3// assign hfp with offset 0
> be,n 0(%sr4,%r1)
>
>
> main
> ...
> stw %r30,8(%r1)
> stw %r28,4(%r1)
> ldo 512(%r30),%r30
> depi 0,31,3,%r20
> stw %r3,0(%r1) // store hard frame pointer
> ldi 0,%r28
> ldi 115,%r21
>
> I can commit this if you like or do you want to test it first?
The change fixes all the test failures on hppa-unknown-linux-gnu.

Would you please commit with comment update.

Thanks,
Dave

[Bug target/90822] Remove PowerPC lfiwax and lfiwzx patterns

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
I split part of the issue off into a separate bug (PR target/91009).

[Bug target/91009] Bug with future PowerPC patches with lfiwax/lfiwzx (related to PR 90822)

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-26
 Ever confirmed|0   |1

[Bug target/91009] New: Bug with future PowerPC patches with lfiwax/lfiwzx (related to PR 90822)

[meissner at gcc dot gnu.org]

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

Bug ID: 91009
   Summary: Bug with future PowerPC patches with lfiwax/lfiwzx
(related to PR 90822)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

In bug 90822, I opened the bug to clean up some old code.

This bug is separated from that bug, to track the original issue that got me
looking at the lfiwax/lfiwzx patterns.  PR 90822 will remain to be the cleanup
items for the patterns.

In working on some patches for a future PowerPC processor, I discovered that
the lfiwax and lfiwzx patterns could cause an abort.

To understand this, the floatsi{sf,df}2_lfiwax pattern is generated by the
normal floatsi{sf,df}2 insn during expansion.

(define_insn_and_split "floatsi2_lfiwax"
  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=")
(float:SFDF (match_operand:SI 1 "nonimmediate_operand" "r")))
   (clobber (match_scratch:DI 2 "=wa"))]
  "TARGET_HARD_FLOAT && TARGET_LFIWAX
   &&  && can_create_pseudo_p ()"
  "#"
  ""
  [(pc)]
{
  rtx dest = operands[0];
  rtx src = operands[1];
  rtx tmp;

  if (!MEM_P (src) && TARGET_POWERPC64 && TARGET_DIRECT_MOVE)
tmp = convert_to_mode (DImode, src, false);
  else
{
  tmp = operands[2];
  if (GET_CODE (tmp) == SCRATCH)
tmp = gen_reg_rtx (DImode);
  if (MEM_P (src))
{
  src = rs6000_force_indexed_or_indirect_mem (src);
  emit_insn (gen_lfiwax (tmp, src));
}
  else
{
  rtx stack = rs6000_allocate_stack_temp (SImode, false, true);
  emit_move_insn (stack, src);
  emit_insn (gen_lfiwax (tmp, stack));
}
}
  emit_insn (gen_floatdi2 (dest, tmp));
  DONE;
}
  [(set_attr "length" "12")
   (set_attr "type" "fpload")])

In the future patches, there is a new "prefixed" attribute that determines if
an insn is prefixed or not.  The GCC machinery calls extract_constrain_insn on
the insn before the first split in processing the "prefixed" attribute.

Unfortunately if you use the -mno-vsx option (which some of the tests in the
testsuite do), the only alternative ("wa") is not valid with the -mno-vsx
option.

As a quick fix, the solution is simple, add an alternative in the split
patterns that just uses "d" and not "wa", or eliminate the alternatives (since
the pattern is split before register allocation).

Ultimately the whole section should be cleaned up (i.e. PR 90822), but at the
very least, we will need the small change as the 'future' cpu changes are put
into the compiler.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Wed Jun 26 21:36:27 2019
New Revision: 272717

URL: https://gcc.gnu.org/viewcvs?rev=272717=gcc=rev
Log:
PR tree-optimization/90883
* tree-ssa-alias.c (stmt_kills_ref_p): Handle BUILT_IN_CALLOC.
* tree-ssa-dse.c: Update various comments to distinguish between
dead and redundant stores.
(initialize_ao_ref_for_dse): Handle BUILT_IN_CALLOC.
(dse_optimize_redundant_stores): New function.
(delete_dead_or_redundant_call): Renamed from delete_dead_call.
Distinguish between dead and redundant calls in dump output.  All
callers updated.
(delete_dead_or_redundant_assignment): Similarly for assignments.
(dse_optimize_stmt): Handle _CHK variants.  For statements which
store 0 into multiple memory locations, try to prove a subsequent
store is redundant.

PR tree-optimization/90883
* g++.dg/tree-ssa/pr90883.C: New test.
* gcc.dg/tree-ssa/ssa-dse-36.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr90883.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-36.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-dse.c

[Bug c++/55442] G++ uses up all my RAM when compiling a constexpr with exponential call graph

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/90975] A suspicious code in optabs.c since r177852

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
Agreed.  Given the usual bootstrap & regression test, consider a patch to use
xop0/xop1 in the calls to create_convert_operand_from as pre-approved.

[Bug rtl-optimization/90976] A suspicious code in lra.c since r177852

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-06-24 00:00:00 |2019-06-26
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
Agreed, looks suspicious.  From my reading of the code, I think using
"constraints" rather than "recog_data.constraints" is correct.

The  prior call to decode_asm_operands should have set up the constraint
strings into "constraints".  I don't think "recog_data.constraints" will
necessarily have the right bits because the insn was not recognized (it's an
asm after all :-)

So I think the obvious (and pre-approved) change here is to just eliminate the
initializer for p which uses recog_data.constraints.

[Bug debug/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

  Component|c++ |debug

--- Comment #5 from Mark Wielaard  ---
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01682.html

[Bug c++/91008] New: error redeclaring the same type involving a non-type template argument

[msebor at gcc dot gnu.org]

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

Bug ID: 91008
   Summary: error redeclaring the same type involving a non-type
template argument
   Product: gcc
   Version: 9.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: ---

The three typedefs below all define the same type yet they are rejected.

$ cat t.C && gcc -O2 -c -Wall -Wpedantic -std=c++2a t.C
struct A
{
  constexpr A (int i = 0): i (i + 1) { }
  int i;
};

struct B { A a[2]; };

template  struct X { };

typedef X XB;
typedef X XB;
typedef X XB;

t.C:12:19: error: conflicting declaration ‘typedef struct X XB’
   12 | typedef X XB;
  |   ^~
t.C:11:17: note: previous declaration as ‘typedef struct X XB’
   11 | typedef X XB;
  | ^~
t.C:13:22: error: conflicting declaration ‘typedef struct X XB’
   13 | typedef X XB;
  |  ^~
t.C:11:17: note: previous declaration as ‘typedef struct X XB’
   11 | typedef X XB;
  | ^~

[Bug libstdc++/91007] New: stable_sort segfaults on -O3

[barry.revzin at gmail dot com]

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

Bug ID: 91007
   Summary: stable_sort segfaults on -O3
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced from StackOverflow (https://stackoverflow.com/q/56779605/2069064):

#include 
#include 

int main() {
using V = std::vector;
std::vector conns{
V{0,2},
V{0,2},
V{0,2},
};  

std::stable_sort(conns.begin(), conns.end(),
[](const V& a, const V& b){ 
return a[0] < b[0];
}
);  
}

On gcc 9.1, compiled with -O3, this segfaults. With -O2 and under, it's fine.
On gcc 8.3, it's fine.

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[mimomorin at gmail dot com]

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

--- Comment #15 from Michel Morin  ---
> Backporting to stable branches should not be done as a way to find bugs.

Makes sense. I stand corrected.

> The patch affects all targets, not just the ones currently using a PRNG, so 
> it's not as simple as just saying it must be better.

Ah, I didn't notice that.

> I'm afraid you aren't making a very good case for backporting it.

I just felt that waiting for GCC-10 (i.e. about a year) is a bit too long.
(Some of my colleagues suffer from this issue; so I hoped that this fix gets
released earlier... but anyway, I'll probably provide them a wrapper to
workaround the issue.)

[Bug debug/82738] [meta-bug] issues with the -Og optimization level

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Richard Sandiford has a series of patches radically overhauling how -Og works:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html
cc-ing him so he can comment on how it affects some of the bugs listed as
dependencies here.

[Bug target/89021] Implement mmintrin.h in SSE

[uros at gcc dot gnu.org]

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

--- Comment #55 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jun 26 19:12:27 2019
New Revision: 272711

URL: https://gcc.gnu.org/viewcvs?rev=272711=gcc=rev
Log:
PR target/89021
* config/i386/i386.c (ix86_autovectorize_vector_sizes):
Autovectorize 8-byte vectors for TARGET_MMX_WITH_SSE.

testsuite/ChangeLog:

PR target/89021
* lib/target-supports.exp (available_vector_sizes)
<[istarget i?86-*-*] || [istarget x86_64-*-*]>: Add
64-bit vectors for !ia32.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Backporting to stable branches should not be done as a way to find bugs. Quite
the opposite!

The patch affects all targets, not just the ones currently using a PRNG, so
it's not as simple as just saying it must be better.

I'm afraid you aren't making a very good case for backporting it.

[Bug c++/91006] [10 Regression] Several test suite fails on *darwin* after r272618

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target||*-*-darwin*
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2019-06-26
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.0
  Known to fail||10.0

[Bug c++/91006] New: [10 Regression] Several test suite fails on *darwin* after r272618

[iains at gcc dot gnu.org]

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

Bug ID: 91006
   Summary: [10 Regression] Several test suite fails on *darwin*
after r272618
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

After r272618, the following tests fail for i686,x86-64-*darwin*.
flifetime-dse2.C (m32, m64)
Warray-bounds-4.C (m32, m64)
ivopts-3.C (m64).

The problem is occurring it seems quite early in the middle end (already
complete before we get to RTL expansion)

Th problem also manifests on a stage1 FE, so it ought to be possible to
investigate on a cross.

=

I did some comparisions of the IL for flifetime-dse2.C between before/after and
against a linux version.

Up to flifetime-dse2.C.021t.nothrow the IL looks similar for all three cases
...

At flifetime-dse2.C.023t.fixup_cfg2  there is a divergence:

(OK):

main ()
{
  struct A * ap;
  int ar[1];
  int _1;
  int _2;
  void * _6;
  int _12;

   :
  ar[0] = 42;
  _6 = _ZnwmPv.isra.0 ();
  A::A (_6);
  ap_8 = _6;
  _1 = ap_8->i;
  if (_1 == 42)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_abort ();

   :
  ap_8->i = 42;
  A::~A (ap_8);
  _2 = ar[0];
  if (_2 == 42)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_abort ();

   :
  ar ={v} {CLOBBER};
  _12 = 0;
  return _12;

}

(Bad):

;; Function main (main, funcdef_no=7, decl_uid=2353, cgraph_uid=8,
symbol_order=7)

main ()
{
  struct A * ap;
  int ar[1];
  int _1;
  int _2;
  void * _6;
  int _12;

   :
  ar[0] = 42;
  _6 = _ZnwmPv.isra.0 ();
  A::_ZN1AC1Ev.isra.0 ();
  ap_8 = _6;
  _1 = ap_8->i;
  if (_1 == 42)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_abort ();

   :
  ap_8->i = 42;
  A::_ZN1AD1Ev.isra.0 ();
  _2 = ar[0];
  if (_2 == 42)
goto ; [INV]
  else
goto ; [INV]

   :
  __builtin_abort ();

   :
  ar ={v} {CLOBBER};
  _12 = 0;
  return _12;

}

I can attach the tree dumps / or more comparisons etc. as needed.

[Bug fortran/91003] [10 Regression] ICE when compiling LAPACK (CGEGV) with optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
Summary|ICE when compiling LAPACK   |[10 Regression] ICE when
   |(CGEGV) with optimization   |compiling LAPACK (CGEGV)
   ||with optimization

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase for -Ofast:
  SUBROUTINE FOO(N, A, B, C, D, E, F, G)
  COMPLEX A(*)
  LOGICAL H
  INTEGER G
  REAL I, C, J, F, F1, F2, K, E, L, M, B, D
  DO JC = 1, N
K = F*REAL(A(JC))
Z = F*AIMAG(A(JC))
H = .FALSE.
L = G
IF(ABS(Z).LT.D .AND. I.GE. MAX(D, B*C, B*J)) THEN
  H = .TRUE.
  L = (D / F1) / MAX(D, F2*I)
END IF
IF(ABS(K).LT.D .AND. C.GE. MAX(D, B*I, B*J)) THEN
  L = MAX(L, (D / F1) / MAX(D, F2*C))
END IF
IF(ABS(E).LT.D .AND. J.GE. MAX(D, B*C, B*I)) THEN
  H = .TRUE.
  L = MAX(L, (D / BNRM1) / MAX(D, BNRM2*J))
END IF
IF(H) THEN
  M = (L*D)*MAX(ABS(K), ABS(Z), ABS(E))
END IF
IF(H) THEN
  K = (L*REAL(A(JC)))*F
  Z = (L*AIMAG(A(JC)))*F
END IF
A(JC) = CMPLX(K, Z)
  END DO
  END

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[mimomorin at gmail dot com]

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

--- Comment #13 from Michel Morin  ---
Pushing this into GCC-9 might help finding bugs (if there are some) and 
I think having non-deterministic `random_device` _with possible small bugs_
would be more important than having deterministic one.

[Bug c++/91000] noexcept in constexpr context with std=c++11 and std=c++14

[federico.kircheis at gmail dot com]

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

--- Comment #4 from Federico Kircheis  ---
> As I explained in PR 87603 comment 6, and as the patch
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00466.html says, the old
> behaviour triggers unwanted instantiations and so causes valid code to not
> compile.

Ok, I did not really understood that part of the discussion, I thought it was
an issue in the code.
The comment states explicitly that the code fails when compiling with c++2a,
says nothing about c++11 and c++14 (of course I've could have tested it, my
fault).

> The old behaviour was not consistently implemented by other compilers so was
> never portable anyway.

Actually the old behaviour is implemented by GCC<9, MSVC and ICC, clang was the
notable exception on my list.
Testing with compiler explorer, every compiler that understands c++14 except
from gcc9, clang, elcc and zapcc can compile the sample.
So it seems to me that the majority got it right.

There are bugs where every compiler behaves differently, so it does not seem
like a big portability issue.

> The C++ committee decided that the old behaviour was
> not desirable, and removed it.

They removed it from c++17, not from the previous standards, and it has been
more by accident than by design (at least that's what I understood, also stated
in https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00466.html).

> How many reasons do you need?

Sorry, but I could not find *the* reason why the behaviour has been changed for
the previous standards.
The discussion starts with the c++17 change, then shows a failing sample in
c++2a, and then it's fixed retroactively for every standard.

Since now I've understood that PR 87603 comment 6 is also valid for previous
standards I suppose that that's why you meant that the old behaviour is not
consistent with the standards.
(For the record: it seems that no compiler can compile the code in PR 87603
comment 6 with c++14, so the behaviour is consistent with GCC<9).

[Bug fortran/91003] ICE when compiling LAPACK (CGEGV) with optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r270941. Just -Ofast is needed on x86_64-linux.

[Bug other/89863] [meta-bug] Issues that cppcheck finds that gcc misses

[egallager at gcc dot gnu.org]

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

--- Comment #1 from Eric Gallager  ---
I see Martin Liska added a bunch of bugs found by the clang static analyzer as
blocking this... Martin, did you verify that cppcheck catches them, too, or are
we using this bug for static analyzers in general now? It's ok if it's the
latter, we'll just need to update the title...

[Bug c/91005] Cannot put a nested function into a different section

[pipcet at gmail dot com]

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

--- Comment #1 from pipcet at gmail dot com ---
Created attachment 46524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46524=edit
illustrative patch

[Bug c/91005] New: Cannot put a nested function into a different section

[pipcet at gmail dot com]

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

Bug ID: 91005
   Summary: Cannot put a nested function into a different section
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pipcet at gmail dot com
  Target Milestone: ---

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

Compiling the attached file fails:

/usr/bin/ld: /tmp/ccuSWyMB.o: in function `main':
inner-section.c:(.text+0x5): undefined reference to `inner.1911'
collect2: error: ld returned 1 exit status

I've looked into the problem a little, and it seems that the C frontend sets
DECL_CONTEXT only after the section attribute is handled, so this code

  if (DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL)
{
  node->origin = cgraph_node::get_create (DECL_CONTEXT (decl));
  node->next_nested = node->origin->nested;
  node->origin->nested = node;
}

in cgraph.c is run early, when DECL_CONTEXT isn't yet set, so the function is
never added to the nested list.

I might be wrong, though.

The attached patch seems to fix this specific example on this specific machine,
but I'm almost certain it'll turn out to be wrong somehow.

[Bug other/91004] New: [10 regression] Excess errors in g++.dg/torture/pr34850.C starting with r272688

[seurer at gcc dot gnu.org]

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

Bug ID: 91004
   Summary: [10 regression] Excess errors in
g++.dg/torture/pr34850.C starting with r272688
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

testgcc: Tried 272688

make -k check-gcc RUNTESTFLAGS=dg-torture.exp=g++.dg/torture/pr34850.C

FAIL: g++.dg/torture/pr34850.C   -O2  (test for excess errors)
FAIL: g++.dg/torture/pr34850.C   -O3 -g  (test for excess errors)
FAIL: g++.dg/torture/pr34850.C   -Os  (test for excess errors)
FAIL: g++.dg/torture/pr34850.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/torture/pr34850.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)


Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr34850.C:16:29:
warning: call to '__warn_memset_zero_len' declared with attribute warning: 
[-Wattribute-warning]

[Bug libstdc++/90634] filesystem::path insane memory allocations

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Author: redi
Date: Wed Jun 26 15:12:15 2019
New Revision: 272697

URL: https://gcc.gnu.org/viewcvs?rev=272697=gcc=rev
Log:
PR libstdc++/90634 reduce allocations in filesystem::path construction

Backport from mainline
2019-05-28  Jonathan Wakely  

PR libstdc++/90634
* include/experimental/bits/fs_path.h (path::path(path&&)): Only call
_M_split_cmpts() for a path with multiple components.
(path::_S_is_dir_sep()): Add missing 'static' keyword to function.
* src/filesystem/path.cc (path::_M_split_cmpts()): Count number of
components and reserve space in vector. Return early when there is
only one component.
* testsuite/experimental/filesystem/path/construct/90634.cc: New test.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/experimental/filesystem/path/construct/90634.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/experimental/bits/fs_path.h
branches/gcc-7-branch/libstdc++-v3/src/filesystem/path.cc

[Bug fortran/91003] New: ICE when compiling LAPACK (CGEGV) with optimization

[kristopher.kuhlman at gmail dot com]

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

Bug ID: 91003
   Summary: ICE when compiling LAPACK (CGEGV) with optimization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristopher.kuhlman at gmail dot com
  Target Milestone: ---

Latest version of gfortran gives error and ICE when compiling CGEGV from LAPACK
using the following command line (from petsc build). 

home/klkuhlm/src/petsc/tgcc-c-perf/bin/mpif90 -c -Wall -ffree-line-length-0
-Wno-unused-dummy-argument -Ofast -march=native 

This same thing worked with the trunk version of the compiler from a month or
so ago.  It also works with this same compiler without optimizations turned on.

Kris

--

cgegv.f:282:0:

  282 |   SUBROUTINE CGEGV( JOBVL, JOBVR, N, A, LDA, B, LDB, ALPHA, BETA,
  | 
Error: type mismatch in ‘vec_cond_expr’
vector(8) unsigned int
vector(8) 
vector(8) 
vect_ilimit_186.167_852 = VEC_COND_EXPR ;
cgegv.f:282:0: Error: type mismatch in ‘vec_cond_expr’
vector(8) unsigned int
vector(8) 
vector(8) 
vect_ilimit_186.167_853 = VEC_COND_EXPR ;
during GIMPLE pass: vect
cgegv.f:282:0: internal compiler error: verify_gimple failed
0xe3bcd1 verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.c:5426
0xd19cbf execute_function_todo
../../gcc-trunk/gcc/passes.c:1963
0xd1abee execute_todo
../../gcc-trunk/gcc/passes.c:2017
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/91000] noexcept in constexpr context with std=c++11 and std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Federico Kircheis from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > This would be more appropriate on the gcc-help mailing list, as you're
> > asking a question not reporting a bug.
> > 
> > The behaviour is as intended, for all -std versions. The standard was
> > changed to remove this feature and no other compilers implemented it anyway.
> 
> Well I'm actually reporting a regression, since g++ is not c++11 and c++14
> standard compliant and it's behaviour changed from previous versions.

And as you already know, this is the intended behaviour.

> I've discovered through https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603
> that it was not by accident (I guess with dialect are meant the different
> c++ versions), but there is no motivation why the regression was introduced
> by design.

As I explained in PR 87603 comment 6, and as the patch
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00466.html says, the old
behaviour triggers unwanted instantiations and so causes valid code to not
compile.

The old behaviour was not consistently implemented by other compilers so was
never portable anyway. The C++ committee decided that the old behaviour was not
desirable, and removed it.

How many reasons do you need?

[Bug c++/65143] [C++11] missing devirtualization for virtual base in "final" classes

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  ---
Jason's r272656 fixes the testcases here too. Again, I suspect that
corresponding testcases involving user-defined operators are not fixed. If
nobody beats me to it I will add fixed testcases and add an example of the
latter.

[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241

[kristopher.kuhlman at gmail dot com]

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

--- Comment #10 from Kris  ---
that fixed the problem for me. thanks!

[Bug c++/91000] noexcept in constexpr context with std=c++11 and std=c++14

[federico.kircheis at gmail dot com]

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

--- Comment #2 from Federico Kircheis  ---
(In reply to Jonathan Wakely from comment #1)
> This would be more appropriate on the gcc-help mailing list, as you're
> asking a question not reporting a bug.
> 
> The behaviour is as intended, for all -std versions. The standard was
> changed to remove this feature and no other compilers implemented it anyway.

Well I'm actually reporting a regression, since g++ is not c++11 and c++14
standard compliant and it's behaviour changed from previous versions.

I've discovered through https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603 that
it was not by accident (I guess with dialect are meant the different c++
versions), but there is no motivation why the regression was introduced by
design.

[Bug c++/91002] New: ICE in make_ssa_name_fn, at tree-ssanames.c:271

[ignat.loskutov at gmail dot com]

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

Bug ID: 91002
   Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:271
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ignat.loskutov at gmail dot com
  Target Milestone: ---

The following piece of code leads to ICE in make_ssa_name_fn, at
tree-ssanames.c:271 when trying to compile with `g++ -O3` (all versions from
7.1 to trunk seem to be affected, the error message applies to 9.1):

namespace my {

int foo() { return 1; }

struct s {

  void bar(int i) {
auto *objects = reinterpret_cast(storage);
void *ptr = [i];
  }

  void baz();

  char *storage;
};

void s::baz() {
  bar(0);
}

} // namespace my


Compiler Explorer link reproducing the issue:
https://godbolt.org/z/srALGm

[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #9 from Nathan Sidwell  ---
Fixed r272692.

[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241

[nathan at gcc dot gnu.org]

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

--- Comment #8 from Nathan Sidwell  ---
Author: nathan
Date: Wed Jun 26 12:58:39 2019
New Revision: 272692

URL: https://gcc.gnu.org/viewcvs?rev=272692=gcc=rev
Log:
[PR preprocessor/90927] Fixe dependency output

https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01664.html
libcpp/
PR preprocessor/90927
* mkdeps.c (mkdeps::vec::operator[]): Add non-const variant.
(deps_add_target): Deal with out of order unquoted targets.

gcc/testsuite/
* c-c++-common/pr90927.c: New.

Added:
trunk/gcc/testsuite/c-c++-common/pr90927.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/mkdeps.c

[Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
To wit:

bool f ()
{ enum : int a; }

we don't ICE on it but we accept it, we should reject it.

[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241

[kristopher.kuhlman at gmail dot com]

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

--- Comment #7 from Kris  ---
Created attachment 46522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46522=edit
petsc source file that ICE happens on

[Bug ipa/90939] ICE in meet_with, at ipa-cp.c:1073

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
Author: jamborm
Date: Wed Jun 26 12:04:08 2019
New Revision: 272689

URL: https://gcc.gnu.org/viewcvs?rev=272689=gcc=rev
Log:
[PR 90939] Remove outdated assert in ipcp_bits_lattice::meet_with

2019-06-26  Martin Jambor  

PR ipa/90939
* ipa-cp.c (ipcp_bits_lattice::meet_with): Remove assert.

testsuite/
* g++.dg/lto/pr90939_[01].C: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/lto/pr90939_0.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/lto/pr90939_1.C
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/ipa-cp.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/90982] [9 Regression] ICE in make_decl_rtl, at varasm.c:1344

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
   |make_decl_rtl, at   |make_decl_rtl, at
   |varasm.c:1344   |varasm.c:1344
  Known to fail|10.0|

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/90982] [9/10 Regression] ICE in make_decl_rtl, at varasm.c:1344

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Jun 26 11:16:56 2019
New Revision: 272688

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

PR ipa/90982
* tree-inline.c (remap_ssa_name): Copy SSA range info.

* g++.dg/torture/pr90982.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr90982.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/90998] [9/10 Regression] ICE (segfalut) in gcc/cp/call.c compare_ics() with -std=c++17

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[Regression] ICE (segfalut) |[9/10 Regression] ICE
   |in gcc/cp/call.c|(segfalut) in gcc/cp/call.c
   |compare_ics() with  |compare_ics() with
   |-std=c++17  |-std=c++17

[Bug c++/90997] [9/10 Regression] ICE on a memset in a template in tsubst_copy_and_build, at cp/pt.c:18480

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |9.2

[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-26
 Ever confirmed|0   |1

[Bug rtl-optimization/90756] g++ ICE in convert_move, at expr.c:218 on i686 and s390x

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Hand reduced:
template  struct A {
  typedef T __attribute__((vector_size(N * sizeof(T a;
};
template  using U = typename A::a;
using B = U<4, float>;
using C = U<4, unsigned long long>;
using D = U<4, short>;
B z;
template  void foo (U, T);
template  T bar (U);
D y(B);
template  T baz (U);
int x;

void
qux ()
{
  B n = z, b = z;
  while (true)
switch (x)
  {
  case 0 ... 15: n = baz (1);
  case 16: { B o = n; n = b; b = o; }
  case 17 ... 46: { D u = y(b); C v = bar (u); foo (qux, v); }
  }
}

[Bug rtl-optimization/90756] g++ ICE in convert_move, at expr.c:218 on i686 and s390x

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #5)
> The r228175
> (promote_ssa_mode): Disregard BLKmode from promote_decl, and
> 
> bypass TYPE_MODE to get the actual vector mode. 
> 
> 
> +  /* Bypass TYPE_MODE when it maps vector modes to BLKmode.  */
> 
> +  if (mode == BLKmode) 
> 
> +{  
> 
> +  gcc_assert (VECTOR_TYPE_P (type));   
> 
> +  mode = type->type_common.mode;   
> 
> +}  
> 
> +   
> 
> 
> change looks highly suspicious, that introduces in the IL vector modes that
> aren't really supported.  If that was done because some SSA_NAMEs might have
> underlying decl that has DECL_MODE, I'd say we should either treat all
> DECL_MODE similarly to TYPE_MODE, or add more hacks where for vector type
> decls we just ignore DECL_MODE and use corresponding TYPE_MODE (I think we
> have quite a few of those already).

Indeed.  We probably need to differentiate callers of promote_ssa_mode.
Like the one in get_temp_reg seems to deal with BLKmode but AFAICS
promote_ssa_mode will never return BLKmode itself?  Thus

Index: gcc/tree-outof-ssa.c
===
--- gcc/tree-outof-ssa.c(revision 272616)
+++ gcc/tree-outof-ssa.c(working copy)
@@ -652,9 +652,10 @@ get_temp_reg (tree name)
 {
   tree type = TREE_TYPE (name);
   int unsignedp;
-  machine_mode reg_mode = promote_ssa_mode (name, );
-  if (reg_mode == BLKmode)
+  if (TYPE_MODE (type) == BLKmode)
 return assign_temp (type, 0, 0);
+  machine_mode reg_mode = promote_ssa_mode (name, );
+  gcc_assert (reg_mode != BLKmode);
   rtx x = gen_reg_rtx (reg_mode);
   if (POINTER_TYPE_P (type))
 mark_reg_pointer (x, TYPE_ALIGN (TREE_TYPE (type)));

the original change may have been motivated by ABI boundary issues
of caller/callee mismatching in what ISA they support despite having
arguments whose ABI depend on that?

[Bug rtl-optimization/90756] g++ ICE in convert_move, at expr.c:218 on i686 and s390x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
The r228175
(promote_ssa_mode): Disregard BLKmode from promote_decl, and
bypass TYPE_MODE to get the actual vector mode. 

+  /* Bypass TYPE_MODE when it maps vector modes to BLKmode.  */
+  if (mode == BLKmode) 
+{  
+  gcc_assert (VECTOR_TYPE_P (type));   
+  mode = type->type_common.mode;   
+}  
+   

change looks highly suspicious, that introduces in the IL vector modes that
aren't really supported.  If that was done because some SSA_NAMEs might have
underlying decl that has DECL_MODE, I'd say we should either treat all
DECL_MODE similarly to TYPE_MODE, or add more hacks where for vector type decls
we just ignore DECL_MODE and use corresponding TYPE_MODE (I think we have quite
a few of those already).

[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #2 from Uroš Bizjak  ---
This is middle-end problem; middle-end is expanding to:

1: NOTE_INSN_DELETED
3: NOTE_INSN_BASIC_BLOCK 2
2: NOTE_INSN_FUNCTION_BEG
5: di:DI=[`d']
6: bp:DI=[const(`d'+0x8)]
7: sp:DI=[const(`d'+0x10)]
8: st:DI=[const(`d'+0x18)]
9: st(1):DI=[const(`d'+0x20)]
   10: st(2):DI=[const(`d'+0x28)]
   11: st(3):DI=[const(`d'+0x30)]
   12: st(4):DI=[const(`d'+0x38)]
   13: st(5):DI=[const(`d'+0x40)]
   14: st(6):DI=[const(`d'+0x48)]
   15: st(7):DI=[const(`d'+0x50)]
   16: argp:DI=[const(`d'+0x58)]
   17: flags:DI=[const(`d'+0x60)]
   18: fpsr:DI=[const(`d'+0x68)]
   19: frame:DI=[const(`d'+0x70)]
   20: xmm0:DI=[const(`d'+0x78)]
   21: ax:QI=0
   22: call [`f'] argc:0
  REG_CALL_DECL `f'
   23: barrier

The number of insns depend on the parameter of the aligned(...) attribute.
having "aligned(512)", we get loads all the way to k0 mask register.

Please note that the above are just consecutive registers from REG_ALLOC_ORDER.

[Bug tree-optimization/90978] A suspicious code in df-scan.c since r160348

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
I doubt -O3 would help much, a significant amount of tests is already with -O3.
As Martin's pages show, the less covered areas is e.g. old reload (you need
some target that doesn't use LRA), driver (say for -march=native, that is hard
to test unless you run it on a lot of different hw), some features that require
other tools (e.g. autofdo), some features that require specially configured
compiler and hw (e.g. offloading).

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
> So it is inliner substituting the return slot which happens to be
> clobber? 

Yes.

> It makes sense but I wonder how this worked w/o the patch.
> > #10 0x010f9dd5 in remap_gimple_stmt (stmt=0x775311e0,
> > id=0x7fffd6d0) at /home/marxin/Programming/gcc/gcc/tree-inline.c:1896

Before the patch we used to have:
  MEM[(struct  &)&] ={v} {CLOBBER};

while now we have a nicer clobber:
   ={v} {CLOBBER};

That's the difference.

> 
> remap_gimple_stmt already has some code to drop clobbers after
> substitution
> 
>   /* For *ptr_N ={v} {CLOBBER}, if ptr_N is SSA_NAME defined
> 
>  in a block that we aren't copying during tree_function_versioning, 
> 
>  just drop the clobber stmt.  */
> 
>   if (id->blocks_to_copy && gimple_clobber_p (stmt))
> 
> {   
> 
>   tree lhs = gimple_assign_lhs (stmt);  
> 
>   if (TREE_CODE (lhs) == MEM_REF
> 
>   && TREE_CODE (TREE_OPERAND (lhs, 0)) == SSA_NAME) 
> 
> 
> perhaps we need to care about the retval here.

I can confirm the following patch works:

diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 2de5e22f10f..04e60d1c9b8 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1734,10 +1734,11 @@ remap_gimple_stmt (gimple *stmt, copy_body_data *id)
   /* For *ptr_N ={v} {CLOBBER}, if ptr_N is SSA_NAME defined
 in a block that we aren't copying during tree_function_versioning,
 just drop the clobber stmt.  */
-  if (id->blocks_to_copy && gimple_clobber_p (stmt))
+  if (gimple_clobber_p (stmt))
{
  tree lhs = gimple_assign_lhs (stmt);
- if (TREE_CODE (lhs) == MEM_REF
+ if (id->blocks_to_copy
+ && TREE_CODE (lhs) == MEM_REF
  && TREE_CODE (TREE_OPERAND (lhs, 0)) == SSA_NAME)
{
  gimple *def_stmt = SSA_NAME_DEF_STMT (TREE_OPERAND (lhs, 0));
@@ -1746,6 +1747,8 @@ remap_gimple_stmt (gimple *stmt, copy_body_data *id)
gimple_bb (def_stmt)->index))
return NULL;
}
+ else if (TREE_CODE (lhs) == RESULT_DECL)
+   return NULL;
}

   if (gimple_debug_bind_p (stmt))

However, I guess we want to preserve clobber that will not end up as a
component ref, right?

[Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
By the way, in general terms, I'm not sure I agree that a snippet which was
accepts-invalid before a given date and ice-on-invalid-code after qualifies as
a proper regression. You see, even the Bugzilla fields don't make much sense:
7.4.0 isn't known to work!

[Bug tree-optimization/90978] A suspicious code in df-scan.c since r160348

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to David Binderman from comment #9)
> (In reply to Martin Liška from comment #8)
> > I'm running that once a week:
> > https://users.suse.com/~mliska/lcov/
> 
> Great ! 
> 
> I'll have a go at duplicating your results, then have a go at extending
> the test case coverage.
> 
> A pretty obvious first question would be: How much better test coverage
> would you get if you ran the test cases with -O3, something like this:
> 
> [dcb30@localhost trunk]$ cd gcc/testsuite/
> [dcb30@localhost testsuite]$ for i in `find . -name \*.c -print | sort`
> > do
> > echo $i
> > $TEST_COMPILER -c -O3 -Wall $i
> > done

Good question!

> 
> I am assuming that there is no easy flag on the testsuite to compile
> everything with -O3 instead of whatever flags each test case wants.

For a torture test-cases it can help. Some other tests have hardcoded
dg-compile options intentionally to scan a pattern.

[Bug tree-optimization/90978] A suspicious code in df-scan.c since r160348

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
(In reply to Martin Liška from comment #8)
> I'm running that once a week:
> https://users.suse.com/~mliska/lcov/

Great ! 

I'll have a go at duplicating your results, then have a go at extending
the test case coverage.

A pretty obvious first question would be: How much better test coverage
would you get if you ran the test cases with -O3, something like this:

[dcb30@localhost trunk]$ cd gcc/testsuite/
[dcb30@localhost testsuite]$ for i in `find . -name \*.c -print | sort`
> do
> echo $i
> $TEST_COMPILER -c -O3 -Wall $i
> done

I am assuming that there is no easy flag on the testsuite to compile
everything with -O3 instead of whatever flags each test case wants.

[Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #2 from Paolo Carlini  ---
As far as I can see, before r256821, say in gcc-7, we simply accepted the
snippet, thus it was an accepts-invalid, and that's why it regressed, we
completely miss an appropriate diagnostic and the gcc_assert (seen_error ())
triggers.

[Bug c++/90996] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:13495

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'm afraid I'm lost here.
replace_placeholders is called here on the outer CONSTRUCTOR, where it doesn't
dive into the nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY while previously it did,
and then once again with obj being ARRAY_REF c[0].b[0] which has int type, but
the PLACEHOLDER_EXPR has type S for some reason.
I think some replace_placeholders call somewhere where we process the inner
constructor is needed, i.e. initializer for c[0] rather than whole c, but have
no idea where that should be.  The first replace_placeholders call is from
store_init_value on the CONTRUCTOR for the whole c and the other is from
cp_gimplify_init_expr.  Jason, could you please have a look?

[Bug c++/67184] Missed optimization with C++11 final specifier

[paolo at gcc dot gnu.org]

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

--- Comment #16 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jun 26 08:51:50 2019
New Revision: 272675

URL: https://gcc.gnu.org/viewcvs?rev=272675=gcc=rev
Log:
2019-06-26  Paolo Carlini  

PR c++/67184
PR c++/69445
* g++.dg/other/final3.C: New.
* g++.dg/other/final5.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/final3.C
trunk/gcc/testsuite/g++.dg/other/final5.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69445] Fail to devirtualize call to base class function even though derived class type is 'final'

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jun 26 08:51:50 2019
New Revision: 272675

URL: https://gcc.gnu.org/viewcvs?rev=272675=gcc=rev
Log:
2019-06-26  Paolo Carlini  

PR c++/67184
PR c++/69445
* g++.dg/other/final3.C: New.
* g++.dg/other/final5.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/other/final3.C
trunk/gcc/testsuite/g++.dg/other/final5.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90990
> 
> --- Comment #7 from Martin Liška  ---
> So before we stream LTO byte code, we have:
> 
> BEFORE:
> 
> Released 0 names, 0.00%, removed 0 holes
> A::A (struct A * const this)
> {
>[local count: 1073741824]:
>   MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
>   return;
> 
> }
> 
> Released 1 names, 12.50%, removed 1 holes
> C::operator() (struct C * const this)
> {
>   struct A D.2395;
>   struct B * _2;
> 
>[local count: 1073741824]:
>   _2 = _1(D)->m_basis;
>   D.2395 = B::operator[] (_2, 1); [return slot optimization]
>   D.2395 = B::operator[] (_2, 2);
>   D.2395 ={v} {CLOBBER};
>   MEM[(struct  &)&] ={v} {CLOBBER};
>   return ;
> 
> }
> 
> Released 1 names, 11.11%, removed 1 holes
> F::F (struct F * const this, struct D & p1, const struct A & p2)
> {
>   struct C D.2369;
> 
>[local count: 1073741824]:
>   MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
>   D::m_fn1 (p1_4(D));
>   *this_2(D).m_pivotInB = C::operator() (); [return slot optimization]
>   D.2369 ={v} {CLOBBER};
>   return;
> }
> 
> AFTER:
> 
> Released 0 names, 0.00%, removed 0 holes
> A::A (struct A * const this)
> {
>[local count: 1073741824]:
>   *this_2(D) ={v} {CLOBBER};
>   return;
> }
> 
> Released 1 names, 12.50%, removed 1 holes
> C::operator() (struct C * const this)
> {
>   struct A D.2397;
>   struct B * _2;
> 
>[local count: 1073741824]:
>   _2 = _1(D)->m_basis;
>   D.2397 = B::operator[] (_2, 1); [return slot optimization]
>   D.2397 = B::operator[] (_2, 2);
>   D.2397 ={v} {CLOBBER};
>={v} {CLOBBER};
>   return ;
> }
> 
> Released 1 names, 11.11%, removed 1 holes
> F::F (struct F * const this, struct D & p1, const struct A & p2)
> {
>   struct C D.2371;
> 
>[local count: 1073741824]:
>   *this_2(D) ={v} {CLOBBER};
>   D::m_fn1 (p1_4(D));
>   *this_2(D).m_pivotInB = C::operator() (); [return slot optimization]
>   D.2371 ={v} {CLOBBER};
>   return;

So it is inliner substituting the return slot which happens to be
clobber?  It makes sense but I wonder how this worked w/o the patch.
> #10 0x010f9dd5 in remap_gimple_stmt (stmt=0x775311e0,
> id=0x7fffd6d0) at /home/marxin/Programming/gcc/gcc/tree-inline.c:1896

remap_gimple_stmt already has some code to drop clobbers after
substitution

  /* For *ptr_N ={v} {CLOBBER}, if ptr_N is SSA_NAME defined
 in a block that we aren't copying during tree_function_versioning, 
 just drop the clobber stmt.  */
  if (id->blocks_to_copy && gimple_clobber_p (stmt))
{   
  tree lhs = gimple_assign_lhs (stmt);  
  if (TREE_CODE (lhs) == MEM_REF
  && TREE_CODE (TREE_OPERAND (lhs, 0)) == SSA_NAME) 

perhaps we need to care about the retval here.

Honza

[Bug fortran/52274] [Meta-bug] Fortran translation related issues: Typos and more

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
(In reply to Eric Gallager from comment #1)
> Are the "Depends on" and "Blocks" fields swapped here? Normally meta-bugs
> depend on more bugs than they block

Looks a bit confused, please rearrange if you think this is worth it.

Also, I am also not sure how this is different from 52279.

Close either this or 52279 as duplicate?

[Bug c++/91000] noexcept in constexpr context with std=c++11 and std=c++14

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
This would be more appropriate on the gcc-help mailing list, as you're asking a
question not reporting a bug.

The behaviour is as intended, for all -std versions. The standard was changed
to remove this feature and no other compilers implemented it anyway.

[Bug target/90991] [9/10 Regression] _mm_loadu_ps instrinsic translates to vmovaps in combination with _mm512_insertf32x4

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 26 08:26:18 2019
New Revision: 272674

URL: https://gcc.gnu.org/viewcvs?rev=272674=gcc=rev
Log:
PR target/90991
* config/i386/sse.md
(*_vinsert_0): Use vmovupd,
vmovups, vmovdqu, vmovdqu32 or vmovdqu64 instead of the aligned
insns if operands[2] is misaligned_operand.

* gcc.target/i386/avx512dq-pr90991-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512dq-pr90991-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/90978] A suspicious code in df-scan.c since r160348

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
> I am guessing that a gcc build with "-ftest-coverage -fprofile-arcs"
> would help. Then find unvisited code, then write a test case that gets
> there etc

I'm running that once a week:
https://users.suse.com/~mliska/lcov/

[Bug target/91001] internal compiler error: in extract_insn, at recog.c:2310

[gsocshubham at gmail dot com]

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

--- Comment #1 from Shubham Narlawar  ---
Below is reduced test case after fixing warning.

void f();

#pragma pack(1)
struct a {
  short b;
  char c;
};
union{
  struct a c;
} __attribute__((aligned(128), transparent_union)) d;

void e() { f(d); }

[Bug tree-optimization/90978] A suspicious code in df-scan.c since r160348

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from David Binderman  ---
(In reply to Jan Hubicka from comment #3)
> It indeed seems like debugging session leftover. Given we had the check
> there for 9 years, perhaps it is enough evidence that path does not
> execute?

On a broader issue than this particular bug report, I've been wondering
for a while about how much source code of the compiler actually gets
visited by the testsuite.

I am guessing that a gcc build with "-ftest-coverage -fprofile-arcs"
would help. Then find unvisited code, then write a test case that gets
there etc

[Bug c/91001] New: internal compiler error: in extract_insn, at recog.c:2310

[gsocshubham at gmail dot com]

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

Bug ID: 91001
   Summary: internal compiler error: in extract_insn, at
recog.c:2310
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gsocshubham at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 46521
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46521=edit
Preprocessed code of ICE causing program "crash1.c"

---COMPILER CONFIGURATION--

Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-lto
--disable-bootstrap : (reconfigured) ../gcc/configure --enable-lto
--disable-bootstrap --enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
gcc version 10.0.0 20190626 (experimental) (GCC) 

COMMAND LINE USED FOR COMPILATION-

extended_csmith@gcc10:~$ ~/pull-martin-compiler/build/gcc/xgcc -B
~/pull-martin-compiler/build/gcc/ crash1.i -Ibug-test-csmith/csmith/runtime/ -w
-O0 --save-temps
crash1.c: In function ‘func_58’:
crash1.c:2793:1: error: unrecognizable insn:
 2793 | }
  | ^
(insn 838 837 839 29 (set (reg:DI 17 flags)
(mem/c:DI (plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -3736 [0xf168])) [8 l_4859+104 S8 A64]))
"crash1.c":1612:37 -1
 (nil))
during RTL pass: vregs
crash1.c:2793:1: internal compiler error: in extract_insn, at recog.c:2310
0x598e50 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x598e6f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0xbd30cb extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2310
0x9573c3 instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1605
0x9573c3 instantiate_virtual_regs
../../gcc/gcc/function.c:1975
0x9573c3 execute
../../gcc/gcc/function.c:2024
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

REDUCED TEST CASE--

#pragma pack(1)
struct a {
  short b;
  char c
};
union {
  struct a c
} __attribute__((aligned(128), transparent_union)) d;
e() { f(d); }

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
So before we stream LTO byte code, we have:

BEFORE:

Released 0 names, 0.00%, removed 0 holes
A::A (struct A * const this)
{
   [local count: 1073741824]:
  MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
  return;

}

Released 1 names, 12.50%, removed 1 holes
C::operator() (struct C * const this)
{
  struct A D.2395;
  struct B * _2;

   [local count: 1073741824]:
  _2 = _1(D)->m_basis;
  D.2395 = B::operator[] (_2, 1); [return slot optimization]
  D.2395 = B::operator[] (_2, 2);
  D.2395 ={v} {CLOBBER};
  MEM[(struct  &)&] ={v} {CLOBBER};
  return ;

}

Released 1 names, 11.11%, removed 1 holes
F::F (struct F * const this, struct D & p1, const struct A & p2)
{
  struct C D.2369;

   [local count: 1073741824]:
  MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
  D::m_fn1 (p1_4(D));
  *this_2(D).m_pivotInB = C::operator() (); [return slot optimization]
  D.2369 ={v} {CLOBBER};
  return;
}

AFTER:

Released 0 names, 0.00%, removed 0 holes
A::A (struct A * const this)
{
   [local count: 1073741824]:
  *this_2(D) ={v} {CLOBBER};
  return;
}

Released 1 names, 12.50%, removed 1 holes
C::operator() (struct C * const this)
{
  struct A D.2397;
  struct B * _2;

   [local count: 1073741824]:
  _2 = _1(D)->m_basis;
  D.2397 = B::operator[] (_2, 1); [return slot optimization]
  D.2397 = B::operator[] (_2, 2);
  D.2397 ={v} {CLOBBER};
   ={v} {CLOBBER};
  return ;
}

Released 1 names, 11.11%, removed 1 holes
F::F (struct F * const this, struct D & p1, const struct A & p2)
{
  struct C D.2371;

   [local count: 1073741824]:
  *this_2(D) ={v} {CLOBBER};
  D::m_fn1 (p1_4(D));
  *this_2(D).m_pivotInB = C::operator() (); [return slot optimization]
  D.2371 ={v} {CLOBBER};
  return;
}

And then the LHS is emitted when we materialize clones:

#0  __memmove_avx_unaligned () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:145
#1  0x014350c3 in copy_node (node=0x7772c810) at
/home/marxin/Programming/gcc/gcc/tree.c:1189
#2  0x01104180 in copy_tree_r (tp=0x7fffcb38,
walk_subtrees=0x7fffcab4, data=0x0) at
/home/marxin/Programming/gcc/gcc/tree-inline.c:5313
#3  0x00bff037 in mostly_copy_tree_r (tp=0x7fffcb38,
walk_subtrees=0x7fffcab4, data=0x0) at
/home/marxin/Programming/gcc/gcc/gimplify.c:869
#4  0x01461871 in walk_tree_1 (tp=0x7fffcb38, func=0xbfef59
, data=0x0, pset=0x0, lh=0x0) at
/home/marxin/Programming/gcc/gcc/tree.c:12151
#5  0x00bff4be in unshare_expr (expr=0x7772c810) at
/home/marxin/Programming/gcc/gcc/gimplify.c:995
#6  0x010f2cf8 in remap_decl (decl=0x77738348, id=0x7fffd6d0)
at /home/marxin/Programming/gcc/gcc/tree-inline.c:413
#7  0x010f6491 in remap_gimple_op_r (tp=0x77531360,
walk_subtrees=0x7fffccf4, data=0x7fffce70) at
/home/marxin/Programming/gcc/gcc/tree-inline.c:1047
#8  0x01461871 in walk_tree_1 (tp=0x77531360, func=0x10f636b
, data=0x7fffce70, pset=0x0, lh=0x0)
at /home/marxin/Programming/gcc/gcc/tree.c:12151
#9  0x00bf7cbf in walk_gimple_op (stmt=0x77531320,
callback_op=0x10f636b ,
wi=0x7fffce70) at /home/marxin/Programming/gcc/gcc/gimple-walk.c:221
#10 0x010f9dd5 in remap_gimple_stmt (stmt=0x775311e0,
id=0x7fffd6d0) at /home/marxin/Programming/gcc/gcc/tree-inline.c:1896
#11 0x010f9fed in copy_bb (id=0x7fffd6d0, bb=0x77736618,
num=..., den=...) at /home/marxin/Programming/gcc/gcc/tree-inline.c:1946
#12 0x010fd2b7 in copy_cfg_body (id=0x7fffd6d0,
entry_block_map=0x777364e0, exit_block_map=0x77736680, new_entry=0x0)
at /home/marxin/Programming/gcc/gcc/tree-inline.c:2919
#13 0x010fde80 in copy_body (id=0x7fffd6d0,
entry_block_map=0x777364e0, exit_block_map=0x77736680, new_entry=0x0)
at /home/marxin/Programming/gcc/gcc/tree-inline.c:3167
#14 0x01102c05 in expand_call_inline (bb=0x777364e0,
stmt=0x77fc7cf0, id=0x7fffd6d0) at
/home/marxin/Programming/gcc/gcc/tree-inline.c:4909
#15 0x011039b6 in gimple_expand_calls_inline (bb=0x777364e0,
id=0x7fffd6d0) at /home/marxin/Programming/gcc/gcc/tree-inline.c:5104
#16 0x01103f22 in optimize_inline_calls (fn=0x77929900) at
/home/marxin/Programming/gcc/gcc/tree-inline.c:5244
#17 0x01e30436 in inline_transform (node=0x77730438) at
/home/marxin/Programming/gcc/gcc/ipa-inline-transform.c:682
#18 0x00ec99bf in execute_one_ipa_transform_pass (node=0x77730438,
ipa_pass=0x2dc7090) at /home/marxin/Programming/gcc/gcc/passes.c:2211
#19 0x00ec9b02 in execute_all_ipa_transforms () at
/home/marxin/Programming/gcc/gcc/passes.c:2250
#20 0x009adba7 in cgraph_node::expand (this=0x77730438) at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2187
#21 0x009ae206 in expand_all_functions () at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2332
#22 0x009aed62 in symbol_table::compile 

[Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-26
 CC||marxin at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
  Known to work||7.4.0
   Target Milestone|--- |8.4
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.0, 9.1.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r256821.

[Bug c++/90996] [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:13495

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, started with r258593.

[Bug c++/90998] [Regression] ICE (segfalut) in gcc/cp/call.c compare_ics() with -std=c++17

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||8.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2019-06-26
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |9.2
  Known to fail||10.0, 9.1.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r269667.

[Bug tree-optimization/90973] A suspicious code in tree-vect-loop.c

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Wed Jun 26 06:44:58 2019
New Revision: 272671

URL: https://gcc.gnu.org/viewcvs?rev=272671=gcc=rev
Log:
Fix one another thinko in tree-vect-loop.c (PR tree-optimization/90973).

2019-06-26  Martin Liska  

PR tree-optimization/90973
* tree-vect-loop.c (vect_get_known_peeling_cost): Use
epilogue_cost_vec instead of prologue_cost_vec for
a epilogue cost.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/90978] A suspicious code in df-scan.c since r160348

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug other/89863] [meta-bug] Issues that cppcheck finds that gcc misses

[marxin at gcc dot gnu.org]

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

Bug 90978 Summary: A suspicious code in df-scan.c since r160348
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90978

   What|Removed |Added

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

[Bug target/90991] [9/10 Regression] _mm_loadu_ps instrinsic translates to vmovaps in combination with _mm512_insertf32x4

[kronbichler.martin at gmail dot com]

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

--- Comment #3 from Martin Kronbichler  ---
I can confirm that this patch creates the right instruction on my test case,
"vmovups (%rdi,%rax,4), %xmm0", and also in the application code where it
originated from.