[Bug tree-optimization/107368] New: [13 Regression] ICE: 'verify_gimple' failed (error: non-trivial conversion in 'var_decl')

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107368
   Summary: [13 Regression] ICE: 'verify_gimple' failed (error:
non-trivial conversion in 'var_decl')
   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 20221023 snapshot (g:0e37fd4dc74c1db99cdc7d71ef378e1221253c6f) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/attr-assume-1.c, w/ -O1:

double
f4 (double x)
{
  [[gnu::assume(x && x > 0.0)]];
  return x;
}

% gcc-13 -O1 -c ynay1wc5.c
ynay1wc5.c: In function 'f4':
ynay1wc5.c:2:1: error: non-trivial conversion in 'var_decl'
2 | f4 (double x)
  | ^~
_Bool
int
D.1992 = iftmp.0;
ynay1wc5.c:2:1: internal compiler error: 'verify_gimple' failed
0xf44b4e verify_gimple_in_seq(gimple*, bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-cfg.cc:5309
0xc2973a gimplify_body(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/gimplify.cc:17697
0xc298fa gimplify_function_tree(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/gimplify.cc:17813
0xa46797 cgraph_node::analyze()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:676
0xa49337 analyze_functions
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:1240
0xa49fdd symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:2514

[Bug tree-optimization/106076] Sub-optimal code is generated for checking bitfields via proxy functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Mine. I am going to get this upstream finally for GCC 14.

[Bug tree-optimization/106076] Sub-optimal code is generated for checking bitfields via proxy functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/85043] -Wuseless-cast false positive for temporary objects; add separate -Wcast-to-the-same-type to cover that case instead

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

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

--- Comment #17 from Eric Gallager  ---
(In reply to Marek Polacek from comment #16)
> Should be fixed now.

It seems the fix just silenced the -Wuseless-cast false positive without also
adding the separate -Wcast-to-the-same-type flag to cover that case instead; I
still think that would be useful.

[Bug libstdc++/107367] All standard library algorithms should optimize to pointers internally when they are contiguous iterators after C++20

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
This optimization will prevent duplications of templates over iterators and
pointers. (vector::iterator and int* duplications for example)

For example:

https://godbolt.org/z/9zEajxxa8
vs
https://godbolt.org/z/n61vEddj1

579 vs 879

[Bug libstdc++/107367] New: All standard library algorithms should detect whether they are contiguous iterators after C++20

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 107367
   Summary: All standard library algorithms should detect whether
they are contiguous iterators after C++20
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://github.com/gcc-mirror/gcc/blob/00716b776200c2de6813ce706d2757eec4cb2735/libstdc%2B%2B-v3/include/bits/stl_algo.h#L3229

Take is_sorted for example:

  template
_GLIBCXX20_CONSTEXPR
inline bool
is_sorted(_ForwardIterator __first, _ForwardIterator __last)
{ return std::is_sorted_until(__first, __last) == __last; }

It should be optimized to

  template
_GLIBCXX20_CONSTEXPR
inline bool
is_sorted(_ForwardIterator __first, _ForwardIterator __last)
{ 
   if
constexpr(contiguous_iterator<_ForwardIterator>&&!is_pointer_v<_ForwardIterator>)
{
   return is_sorted(to_address(__first),to_address(__last));
}
else
{
 return std::is_sorted_until(__first, __last) == __last; 
}
 }

[Bug middle-end/106081] missed vectorization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/107364] [10/11/12/13 Regression] ICE on Via Nehemiah with --march=native

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host|X86_64  |i?86-linux-gnu
   Keywords||ice-on-valid-code
   Target Milestone|--- |10.5
Summary|ICE on Via Nehemiah with|[10/11/12/13 Regression]
   |--march=native  |ICE on Via Nehemiah with
   ||--march=native
  Build|X86_64  |i?86-linux-gnu
 Target|X86_64  |i?86-linux-gnu

[Bug c++/107361] Why does -Wclass-memaccess require trivial types, instead of trivially-copyable types?

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

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-04/msg01571.html

[Bug fortran/105633] ICE in find_array_section, at fortran/expr.cc:1582

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

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

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

https://gcc.gnu.org/g:910156619c93ff988587762b446542c4dfbb00a2

commit r10-11055-g910156619c93ff988587762b446542c4dfbb00a2
Author: Harald Anlauf 
Date:   Wed Oct 19 22:37:56 2022 +0200

Fortran: error recovery with references of bad array constructors
[PR105633]

gcc/fortran/ChangeLog:

PR fortran/105633
* expr.c (find_array_section): Move check for NULL pointers so
that both subscript triplets and vector subscripts are covered.

gcc/testsuite/ChangeLog:

PR fortran/105633
* gfortran.dg/pr105633.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit ecb20df4fa6d99daa635c7fb662dc0554610777e)

[Bug fortran/105633] ICE in find_array_section, at fortran/expr.cc:1582

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-10330-gc6ff6ca2fcefdd5edc37011a2ba8412a466d9b0b
Author: Harald Anlauf 
Date:   Wed Oct 19 22:37:56 2022 +0200

Fortran: error recovery with references of bad array constructors
[PR105633]

gcc/fortran/ChangeLog:

PR fortran/105633
* expr.c (find_array_section): Move check for NULL pointers so
that both subscript triplets and vector subscripts are covered.

gcc/testsuite/ChangeLog:

PR fortran/105633
* gfortran.dg/pr105633.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit ecb20df4fa6d99daa635c7fb662dc0554610777e)

