[Bug target/106910] roundss not vectorized

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r13-2730-gd0c73b6c85677e6755b60fa02d79a5c5e1a8eacd
Author: liuhongt 
Date:   Fri Sep 16 14:28:34 2022 +0800

Support 64-bit vectorization for single-precision floating rounding
operation.

Here's list the patch supported.
rint/nearbyint/ceil/floor/trunc/lrint/lceil/lfloor/round/lround.

gcc/ChangeLog:

PR target/106910
* config/i386/mmx.md (nearbyintv2sf2): New expander.
(rintv2sf2): Ditto.
(ceilv2sf2): Ditto.
(lceilv2sfv2si2): Ditto.
(floorv2sf2): Ditto.
(lfloorv2sfv2si2): Ditto.
(btruncv2sf2): Ditto.
(lrintv2sfv2si2): Ditto.
(roundv2sf2): Ditto.
(lroundv2sfv2si2): Ditto.
(*mmx_roundv2sf2): New define_insn.

gcc/testsuite/ChangeLog:

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

[Bug target/106972] internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Thomas Petazzoni from comment #2)
> Thanks for the quick feedback! I am not super familiar with iwmmxt, but as I
> understand it is used in Marvell PXA270 and above. While these are fairly
> old indeed, their support is still maintained in the upstream Linux kernel,
> so it would be odd to no longer have gcc support for them.

Marvell does not provide any support for them in the last 4 years or more. With
my Marvell hat on, it makes sense to remove the GCC support as it definitely
has bitrotten and I have no resources at all to do any upstream fixes for it.

[Bug target/106972] internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #2 from Thomas Petazzoni  ---
Thanks for the quick feedback! I am not super familiar with iwmmxt, but as I
understand it is used in Marvell PXA270 and above. While these are fairly old
indeed, their support is still maintained in the upstream Linux kernel, so it
would be odd to no longer have gcc support for them.

[Bug tree-optimization/105735] GCC failed to reduce &= loop_inv in loop.

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Kong Lingling :

https://gcc.gnu.org/g:3a035f1932eeb26f997cf28a5c752617dd09cb91

commit r13-2729-g3a035f1932eeb26f997cf28a5c752617dd09cb91
Author: konglin1 
Date:   Tue Sep 20 13:58:35 2022 +0800

middle-end: handle bitop with an invariant induction.[PR105735]

Enhance final_value_replacement_loop to handle bitop
with an invariant induction.

This patch will enable below optimization:

{
-  long unsigned int bit;
-
-   [local count: 32534376]:
-
-   [local count: 1041207449]:
-  # tmp_10 = PHI 
-  # bit_12 = PHI 
-  tmp_7 = bit2_6(D) & tmp_10;
-  bit_8 = bit_12 + 1;
-  if (bit_8 != 32)
-goto ; [96.97%]
-  else
-goto ; [3.03%]
-
-   [local count: 1009658865]:
-  goto ; [100.00%]
-
-   [local count: 32534376]:
-  # tmp_11 = PHI 
-  return tmp_11;
+  tmp_11 = tmp_4 (D) & bit2_6 (D);
+  return tmp_11;

}

gcc/ChangeLog:

PR middle-end/105735
* tree-scalar-evolution.cc
(analyze_and_compute_bitop_with_inv_effect): New function.
(final_value_replacement_loop): Enhanced to handle bitop
with inv induction.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr105735-1.c: New test.
* gcc.target/i386/pr105735-2.c: New test.

[Bug target/106972] internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106279

--- Comment #1 from Andrew Pinski  ---
iwmmxt support is definitely bitrotten and most likely should be removed from
GCC.

[Bug c/106972] New: internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 106972
   Summary: internal compiler error: in extract_insn, at
recog.c:2770 on ARMeb when building gcc itself
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

When building gcc 11.3.0 for armeb, with the following configure command line:


(cd
/home/thomas/autobuild/instance-1/output-1/build/host-gcc-initial-11.3.0/build
&& rm -rf config.cache;
PATH="/home/thomas/autobuild/instance-1/output-1/host/bin:/home/thomas/autobuild/instance-1/output-1/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
PKG_CONFIG="/home/thomas/autobuild/instance-1/output-1/host/bin/pkg-config"
PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1
PKG_CONFIG_ALLOW_SYSTEM_LIBS=1
PKG_CONFIG_LIBDIR="/home/thomas/autobuild/instance-1/output-1/host/lib/pkgconfig:/home/thomas/autobuild/instance-1/output-1/host/share/pkgconfig"
AR="/usr/bin/ar" AS="/usr/bin/as" LD="/usr/bin/ld" NM="/usr/bin/nm"
CC="/usr/bin/gcc" GCC="/usr/bin/gcc" CXX="/usr/bin/g++" CPP="/usr/bin/cpp"
OBJCOPY="/usr/bin/objcopy" RANLIB="/usr/bin/ranlib"
CPPFLAGS="-I/home/thomas/autobuild/instance-1/output-1/host/include"
CFLAGS="-O2 -I/home/thomas/autobuild/instance-1/output-1/host/include"
CXXFLAGS="-O2 -I/home/thomas/autobuild/instance-1/output-1/host/include"
LDFLAGS="-L/home/thomas/autobuild/instance-1/output-1/host/lib
-Wl,-rpath,/home/thomas/autobuild/instance-1/output-1/host/lib"
INTLTOOL_PERL=/usr/bin/perl CFLAGS="-O2
-I/home/thomas/autobuild/instance-1/output-1/host/include"
LDFLAGS="-L/home/thomas/autobuild/instance-1/output-1/host/lib
-Wl,-rpath,/home/thomas/autobuild/instance-1/output-1/host/lib"
MAKEINFO=missing CFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -Os -g0 -D_FORTIFY_SOURCE=1"
CXXFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -Os -g0 -D_FORTIFY_SOURCE=1" AR_FOR_TARGET=gcc-ar
NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib CONFIG_SITE=/dev/null
./configure --prefix="/home/thomas/autobuild/instance-1/output-1/host"
--sysconfdir="/home/thomas/autobuild/instance-1/output-1/host/etc"
--localstatedir="/home/thomas/autobuild/instance-1/output-1/host/var"
--enable-shared --disable-static --disable-gtk-doc --disable-gtk-doc-html
--disable-doc --disable-docs --disable-documentation --disable-debug
--with-xmlto=no --with-fop=no --disable-nls --disable-dependency-tracking 
--target=armeb-buildroot-linux-gnueabi
--with-sysroot=/home/thomas/autobuild/instance-1/output-1/host/armeb-buildroot-linux-gnueabi/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float --enable-plugins --enable-lto
--with-gmp=/home/thomas/autobuild/instance-1/output-1/host
--with-mpc=/home/thomas/autobuild/instance-1/output-1/host
--with-mpfr=/home/thomas/autobuild/instance-1/output-1/host
--with-pkgversion="Buildroot 2022.08-rc1-468-g0f42b81532"
--with-bugurl="http://bugs.buildroot.net/"; --without-zstd --disable-libquadmath
--disable-libquadmath-support --enable-tls --enable-threads --without-isl
--without-cloog --with-float=soft --with-abi="aapcs-linux" --with-cpu=iwmmxt
--with-float=soft --with-mode=arm --enable-languages=c --disable-shared
--without-headers --disable-threads --with-newlib --disable-largefile  )

