[Bug tree-optimization/105736] [12/13 Regression] ICE in force_gimple_operand_1, at gimplify-me.cc:79 since r13-222-g28896b38fabce818

[siddhesh at gcc dot gnu.org via Gcc-bugs]

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

--- Comment #6 from Siddhesh Poyarekar  ---
Fixed for gcc 13 and 12.

[Bug tree-optimization/105736] [12/13 Regression] ICE in force_gimple_operand_1, at gimplify-me.cc:79 since r13-222-g28896b38fabce818

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Siddhesh Poyarekar
:

https://gcc.gnu.org/g:70deb85b995eed16280ed3a45c3b879b16685bbf

commit r12-8508-g70deb85b995eed16280ed3a45c3b879b16685bbf
Author: Siddhesh Poyarekar 
Date:   Tue Jun 21 12:15:07 2022 +0530

tree-object-size: Don't let error_mark_node escape for ADDR_EXPR [PR105736]

The addr_expr computation does not check for error_mark_node before
returning the size expression.  This used to work in the constant case
because the conversion to uhwi would end up causing it to return
size_unknown, but that won't work for the dynamic case.

Modify the control flow to explicitly return size_unknown if the offset
computation returns an error_mark_node.

gcc/ChangeLog:

PR tree-optimization/105736
* tree-object-size.cc (addr_object_size): Return size_unknown
when object offset computation returns an error.

gcc/testsuite/ChangeLog:

PR tree-optimization/105736
* gcc.dg/builtin-dynamic-object-size-0.c (TV4): New struct.
(val3): New variable.
(test_pr105736): New test.
(main): Call it.

Signed-off-by: Siddhesh Poyarekar 
(cherry picked from commit 70454c50b4592fe6876ecca13268264e395e058f)

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[13 Regression] during  |[13 Regression] during
   |GIMPLE pass: einline ICE:   |GIMPLE pass: einline ICE:
   |verify_cgraph_node failed   |verify_cgraph_node failed
   |(edge points to wrong   |(edge points to wrong
   |declaration) with -Og   |declaration) with -Og since
   ||r13-1204-gd68d366425369649
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-23
 CC||jason at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r13-1204-gd68d366425369649.

[Bug tree-optimization/106063] New: [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106063
   Summary: [13 Regression] ICE: in gimple_expand_vec_cond_expr,
at gimple-isel.cc:281 with -O2 -fno-tree-forwprop
--param=evrp-mode=legacy-first
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first
testcase.c
during GIMPLE pass: isel
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:281
4 | foo (V v)
  | ^~~
0x7fc007 gimple_expand_vec_cond_expr
/repo/gcc-trunk/gcc/gimple-isel.cc:281
0x7fc007 gimple_expand_vec_exprs
/repo/gcc-trunk/gcc/gimple-isel.cc:311
0x7fc007 execute
/repo/gcc-trunk/gcc/gimple-isel.cc:365
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1213-20220623060722-g31ce821a790-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.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
--disable-bootstrap --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-r13-1213-20220623060722-g31ce821a790-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220623 (experimental) (GCC)

[Bug middle-end/106010] Miss vectorization for complex type copy.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> It seems loop vectorizer assume unroll factor to be number of elemenets,
> similar as groups size for SLP.
> I'm trying to handle them for when scalar type is COMPLEX, not sure if
> there's other issues? It looks to me Complex type only existed for
> movement(paramenter pass, load, store), any real operators will be lowered
> to operations for imag and real parts.

Maybe add a new member bool complex_p in stmt_vec_info.

[Bug c++/106062] [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-23
   Target Milestone|--- |13.0
 Ever confirmed|0   |1

[Bug middle-end/106010] Miss vectorization for complex type copy.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
It seems loop vectorizer assume unroll factor to be number of elemenets,
similar as groups size for SLP.
I'm trying to handle them for when scalar type is COMPLEX, not sure if there's
other issues? It looks to me Complex type only existed for movement(paramenter
pass, load, store), any real operators will be lowered to operations for imag
and real parts.

[Bug c++/106062] New: [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106062
   Summary: [13 Regression] ICE in build_builtin_unreachable since
r13-1204-gd68d366425369649
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Since the revision the following fails:

$ cat loop.f90
call test (reshape ((/ 'a', 'b', 'c', 'd' /), (/ 2, 2 /)))
contains
  subroutine test (a)
character (*), dimension (:, :) :: a
if (len (a) .ne. 1) STOP 
  end  
end

$ gcc loop.f90 -fsanitize=unreachable -O2 -c
during GIMPLE pass: einline
loop.f90:1:58:

1 | call test (reshape ((/ 'a', 'b', 'c', 'd' /), (/ 2, 2 /)))
  |  ^
internal compiler error: Segmentation fault
0xfe3e1a crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:322
0x778567bf ???
   
/usr/src/debug/glibc-2.35-4.2.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x12d6c45 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3629
0x12d6c45 build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
/home/marxin/Programming/gcc/gcc/tree.cc:10634
0x12d6da0 build_call_expr_loc(unsigned int, tree_node*, int, ...)
/home/marxin/Programming/gcc/gcc/tree.cc:10667
0x12d6de8 build_builtin_unreachable(unsigned int)
/home/marxin/Programming/gcc/gcc/tree.cc:10819
0xac0aad fold_builtin_0
/home/marxin/Programming/gcc/gcc/builtins.cc:9270
0xac0aad fold_builtin_n
/home/marxin/Programming/gcc/gcc/builtins.cc:9578
0xac31a2 fold_call_stmt(gcall*, bool)
/home/marxin/Programming/gcc/gcc/builtins.cc:10836
0xcb7c34 gimple_fold_builtin
/home/marxin/Programming/gcc/gcc/gimple-fold.cc:5151
0xcb7c34 gimple_fold_call
/home/marxin/Programming/gcc/gcc/gimple-fold.cc:5551
0xcba373 fold_stmt_1
/home/marxin/Programming/gcc/gcc/gimple-fold.cc:6295
0x1066af8 fold_marked_statements
/home/marxin/Programming/gcc/gcc/tree-inline.cc:5366
0x107afd3 optimize_inline_calls(tree_node*)
/home/marxin/Programming/gcc/gcc/tree-inline.cc:5514
0x1e6077f early_inliner(function*)
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:3038
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Can be fixed with:

 gcc/ubsan.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/ubsan.cc b/gcc/ubsan.cc
index f15026872a1..b6c4301dfaf 100644
--- a/gcc/ubsan.cc
+++ b/gcc/ubsan.cc
@@ -654,9 +654,10 @@ sanitize_unreachable_fn (tree *data, location_t loc)
 }
   else if (san)
 {
-  fn = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE);
+  /* Call ubsan_create_data first as it initializes SANITIZER built-ins. 
*/
   *data = ubsan_create_data ("__ubsan_unreachable_data", 1, &loc,
 NULL_TREE, NULL_TREE);
+  fn = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE);
   *data = build_fold_addr_expr_loc (loc, *data);
 }
   else

