[Bug c++/106011] New: [12 Regression] ICE: unexpected expression 'ElemSize' of kind template_parm_index

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

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

Bug ID: 106011
   Summary: [12 Regression] ICE: unexpected expression 'ElemSize'
of kind template_parm_index
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with the gcc-12 branch 20220616, trying to build the 0ad package:

$ cat Unified_cpp_js_src4.ii
typedef unsigned size_t;
template  decltype(0 % ElemSize == 0)

$ LANG=C g++ -c -O0 Unified_cpp_js_src4.ii
Unified_cpp_js_src4.ii:2:50: internal compiler error: unexpected expression
'ElemSize' of kind template_parm_index
2 | template  decltype(0 % ElemSize == 0)
  | ~^~~~
0x6d9b71 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.cc:7587
0x6d9ec0 cxx_eval_outermost_constant_expr
../../src/gcc/cp/constexpr.cc:7824
0x6dbdcc potential_constant_expression_1
../../src/gcc/cp/constexpr.cc:9274
0x6dc636 potential_constant_expression_1(tree_node*, bool, bool, bool, int)
../../src/gcc/cp/constexpr.cc:9550
0x6dc636 is_constant_expression(tree_node*)
../../src/gcc/cp/constexpr.cc:9607
0x6dc636 is_nondependent_constant_expression(tree_node*)
../../src/gcc/cp/constexpr.cc:9644
0x6dd0c0 maybe_constant_value(tree_node*, tree_node*, bool)
../../src/gcc/cp/constexpr.cc:8071
0x7435eb fold_for_warn(tree_node*)
../../src/gcc/cp/expr.cc:416
0x8ad582 shorten_compare(unsigned int, tree_node**, tree_node**, tree_node**,
tree_code*)
../../src/gcc/c-family/c-common.cc:3237
0x86fef7 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
../../src/gcc/cp/typeck.cc:6158
0x6b97ac build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
../../src/gcc/cp/call.cc:6935
0x866dff build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
../../src/gcc/cp/typeck.cc:4563
0x80a7c7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.cc:20369
0x80e32a instantiate_non_dependent_expr_internal(tree_node*, int)
../../src/gcc/cp/pt.cc:6367
0x80e32a instantiate_non_dependent_expr_sfinae(tree_node*, int)
../../src/gcc/cp/pt.cc:6388
0x846e6f finish_decltype_type(tree_node*, bool, int)
../../src/gcc/cp/semantics.cc:11255
0x7cfb31 cp_parser_decltype
../../src/gcc/cp/parser.cc:16540
0x7e7447 cp_parser_simple_type_specifier
../../src/gcc/cp/parser.cc:19647
0x7c5435 cp_parser_type_specifier
../../src/gcc/cp/parser.cc:19424
0x7c6349 cp_parser_decl_specifier_seq
../../src/gcc/cp/parser.cc:15905
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Why would you expect gfortran to support a non-existent Fortran standard?

[Bug c++/106011] [12 Regression] ICE: unexpected expression 'ElemSize' of kind template_parm_index

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
An almost exact dup of bug 105931.

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

[Bug c++/105931] [12/13 regression] ICE in cxx_eval_constant_expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

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

[Bug target/106012] New: rsqrtss instruction generated even if -mno-recip specified

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

Bug ID: 106012
   Summary: rsqrtss instruction generated even if -mno-recip
specified
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

with option -Ofast -mno-recip rsqrtss instruction is still generated.

https://godbolt.org/z/hGxrG7xPh

inhibiting rsqrtss and rcpss is critical to obtain identical results when
running on INTEL and AMD platforms. Having to inhibit Ofast is clearly a larger
performance penalty.

[Bug libstdc++/106013] New: weakly_incrementable cannot apply on common_iterator

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 106013
   Summary: weakly_incrementable cannot apply on common_iterator
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

At the moment I don't know why this is recursive, I'll try to reduce it when I
have time. So let me assume this is a libstdc++ bug and not a language bug.

#include 

struct I {
  using difference_type = int;
  int operator*() const;
  I& operator++();
  I operator++(int);
};

using CI = std::common_iterator;
static_assert(std::weakly_incrementable);

https://godbolt.org/z/661djbrPs

[Bug libstdc++/106013] weakly_incrementable cannot apply on common_iterator

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
Note that if I add using value_type = int it will compile fine.