The build fails with:

../../../libgcc/config/arm/unwind-arm.c:467:1: error: unrecognizable insn:
  467 | }
  | ^
(insn 2 4 3 2 (set (reg/v/f:SI 118 [ p ])
(reg:SI 0 r0 [ p ])) "../../../libgcc/config/arm/unwind-arm.c":456:1 -1
 (nil))
during RTL pass: vregs
../../../libgcc/config/arm/unwind-arm.c:467:1: internal compiler error: in
extract_insn, at recog.c:2770

(The same error happens in several place)

Full build log at
http://autobuild.buildroot.net/results/8e4c4512902c34d8ec0c6f8dfff92b7a198e4b4a/build-end.log

There are a number of similar reports, but they don't seem to apply:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724 is already fixed in gcc
11.3.0
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 is S390 specific

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

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

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

--- Comment #3 from Thomas Rodgers  ---
Since this latter point has come up before, I want to additionally note that
the optimization to use an atomic count of waiters per-waiter pool bucket means
that a call to notify_one/notify_all is roughly 25x faster based on my testing
than naively issuing a syscall to FUTEX_WAKE when there is no possibility of
the wake being issued to a waiter.

2022-09-19T20:34:28-07:00
Running ./benchmark
Run on (20 X 4800 MHz CPU s)
CPU Caches:
  L1 Data 48 KiB (x10)
  L1 Instruction 32 KiB (x10)
  L2 Unified 1280 KiB (x10)
  L3 Unified 24576 KiB (x1)
Load Average: 0.69, 0.61, 1.30
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may
be noisy and will incur extra overhead.
--
BenchmarkTime CPU   Iterations
--
BM_empty_notify_checked   3.79 ns 3.79 ns179929051
BM_empty_notify_syscall   94.1 ns 93.9 ns  7477997

For types that can use a FUTEX directly (e.g. int) there is no place to put
that extra atomic to perform this check, so we can either have the type that is
directly usable by the underlying platform be significantly more expensive to
call, or we can use the waiter count in the waiter_pool.

[Bug tree-optimization/106963] [13 Regression] ICE in vect_gen_perm_mask_checked, at tree-vect-stmts.cc:8606

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
When init_expr is INTEGER_CST or REAL_CST, we don't need can_vec_perm_const_p
since there's no real vec_perm needed, but vec_gen_perm_mask_checked will
gcc_assert (can_vec_perm_const_p). So it's better to use vec_gen_perm_mask_any
here.

[Bug target/106971] New: ICE in aarch64_init_ls64_builtins_types, at config/aarch64/aarch64-builtins.cc:1856

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 106971
   Summary: ICE in aarch64_init_ls64_builtins_types, at
config/aarch64/aarch64-builtins.cc:1856
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gcc 13.0.0 20220918 snapshot (g:313879d8768d08dea035efd7fd62b753dc91c364) ICEs
when compiling the following testcase w/ -march=armv8-a+ls64 -O1 -fpack-struct:

#pragma GCC aarch64 "arm_acle.h"

% aarch64-linux-gnu-gcc-13.0.0 -march=armv8-a+ls64 -O1 -fpack-struct -c
kpgwlgsl.c
kpgwlgsl.c:1:9: internal compiler error: in aarch64_init_ls64_builtins_types,
at config/aarch64/aarch64-builtins.cc:1856
1 | #pragma GCC aarch64 "arm_acle.h"
  | ^~~
0x7ffca6 aarch64_init_ls64_builtins_types
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/config/aarch64/aarch64-builtins.cc:1856
0x7ffca6 aarch64_init_ls64_builtins
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/config/aarch64/aarch64-builtins.cc:1862
0x7ffca6 handle_arm_acle_h()
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/config/aarch64/aarch64-builtins.cc:1919
0x9cbd2d aarch64_pragma_aarch64
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/config/aarch64/aarch64-c.cc:293
0x90b4d7 c_parser_pragma
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/c/c-parser.cc:12707
0x937e45 c_parser_external_declaration
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/c/c-parser.cc:1770
0x9385cb c_parser_translation_unit
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/c/c-parser.cc:1662
0x9385cb c_parse_file()
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/c/c-parser.cc:23682
0x99b951 c_common_parse_file()
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/c-family/c-opts.cc:1255