[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 23 Jun 2022, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
> 
> Kewen Lin  changed:
> 
>What|Removed |Added
> 
>  Resolution|--- |FIXED
>  Status|ASSIGNED|RESOLVED
> 
> --- Comment #12 from Kewen Lin  ---
> Both backports were bootstrapped on ppc64le and aarch64, the extra aarch64 
> case
> was also verified.
> 
> Guess we don't want to backport r13-1173 as the fixed inconsistent slp 
> decision
> will not cause functionality correctness issue? Marking this as resolved.

Yeah, that one doesn't look for backporting.

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Richard Biener  ---
(In reply to H.J. Lu from comment #9)
> (In reply to Richard Biener from comment #8)
> > (In reply to H.J. Lu from comment #6)
> > > Created attachment 53169 [details]
> > > A patch
> > > 
> > > This patch multiplies the vector store cost by the number of scalar 
> > > elements
> > > in
> > > a word to properly compare scalar store cost against vector store cost.
> > 
> > But that's not "properly" but "wrong" ...
> > 
> > Note we already cost the vector load from the constant pool so the vector
> > side costing is correct.
> > 
> > What's eventually imprecise is the scalar cost where you could anticipate
> > store merging, but adjusting the vector cost side is just wrong.
> 
> I tried to adjust the scalar cost.  When the scalar cost of storing a byte
> is 6, dividing it by 8 (the number of scalar elements in a word) becomes 0.
> Will it work?

No, I think you would need to pattern match an actual store sequence,
for example by looking at

 if (STMT_VINFO_GROUPED_ACCESS (stmt_info)
 && pow2p_hwi (DR_GROUP_STORE_COUNT (stmt_info)))
   /* cost a possibly merged store only once (but with larger mode?) */
   if (DR_GROUP_FIRST_ELEMENT (stmt_info) == stmt_info)
 ...

So costing the whole sequence of scalar stores a single time, with
adjusted mode.

store-merging also handles non-QImode stores btw.

[Bug ipa/106061] New: [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106061
   Summary: [13 Regression] during GIMPLE pass: einline ICE:
verify_cgraph_node failed (edge points to wrong
declaration) with -Og
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og testcase.c 
testcase.c: In function 'foo':
testcase.c:14:3: error: edge points to wrong declaration:
   14 |   bar (-1);
  |   ^~~~
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f78c98d55e8
arg-types >>
volatile nothrow public external built-in decl_6 QI :0:0
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_TRAP context

attributes 
chain 
chain 
chain  chain
>
 Instead of: 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7f78c98c55e8 precision:32 min  max

pointer_to_this >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f78c98d4930
pointer_to_this >
addressable used public external decl_5 QI testcase.c:1:5 align:8
warn_if_not_align:0 context 
chain >
bar/1 (bar) @0x7f78c9a0e000
  Type: function definition analyzed
  Visibility: semantic_interposition prevailing_def_ironly
  References: 
  Referring: 
  Function bar/1 is inline copy in foo/2
  Availability: local
  Function flags: body local
  Called by: foo/2 (inlined) 
  Calls: __builtin_trap/4 (0 (precise),1.00 per call) 
during GIMPLE pass: einline
testcase.c:14:3: internal compiler error: verify_cgraph_node failed
0xed2848 cgraph_node::verify_node()
/repo/gcc-trunk/gcc/cgraph.cc:3881
0xec1a54 symtab_node::verify()
/repo/gcc-trunk/gcc/symtab.cc:1359
0x144eba1 expand_call_inline
/repo/gcc-trunk/gcc/tree-inline.cc:4912
0x1451659 gimple_expand_calls_inline
/repo/gcc-trunk/gcc/tree-inline.cc:5318
0x1451659 optimize_inline_calls(tree_node*)
/repo/gcc-trunk/gcc/tree-inline.cc:5490
0x24590be early_inliner(function*)
/repo/gcc-trunk/gcc/ipa-inline.cc:3038
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1213-20220623060722-g31ce821a790-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.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
--disable-bootstrap --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-r13-1213-20220623060722-g31ce821a790-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220623 (experimental) (GCC)

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

[jason at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jason Merrill  ---
(In reply to Daniel Krügler from comment #3)
> The example is ill-formed because the condition of 'if constexpr' is more
> restricted than that of normal 'if': It expects "a contextually converted
> constant expression of type bool" and [expr.const] p10 lists the allowed
> conversions in this case. This list omits the boolean conversions
> ([conv.bool]).

This was changed by wg21.link/p1401 so the conversion is allowed in this
context as well.

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-23
 Status|UNCONFIRMED |ASSIGNED
 CC||jason at gcc dot gnu.org

[Bug ipa/105600] [10/11/12 Regression] ICE with LTO when building Mumble

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||13.0
  Known to fail|13.0|
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
   |ICE with LTO when building  |with LTO when building
   |Mumble  |Mumble

--- Comment #17 from Martin Liška  ---
Fixed on master so far.

[Bug ipa/105600] [10/11/12/13 Regression] ICE with LTO when building Mumble

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:31ce821a790caec8a2849dd67a9847e78a33d14c

commit r13-1213-g31ce821a790caec8a2849dd67a9847e78a33d14c
Author: Martin Liska 
Date:   Wed May 18 15:07:53 2022 +0200

ipa-icf: skip variables with body_removed

Similarly to cgraph_nodes, it may happen that body_removed is set
during merging of symbols.

PR ipa/105600

gcc/ChangeLog:

* ipa-icf.cc (sem_item_optimizer::filter_removed_items):
Skip variables with body_removed.

[Bug c++/105964] [12 Regression] Return type deduction fails during NTTP use of function dependent on template parameter

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-8507-gc85cea9ca165b0b771d9f913016c9dc8db46b5d7
Author: Jason Merrill 
Date:   Wed Jun 22 18:19:11 2022 -0400

c++: dependence of baselink [PR105964]

helper::c isn't dependent just because we haven't deduced its return
type yet.  type_dependent_expression_p already knows how to deal with that
for bare FUNCTION_DECL, but needs to learn to look through a BASELINK.

PR c++/105964

gcc/cp/ChangeLog:

* pt.cc (type_dependent_expression_p): Look through BASELINK.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nontype-auto21.C: New test.

[Bug c++/105908] [12 Regression] out-of-class definition of templated method with decltype in trailing return type fails to compile

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:4fcf79c8ab835615aea0687195871ac43b84d156

commit r12-8506-g4fcf79c8ab835615aea0687195871ac43b84d156
Author: Jason Merrill 
Date:   Wed Jun 22 14:57:21 2022 -0400

c++: class scope function lookup [PR105908]

In r12-1273 for PR91706, I removed the code in get_class_binding that
stripped BASELINK.  This testcase demonstrates that we still need to strip
it in outer_binding before putting the overload set in IDENTIFIER_BINDING,
for compatibility with bindings added directly for declarations.

PR c++/105908

gcc/cp/ChangeLog:

* name-lookup.cc (outer_binding): Strip BASELINK.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/trailing16.C: New test.

[Bug tree-optimization/106054] Tree optimizations cause mcf generates incorrect results

[dizhao at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #4 from Di Zhao  ---
(In reply to Andrew Pinski from comment #3)
> From https://www.spec.org/cpu2017/Docs/benchmarks/505.mcf_r.html:
> >The module spec_qsort.c does not obey strict ANSI aliasing rules. You may 
> >need to add your compiler's flag that informs it not to assume strict ANSI 
> >compliance.

I tried the "-fno-strict-aliasing" option and it works. Apologize for not
noticing this. Thanks a lot!

[Bug c++/105885] [12/13 Regression] the address of 'template argument' will never be NULL warning

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/105964] [12/13 Regression] Return type deduction fails during NTTP use of function dependent on template parameter

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r13-1210-gd29f61a3291a8c4cff0bd754fa3bb8e9399589bc
Author: Jason Merrill 
Date:   Wed Jun 22 18:19:11 2022 -0400

c++: dependence of baselink [PR105964]

helper::c isn't dependent just because we haven't deduced its return
type yet.  type_dependent_expression_p already knows how to deal with that
for bare FUNCTION_DECL, but needs to learn to look through a BASELINK.

PR c++/105964

gcc/cp/ChangeLog:

* pt.cc (type_dependent_expression_p): Look through BASELINK.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nontype-auto21.C: New test.

[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #12 from Kewen Lin  ---
Both backports were bootstrapped on ppc64le and aarch64, the extra aarch64 case
was also verified.

Guess we don't want to backport r13-1173 as the fixed inconsistent slp decision
will not cause functionality correctness issue? Marking this as resolved.

[Bug tree-optimization/105254] ICE in exact_div, at poly-int.h:2219

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Kewen Lin :

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

commit r12-8505-gbb1a6d92989a50df13b1a21085c86625089c9e53
Author: Richard Sandiford 
Date:   Wed Jun 15 11:12:51 2022 +0100

aarch64: Revert bogus fix for PR105254

In f2ebf2d98efe0ac2314b58cf474f44cb8ebd5244 I'd forced the
chosen unroll factor to be a factor of the VF, in order to
work around an exact_div ICE in PR105254.  This was completely
bogus -- clearly I didn't look in enough detail at why we ended
up with an unrolled VF that wasn't a multiple of the UF.

Kewen has since fixed the bug properly for PR105940, so this
patch reverts my earlier attempt.  Sorry for the stupidity.

gcc/
PR tree-optimization/105254
PR tree-optimization/105940

Revert:

* config/aarch64/aarch64.cc
(aarch64_vector_costs::determine_suggested_unroll_factor): Take a
loop_vec_info as argument.  Restrict the unroll factor to values
that divide the VF.
(aarch64_vector_costs::finish_cost): Update call accordingly.

gcc/testsuite/
* gcc.target/aarch64/sve/cost_model_14.c: New test.

(cherry picked from commit 2636660b6f35423e0cfbf53bfad5c5fed6ae6471)

[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Kewen Lin :

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

commit r12-8505-gbb1a6d92989a50df13b1a21085c86625089c9e53
Author: Richard Sandiford 
Date:   Wed Jun 15 11:12:51 2022 +0100

aarch64: Revert bogus fix for PR105254

In f2ebf2d98efe0ac2314b58cf474f44cb8ebd5244 I'd forced the
chosen unroll factor to be a factor of the VF, in order to
work around an exact_div ICE in PR105254.  This was completely
bogus -- clearly I didn't look in enough detail at why we ended
up with an unrolled VF that wasn't a multiple of the UF.

Kewen has since fixed the bug properly for PR105940, so this
patch reverts my earlier attempt.  Sorry for the stupidity.

gcc/
PR tree-optimization/105254
PR tree-optimization/105940

Revert:

* config/aarch64/aarch64.cc
(aarch64_vector_costs::determine_suggested_unroll_factor): Take a
loop_vec_info as argument.  Restrict the unroll factor to values
that divide the VF.
(aarch64_vector_costs::finish_cost): Update call accordingly.

gcc/testsuite/
* gcc.target/aarch64/sve/cost_model_14.c: New test.

(cherry picked from commit 2636660b6f35423e0cfbf53bfad5c5fed6ae6471)

[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Kewen Lin :

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

commit r12-8504-gb3200ac82fd5aed39293a54e0e83258bb6caa600
Author: Kewen Lin 
Date:   Tue Jun 14 00:57:01 2022 -0500

vect: Move suggested_unroll_factor applying [PR105940]

As PR105940 shown, when rs6000 port tries to assign
m_suggested_unroll_factor by 4 or so, there will be ICE on:

  exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
 loop_vinfo->suggested_unroll_factor);

In function vect_analyze_loop_2, the current place of
suggested_unroll_factor applying can't guarantee it's
applied for all cases.  As the case shows, vectorizer
could retry with SLP forced off, the vf is reset by
saved_vectorization_factor which isn't applied with
suggested_unroll_factor before.  It means it can end
up with one vf which neglects suggested_unroll_factor.
I think it's off design, we should move the applying
of suggested_unroll_factor after start_over.

PR tree-optimization/105940

gcc/ChangeLog:

* tree-vect-loop.cc (vect_analyze_loop_2): Move the place of
applying suggested_unroll_factor after start_over.

(cherry picked from commit f907cf4c07cf51863dadbe90894e2ae3382bada5)

[Bug target/106060] New: Inefficient constant broadcast on x86_64

[goldstein.w.n at gmail dot com via Gcc-bugs]

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

Bug ID: 106060
   Summary: Inefficient constant broadcast on x86_64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goldstein.w.n at gmail dot com
  Target Milestone: ---

```
#include 

__m256i
shouldnt_have_movabs ()
{
  return _mm256_set1_epi8 (123);
}

__m256i
should_be_cmpeq_abs ()
{
  return _mm256_set1_epi8 (1);
}

__m256i
should_be_cmpeq_add ()
{
  return _mm256_set1_epi8 (-2);
}
```

Compiled with: '-O3 -march=x86-64-v3'

Results in:
```
Disassembly of section .text:

 :
   0:   48 b8 7b 7b 7b 7b 7bmovabs $0x7b7b7b7b7b7b7b7b,%rax
   7:   7b 7b 7b
   a:   c4 e1 f9 6e c8  vmovq  %rax,%xmm1
   f:   c4 e2 7d 59 c1  vpbroadcastq %xmm1,%ymm0
  14:   c3  retq
  15:   66 66 2e 0f 1f 84 00data16 nopw %cs:0x0(%rax,%rax,1)
  1c:   00 00 00 00

0020 :
  20:   48 b8 01 01 01 01 01movabs $0x101010101010101,%rax
  27:   01 01 01
  2a:   c4 e1 f9 6e c8  vmovq  %rax,%xmm1
  2f:   c4 e2 7d 59 c1  vpbroadcastq %xmm1,%ymm0
  34:   c3  retq
  35:   66 66 2e 0f 1f 84 00data16 nopw %cs:0x0(%rax,%rax,1)
  3c:   00 00 00 00

0040 :
  40:   48 b8 fe fe fe fe femovabs $0xfefefefefefefefe,%rax
  47:   fe fe fe
  4a:   c4 e1 f9 6e c8  vmovq  %rax,%xmm1
  4f:   c4 e2 7d 59 c1  vpbroadcastq %xmm1,%ymm0
  54:   c3  retq
```

Compiled with: '-O3 -march=x86-64-v4'

Results in:
```
 :
   0:   48 b8 7b 7b 7b 7b 7bmovabs $0x7b7b7b7b7b7b7b7b,%rax
   7:   7b 7b 7b
   a:   62 f2 fd 28 7c c0   vpbroadcastq %rax,%ymm0
  10:   c3  retq
  11:   66 66 2e 0f 1f 84 00data16 nopw %cs:0x0(%rax,%rax,1)
  18:   00 00 00 00
  1c:   0f 1f 40 00 nopl   0x0(%rax)

0020 :
  20:   48 b8 01 01 01 01 01movabs $0x101010101010101,%rax
  27:   01 01 01
  2a:   62 f2 fd 28 7c c0   vpbroadcastq %rax,%ymm0
  30:   c3  retq
  31:   66 66 2e 0f 1f 84 00data16 nopw %cs:0x0(%rax,%rax,1)
  38:   00 00 00 00
  3c:   0f 1f 40 00 nopl   0x0(%rax)

0040 :
  40:   48 b8 fe fe fe fe femovabs $0xfefefefefefefefe,%rax
  47:   fe fe fe
  4a:   62 f2 fd 28 7c c0   vpbroadcastq %rax,%ymm0
  50:   c3  retq
```


All functions / targets are inoptimal.

Generating 1/2 can be done without any lane-cross broadcast.

Generating constants like 123 shouldn't first be constant broadcast
into an imm64. That makes it require an 10-byte `movabs` and wastes
spaces.

[Bug testsuite/106059] New: [13 regression] cc.dg/vect/pr79347.c fails after r13-1171-g9f55aee9dca759

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106059
   Summary: [13 regression] cc.dg/vect/pr79347.c fails after
r13-1171-g9f55aee9dca759
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:9f55aee9dca759da84afd4563ff72d3ca8ab8a1c,  r13-1171-g9f55aee9dca759
make  -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr79347.c"
FAIL: gcc.dg/vect/pr79347.c scan-tree-dump-not vect "Invalid sum of "
FAIL: gcc.dg/vect/pr79347.c -flto -ffat-lto-objects  scan-tree-dump-not vect
"Invalid sum of "
# of expected passes2
# of unexpected failures2

I only saw this issue on a power 7 which does not support all the vectorization
stuff.  So it may be that this test just needs to be ignored there now.

commit 9f55aee9dca759da84afd4563ff72d3ca8ab8a1c
Author: Martin Liska 
Date:   Tue Jan 25 19:16:06 2022 +0100

Add operators / and * for profile_{count,probability}.

[Bug tree-optimization/94899] Failure to optimize out add before compare with INT_MIN

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Gabriel Ravier  ---
Can confirm that this appears to be fixed.

[Bug c++/105964] [12/13 Regression] Return type deduction fails during NTTP use of function dependent on template parameter

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/105908] [12/13 Regression] out-of-class definition of templated method with decltype in trailing return type fails to compile

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:349a39f061407ce2339d2ba25da97005f2030c88

commit r13-1207-g349a39f061407ce2339d2ba25da97005f2030c88
Author: Jason Merrill 
Date:   Wed Jun 22 14:57:21 2022 -0400

c++: class scope function lookup [PR105908]

In r12-1273 for PR91706, I removed the code in get_class_binding that
stripped BASELINK.  This testcase demonstrates that we still need to strip
it in outer_binding before putting the overload set in IDENTIFIER_BINDING,
for compatibility with bindings added directly for declarations.

PR c++/105908

gcc/cp/ChangeLog:

* name-lookup.cc (outer_binding): Strip BASELINK.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/trailing16.C: New test.

[Bug tree-optimization/105751] std::array comparision does not inline memcmp

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #2 from Andrew Pinski  ---
Hmm:

  _5 = a_2(D) + 8;
  _6 = &MEM[(const struct array *)a_2(D)]._M_elems;
  _8 = _5 - _6;

I think there is another bug for this similar thing.

[Bug target/105773] [Aarch64] Failure to optimize and+cmp to tst

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|minor   |enhancement

[Bug tree-optimization/106053] [13 Regression] wrong code with -O -fno-tree-fre

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/106055] [13 Regression] ICE in replace_uses_by with -floop-parallelize-all and returns_twice

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |replace_uses_by, at |replace_uses_by with
   |tree-cfg.cc:1989|-floop-parallelize-all and
   ||returns_twice
   Target Milestone|--- |13.0

--- Comment #1 from Andrew Pinski  ---
I suspect this is a latent bug with -floop-parallelize-all which does not get
much testing at all.

[Bug fortran/106047] ICE in structure_alloc_comps, at fortran/trans-array.cc:9574

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-22
 Ever confirmed|0   |1
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
ICE confirmed.  But it is really invalid?  Intel & NAG accept it.

Part of the problem is gfc_element_size.  It calculates a number that
is 8 for -m64, and 4 for -m32, likely sizeof (gfc_charlen_t), instead
of noticing that we have a descriptor for deferred length character.

(OTOH using  character, allocatable :: c(:)  seems to work, so maybe the
real issue is in gfc_typenode_for_spec).

[Bug tree-optimization/105749] Bogus maybe-unitialized when using std::optional, regex and sstream

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.3.0

--- Comment #3 from Andrew Pinski  ---
Note in GCC 10.3.0 we got:
: In function 'void t(const string&)':
:13:51: warning: 'port' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   13 | reqb << "Host: " << port.value_or(443) << "\r\n";
  |   ^~

[Bug tree-optimization/105749] Bogus maybe-unitialized when using std::optional, regex and sstream

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
: In function 'void t(const std::string&)':
:13:51: warning: '*(int*)((char*)&port +
offsetof(std::optional,std::optional::.std::_Optional_base::))' may be used uninitialized [-Wmaybe-uninitialized]
   13 | reqb << "Host: " << port.value_or(443) << "\r\n";
  |   ^~
:9:28: note: '*(int*)((char*)&port +
offsetof(std::optional,std::optional::.std::_Optional_base::))' was declared here
9 | std::optional port(i.length() > 0 ?
std::make_optional(std::strtol("99", nullptr, 10)) : std::nullopt);
  |^~~~

[Bug tree-optimization/105749] Bogus maybe-unitialized when using std::optional, regex and sstream

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
>Interesting that commenting unrelated parts or changing them slightly makes
warning go away.

Most likely inlining changes with those being there vs not being there.

[Bug fortran/106049] ICE in gfc_simplify_pack, at fortran/simplify.cc:6481

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-22
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Error recovery issue while trying to simplify pack.
The chain of bad declarations passes an invalid constructor for the ARRAY
argument.

The following patch solves the problem at hand:

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index e8e3ec63669..c4ba2e615a1 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -6373,6 +6374,10 @@ gfc_simplify_pack (gfc_expr *array, gfc_expr *mask,
gfc_expr *vector)
   && !is_constant_array_expr (mask)))
 return NULL;

+  if (mask->expr_type == EXPR_ARRAY
+  && gfc_is_size_zero_array (mask) != gfc_is_size_zero_array (array))
+return NULL;
+
   result = gfc_get_array_expr (array->ts.type, array->ts.kind, &array->where);
   if (array->ts.type == BT_DERIVED)
 result->ts.u.derived = array->ts.u.derived;

Maybe there is a better solution.

[Bug tree-optimization/106054] Tree optimizations cause mcf generates incorrect results

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
>From https://www.spec.org/cpu2017/Docs/benchmarks/505.mcf_r.html:
>The module spec_qsort.c does not obey strict ANSI aliasing rules. You may need 
>to add your compiler's flag that informs it not to assume strict ANSI 
>compliance.

[Bug debug/106058] New: -fcompare-debug failure with -O -fno-dce -fno-tree-dce -fno-cprop-registers on powerpc64le-unknown-linux-gnu

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106058
   Summary: -fcompare-debug failure with -O -fno-dce -fno-tree-dce
-fno-cprop-registers on powerpc64le-unknown-linux-gnu
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu

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

Compiler output:
$ powerpc64le-unknown-linux-gnu-gcc -O -fno-dce -fno-tree-dce
-fno-cprop-registers -fcompare-debug testcase.c
powerpc64le-unknown-linux-gnu-gcc: error: testcase.c: '-fcompare-debug' failure

$ diff -u *gkd
--- a-testcase.c.gkd2022-06-22 20:27:59.271068364 +0200
+++ a-testcase.gk.c.gkd 2022-06-22 20:27:59.314401459 +0200
@@ -34,9 +34,9 @@
  (expr_list:REG_UNUSED (reg:DI 11 11 [+8 ])
 (nil)))
 (note # 0 0 NOTE_INSN_DELETED)
-(insn # 0 0 (set (reg:DI 10 10 [131])
+(insn # 0 0 (set (reg:DI 11 11 [+8 ])
 (zero_extend:DI (reg:HI 9 9 [orig:119 v.1_3 ] [119])))
"testcase.c":10:9# {zero_extendhidi2}
- (expr_list:REG_UNUSED (reg:DI 10 10 [131])
+ (expr_list:REG_UNUSED (reg:DI 11 11 [+8 ])
 (nil)))
 (insn # 0 0 (set (reg/f:DI 10 10 [128])
 (high:DI (unspec:DI [


$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1203-20220622112715-g038b077689b-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/13.0.0/lto-wrapper
Target: powerpc64le-unknown-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
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1203-20220622112715-g038b077689b-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220622 (experimental) (GCC)

[Bug c++/106057] Missed stmt_can_throw_external check in stmt_kills_ref_p

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jan Hubicka  ---
C only testcase (also misoptimized in clang)

#include 
int b;
jmp_buf buf;

__attribute__((noinline))
int maybethrow()
{
if (!b)
longjmp (buf,1);
return 2;
}

void
test(int *a)
{
*a=1;
*a=maybethrow();
}
int
main()
{
int a=-1;
if (setjmp (buf) == 1)
{
if (a!=1)
__builtin_abort ();
return 0;
}
test (&a);
return 0;
}

[Bug c++/106057] New: Missed stmt_can_throw_external check in stmt_kills_ref_p

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106057
   Summary: Missed stmt_can_throw_external check in
stmt_kills_ref_p
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

int a;
int b;

__attribute__((const))
int maybethrow()
{
if (!b)
throw(0);
return 0;
}

void
test()
{
a=1;
a=maybethrow();
a=0;
}
int
main()
{
try {
test();
}
catch(int) {
if (!a)
__builtin_abort ();
}
return 0;
}

aborts when built with -O2 while I think it should not.  The bug is that
 a=maybethrow()
is considered a kill which it is not since exception happens earlier.

I think we need:
diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index b1e7a2d5afc..7307e386f96 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -3337,7 +3338,9 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
 ???  We only need to care about the RHS throwing.  For aggregate
 assignments or similar calls and non-call exceptions the LHS
 might throw as well.  */
-  && !stmt_can_throw_internal (cfun, stmt))
+  && !stmt_can_throw_internal (cfun, stmt)
+  && (!stmt_can_throw_external (cfun, stmt)
+ || !ref_may_alias_global_p (ref, false)))
 {
   tree lhs = gimple_get_lhs (stmt);
   /* If LHS is literally a base of the access we are done.  */

[Bug c++/104642] Add __builtin_trap() for missing return at -O0

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |13.0

--- Comment #7 from Jason Merrill  ---
Implemented for GCC 13.

[Bug c/105660] [12/13 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9

[romain at dolbeau dot org via Gcc-bugs]

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

--- Comment #4 from Romain Dolbeau  ---
It seems the issue was an 'r' dropped from the name of 'strrchr' in the
offending commit. Fixing this resolves the bug for us. See the attached patch.

[Bug c/105660] [12/13 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9

[romain at dolbeau dot org via Gcc-bugs]

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

Romain Dolbeau  changed:

   What|Removed |Added

 CC||romain at dolbeau dot org

--- Comment #3 from Romain Dolbeau  ---
Created attachment 53191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53191&action=edit
Patch to resolve the issue by moving strchr to strrchr

[Bug c++/104642] Add __builtin_trap() for missing return at -O0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r13-1204-gd68d366425369649cb4e25a07752e25a4fff52cf
Author: Jason Merrill 
Date:   Fri Jun 10 16:35:21 2022 -0400

ubsan: default to trap on unreachable at -O0 and -Og [PR104642]

When not optimizing, we can't do anything useful with unreachability in
terms of code performance, so we might as well improve debugging by turning
__builtin_unreachable into a trap.  I think it also makes sense to do this
when we're explicitly optimizing for the debugging experience.

In the PR richi suggested introducing an -funreachable-traps flag for this.
This functionality is already implemented as -fsanitize=unreachable
-fsanitize-trap=unreachable, and we want to share the implementation, but
it
does seem useful to have a separate flag that isn't affected by the various
sanitization controls.  -fsanitize=unreachable takes priority over
-funreachable-traps if both are enabled.

Jakub observed that this would slow down -O0 by default from running the
sanopt pass, so this revision avoids the need for sanopt by rewriting calls
introduced by the compiler immediately, and calls written by the user at
fold time.  Many of the calls introduced by the compiler are also rewritten
immediately to ubsan calls when not trapping, which fixes ubsan-8b.C;
previously the call to f() was optimized away before sanopt.  But this
early
rewriting isn't practical for uses of __builtin_unreachable in
devirtualization and such, so sanopt rewriting is still done for
non-trapping sanitize.

PR c++/104642

gcc/ChangeLog:

* common.opt: Add -funreachable-traps.
* doc/invoke.texi (-funreachable-traps): Document it.
* opts.cc (finish_options): Enable at -O0 or -Og.
* tree.cc (build_common_builtin_nodes): Add __builtin_trap.
(builtin_decl_unreachable, build_builtin_unreachable): New.
* tree.h: Declare them.
* ubsan.cc (sanitize_unreachable_fn): Factor out.
(ubsan_instrument_unreachable): Use
gimple_build_builtin_unreachable.
* ubsan.h (sanitize_unreachable_fn): Declare.
* gimple.cc (gimple_build_builtin_unreachable): New.
* gimple.h: Declare it.
* builtins.cc (expand_builtin_unreachable): Add assert.
(fold_builtin_0): Call build_builtin_unreachable.
* sanopt.cc: Don't run for just SANITIZE_RETURN
or SANITIZE_UNREACHABLE when trapping.
* cgraphunit.cc (walk_polymorphic_call_targets): Use new
unreachable functions.
* gimple-fold.cc (gimple_fold_call)
(gimple_get_virt_method_for_vtable)
* ipa-fnsummary.cc (redirect_to_unreachable)
* ipa-prop.cc (ipa_make_edge_direct_to_target)
(ipa_impossible_devirt_target)
* ipa.cc (walk_polymorphic_call_targets)
* tree-cfg.cc (pass_warn_function_return::execute)
(execute_fixup_cfg)
* tree-ssa-loop-ivcanon.cc (remove_exits_and_undefined_stmts)
(unloop_loops)
* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt):
Likewise.

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_builtin_function_call): Handle
unreachable/trap earlier.
* cp-gimplify.cc (cp_maybe_instrument_return): Use
build_builtin_unreachable.

gcc/testsuite/ChangeLog:

* g++.dg/ubsan/return-8a.C: New test.
* g++.dg/ubsan/return-8b.C: New test.
* g++.dg/ubsan/return-8d.C: New test.
* g++.dg/ubsan/return-8e.C: New test.

[Bug target/106056] New: Missing call to targetm.asm_out.final_postscan_insn after processing an asm_input

[piannetta at kalrayinc dot com via Gcc-bugs]

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

Bug ID: 106056
   Summary: Missing call to targetm.asm_out.final_postscan_insn
after processing an asm_input
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piannetta at kalrayinc dot com
  Target Milestone: ---

Created attachment 53190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53190&action=edit
patch which adds a call to final_postscan_insn after the processing of an
asm_input

When an instruction is output, there should be a call to `final_postscan_insn`
but this is not the case after the processing of an asm_input.

I did not check from which version this call is missing but the surrounding
lines where last edited around 2007.

This patch adds the missing call to `final_postscan_insn`.

[Bug driver/93371] -ffile-prefix-map ignored with assembly files

[caleb.zulawski at gmail dot com via Gcc-bugs]

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

Caleb Zulawski  changed:

   What|Removed |Added

 CC||caleb.zulawski at gmail dot com

--- Comment #1 from Caleb Zulawski  ---
I just found this report--seems to be still an issue in 12.1.

[Bug tree-optimization/106054] Tree optimizations cause mcf generates incorrect results

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
It is the access via different pointer types. That is the issue.

[Bug tree-optimization/106054] Tree optimizations cause mcf generates incorrect results

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Aliasing violations are present.
Use -fno-strict-aliasing.

[Bug c++/106052] ICE with -Wmismatched-tags with partially specialized friend struct of self type

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2022-06-22

--- Comment #2 from Jonathan Wakely  ---
The ICE is still present on trunk.

[Bug c++/106051] -Wmismatched-tags gives false positive warning when "class C" is "using namespace"d into a namespace with another "class C" declaration

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-22
 Ever confirmed|0   |1

[Bug c++/106051] -Wmismatched-tags gives false positive warning when "class C" is "using namespace"d into a namespace with another "class C" declaration

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Confirmed. The -Wmismatched-tags warnings has always caused this incorrect
error since it was added in r279480

I don't think it qualifies as a regression, because using -Wmismatched-tags was
an error before that commit anyway, because the warning didn't exist at all.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

Bug 106019 Summary: Surprising SLP failure on trivial code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106019

   What|Removed |Added

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

[Bug tree-optimization/106019] Surprising SLP failure on trivial code

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed -- thanks for the catch.

[Bug tree-optimization/106019] Surprising SLP failure on trivial code

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:038b077689bb5310386b04d40a2cea234f01e6aa

commit r13-1203-g038b077689bb5310386b04d40a2cea234f01e6aa
Author: Richard Sandiford 
Date:   Wed Jun 22 11:27:15 2022 +0100

data-ref: Improve non-loop disambiguation [PR106019]

When dr_may_alias_p is called without a loop context, it tries
to use the tree-affine interface to calculate the difference
between the two addresses and use that difference to check whether
the gap between the accesses is known at compile time.  However, as the
example in the PR shows, this doesn't expand SSA_NAMEs and so can easily
be defeated by things like reassociation.

One fix would have been to use aff_combination_expand to expand the
SSA_NAMEs, but we'd then need some way of maintaining the associated
cache.  This patch instead reuses the innermost_loop_behavior fields
(which exist even when no loop context is provided).

It might still be useful to do the aff_combination_expand thing too,
if an example turns out to need it.

gcc/
PR tree-optimization/106019
* tree-data-ref.cc (dr_may_alias_p): Try using the
innermost_loop_behavior to disambiguate non-loop queries.

gcc/testsuite/
PR tree-optimization/106019
* gcc.dg/vect/bb-slp-pr106019.c: New test.

[Bug tree-optimization/106055] New: [13 Regression] ICE in replace_uses_by, at tree-cfg.cc:1989

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 106055
   Summary: [13 Regression] ICE in replace_uses_by, at
tree-cfg.cc:1989
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20220619 snapshot (g:4390e7bfbc641a52c6192b448768dafdf4565527) ICEs
when compiling the following testcase w/ -Os -floop-parallelize-all
-fno-tree-dce:

__attribute__ ((returns_twice)) int
bar (void);

void
quux (void);

void
empty (void)
{
}

unsigned int
choose (unsigned int x, unsigned int y)
{
  return y ? x : 0;
}

int
foo (int *p, unsigned int x, int y)
{
  unsigned int acc = 0;

  empty ();

  while (x)
{
  bar ();
  ++x;
}

  while (y)
acc += y;

  *p = choose (acc, 1);
  quux ();

  return x;
}

% gcc-13.0.0 -Os -floop-parallelize-all -fno-tree-dce -c e2hatkyd.c
during GIMPLE pass: graphite
e2hatkyd.c: In function 'foo':
e2hatkyd.c:19:1: internal compiler error: in replace_uses_by, at
tree-cfg.cc:1989
   19 | foo (int *p, unsigned int x, int y)
  | ^~~
0x73a403 replace_uses_by(tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220619/work/gcc-13-20220619/gcc/tree-cfg.cc:1989
0x1d361b2 canonicalize_loop_closed_ssa
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220619/work/gcc-13-20220619/gcc/graphite.cc:342
0x1d361b2 canonicalize_loop_form
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220619/work/gcc-13-20220619/gcc/graphite.cc:386
0x1d361b2 graphite_transform_loops()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220619/work/gcc-13-20220619/gcc/graphite.cc:435
0x1d376c0 graphite_transforms
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220619/work/gcc-13-20220619/gcc/graphite.cc:536
0x1d376c0 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220619/work/gcc-13-20220619/gcc/graphite.cc:613

[Bug c++/104160] Wrongly allowed: Function argumentin constant expression

[csaba_22 at yahoo dot co.uk via Gcc-bugs]

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

Csaba Ráduly  changed:

   What|Removed |Added

 CC||csaba_22 at yahoo dot co.uk

--- Comment #5 from Csaba Ráduly  ---
Here's my simple example:

https://godbolt.org/z/9aMevabbq

[Bug tree-optimization/106054] New: Tree optimizations cause mcf generates incorrect results

[dizhao at os dot amperecomputing.com via Gcc-bugs]

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

Bug ID: 106054
   Summary: Tree optimizations cause mcf generates incorrect
results
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dizhao at os dot amperecomputing.com
  Target Milestone: ---

Created attachment 53189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53189&action=edit
test code in C

Some tree optimization caused verification error on the spec2017 505.mcf test
case.

Attached is a small example I extracted, to help debugging the problem.
When compiled with "-std=c99 -O2 -funroll-loops -fdisable-tree-slp1" the result
is different with "-std=c99 -O2 -funroll-loops", the latter result is
incorrect. (It is possible the problem is not slp itself. I haven't figured out
the root cause by now.)

Tested on trunk commit: 98b6e62cf5e7d477b5797084da59561f6d018668 . And the
error seems to exist at least since trunk commit
a1c9f779f75283427316b5c670c1e01ff8ce9ced.

Thanks.

[Bug c++/106040] gcc reports error in aggregate when member has explicit constructor

[pj at patrickjohnston dot org via Gcc-bugs]

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

pj at patrickjohnston dot org changed:

   What|Removed |Added

 CC||pj at patrickjohnston dot org

--- Comment #2 from pj at patrickjohnston dot org ---
Note that http://eel.is/c++draft/dcl.init.aggr#4.2
> the element is copy-initialized from the corresponding initializer-clause or 
> is initialized with the brace-or-equal-initializer of the corresponding 
> designated-initializer-clause
possibly suggests that copy initialisation semantics are used (meaning no
explicit conversion), dependent on if your interpretation agrees that the
"copy-initialized" bit still applies to the brace-or-equal-initializer bit