[Bug fortran/105633] ICE in find_array_section, at fortran/expr.cc:1582

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

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

commit r12-8860-ge3c997824f17dd6a4f7eb8d668b9ed2ef84408fc
Author: Harald Anlauf 
Date:   Wed Oct 19 22:37:56 2022 +0200

Fortran: error recovery with references of bad array constructors
[PR105633]

gcc/fortran/ChangeLog:

PR fortran/105633
* expr.cc (find_array_section): Move check for NULL pointers so
that both subscript triplets and vector subscripts are covered.

gcc/testsuite/ChangeLog:

PR fortran/105633
* gfortran.dg/pr105633.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit ecb20df4fa6d99daa635c7fb662dc0554610777e)

[Bug fortran/107362] Segfault for recursive class

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-23
   Keywords||compile-time-hog,
   ||ice-on-valid-code
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
This eats a lot of memory until virtual memory is exhausted.

Also likely a duplicate of pr106606.

[Bug c++/105774] Bogus overflow in constant expression with signed char++

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 53763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53763=edit
gcc13-pr105774.patch

Untested fix.

[Bug c++/107363] Wrong caret location for "redundant move in return statement" and nvo

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

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

--- Comment #1 from Andrew Pinski  ---
The wrong caret comes from named return value optimization iirc.

[Bug c++/107327] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12930