It seems either assert is too strict, or the compiler should somehow bail out
earlier when -fpack-struct is passed.

[Bug tree-optimization/106970] New: [13 Regression] ICE in verify_range, at value-range.cc:702

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 106970
   Summary: [13 Regression] ICE in verify_range, at
value-range.cc:702
   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 20220918 snapshot (g:313879d8768d08dea035efd7fd62b753dc91c364) ICEs
when compiling the following testcase w/ -O1 -fno-signed-zeros:

void
foo (double x, double y)
{
  if (!x == !y * -1.0)
__builtin_trap ();
}

% gcc-13.0.0 -O1 -fno-signed-zeros -c kis6ezgv.c
during GIMPLE pass: ethread
kis6ezgv.c: In function 'foo':
kis6ezgv.c:6:1: internal compiler error: in verify_range, at value-range.cc:702
6 | }
  | ^
0x7b68a9 frange::verify_range()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/value-range.cc:702
0x12106b7 frange::intersect(vrange const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/value-range.cc:549
0x1e62c88 foperator_equal::fold_range(irange&, tree_node*, frange const&,
frange const&, relation_kind_t) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/range-op-float.cc:382
0x1e62e50 foperator_equal::fold_range(irange&, tree_node*, frange const&,
frange const&, relation_kind_t) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/range-op.h:219
0x1d407b7 fold_using_range::range_of_range_op(vrange&, gimple*, fur_source&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:634
0x1d438d0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:555
0x1d43c9c fold_range(vrange&, gimple*, range_query*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:316
0x10a647d path_range_query::range_of_stmt(vrange&, gimple*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-path.cc:725
0x1130994 back_threader::find_taken_edge_cond(vec const&, gcond*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:334
0x1130b82 back_threader::maybe_register_path(back_threader_profitability&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:248
0x1131098 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:380
0x1131614 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:502
0x1131614 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:502
0x11320af back_threader::maybe_thread_block(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:574
0x1132161 back_threader::thread_blocks()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:1002
0x11322b0 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:1076

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #1 from Arseny Solokha  ---
JFTH, a similar ICE in lower_bound is also possible. I currently have an F77
testcase, will try to get a C one.

[Bug target/106887] ICE in extract_insn, at recog.cc:2791 since r13-2111-g6910cad55ffc330d

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Kong Lingling :

https://gcc.gnu.org/g:78260b9a9c0bf5a4495320466e2cd1c259504905

commit r13-2725-g78260b9a9c0bf5a4495320466e2cd1c259504905
Author: konglin1 
Date:   Fri Sep 16 15:59:19 2022 +0800

i386: Fixed vec_init_dup_v16bf [PR106887]

gcc/ChangeLog:

PR target/106887
* config/i386/i386-expand.cc (ix86_expand_vector_init_duplicate):
Fixed V16BF mode case.

gcc/testsuite/ChangeLog:

PR target/106887
* gcc.target/i386/vect-bfloat16-2c.c: New test.

[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Keywords||ice-on-valid-code

--- Comment #2 from anlauf at gcc dot gnu.org ---
Potential fix:

diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 908a4c6d42e..5d16d640322 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -5529,6 +5529,7 @@ generate_coarray_sym_init (gfc_symbol *sym)

   if (sym->attr.dummy || sym->attr.allocatable || !sym->attr.codimension
   || sym->attr.use_assoc || !sym->attr.referenced
+  || sym->attr.associate_var
   || sym->attr.select_type_temporary)
 return;

[Bug fortran/100132] Optimization breaks pointer association

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Pinged here: https://gcc.gnu.org/pipermail/fortran/2022-September/058212.html

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

[amachronic at protonmail dot com via Gcc-bugs]

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

Aidan MacDonald  changed:

   What|Removed |Added

 CC||amachronic at protonmail dot 
com

--- Comment #9 from Aidan MacDonald  ---
I am also hitting this with GCC 12.2. One more detail to add is that the info
manual says the -Waddress warning should be suppressed if it's a result of a
macro expansion. This does indeed happen when the macro is the only thing in
the conditional, but not when the macro is part of a larger expression.

Example (https://godbolt.org/z/YEY4Yzdnf):

#include 

#define MACRO(buf, off) (off < 0 ? NULL : (void*)&buf[off])

void func(char *buf, long off)
{
if (off < 0 ? NULL : (void*)&buf[off]) { } // warning (correct)
if (!(off < 0 ? NULL : (void*)&buf[off])) { } // warning (correct)
if (MACRO(buf, off)) { } // no warning (correct)
if (!MACRO(buf, off)) { } // gives a false positive -Waddress
}

[Bug c++/106812] Throwing a non-copyable exception

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

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

--- Comment #3 from Marek Polacek  ---
The difference between #3 and not-#3 is that without the NSDMI, S isn't
TYPE_NEEDS_CONSTRUCTING, which makes a difference in initialize_handler_parm:

 339   /* If the constructor for the catch parm exits via an exception, we
 340  must call terminate.  See eh23.C.  */
 341   if (TYPE_NEEDS_CONSTRUCTING (TREE_TYPE (decl)))
 342 {
 343   /* Generate the copy constructor call directly so we can wrap it.
 344  See also expand_default_init.  */
 345   init = ocp_convert (TREE_TYPE (decl), init,
 346   CONV_IMPLICIT|CONV_FORCE_TEMP, 0,
 347   tf_warning_or_error);

[Bug c++/106812] Throwing a non-copyable exception

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-09-19

--- Comment #2 from Marek Polacek  ---
Confirmed.

[Bug c++/106903] Incorrectly accepts call to function template when deduced type doesn't match adjusted type

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-09-19

[Bug c/106947] [12/13 Regression] -Waddress + bool + pragma generates meaningless diagnostic

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c/106947] [12/13 Regression] -Waddress + bool + pragma generates meaningless diagnostic

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

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

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

https://gcc.gnu.org/g:97803ee561c7a2692a6d7863a5d86797d79a18b1

commit r12-8774-g97803ee561c7a2692a6d7863a5d86797d79a18b1
Author: Marek Polacek 
Date:   Mon Sep 19 14:12:55 2022 -0400

c: Stray inform note with -Waddress [PR106947]

A trivial fix for maybe_warn_for_null_address where we print an
inform note without first checking the return value of a warning
call.

PR c/106947

gcc/c/ChangeLog:

* c-typeck.cc (maybe_warn_for_null_address): Don't emit stray
notes.

gcc/testsuite/ChangeLog:

* c-c++-common/Waddress-7.c: New test.

(cherry picked from commit 2d9429d5c0f86f588bdfd85bb9e236d2be367d3f)

[Bug c/106947] [12/13 Regression] -Waddress + bool + pragma generates meaningless diagnostic

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:2d9429d5c0f86f588bdfd85bb9e236d2be367d3f

commit r13-2723-g2d9429d5c0f86f588bdfd85bb9e236d2be367d3f
Author: Marek Polacek 
Date:   Mon Sep 19 14:12:55 2022 -0400

c: Stray inform note with -Waddress [PR106947]

A trivial fix for maybe_warn_for_null_address where we print an
inform note without first checking the return value of a warning
call.

PR c/106947

gcc/c/ChangeLog:

* c-typeck.cc (maybe_warn_for_null_address): Don't emit stray
notes.

gcc/testsuite/ChangeLog:

* c-c++-common/Waddress-7.c: New test.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jeffrey.rahr at baesystems dot com via Gcc-bugs]

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

--- Comment #21 from Jeff Rahr  ---
Roger - I was getting that same error when building out of the box for
langueages=c,c++,fortran,lto,jit,go,d (ie didn't edit Makefile.def). Based on
https://forum.dlang.org/post/qgrchukzyceflenrr...@forum.dlang.org that said on
some platforms libphobos is not enabled by default,  I added --enable-libphobos
to my configure and my build worked after that.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

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

--- Comment #20 from Roger Sayle  ---
I can confirm that removing the bootstrap=true from the two lines in
Makefile.def suggested by Jeff in comment #18, does fix the libgo build for me.

But unfortunately, I can't get "d" to build (with these changes) due to "import
gcc.config" in libphobos/libdruntime/core/internal/atomic.d being unable to
read module 'config' during stage2.

[Bug c++/106969] [12/13 Regression] member function constness incorrectly propagates to local class member function return type deduction

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|member function constness   |[12/13 Regression] member
   |incorrectly propagates to   |function constness
   |local class member function |incorrectly propagates to
   |return type deduction   |local class member function
   ||return type deduction
  Known to fail||12.2.0
   Last reconfirmed||2022-09-19
   Keywords||needs-bisection,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.3
  Known to work||12.1.0

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

[Bug c++/106969] New: member function constness incorrectly propagates to local class member function return type deduction

[enolan at alumni dot cmu.edu via Gcc-bugs]

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

Bug ID: 106969
   Summary: member function constness incorrectly propagates to
local class member function return type deduction
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enolan at alumni dot cmu.edu
  Target Milestone: ---

When using decltype in the return type of a member function of a local class
defined inside of a const member function, the type of 'this' seems to be
deduced as a pointer to const, when it should be a pointer to non-const.

Compiler explorer link: https://godbolt.org/z/9KKbrzq1e

Minimal reproduction:

struct Context
{
void
action() const
{
struct
{
int wrapped;
decltype( & wrapped ) get() { return &wrapped; }
} t;

*t.get()= 42;
}
};

Note that if the local class member function definition is changed to:

auto get() -> decltype( & wrapped ) { return &wrapped; }

Then the bug no longer appears.

> the exact version of gcc

gcc version 12.2.1 20220819 (Red Hat 12.2.1-2) (GCC)

> the system type

Fedora release 38 (Rawhide)

> the options given when GCC was configured/built

Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.2.1-20220819/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1

> the complete command line that triggers the bug

g++ poc.cpp

> the compiler output

poc.cpp: In member function ‘void Context::action() const’:
poc.cpp:12:17: error: assignment of read-only location ‘* t.Context::action()
constget()’
   12 | *t.get()= 42;
  | ^~~~

[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE

[jan.zizka at nokia dot com via Gcc-bugs]

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

--- Comment #12 from Jan Žižka  ---
(In reply to Richard Biener from comment #11)
> So there's a similar missed optimization but it's not caused by the bisected
> revision.  

Ah I see. I didn't try to bisect this again. I can do that if that would help
anything, let me know if I should try. I have bisect script so I can run it
overnight ...

Also is it better then to open new BZ for this case then?

> I have
> a patch that fixes the above but that miscompiles genrecog.cc
> merge_into_decision (but no testcase in the testsuite ...).

I could at least try to test the patch with our production code. Unfortunately
can't help with genrecog.cc ..

[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE

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

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

--- Comment #11 from Richard Biener  ---
So there's a similar missed optimization but it's not caused by the bisected
revision.  The situation is like

float bar, baz;
void foo (int *p, int n)
{
  *p = 0;
  do
{
  bar = 1.;
  if (*p)
{
  baz = 2.;
  *p = 0;
}
}
  while (--n);
}

where we fail to realize that in the first if (*p), *p stays zero.  I have
a patch that fixes the above but that miscompiles genrecog.cc
merge_into_decision (but no testcase in the testsuite ...).

[Bug target/106966] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

[christian.ehrhardt at canonical dot com via Gcc-bugs]

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

--- Comment #3 from Christian Ehrhardt  ---
> Just drop -mbuild-constants.

Thanks for the hint Uroš, but I'm not sure if one can do that, this option is
from [1]. I do not have the background on this, but it reads as there was a
reason "Use -mbuild-constants to prevent the compiler using static data" to set
this which seems more breaking than my current workaround (reduce -O2 to -O1).

[1]:
https://github.com/qemu/qemu-palcode/commit/0830e72f0bce29bdf1de0d67ad503a9a8b99c968

[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang

[immoloism at googlemail dot com via Gcc-bugs]

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

--- Comment #5 from Immolo  ---
How would I go about creating a reduce for this as I'd assume it's to with
running something llvm-reduce with
`/var/tmp/portage/sys-libs/compiler-rt-sanitizers-15.0.0/work/compiler-rt/lib/sanitizer_common/..
 -DNDEBUG -march=native -O2 -pipe -falign-functions=32 -m32 -Wthread-safety
-Wthread-safety-reference -Wthread-safety-beta -O3 -MD -MT
lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.i386.dir/sanitizer_deadlock_detector2.cpp.o
-MF
lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.i386.dir/sanitizer_deadlock_detector2.cpp.o.d
-o
lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.i386.dir/sanitizer_deadlock_detector2.cpp.o
-c
/var/tmp/portage/sys-libs/compiler-rt-sanitizers-15.0.0/work/compiler-rt/lib/sanitizer_common/sanitizer_deadlock_detector2.cpp`
however I can't seem to find a guide to make this understandable.

[Bug target/106966] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Christian Ehrhardt from comment #0)

> alpha-linux-gnu-gcc -O2 -g1 -Wall -fvisibility=hidden -fno-strict-aliasing
> -msmall-text -msmall-data -mno-fp-regs -mbuild-constants -mcpu=ev67

Just drop -mbuild-constants.

(There is a problem in alpha_emit_set_long_const which is not prepared to
handle V4HImode target).

[Bug c++/106965] g++ optimization removes assigning 0 to deleted pointer- causes double free.

[olddra3rd at mozmail dot com via Gcc-bugs]

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

--- Comment #2 from Boaz  ---
(In reply to Richard Biener from comment #1)
> I think it's undefined to invoke a DTOR twice which is what you do here. 
> After the DTOR the m_ptr member becomes undefined so re-evaluating that in
> the second invocation (when there's no object of type X anymore) is
> undefined.

Damn, you're right. Was told it's legal, but upon further check seems I was
wrong.
Cheers and thanks.

[Bug c++/106968] New: ignored noexcept(false) in explicitly-defaulted functions

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 106968
   Summary: ignored noexcept(false) in explicitly-defaulted
functions
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This code is accepted in Clang and MSVC:
```
#include 

struct A {
A(A &&) noexcept(false) = default;
};

static_assert(!std::is_nothrow_move_constructible_v);
```
but in GCC static assertion fails, online demo: https://godbolt.org/z/x3Gz46Exe

[Bug tree-optimization/106967] New: [13 Regression] ICE in upper_bound, at value-range.h:348

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 106967
   Summary: [13 Regression] ICE in upper_bound, at
value-range.h:348
   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 20220918 snapshot (g:313879d8768d08dea035efd7fd62b753dc91c364) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/pr29921-2.c, w/ -O2 -ffinite-math-only -fno-trapping-math
-fno-tree-dominator-opts:

void
foo (float x, int *y)
{
  int i;
  float sum2 = 0.0;

  for (i = 0; i < *y; ++i)
sum2 += x;

  sum2 = 1.0 / sum2;
  if (sum2 * 0.0 < 5.E-5)
*y = 0;
}

% gcc-13.0.0 -O2 -ffinite-math-only -fno-trapping-math -fno-tree-dominator-opts
-c skavkcop.c
during GIMPLE pass: thread
skavkcop.c: In function 'foo':
skavkcop.c:2:1: internal compiler error: in upper_bound, at value-range.h:348
2 | foo (float x, int *y)
  | ^~~
0x86077a frange::upper_bound() const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/value-range.h:348
0x86089c frange::upper_bound() const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree.h:3643
0x86089c foperator_lt::fold_range(irange&, tree_node*, frange const&, frange
const&, relation_kind_t) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/range-op-float.cc:550
0x86089c foperator_lt::fold_range(irange&, tree_node*, frange const&, frange
const&, relation_kind_t) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/range-op-float.cc:541
0x1d407b7 fold_using_range::range_of_range_op(vrange&, gimple*, fur_source&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:634
0x1d438d0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:555
0x1d43c9c fold_range(vrange&, gimple*, range_query*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-fold.cc:316
0x10a647d path_range_query::range_of_stmt(vrange&, gimple*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/gimple-range-path.cc:725
0x1130994 back_threader::find_taken_edge_cond(vec const&, gcond*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:334
0x1130b82 back_threader::maybe_register_path(back_threader_profitability&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:248
0x1131098 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:380
0x1131614 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:502
0x11320af back_threader::maybe_thread_block(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:574
0x1132161 back_threader::thread_blocks()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:1002
0x11321d3 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220918/work/gcc-13-20220918/gcc/tree-ssa-threadbackward.cc:1104

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jeffrey.rahr at baesystems dot com via Gcc-bugs]

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

--- Comment #19 from Jeff Rahr  ---
I added D language to my build and was able to get 12.2 to build "out of the
box" without editing Makefile.def on x86-64-pc-linux-gnu. Make is using 4
processors.

[Bug c++/106965] g++ optimization removes assigning 0 to deleted pointer- causes double free.

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I think it's undefined to invoke a DTOR twice which is what you do here.  After
the DTOR the m_ptr member becomes undefined so re-evaluating that in the second
invocation (when there's no object of type X anymore) is undefined.

[Bug c/106966] alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

[christian.ehrhardt at canonical dot com via Gcc-bugs]

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

--- Comment #1 from Christian Ehrhardt  ---
I compared a few more cross-gcc's I could get hold of.
Thereby I can state this was already broken with 12.1.0 on Ubuntu 22.04 and
Fedora 36.

Note: I'm only listing where the instructions for these differ

1. Fedora 36
gcc version 12.1.1 20220507 (Red Hat Cross 12.1.1-1) (GCC) 

$ dnf install gcc-alpha-linux-gnu make git
...
alpha-linux-gnu-gcc -O2 -g1 -Wall -fvisibility=hidden -fno-strict-aliasing
-msmall-text -msmall-data -mno-fp-regs -mbuild-constants -mcpu=ev67
-DSYSTEM_H='"sys-clipper.h"'  -c -o console.o console.c
during RTL pass: expand
console.c: In function ‘do_console’:
console.c:130:12: internal compiler error: in emit_move_insn, at expr.cc:4010
  130 | vga[0] = 'H' + attr;
  | ~~~^~~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
Preprocessed source stored into /tmp/cchVNtxj.out file, please attach this to
your bugreport.
make: *** [: console.o] Error 1



2. Ubuntu 22.04 gcc-12
gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04) 

$ apt install gcc-12-alpha-linux-gnu
...
alpha-linux-gnu-gcc-12 -O2 -g1 -Wall -fvisibility=hidden -fno-strict-aliasing
-msmall-text -msmall-data -mno-fp-regs -mbuild-constants -mcpu=ev67
-DSYSTEM_H='"sys-clipper.h"'  -c -o console.o console.c
during RTL pass: expand
console.c: In function ‘do_console’:
console.c:130:12: internal compiler error: in emit_move_insn, at expr.cc:4010
  130 | vga[0] = 'H' + attr;
  | ~~~^~~~
0x13767bb internal_error(char const*, ...)
???:0
0x5a92b0 fancy_abort(char const*, int, char const*)
???:0
0xe09a32 alpha_split_const_mov(machine_mode, rtx_def**)
???:0
0xe09ba1 alpha_expand_mov(machine_mode, rtx_def**)
???:0
0x112c7fd gen_movv4hi(rtx_def*, rtx_def*)
???:0
0x7ee88b emit_move_insn_1(rtx_def*, rtx_def*)
???:0
0x7eec77 emit_move_insn(rtx_def*, rtx_def*)
???:0
0xe0c3b6 alpha_expand_movmisalign(machine_mode, rtx_def**)
???:0
0x112caca gen_movmisalignv4hi(rtx_def*, rtx_def*)
???:0
0xa272fc expand_insn(insn_code, unsigned int, expand_operand*)
???:0
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.
make: *** [: console.o] Error 1

[Bug c/106966] New: alpha cross build crashes gcc-12 "internal compiler error: in emit_move_insn"

[christian.ehrhardt at canonical dot com via Gcc-bugs]

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

Bug ID: 106966
   Summary: alpha cross build crashes gcc-12 "internal compiler
error: in emit_move_insn"
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian.ehrhardt at canonical dot com
  Target Milestone: ---

Created attachment 53591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53591&action=edit
Full interim state generated with -freport-bug

Hi,
this was found as part of Ubuntu's build of qemu for the upcoming 22.10
release.
That already uses gcc 12.2. But gladly it can be reproduced much easier as it
breaks in cross-building one of the firmware blobs.

Repro steps in Ubuntu 22.10:
$ git clone https://gitlab.com/qemu-project/qemu-palcode.git
$ cd qemu-palcode/
$ apt install gcc-alpha-linux-gnu
$ make CROSS=alpha-linux-gnu-
...

alpha-linux-gnu-gcc -O2 -g1 -Wall -fvisibility=hidden -fno-strict-aliasing
-msmall-text -msmall-data -mno-fp-regs -mbuild-constants -mcpu=ev67
-DSYSTEM_H='"sys-clipper.h"'  -c -o console.o console.c
during RTL pass: expand
console.c: In function ‘do_console’:
console.c:130:12: internal compiler error: in emit_move_insn, at expr.cc:4010
  130 | vga[0] = 'H' + attr;
  | ~~~^~~~
0x137917b internal_error(char const*, ...)
???:0
0x5a9326 fancy_abort(char const*, int, char const*)
???:0
0xe0a692 alpha_split_const_mov(machine_mode, rtx_def**)
???:0
0xe0a801 alpha_expand_mov(machine_mode, rtx_def**)
???:0
0x112e2dd gen_movv4hi(rtx_def*, rtx_def*)
???:0
0x7eedeb emit_move_insn_1(rtx_def*, rtx_def*)
???:0
0x7ef1d7 emit_move_insn(rtx_def*, rtx_def*)
???:0
0xe0d016 alpha_expand_movmisalign(machine_mode, rtx_def**)
???:0
0x112e5aa gen_movmisalignv4hi(rtx_def*, rtx_def*)
???:0
0xa278fc expand_insn(insn_code, unsigned int, expand_operand*)
???:0
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.
make: *** [: console.o] Error 1



Note: Sadly I have no more recent e.g. gcc-snapshot of the cross toolchain to
test.

The issue occurred on my laptop on the builders of Ubuntu, so I assume it is
pretty generic.

Details about how GCC was built can be fetched from the Ubuntu build logs at
https://launchpad.net/ubuntu/+source/gcc-12/12.2.0-2ubuntu1

I have tried to compare older builds using gcc on Jammy. The version
11.3.0-1ubuntu1~22.04 there works fine. So it seems to be a regression between
that and 12.2.0-2ubuntu1.

Note: I have found that setting -O1 (instead of the -O2 default) will mitigate
the issue.

[Bug c++/106965] New: g++ optimization removes assigning 0 to deleted pointer- causes double free.

[olddra3rd at mozmail dot com via Gcc-bugs]

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

Bug ID: 106965
   Summary: g++ optimization removes assigning 0 to deleted
pointer- causes double free.
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olddra3rd at mozmail dot com
  Target Milestone: ---

Created attachment 53590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53590&action=edit
source file of the function implementations.

Dear GNU, how are you?
Using gcc version 11.2.0 (Ubuntu 11.2.0-19ubuntu1) on a Ubuntu 22.04,
received a double free after using a destructor twice (one explicitly and one
at the end of function) with compiling optimizations..

Comp
Bug occurs when when the call happens on a different compilation unit:

int main()
{
 X x1;
 x1.~X();

 return 0;
}

>From looking at the assembly - it seems assigning 0 to the pointer is removed
from the code.

Compilation flags:
g++ -O
Seems to work fine with clang++.

Have a great day!

[Bug c/44677] Warn for variables incremented but not used

[stormbyte at gmail dot com via Gcc-bugs]

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

David Manuelda  changed:

   What|Removed |Added

 CC||stormbyte at gmail dot com

--- Comment #14 from David Manuelda  ---
It is worth to notice that this bug propagates to C++ whenever an object uses
an int that increments but is never used, like the following example:

class Test{
public:
Test() { i = 0; i++; }
private:
int i;
};

int main(int, char**) {
Test unused;

return 0;
}

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|NEW

--- Comment #14 from Richard Biener  ---
(In reply to Alexander Monakov from comment #13)
> (In reply to Richard Biener from comment #12)
> > Of course for the testcase at hand it's all in
> > a single statement and no parens specify association (in case parens also
> > matter here, like in Fortran).  The fortran frontend adds PAREN_EXPRs
> > as association barriers which also would prevent FMAs to be formed.
> 
> Please note that in this testcase GCC is breaking language semantics by
> computing the same value in two different ways, and then using different
> computed values in dependent computations. This could not have happened in
> the abstract machine (there's a singular assignment in the original program,
> which is then used in subsequent iterations of the loop).

Hmm, OK.  I think we have a separate bugreport for this kind of thing.  I can't
seem to reproduce any vectorization for your smaller example though.

For SLP vectorization the main source of "duplication" is when we have
unvectorized uses of an SSA name (aka a LIVE def) and cannot use a lane
extract but retain the scalar computations.  In the updated Sample Program
this happens once but the corresponding subgraph is then not profitable
to vectorize for me, so it must be something else.

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

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

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

Bug 106902 Summary: [11/12/13 Regression] Program compiled with -O3 -mfma 
produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

--- Comment #13 from Alexander Monakov  ---
(In reply to Richard Biener from comment #12)
> > Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
> > rule?
> 
> You mean in the frontend only for -ffp-contract=on?

Yes. 

> Maybe, I suppose FE
> specific folding would also work in that case.  One would also need to read
> the fine prints in the language standards again as to whether FP contraction
> allows to form FMA for
> 
>  double tem = a * b;
>  double res = tem + c;
> 
> or across inlined function call boundaries which we'll happily do.

In C contraction is allowed only within an expression (hence a difference
between -ffp-contract=fast vs. -ffp-contract=on).

The original testcase was in C++, I think C++ does not specify it, but
hopefully we'd aim to implement the same semantics as for C.

> Of course for the testcase at hand it's all in
> a single statement and no parens specify association (in case parens also
> matter here, like in Fortran).  The fortran frontend adds PAREN_EXPRs
> as association barriers which also would prevent FMAs to be formed.

Please note that in this testcase GCC is breaking language semantics by
computing the same value in two different ways, and then using different
computed values in dependent computations. This could not have happened in the
abstract machine (there's a singular assignment in the original program, which
is then used in subsequent iterations of the loop).

[Bug target/99184] [avr] wrong double to 16-Bit and 32-Bit integers in libgcc/libf7

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
 Resolution|--- |FIXED
  Known to work||10.4.1, 11.3.1, 12.2.1,
   ||13.0
 Status|UNCONFIRMED |RESOLVED
  Known to fail||10.4.0, 11.3.0, 12.2.0

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug target/99184] [avr] wrong double to 16-Bit and 32-Bit integers in libgcc/libf7

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:848ddecfe14446947fe7697cdfafe0031c3c54c5

commit r10-10993-g848ddecfe14446947fe7697cdfafe0031c3c54c5
Author: Georg-Johann Lay 
Date:   Mon Sep 19 09:46:58 2022 +0200

Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints

this patch fixed PR target/99184 which incorrectly rounded during 64-bit
(long) double to 16-bit and 32-bit integers.

The patch just removes the respective roundings from
libf7-asm.sx::to_integer and ::to_unsigned.  Luckily, LibF7 does nowhere
use respective functions internally, the only user is in libf7.c::f7_exp

which reads

   f7_round (qq, qq);
   int16_t q = f7_get_s16 (qq);

so that f7_get_s16() operates on an already rounded value, and therefore
this code works unaltered with or without rounding in to_integer.

PR target/99184
libgcc/config/avr/libf7/
* libf7-asm.sx (to_integer, to_unsigned): Don't round 16-bit
and 32-bit integers.

(cherry picked from commit 0b5b8ac5cb7fe92dd17ae8bd7de84640daa59e84)

[Bug target/99184] [avr] wrong double to 16-Bit and 32-Bit integers in libgcc/libf7

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:175d6ba5f025c886f7f81bc8f9b24717da978933

commit r11-10263-g175d6ba5f025c886f7f81bc8f9b24717da978933
Author: Georg-Johann Lay 
Date:   Mon Sep 19 09:46:58 2022 +0200

Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints

this patch fixed PR target/99184 which incorrectly rounded during 64-bit
(long) double to 16-bit and 32-bit integers.

The patch just removes the respective roundings from
libf7-asm.sx::to_integer and ::to_unsigned.  Luckily, LibF7 does nowhere
use respective functions internally, the only user is in libf7.c::f7_exp

which reads

   f7_round (qq, qq);
   int16_t q = f7_get_s16 (qq);

so that f7_get_s16() operates on an already rounded value, and therefore
this code works unaltered with or without rounding in to_integer.

PR target/99184
libgcc/config/avr/libf7/
* libf7-asm.sx (to_integer, to_unsigned): Don't round 16-bit
and 32-bit integers.

(cherry picked from commit 0b5b8ac5cb7fe92dd17ae8bd7de84640daa59e84)

[Bug target/99184] [avr] wrong double to 16-Bit and 32-Bit integers in libgcc/libf7

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

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

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

https://gcc.gnu.org/g:57896e8cddd2eb952145fa32ca25635fd63246b4

commit r12-8773-g57896e8cddd2eb952145fa32ca25635fd63246b4
Author: Georg-Johann Lay 
Date:   Mon Sep 19 09:46:58 2022 +0200

Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints

this patch fixed PR target/99184 which incorrectly rounded during 64-bit
(long) double to 16-bit and 32-bit integers.

The patch just removes the respective roundings from
libf7-asm.sx::to_integer and ::to_unsigned.  Luckily, LibF7 does nowhere
use respective functions internally, the only user is in libf7.c::f7_exp

which reads

   f7_round (qq, qq);
   int16_t q = f7_get_s16 (qq);

so that f7_get_s16() operates on an already rounded value, and therefore
this code works unaltered with or without rounding in to_integer.

PR target/99184
libgcc/config/avr/libf7/
* libf7-asm.sx (to_integer, to_unsigned): Don't round 16-bit
and 32-bit integers.

(cherry picked from commit 0b5b8ac5cb7fe92dd17ae8bd7de84640daa59e84)

[Bug target/99184] [avr] wrong double to 16-Bit and 32-Bit integers in libgcc/libf7

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

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

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

https://gcc.gnu.org/g:0b5b8ac5cb7fe92dd17ae8bd7de84640daa59e84

commit r13-2719-g0b5b8ac5cb7fe92dd17ae8bd7de84640daa59e84
Author: Georg-Johann Lay 
Date:   Mon Sep 19 09:46:58 2022 +0200

Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints

this patch fixed PR target/99184 which incorrectly rounded during 64-bit
(long) double to 16-bit and 32-bit integers.

The patch just removes the respective roundings from
libf7-asm.sx::to_integer and ::to_unsigned.  Luckily, LibF7 does nowhere
use respective functions internally, the only user is in libf7.c::f7_exp

which reads

   f7_round (qq, qq);
   int16_t q = f7_get_s16 (qq);

so that f7_get_s16() operates on an already rounded value, and therefore
this code works unaltered with or without rounding in to_integer.

PR target/99184
libgcc/config/avr/libf7/
* libf7-asm.sx (to_integer, to_unsigned): Don't round 16-bit
and 32-bit integers.

[Bug tree-optimization/68097] We should track ranges for floating-point values too

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

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

--- Comment #8 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #7)
> Yes, I think fixed in that we can now record info on FP SSA names.  There
> are other bugs for specific things.
> 
> What's not fixed is that we still recurse to SSA defs in
> gimple_assign_nonnegative_warnv_p and friends.  We might think to fix that
> now,

I see.  If I understand things correctly, you may want to do something like:

  if (frange::supports_p (TREE_TYPE (name)))
{
  frange r;
  bool sign;
  if (get_global_range_query ()->range_of_expr (r, name)
  && r.signbit_p (sign))
return sign == false;
}

That is, get the global range of the SSA name, and if it has a known signbit,
you should be able to determine if it's nonnegative.  The above works correctly
for signed zeros now too.

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #12 from Richard Biener  ---
(In reply to Alexander Monakov from comment #11)
> Can we move -ffp-contract=fast under the -ffast-math umbrella and default to
> -ffp-contract=on/off?

That's probably a question for the frontend maintainers.

> Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
> rule?

You mean in the frontend only for -ffp-contract=on?  Maybe, I suppose FE
specific folding would also work in that case.  One would also need to read
the fine prints in the language standards again as to whether FP contraction
allows to form FMA for

 double tem = a * b;
 double res = tem + c;

or across inlined function call boundaries which we'll happily do.

Of course for the testcase at hand it's all in
a single statement and no parens specify association (in case parens also
matter here, like in Fortran).  The fortran frontend adds PAREN_EXPRs
as association barriers which also would prevent FMAs to be formed.

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

--- Comment #11 from Alexander Monakov  ---
Can we move -ffp-contract=fast under the -ffast-math umbrella and default to
-ffp-contract=on/off?

Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
rule?

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

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

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

Bug 106902 Summary: [11/12/13 Regression] Program compiled with -O3 -mfma 
produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Keywords|wrong-code  |
 Resolution|--- |INVALID

--- Comment #10 from Richard Biener  ---
Thanks Alexander for the analysis.  The situation seems to be impossible to
avoid in general so I think it isn't a bug but just very unfortunate and the
suggested fixes sound correct.

[Bug tree-optimization/68097] We should track ranges for floating-point values too

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog

--- Comment #7 from Richard Biener  ---
Yes, I think fixed in that we can now record info on FP SSA names.  There are
other bugs for specific things.

What's not fixed is that we still recurse to SSA defs in
gimple_assign_nonnegative_warnv_p and friends.  We might think to fix that now,
so I'm leaving this bug open for this particular issue, it's a good thing to
try for GCC 13.