[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
emit_move_insn in this part of ix86_output_mi_thunk:

21464 if (!sibcall_insn_operand (fnaddr, word_mode))
21465   {
21466 tmp = gen_rtx_REG (word_mode, tmp_regno);
21467 if (GET_MODE (fnaddr) != word_mode)
21468   fnaddr = gen_rtx_ZERO_EXTEND (word_mode, fnaddr);
21469 emit_move_insn (tmp, fnaddr);
21470 fnaddr = tmp;
21471   }

is creating RTX with pseudos when trying to move fnaddr:

(symbol_ref:SI ("*.LTHUNK0") [flags 0x3] )

to a temporary register:

(insn 6 5 7 (set (reg:SI 82)
(plus:SI (reg:SI 82)
(const:SI (unspec:SI [
(symbol_ref:SI ("*.LTHUNK0") [flags 0x3] )
] UNSPEC_GOTOFF "pr105980.C":4:8 -1
 (nil))

(insn 7 6 8 (set (reg:SI 2 cx)
(reg:SI 82)) "pr105980.C":4:8 -1
 (expr_list:REG_EQUAL (symbol_ref:SI ("*.LTHUNK0") [flags 0x3]
)
(nil)))

This won't fly when we are in the final pass, way late after reload.

[Bug target/106004] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-06-17
   Assignee|unassigned at gcc dot gnu.org  |rearnsha at gcc dot 
gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Earnshaw  ---
Mine.  Same underlying problem as PR105974.

[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

--- Comment #8 from Kewen Lin  ---
(In reply to Kewen Lin from comment #6)
> (In reply to Kewen Lin from comment #4)
> > (In reply to Richard Biener from comment #2)
> > > (In reply to Kewen Lin from comment #1)
> > > > Created attachment 53126 [details]
> > > > move_applying
> > > 
> > > LGTM (maybe the suggested unroll factor should be only applied if the
> > > suggestion was from a matching with/without SLP analysis, or in fact
> > > vect_analyze_loop_1 should communicate that down - disabling SLP when
> > > the one suggesting unrolling did the re-analysis).
> > 
> > Oops, just noticed the nice suggestion.  Will make a follow up patch for
> > this.
> > It would looks like:
> >   when working out suggested unroll factor, save slp decision into one
> > passed down variable from vect_analyze_loop_1.
> >   when applying suggested unroll factor, if the save slp is false, directly
> > ignore slp handlings, otherwise, go the normal slp path but won't start over
> > for slp off.
> 
> I tested one patch which was bootstrapped and regress-tested on x86, aarch64
> and powerpc64le, but found some failures on SPEC2017 run with rs6000
> hackings, the reason to fail is that we can save reduction chain in
> vect_is_simple_reduction for further analysis in SLP detection, if we
> aggressively skip SLP related analyses in vect_analyze_loop_2, there is ICE
> in vectorizable_reduction
> 
> if (REDUC_GROUP_FIRST_ELEMENT (stmt_info))
>   gcc_assert (slp_node
>   && REDUC_GROUP_FIRST_ELEMENT (stmt_info) == stmt_info);
> 
> There seem to be some alternatives:
>   1) check if applying_suggested_uf && !slp_done_for_suggested_uf initially
> in vect_analyze_loop_2, if yes, pass slp disabled information down to
> vect_is_simple_reduction, not to save reduction chain for later slp analysis
> (not existed).
>   2) before we are going to do the slp related analyses (vect_analyze_slp
> etc.), check if applying_suggested_uf && !slp_done_for_suggested_uf, if yes,
> dissolve LOOP_VINFO_REDUCTION_CHAINS(loop_info).
>   3) for the case applying_suggested_uf && !slp_done_for_suggested_uf, we
> still let it go through slp related analyses but not applying suggested
> unroll factor, only applying for its retry without slp.
> 
> 3) is simple but seems to be the worst since we still do some useless
> analyses.
> 1) can save the reduction chain handlings, seems to be the best, not sure if
> it's too intrusive, and if there are some similar needs (in future) to do so.
> 2) is similar to 1), it's to add one common place to undo those previous
> analysis results which are only for slp analyses and can cause unexpected
> result if we don't undo it.
> 
> Any suggestions on this?

Sent out one tested patch for 1) at
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596788.html

[Bug libstdc++/106014] New: Overload std::distance for filesystem::recursive_directory_iterator

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

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

Bug ID: 106014
   Summary: Overload std::distance for
filesystem::recursive_directory_iterator
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

See
https://www.reddit.com/r/cpp/comments/vdtlzp/comment/icn3fva/?utm_source=share&utm_medium=web2x&context=3

A user reported that a C++ program (using GCC) to count the number of files
under a directory is 5x slower than the Rust equivalent. The reason is that
dereferencing a directory iterator has to construct a filesystem::path, which
is expensive. Avoiding the dereference improves it a lot, but it's still 2x
slower.

By defining a specialized overload of std::distance for
filesystem::recursive_iterator we can double the speed of the C++ version and
slightly beat the Rust code that uses the walkdir crate (although the jwalk
crate is still faster).


The custom overload looks like this:

--- a/libstdc++-v3/include/bits/fs_dir.h
+++ b/libstdc++-v3/include/bits/fs_dir.h
@@ -44,6 +44,10 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION

+  ptrdiff_t
+  distance(filesystem::recursive_directory_iterator,
+  filesystem::recursive_directory_iterator);
+
 namespace filesystem
 {
   /** @addtogroup filesystem
@@ -545,6 +549,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 filesystem::remove_all(const path&, error_code&);
 friend uintmax_t
 filesystem::remove_all(const path&);
+
+friend ptrdiff_t
+std::distance(recursive_directory_iterator, recursive_directory_iterator);
   };

   /// @relates std::filesystem::recursive_directory_iterator @{


--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -559,3 +564,25 @@ fs::recursive_directory_iterator::__erase(error_code*
ecptr)

   return *this;
 }
+
+std::ptrdiff_t
+std::distance(fs::recursive_directory_iterator first,
+ fs::recursive_directory_iterator last)
+{
+  if (first == last)
+return 0;
+
+#if _GLIBCXX_HAVE_DIRFD
+  if (last == fs::recursive_directory_iterator())
+{
+  first._M_dirs->options |= __directory_iterator_filename_only;
+  first._M_dirs->top().path.clear();
+}
+#endif
+
+  ptrdiff_t d = 0;
+  do
+++d;
+  while (++first != last);
+  return d;
+}


(Additional changes are needed to export the symbols from the shared lib).

The libstdc++ code for actually walking directories is reasonably efficient,
all the overhead is in creating the path objects that are required for the
public API. So the trick is to avoid storing the path when we increment the
iterator, because we know that it will never be needed by std::distance. This
is only possible when using ::dirfd and ::openat to recurse into directories,
because without those we do need the path. For an OS without those POSIX
functions the custom std::distance will be no faster than the naive handwritten
loop (but no slower).

It should be worth doing for filesystem::directory_iterator too, but I haven't
benchmarked that. I think that would just require clearing the path stored in
the _Dir.

[Bug tree-optimization/106012] rsqrtss instruction generated even if -mno-recip specified

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-06-17
  Component|target  |tree-optimization
 Status|UNCONFIRMED |NEW

--- Comment #1 from Uroš Bizjak  ---
recip pass is converting to .RSQRT, target is just expanding what it gets.

[Bug libstdc++/106014] Overload std::distance for filesystem::recursive_directory_iterator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
N.B. using std::ranges::distance defeats this optimization, because that is not
customizable by providing an overload of distance. So we'd need to add extra
code to ranges::distance.operator() to recognize directory iterators and then
dispatch to std::distance to get the optimized code.

[Bug libstdc++/106014] Overload std::distance for filesystem::recursive_directory_iterator

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

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

--- Comment #2 from Jonathan Wakely  ---
We already have a custom std::distance for filesystem::path::iterator, and
std::ranges::distance doesn't use that either. Maybe we want to add a
customization point for std::ranges::distance that we can use internally.

We also already have a custom std::advance for filesystem::path::iterator,
because we can advance by N steps in O(1) instead of O(N). That might be
possible for directory iterators too, so that advancing a directory iterator by
N would only create a path for the final increment, not the intermediate ones.
It wouldn't be O(1) but it would be a much cheaper O(N) than it is now.

[Bug libstdc++/106014] Overload std::distance for filesystem::recursive_directory_iterator

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

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

--- Comment #3 from Jonathan Wakely  ---
Also, ranges::advance doesn't use the custom advance for path::iterator. Maybe
we should make path::iterator satisfy the random_access_iterator concept. We
can't do that for directory iterators though, so maybe we want another
customization point for internal use.

[Bug target/106004] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Earnshaw :

https://gcc.gnu.org/g:040f8224617ad3924f606c8982da369f898693d1

commit r13-1152-g040f8224617ad3924f606c8982da369f898693d1
Author: Richard Earnshaw 
Date:   Fri Jun 17 14:25:51 2022 +0100

arm: fix checking ICE in arm_print_operand [PR106004]

Sigh, another instance where I incorrectly used XUINT instead of
UINTVAL.

I've also made the code here a little more robust (although I think
this case can't in fact be reached) if the 32-bit clear mask includes
bit 31.  This case, if reached, would print out an out-of-range value
based on the size of the compiler's HOST_WIDE_INT type due to
sign-extension.  We avoid this by masking the value after inversion.

gcc/ChangeLog:
PR target/106004
* config/arm/arm.cc (arm_print_operand, case 'V'): Use UINTVAL.
Clear bits in the mask above bit 31.

[Bug target/106004] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Earnshaw  ---
Fixed

[Bug target/105993] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -O -mxop

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r13-1155-g1d6044c250e3badfa2a403fee670b295106bf4fc
Author: Uros Bizjak 
Date:   Fri Jun 17 16:22:20 2022 +0200

i386: Fix VPMOV splitter [PR105993]

REGNO should not be used with register_operand before reload because
subregs of registers or even subregs of memory match the predicate.
The build with RTL checking enabled does not tolerate REGNO with
non-reg operand.
The patch splits the splitter into two related splitters and uses
(match_dup ...) RTXes instead of REGNO comparisons.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105993
* config/i386/sse.md (vpmov splitter): Use (match_dup ...)
instead of REGNO comparisons in combine splitter.

gcc/testsuite/ChangeLog:

PR target/105993
* gcc.target/i386/pr105993.c: New test.

[Bug c/106015] New: [PowerPC] pointer to MMA accumulator not convertible to char pointer

[nemanja.i.ibm at gmail dot com via Gcc-bugs]

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

Bug ID: 106015
   Summary: [PowerPC] pointer to MMA accumulator not convertible
to char pointer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nemanja.i.ibm at gmail dot com
  Target Milestone: ---

Code:
$ cat aa.c 
unsigned char *conv(__vector_quad *a) {
  return (unsigned char *)a;
}

Compile:
gcc -mcpu=power10 -O3 aa.c -S
aa.c:2:3: error: invalid conversion from type '* __vector_quad'
2 |   return (unsigned char *)a;
  |   ^~

Version:
gcc --version
gcc (GCC) 12.1.1 20220524 [releases/gcc-12 r12-8410-gf0a0aeec44]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/105993] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -O -mxop

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug c/106016] New: [PowerPC] crash with attempt to initialize array of MMA accumulators

[nemanja.i.ibm at gmail dot com via Gcc-bugs]

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

Bug ID: 106016
   Summary: [PowerPC] crash with attempt to initialize array of
MMA accumulators
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nemanja.i.ibm at gmail dot com
  Target Milestone: ---

Code:
$ cat aa.c 
void array_crash(__vector_quad *a, __vector_quad *b) {
  __vector_quad arr[2] = {*a, *b}; // Should not crash
}

Compile:
$ /opt/gcc-nightly/12/bin/gcc -mcpu=power10 -O3 aa.c -S
aa.c: In function 'array_crash':
aa.c:2:17: internal compiler error: in count_type_elements, at expr.cc:6407
2 |   __vector_quad arr[2] = {*a, *b}; // Should not crash
  | ^~~
0x105583df count_type_elements
/home/gccbuild/gcc_12_git/gcc/gcc/expr.cc:6407
0x1055cd3b categorize_ctor_elements_1
/home/gccbuild/gcc_12_git/gcc/gcc/expr.cc:6519
0x10646293 gimplify_init_constructor
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:5179
0x10647643 gimplify_modify_expr
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:6040
0x10639d93 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:15098
0x10643fd3 gimplify_stmt(tree_node**, gimple**)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:7151
0x10643fd3 gimplify_and_add(tree_node*, gimple**)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:496
0x10643fd3 gimplify_decl_expr
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:1936
0x1063ad0b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:15295
0x10642b6f gimplify_stmt(tree_node**, gimple**)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:7151
0x10642b6f gimplify_bind_expr
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:1428
0x1063a79b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:15299
0x1063e3d7 gimplify_stmt(tree_node**, gimple**)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:7151
0x1063e3d7 gimplify_body(tree_node*, bool)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:16355
0x1063e83b gimplify_function_tree(tree_node*)
/home/gccbuild/gcc_12_git/gcc/gcc/gimplify.cc:16509
0x1044cab7 cgraph_node::analyze()
/home/gccbuild/gcc_12_git/gcc/gcc/cgraphunit.cc:676
0x1044fbf7 analyze_functions
/home/gccbuild/gcc_12_git/gcc/gcc/cgraphunit.cc:1241
0x10450893 symbol_table::finalize_compilation_unit()
/home/gccbuild/gcc_12_git/gcc/gcc/cgraphunit.cc:2501
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.

Version:
$ /opt/gcc-nightly/12/bin/gcc --version
gcc (GCC) 12.1.1 20220524 [releases/gcc-12 r12-8410-gf0a0aeec44]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[wileamyp at outlook dot com via Gcc-bugs]

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

--- Comment #2 from Wileam Yonatan Phan  ---
Wait, I thought the committee is ready to vote on it? I've seen the draft of
the summary paper by Reid linked from here:

[Bug c/106017] New: [PowerPC] No array-to-pointer conversion for MMA accumulator

[nemanja.i.ibm at gmail dot com via Gcc-bugs]

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

Bug ID: 106017
   Summary: [PowerPC] No array-to-pointer conversion for MMA
accumulator
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nemanja.i.ibm at gmail dot com
  Target Milestone: ---

It appears that the typical array to pointer conversion for function arguments
does not work for MMA accumulator types. The user has to explicitly convert.

Code:
$ cat aa.c 
void takeacc(__vector_quad *);
void passacc() {
__vector_quad arr[4];
#ifdef _EXPLICIT
takeacc(&arr[0]);
#else
takeacc(arr);
#endif
}

Compile (success):
$ gcc -mcpu=power10 -O3 aa.c -S -D_EXPLICIT && echo Success
Success

Compile (failure):
$ gcc -mcpu=power10 -O3 aa.c -S && echo Success
aa.c: In function 'passacc':
aa.c:7:9: error: invalid conversion to type '* __vector_quad'
7 | takeacc(arr);
  | ^~~

Version:
$ gcc --version
gcc (GCC) 12.1.1 20220524 [releases/gcc-12 r12-8410-gf0a0aeec44]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Fri, Jun 17, 2022 at 02:31:20PM +, wileamyp at outlook dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005
> 
> --- Comment #2 from Wileam Yonatan Phan  ---
> Wait, I thought the committee is ready to vote on it? I've seen the draft of
> the summary paper by Reid linked from here:
> 
> 

Everything you said is correct.  The committee is ready to vote,
but it is still a none existent standard.  The first thing required
for gfortran to support any F2023 feature would be the addition of
a -std=2023.  This has not been implemented, yet.

I'll also note that things don't magically appear in gfortran.
Someone has to implement it.

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #4 from Steve Kargl  ---
On Fri, Jun 17, 2022 at 02:31:20PM +, wileamyp at outlook dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005
> 
> --- Comment #2 from Wileam Yonatan Phan  ---
> Wait, I thought the committee is ready to vote on it? I've seen the draft of
> the summary paper by Reid linked from here:
> 
> 

Everything you said is correct.  The committee is ready to vote,
but it is still a none existent standard.  The first thing required
for gfortran to support any F2023 feature would be the addition of
a -std=2023.  This has not been implemented, yet.

I'll also note that things don't magically appear in gfortran.
Someone has to implement it.

[Bug c++/106011] [12 Regression] ICE: unexpected expression 'ElemSize' of kind template_parm_index

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #2 from Sam James  ---
Indeed, from the same source :)

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[wileamyp at outlook dot com via Gcc-bugs]

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

--- Comment #5 from Wileam Yonatan Phan  ---
Hi Steve,

I think I recognize you from the Fortran-lang Discourse forum!

> The committee is ready to vote, but it is still a non-existent standard.

That's technically true, since the votes haven't been cast, yet.

> The first thing required for gfortran to support any F2023 feature would be 
> the addition of a -std=f2023.  This has not been implemented, yet.

That is correct, and I guess work on implementing the `-std=f2023` flag will
start as soon as the standard is agreed upon and published. Do you know when
the committee will meet to vote?

> I'll also note that things don't magically appear in gfortran. Someone has to 
> implement it.

Hopefully I will be able to implement this particular part (REDUCE) as part of
my GSoC '22 project
. The
second phase of the project specifically addresses support in the parser, and
the third phase implements the actual parallelization.

So, my intention on filing this bug is to have a public record for tracking my
project's progress. I'll also periodically blog about it at
 and


Wish me luck!

Thanks,
Wil

[Bug c/105970] ICE in ix86_function_arg, at config/i386/i386.cc:3351

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r13-1156-g1f8278bfcfc7f7157bf2b405471e67dd5097636b
Author: Uros Bizjak 
Date:   Fri Jun 17 17:01:31 2022 +0200

i386: Fix assert in ix86_function_arg [PR105970]

The mode of pointer argument should equal ptr_mode, not Pmode.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105970
* config/i386/i386.cc (ix86_function_arg): Assert that
the mode of pointer argumet is equal to ptr_mode, not Pmode.

gcc/testsuite/ChangeLog:

PR target/105970
* gcc.target/i386/pr105970.c: New test.

[Bug target/105209] internal compiler error: in store_data_bypass_p_1

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r13-1157-gcc378e655740e93743e7f43e14faaff707aef6c1
Author: Uros Bizjak 
Date:   Fri Jun 17 17:19:44 2022 +0200

alpha: Introduce target specific store_data_bypass_p function [PR105209]

This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal
compiler error) in the generic store_data_bypass_p function.

While at it, also remove ev4_ist_c reservation, store_data_bypass_p
can handle the patterns with multiple sets since some time ago.

2022-06-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/105209
* config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New.
* config/alpha/alpha.cc (alpha_store_data_bypass_p): New function.
(alpha_store_data_bypass_p_1): Ditto.
* config/alpha/ev4.md: Use alpha_store_data_bypass_p instead
of generic store_data_bypass_p.
(ev4_ist_c): Remove insn reservation.

gcc/testsuite/ChangeLog:

PR target/105209
* gcc.target/alpha/pr105209.c: New test.

[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935

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

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

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

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

commit r13-1158-ga284fadcce8ef443cc3cc047a8017745efb51758
Author: Jakub Jelinek 
Date:   Fri Jun 17 17:40:49 2022 +0200

c++: Use fold_non_dependent_expr rather than maybe_constant_value in
__builtin_shufflevector handling [PR106001]

In this case the STATIC_CAST_EXPR expressions in the call aren't
type nor value dependent, but maybe_constant_value still ICEs on those
when processing_template_decl.  Calling fold_non_dependent_expr on it
instead fixes the ICE and folds them to INTEGER_CSTs.

2022-06-17  Jakub Jelinek  

PR c++/106001
* typeck.cc (build_x_shufflevector): Use fold_non_dependent_expr
instead of maybe_constant_value.

* g++.dg/ext/builtin-shufflevector-4.C: New test.

[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer

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

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

--- Comment #3 from Tim Lange  ---
See also this mailing list thread:
https://gcc.gnu.org/pipermail/gcc/2022-June/238907.html

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Fri, Jun 17, 2022 at 02:56:50PM +, wileamyp at outlook dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005
> 
> --- Comment #5 from Wileam Yonatan Phan  ---
> Hi Steve,
> 
> I think I recognize you from the Fortran-lang Discourse forum!
> 

Yep.

> > The committee is ready to vote, but it is still a non-existent standard.
> 
> That's technically true, since the votes haven't been cast, yet.
> 
> > The first thing required for gfortran to support any F2023 feature would be 
> > the addition of a -std=f2023.  This has not been implemented, yet.
> 
> That is correct, and I guess work on implementing the `-std=f2023` flag will
> start as soon as the standard is agreed upon and published. Do you know when
> the committee will meet to vote?

I've seem some voting in the J3 mailing list, bu that may have
been for interpretation requests against the current standard.
J3 is scheduled to meet in July.  If J3 hasn't passed F2023 to
ISO yet, then it likely will be finalized at this meeting.


> > I'll also note that things don't magically appear in gfortran. Someone has 
> > to implement it.
> 
> Hopefully I will be able to implement this particular part (REDUCE) as part of
> my GSoC '22 project
> . The
> second phase of the project specifically addresses support in the parser, and
> the third phase implements the actual parallelization.
> 
> So, my intention on filing this bug is to have a public record for tracking my
> project's progress. I'll also periodically blog about it at
>  and
> 
> 

I haven't used DO CURRENT in my own codes so only have a small
amount of exposure to what gfortran does.  I suspect it is 
missing some, if not most, of the locality stuff from F2018.
If you have general questions about gfortran internals, feel
free to ping me.

[Bug c/106018] New: Feature Request: Add function attribute fn_enter, and fn_exit

[alan.rosenthal at gmail dot com via Gcc-bugs]

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

Bug ID: 106018
   Summary: Feature Request: Add function attribute fn_enter, and
fn_exit
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alan.rosenthal at gmail dot com
  Target Milestone: ---

Add a function attributes: fn_enter and fn_exit to auto generate functions that
are called before a function starts and after a function ends.

This function:
char myfn(int param1, bool pararm2, void* param3) __attribute__ ((fn_enter,
fn_exit)) {
  if (param1) {
return '0';
  }
  if (param2) {
return '1';
  }
  char ret = (char) param3;
  return ret;
}

Would generated these two functions:

void __enter_myfn(int param1, bool pararm2, void* param3);
void __exit_myfn(char ret);

These functions would be called during normal enter/exit conditions, i.e.:
char myfn(int param1, bool pararm2, void* param3) __attribute__ ((fn_enter,
fn_exit)) {
  __enter_myfn(param1, param2, param3);
  if (param1) {
__exit_fn('0');
return '0';
  }
  if (param2) {
__exit_fn('1');
return '1';
  }
  char ret = (char) param3;
  __exit_fn(ret);
  return ret;
}


This would allow a developer to easily add diagnostics to a specific function
to get a better sense of how often it was called, with what arguments, and what
the return value were. 

Similarly functionality exists in -finstrument-functions, but it doesn't
provide a way to capture function parameters or return values.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
Confirmed.

C allows to convert a pointer to data to any other pointer to data (possibly
modulo alignment restrictions).  What is *not* valid is accessing anything via
a type not compatible with its effective type (or via a character type).

So the restriction in rs6000_invalid_conversion errors for valid C programs.
What was it intended to accomplish?

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  Thanks for reporting these bugs!

[Bug target/106015] [PowerPC] pointer to MMA accumulator not convertible to char pointer

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #1 from Peter Bergner  ---
Confirmed.

[Bug target/106015] [PowerPC] pointer to MMA accumulator not convertible to char pointer

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

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

--- Comment #2 from Segher Boessenkool  ---
Confirmed.  Likely the same cause as PR106017.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

--- Comment #2 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #1)
> So the restriction in rs6000_invalid_conversion errors for valid C programs.
> What was it intended to accomplish?

We do not want or allow automatic conversions between the opaque __vector_pair
and __vector_quad types and other types and those are correctly disallowed
there.  Conversions between those types needs to go through the builtins
defined for that.

As for the pointer conversions tested there, I guess they came along for the
ride?  Nemanja, do you remember the history there?  Or does LLVM allow the
pointer conversions and it's just GCC that complains?

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #2 from Peter Bergner  ---
Given where this is ICEing, I'm guessing this is non-target specific issue in
handling opaque types.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

--- Comment #3 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #2)
> We do not want or allow automatic conversions between the opaque
> __vector_pair and __vector_quad types and other types and those are
> correctly disallowed there.

Of course, but that is not what this is about...

> As for the pointer conversions tested there, I guess they came along for the
> ride?  Nemanja, do you remember the history there?  Or does LLVM allow the
> pointer conversions and it's just GCC that complains?

... this is.

Possibly the restriction prevents some ICEs elsewhere, but those just need to
be solved then, not hidden.

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #3 from Segher Boessenkool  ---
Yeah.  It should just return 1 like the other scalar types?

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

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

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

Bug ID: 106019
   Summary: Surprising SLP failure on trivial code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

In the following code, 'f' is not SLP-vectorized, but 'g' is. From a brief look
at slp2 dump, looks like dependence analysis for p[i] vs. p[i+1] fails?

void f(double *p, long i)
{
p[i+0] += 1;
p[i+1] += 1;
}
void g(double *p, long i)
{
double *q = p + i;
q[0] += 1;
q[1] += 1;
}

[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #7 from hubicka at kam dot mff.cuni.cz ---
> I can try implementing that.
That would be nice.  I think if path predictor logic hits the same
predictor both ways, it can simply predict that basic block with the
same predictor (i.e. recurse on that block).   It will need to keep
track what basic blocks were already predicted to handle cycles.

Honza

[Bug preprocessor/64698] preprocessor ignores #pragma GCC diagnostic when using -save-temps

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||lhyatt at gcc dot gnu.org

--- Comment #3 from Lewis Hyatt  ---
It is indeed a dup of PR53920. Also, I have a patch awaiting review for
PR53431; that fixes all 3.

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

[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"

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

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

--- Comment #4 from Lewis Hyatt  ---
*** Bug 64698 has been marked as a duplicate of this bug. ***

[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #5 from Lewis Hyatt  ---
I have a patch awaiting review to fix PR53431 which would fix this one too.
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

[nemanja.i.ibm at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Nemanja Ivanovic  ---
(In reply to Peter Bergner from comment #2)
> (In reply to Segher Boessenkool from comment #1)
> > So the restriction in rs6000_invalid_conversion errors for valid C programs.
> > What was it intended to accomplish?
> 
> We do not want or allow automatic conversions between the opaque
> __vector_pair and __vector_quad types and other types and those are
> correctly disallowed there.  Conversions between those types needs to go
> through the builtins defined for that.
> 
> As for the pointer conversions tested there, I guess they came along for the
> ride?  Nemanja, do you remember the history there?  Or does LLVM allow the
> pointer conversions and it's just GCC that complains?

Yes, the desired semantics are to disallow implicit or explicit conversions
from these types to any other types. But pointer casts (presumably including
reinterpret_cast in C++) should be fair game. Clang allows these conversions.

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #4 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #3)
> Yeah.  It should just return 1 like the other scalar types?

So the code did look for OPAQUE_TYPE and expected never to see it, so it was on
an error path.  I agree with your comment above and I'm guessing we want
something like:

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 78c839ab425..1675198a146 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool for_ctor_p)
 case OFFSET_TYPE:
 case REFERENCE_TYPE:
 case NULLPTR_TYPE:
+case OPAQUE_TYPE:
   return 1;

 case ERROR_MARK:
   return 0;

 case VOID_TYPE:
-case OPAQUE_TYPE:
 case METHOD_TYPE:
 case FUNCTION_TYPE:
 case LANG_TYPE:

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #5 from Peter Bergner  ---
(In reply to Peter Bergner from comment #4)
> diff --git a/gcc/expr.cc b/gcc/expr.cc
> index 78c839ab425..1675198a146 100644
> --- a/gcc/expr.cc
> +++ b/gcc/expr.cc
> @@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool
> for_ctor_p)
>  case OFFSET_TYPE:
>  case REFERENCE_TYPE:
>  case NULLPTR_TYPE:
> +case OPAQUE_TYPE:
>return 1;
>  
>  case ERROR_MARK:
>return 0;
>  
>  case VOID_TYPE:
> -case OPAQUE_TYPE:
>  case METHOD_TYPE:
>  case FUNCTION_TYPE:
>  case LANG_TYPE:

It does fix the ICE.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Okay, I'll handle it.

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #6 from Segher Boessenkool  ---
Like that yes.  Pre-approved if it survives regcheck, too.  Thanks!

Please add the testcase as well of course :-)

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

--- Comment #6 from Segher Boessenkool  ---
FWIW, reinterpret_cast allows exactly the same things as C casts (but with the
obvious C++ extensions: member objects, member functions, C++'s concept of
lvalue, that kins of thing).  It is not similar to bit_cast at all.

[Bug lto/106020] New: Spurious warnings about stringop overflows only with LTO

[matt at godbolt dot org via Gcc-bugs]

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

Bug ID: 106020
   Summary: Spurious warnings about stringop overflows only with
LTO
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When using Howard Hinnant's date library, and GCC 12.1 on x86, and then with
LTO enabled, there are many apparently spurious errors after the read.constprop
pass:

/opt/compiler-explorer/libs/date/v3.0.1/include/date/date.h: In function
'read.constprop':
/opt/compiler-explorer/libs/date/v3.0.1/include/date/date.h:6506:15: note:
destination object 'buf' of size 11
 6506 | CharT buf[std::numeric_limits::digits10+2u] = {};

It has proven tricky to get a smaller case but https://godbolt.org/z/hPaqz7TY1
demonstrates it with an inline version of date.h - a smaller version that
doesn't inline the date library is https://godbolt.org/z/e75YG6ano and the code
amounts to:

std::chrono::system_clock::time_point parse_datetime(const std::string &sv) {
std::istringstream ss{sv};
std::chrono::system_clock::time_point tp;
ss >> date::parse("%FT%T%Z", tp); // ignoring errors for simplicity
return tp;
}

(though it has to be linked in a separate TU with LTO enabled to trigger the
issues).

I initially filed this as a bug in the date library itself:
https://github.com/HowardHinnant/date/issues/740 but we now believe this is a
compiler issue.

Compiling with GCC 11 or earlier, or with clang, or without LTO doesn't trigger
these warnings.

[Bug lto/106020] Spurious warnings about stringop overflows only with LTO

[matt at godbolt dot org via Gcc-bugs]

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

--- Comment #1 from Matt Godbolt  ---
Apologies for the unreduced issue, if I get a chance I'll try and shorten it,
but I hoped someone might recognise what the issue is from just this.

[Bug lto/106020] Spurious warnings about stringop overflows only with LTO

[matt at godbolt dot org via Gcc-bugs]

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

--- Comment #2 from Matt Godbolt  ---
There are many hundreds of similar errors in that example; perhaps this example
is more of a clue:

/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/move.h:205:11:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  205 |   __a = _GLIBCXX_MOVE(__b);

(which seems very suspicious, size 0 inside std::move?)

[Bug analyzer/106021] New: RFE: more sources of taint: scanf and its cousins

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

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

Bug ID: 106021
   Summary: RFE: more sources of taint: scanf and its cousins
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

scanf and its cousins should taint their arguments:

   #include 

   int scanf(const char *format, ...);
   int fscanf(FILE *stream, const char *format, ...);
   int sscanf(const char *str, const char *format, ...);

   #include 

   int vscanf(const char *format, va_list ap);
   int vsscanf(const char *str, const char *format, va_list ap);
   int vfscanf(FILE *stream, const char *format, va_list ap);

Possibly add/reuse an attribute for this, or hardcode it.

Additionally, we should probably "teach" the analyzer about the semantics of
them (possibly by refactoring the -Wformat code?)

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #7 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #6)
> Like that yes.  Pre-approved if it survives regcheck, too.  Thanks!
> 
> Please add the testcase as well of course :-)

Ok, bootstrap and regtests are running.

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

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 106022
   Summary: [12/13 Regression] Enable vectorizer generates extra
load
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---

[hjl@gnu-clx-1 gcc-bisect]$ cat x.c
void foo(char * c) {
c[0] = 0;
c[1] = 1;
c[2] = 2;
c[3] = 3;
}
[hjl@gnu-clx-1 gcc-bisect]$ gcc -O3 x.c -S
[hjl@gnu-clx-1 gcc-bisect]$ cat x.s 
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl.LC0(%rip), %eax
movl%eax, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC0:
.byte   0
.byte   1
.byte   2
.byte   3
.ident  "GCC: (GNU) 12.1.1 20220507 (Red Hat 12.1.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-clx-1 gcc-bisect]$ gcc -O3 x.c -S -fno-tree-vectorize
[hjl@gnu-clx-1 gcc-bisect]$ cat x.s
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl$50462976, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 12.1.1 20220507 (Red Hat 12.1.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-clx-1 gcc-bisect]$ /usr/gcc-11.2.1-x32/bin/gcc -S -O3 x.c 
[hjl@gnu-clx-1 gcc-bisect]$ cat x.s
.file   "x.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl$50462976, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 11.2.1 20220118"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-clx-1 gcc-bisect]$

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #8 from Lewis Hyatt  ---
I submitted a patch for this here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596820.html

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

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #1 from H.J. Lu  ---
SLP thinks that it needs 4 stores to store 4 bytes of integer constant.
But it takes only 1 4-byte store.

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #8 from Peter Bergner  ---
(In reply to Peter Bergner from comment #7)
> (In reply to Segher Boessenkool from comment #6)
> > Like that yes.  Pre-approved if it survives regcheck, too.  Thanks!
> > 
> > Please add the testcase as well of course :-)
> 
> Ok, bootstrap and regtests are running.

Bootstrap and regression testing were clean.

[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi

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

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

--- Comment #4 from Segher Boessenkool  ---
(In reply to Marek Polacek from comment #0)
> It doesn't look like a wrong code problem, but it seems more optimal to use
> rldimi (rotate left, mask insert) rather than rotate left by 0 bits, AND
> with a mask, shift left, and add.

Confirmed.  The original code is much better (and yes, the current is correct
as well).

[Bug c/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

Peter Bergner  changed:

   What|Removed |Added

  Component|target  |c

--- Comment #9 from Peter Bergner  ---
This is not a target issue, so changing the Component to C.

[Bug tree-optimization/106020] Spurious warnings about stringop overflows only with LTO

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

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

--- Comment #3 from Andrew Pinski  ---
Can you attach both files instead of the godbolt link?

[Bug tree-optimization/106020] Spurious warnings about stringop overflows only with LTO

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

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

--- Comment #4 from Andrew Pinski  ---
I suspect it is warning on some unreachable code which is not optimized away
until later. Until a full testcase is attached, it is going to be hard. Also it
would be better if not using cmake, just use a makefile if needed or just a
normal shell script to describe how to compile the files (cmake adds so much
stuff to it is sometimes hard to tell if it is doing the right thing).

[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #5 from Roger Sayle  ---
Patch proposed: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596778.html