[kaploceh at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Carlos E  ---
(In reply to Martin Liška from comment #7)
> (In reply to Carlos E from comment #6)
> > (In reply to Martin Liška from comment #4)
> > > > When you say to attach a preprocessed source, what would be the most
> > > > accepted command that I should be running which can reliably show 
> > > > whatever
> > > > was preprocessed?   
> > > 
> > > Just append -E to the existing command line arguments, that would be fine.
> > 
> > done.
> 
> We need what was likely printed to stdout, or saved to a .o file.
> 
> See what's the pre-processed source file:
> echo '#include ' | gcc -x c - -E

thank you Martin. 

It did compile as Richard suggested with 10.4 

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --with-mpc-lib= --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.4.0 (GCC) 

the preprocessed file was after installing 10.4.
I can revert to 10.2

[Bug c++/107327] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12930

[kaploceh at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Carlos E  ---
Created attachment 53762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53762=edit
preprocessed file

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

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

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

--- Comment #2 from Aldy Hernandez  ---
Created attachment 53761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53761=edit
untested

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

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

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

--- Comment #1 from Aldy Hernandez  ---
Ok, this is getting ridiculous.  I'm tired of these weird finite-math-only
combinations in Vax and rx-elf.  I think we should just test -ffinite-math-only
and -fno-finite-math-only in the self tests for all architectures.  Heck, we
should probably check -fno-finite-math-only + !HONOR_NANS (float_type_mode).

[Bug tree-optimization/107346] [13 Regression] gnat.dg/loop_optimization23_pkg.ad failure afer r13-3413-ge10ca9544632db

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

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

--- Comment #9 from avieira at gcc dot gnu.org ---
Hi Eric,

I realised the same, got a patch pending here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604139.html

[Bug c/107366] New: -fanalyzer with -fdiagnostics-format=sarif-file or sarif-stderr

[rainer.keller--- via Gcc-bugs]

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

Bug ID: 107366
   Summary: -fanalyzer with -fdiagnostics-format=sarif-file or
sarif-stderr
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rainer.kel...@hs-esslingen.de
  Target Milestone: ---

Created attachment 53760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53760=edit
Compilation of -freport-bug

Compiling hwloc-2.8.0 with -fanalyzer and either
-fdiagnostics-format=sarif-file or -fdiagnostics-format=sarif-stderr produces:

during IPA pass: analyzer
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

Unfortunately I wasn't able to produce a MWE.
Steps to reproduce:
   wget https://download.open-mpi.org/release/hwloc/v2.8/hwloc-2.8.0.tar.bz2
   tar xf hwloc-2.8.0.tar.bz2 && cd hwloc-2.8.0
   mkdir BUILD && cd $_
   ../configure --prefix=$PWD/usr
   make CFLAGS="-fanalyzer -fdiagnostics-format=sarif-stderr"
fails in hwloc/diff.c

Using -fdiagnostics-format=json-stderr and -file works.

The above does not seem to be related to https://gcc.gnu.org/PR106703

Attached is the -freport-bug of same file.
Thanks

[Bug tree-optimization/107346] [13 Regression] gnat.dg/loop_optimization23_pkg.ad failure afer r13-3413-ge10ca9544632db

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
> I am wondering whether I should try to support this, or bail out of
> vect_check_gather_scatter if pbitpos is not a multiple of BITS_PER_UNIT. The
> latter obviously feels safer.

It turns out that this vect_check_gather_scatter problem was latent since I can
reproduce it with the GCC 12 compiler in Ada, and the following fix:

diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index e32b1779c5d..a22eb2d763d 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -4013,7 +4013,7 @@ vect_check_gather_scatter (stmt_vec_info stmt_info,
loop_vec_info loop_vinfo,
  that can be gimplified before the loop.  */
   base = get_inner_reference (base, , , , ,
  , , );
-  if (reversep)
+  if (!multiple_p (pbitpos, BITS_PER_UNIT) || reversep)
 return false;

   poly_int64 pbytepos = exact_div (pbitpos, BITS_PER_UNIT);

is sufficient to get rid of it.

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||amacleod at redhat dot com

[Bug tree-optimization/107365] New: ICE in verify_range, at value-range.cc:726

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

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

Bug ID: 107365
   Summary: ICE in verify_range, at value-range.cc:726
   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: marxin at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: vax-linux-gnu

Happens for a cross compiler:

$ ./xgcc -B./ -B/home/marxin/bin/gcc/vax-linux-gnu/bin/ -isystem
/home/marxin/bin/gcc/vax-linux-gnu/include -isystem
/home/marxin/bin/gcc/vax-linux-gnu/sys-include -L/dev/shm/objdir2/gcc/../ld 
-xc++ -nostdinc /dev/null -S -o /dev/null
-fself-test=/home/marxin/Programming/gcc/gcc/testsuite/selftests
In function ‘test_fn’:
cc1plus: internal compiler error: in verify_range, at value-range.cc:726
0x18dbdc5 frange::verify_range()
/home/marxin/Programming/gcc/gcc/value-range.cc:726
0x18da448 frange::set(tree_node*, real_value const&, real_value const&,
value_range_kind)
/home/marxin/Programming/gcc/gcc/value-range.cc:366
0x18f17fe frange::frange(tree_node*, real_value const&, real_value const&,
value_range_kind)
/home/marxin/Programming/gcc/gcc/value-range.h:1080
0x18ed069 frange_float
/home/marxin/Programming/gcc/gcc/value-range.cc:3692
0x18f021c range_tests_floats
/home/marxin/Programming/gcc/gcc/value-range.cc:3959
0x18f11c9 selftest::range_tests()
/home/marxin/Programming/gcc/gcc/value-range.cc:4052
0x20549b7 test_ranges
/home/marxin/Programming/gcc/gcc/function-tests.cc:584
0x20549b7 selftest::function_tests_cc_tests()
/home/marxin/Programming/gcc/gcc/function-tests.cc:680
0x21b488c selftest::run_tests()
/home/marxin/Programming/gcc/gcc/selftest-run-tests.cc:107
0x146880e toplev::run_self_tests()
/home/marxin/Programming/gcc/gcc/toplev.cc:2184
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.

[Bug c/107364] New: ICE on Via Nehemiah with --march=native

[orzel at freehackers dot org via Gcc-bugs]

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

Bug ID: 107364
   Summary: ICE on Via Nehemiah with --march=native
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orzel at freehackers dot org
  Target Milestone: ---

The cpu is very old:
chopin /etc # cat /proc/cpuinfo 
processor   : 0
vendor_id   : CentaurHauls
cpu family  : 6
model   : 9
model name  : VIA Nehemiah
stepping: 3
cpu MHz : 997.000
cache size  : 64 KB
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de pse tsc msr cx8 mtrr pge cmov mmx fxsr sse cpuid rng
rng_en
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
swapgs itlb_multihit mmio_unknown
bogomips: 1999.03
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:

The compiler crashes when using -march=native. You dont need to compile for it
to crash, --help=target is enough. As a result, gcc can't build itself anymore.
The last known 'working' version is gcc 9. Tested are gcc 10, 11, and 12, all
crashing the same way. This is how it looks:


chopin /etc # gcc-12 -Q --help=target -march=native -freport-bug
gcc-12: internal compiler error: in cpu_indicator_init, at
common/config/i386/cpuinfo.h:986
0xb7cd535e __libc_start_main
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
chopin /etc # gcc-12 -Q --help=target
The following options are target specific:
  -m128bit-long-double  [disabled]
  -m16  [disabled]
  -m32  [enabled]
  -m3dnow   [disabled]
  -m3dnowa  [disabled]
  -m64  [disabled]
  -m80387   [enabled]
  -m8bit-idiv   [disabled]
  -m96bit-long-double   [enabled]
  -mabi=sysv
  -mabm [disabled]
  -maccumulate-outgoing-args[disabled]
  -maddress-mode=   short
  -madx [disabled]
  -maes [disabled]
  -malign-data= compat
  -malign-double[disabled]
  -malign-functions=0
  -malign-jumps=0
  -malign-loops=0
  -malign-stringops [enabled]
  -mamx-bf16[disabled]
  -mamx-int8[disabled]
  -mamx-tile[disabled]
  -mandroid [disabled]
  -march=   i686
  -masm=att
  -mavx [disabled]
  -mavx2[disabled]
  -mavx256-split-unaligned-load [disabled]
  -mavx256-split-unaligned-store[disabled]
  -mavx5124fmaps[disabled]
  -mavx5124vnniw[disabled]
  -mavx512bf16  [disabled]
  -mavx512bitalg[disabled]
  -mavx512bw[disabled]
  -mavx512cd[disabled]
  -mavx512dq[disabled]
  -mavx512er[disabled]
  -mavx512f [disabled]
  -mavx512fp16  [disabled]
  -mavx512ifma  [disabled]
  -mavx512pf[disabled]
  -mavx512vbmi  [disabled]
  -mavx512vbmi2 [disabled]
  -mavx512vl[disabled]
  -mavx512vnni  [disabled]
  -mavx512vp2intersect  [disabled]
  -mavx512vpopcntdq [disabled]
  -mavxvnni [disabled]
  -mbionic  [disabled]
  -mbmi [disabled]
  -mbmi2[disabled]
  -mbranch-cost=<0,5>   3
  -mcall-ms2sysv-xlogues[disabled]
  -mcet-switch  [disabled]
  -mcld [disabled]
  -mcldemote[disabled]
  -mclflushopt  [disabled]
  -mclwb[disabled]
  -mclzero  [disabled]
  -mcmodel= 32
  -mcpu=  

[Bug c++/107363] New: Wrong caret location for "redundant move in return statement"

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 107363
   Summary: Wrong caret location for "redundant move in return
statement"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

The caret in the following "redundant move in return statement" warning does
not point to a return statement (https://godbolt.org/z/4v7Y9G9e3):

```
#include 

template 
struct Optional {
  T ();
  T release_value() {
T released_value = std::move(value());
return released_value;
  }
};

struct Foo {};
void test(Optional o) { o.release_value(); }
```

:7:7: warning: redundant move in return statement [-Wredundant-move]
7 | T released_value = std::move(value());
  |   ^~
:7:7: note: remove 'std::move' call

As an aside, it's a bit annoying to have this warning when the moved type
depends on a template parameter in library code. We are forced to either
silence this warning with a #pragma, or use concepts to have a variant of the
release_value method that does not call std::move for const-qualified T.

[Bug c++/107360] ICE on sizeof(*f(x)) when f's (deduced) return type is a pointer to VLA

[izbyshev at ispras dot ru via Gcc-bugs]

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

--- Comment #2 from Alexey Izbyshev  ---
(In reply to Andrew Pinski from comment #1)
> Maybe this should be invalid code ...

Yes, I think it should be invalid. VLAs are not allowed in function return
types in C. VLAs in C++ are a GCC extension, but it's unclear to me why (and
how) GCC should allow them in return types, even when they don't depend on
function parameters.

Currently, GCC crashes even in the latter case, e.g.:

extern int n;

auto f() {
int (*a)[n] = 0;
return a;
}

int g() {
return sizeof *f();
}

[Bug fortran/107362] New: Segfault for recursive class

[baradi09 at gmail dot com via Gcc-bugs]

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

Bug ID: 107362
   Summary: Segfault for recursive class
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

When trying to build Fortuno (https://github.com/aradi/fortuno), our new
Fortran unit testing system, I encounter a segfault with GFortran. The problem
can be reduced to the following MWE:

[details: failureinfo.f90]
module fortuno_failureinfo
  implicit none

  type :: failure_info
class(failure_info), allocatable :: previous
  end type failure_info

end module fortuno_failureinfo
[/details]

> gfortran -freport-bug -c failureinfo.f90 
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report, with preprocessed source.
See 
for instructions.

Apparently, the problem is the "class(failure_info)" field within the derived
type. Turning it into "type(failure_info)" allows compilation.

I use GNU Fortran (conda-forge gcc 12.2.0-18) 12.2.0 on x86_64/Linux.

Thanks a lot for having a look at it in advance!

[Bug c++/107361] New: Why does -Wclass-memaccess require trivial types, instead of trivially-copyable types?

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 107361
   Summary: Why does -Wclass-memaccess require trivial types,
instead of trivially-copyable types?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

I find -Wclass-memaccess warns on this kind of code:

#include 

struct Foo
{
int x{};
char y{};
int z{};
};

int main()
{
Foo a;
std::memset(, 0, sizeof(a));
}

All because Foo has default member initializers, making it a non-trivial type.
It's still trivially-copyable, which is the requirement for std::memset.
Therefore I ask: why is the warning stricter than it needs to be?

Making sure structs are initialized is defensive programming, and consistent
with coding guidelines that require classes to initialize their data members. 

Also, there are cases where we cannot use the C++ initialization (Foo a = {};).
For example, this class has implicit padding, and the C++ initialization will
not initialize that. This is a problem for serializer/deserializer type of code
(copying/reading uninitialized padding bytes, valgrind will complain).

[Bug c++/107360] ICE on sizeof(*f(x)) when f's (deduced) return type is a pointer to VLA

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |

--- Comment #1 from Andrew Pinski  ---
Maybe this should be invalid code ...

[Bug target/107359] [aarch64] should avoid the punpklo/punpkhi compare to llvm

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

Note if you use float instead of double. GCC produces better code. That is the
following testcase:
int check (char *mask, float *result, int n) {
int count = 0;
for (int i=0; i

[Bug c++/107360] New: ICE on sizeof(*f(x)) when f's (deduced) return type is a pointer to VLA

[izbyshev at ispras dot ru via Gcc-bugs]

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

Bug ID: 107360
   Summary: ICE on sizeof(*f(x)) when f's (deduced) return type is
a pointer to VLA
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izbyshev at ispras dot ru
  Target Milestone: ---

auto f(int n) {
int (*a)[n] = 0;
return a;
}

int g() {
return sizeof *f(1);
}

Output of GCC 12.2:

during RTL pass: expand
: In function 'int g()':
:7:23: internal compiler error: in expand_expr_real_1, at expr.cc:10586
7 | return sizeof *f(1);
  |   ^
0x1bb069e internal_error(char const*, ...)
???:0
0x6ff396 fancy_abort(char const*, int, char const*)
???:0
0xab97bd expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0xaab144 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xab97bd expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0xaab144 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xab38c4 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
???:0
0xaba7ac expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0xaab144 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xabb2c9 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0xaab144 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0

All versions supporting C++14 return type deduction (i.e. since 4.8) produce
ICE, except 4.9, which generates wrong code for g() instead (it returns 1
regardless of f's argument).

[Bug target/107359] [aarch64] should avoid the punpklo/punpkhi compare to llvm

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

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

--- Comment #1 from Andrew Pinski  ---
Options: -O3  -march=armv8.2-a+sve