[Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999

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

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

--- Comment #5 from Segher Boessenkool  ---
This testcase is invalid code of course, so anything can happen.  ICEs are bad
though ;-)

Please add to the comment that you don't want this substitution because it
leads
to ICEs, and mention the PR # in the comment.  But better, figure out *why*
this
ICEs later on: it is perfectly normal for combine to create RTL that is
non-sensical but structurally correct, and it should simply not pass recog.
This patch avoids the problem, and does not fix it.  It would be good to know
what the real problem is.

[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

--- Comment #29 from Richard Biener  ---
(In reply to Vladimir Makarov from comment #28)
> Could somebody benchmark the following patch on zen2 470.lbm.
> 
> diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
> index 9cee17479ba..76619aca8eb 100644
> --- a/gcc/lra-constraints.cc
> +++ b/gcc/lra-constraints.cc
> @@ -5084,7 +5089,9 @@ lra_constraints (bool first_p)
>  (x, lra_get_allocno_class (i)) == NO_REGS))
> || contains_symbol_ref_p (x
>   ira_reg_equiv[i].defined_p = false;
> -   if (contains_reg_p (x, false, true))
> +   if (contains_reg_p (x, false, true)
> +   || (CONST_DOUBLE_P (x)
> +   && maybe_ge (GET_MODE_SIZE (GET_MODE (x)), 8)))
>   ira_reg_equiv[i].profitable_p = false;
> if (get_equiv (reg) != reg)
>   bitmap_ior_into (equiv_insn_bitmap,
> _reg_info[i].insn_bitmap);
> 
> If it improves the performance, I'll commit this patch.
> 
> The expander unconditionally uses memory pool for double constants.  I think
> the analogous treatment could be done for equiv double constants in LRA.
> 
> I know only x86_64 permits 64-bit constants as immediate for moving them
> into general regs.  As double fp operations is not done in general regs in
> the most cases, they should be moved into fp regs and this is costly as Jan
> wrote.  So it has sense to prohibit using equiv double constant values in
> LRA unconditionally.  If in the future we have a target which can move
> double immediate into fp regs we can introduce some target hooks to deal
> with equiv double constant.  But right now I think there is no need for the
> new hook.

Code generation changes quite a bit, with the patch the offending function
is 16 bytes larger.  I see no large immediate moves to GPRs anymore but
there is still a lot of spilling of XMMs to GPRs.  Performance is
unchanged by the patch:

470.lbm 13740128107 S   13740128107 S
470.lbm 13740128107 *   13740128107 S
470.lbm 13740128107 S   13740128107 *

I've used

diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index 9cee17479ba..a0ec608c056 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -5084,7 +5084,9 @@ lra_constraints (bool first_p)
 (x, lra_get_allocno_class (i)) == NO_REGS))
|| contains_symbol_ref_p (x
  ira_reg_equiv[i].defined_p = false;
-   if (contains_reg_p (x, false, true))
+   if (contains_reg_p (x, false, true)
+   || (CONST_DOUBLE_P (x)
+   && maybe_ge (GET_MODE_SIZE (GET_MODE (x)),
UNITS_PER_WORD)))
  ira_reg_equiv[i].profitable_p = false;
if (get_equiv (reg) != reg)
  bitmap_ior_into (equiv_insn_bitmap,
_reg_info[i].insn_bitmap);

note UNITS_PER_WORD vs. literal 8.

Without knowing much of the code I wonder if we can check whether the move
will be to a reg in GENERAL_REGS?  That is, do we know whether there are
(besides some special constants like zero), immediate moves to the
destination register class?

That said, given the result on LBM I'd not change this at this point.

Honza wanted to look at the move pattern to try to mitigate the
GPR spilling of XMMs.

I do think that we need to take costs into account at some point and get
rid of the reload style hand-waving with !?* in the move patterns.

[Bug tree-optimization/104479] [12 Regression] cond_op is combined without considering single_use

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-10

--- Comment #1 from Richard Biener  ---
Confirmed.  When uncond_op is expensive (there's *div amongst them) that's
definitely unwanted.  OTOH when it is cheap then combining will reduce
latency.

GIMPLE wise it's a neutral transform if uncond_op is not single-use unless
we need two v_c_es.

In the assembly it's masked vpsrld vs. masked vpblendmd, it's not entirely
clear why one should be slower than the other (but yes, blends are usually
very cheap and also not resource constrained).

[Bug c++/104476] [10/11/12 Regression] using-decl shadowed by member function when in incomplete-class context

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #4 from Richard Biener  ---
Makes it P1 on the GCC 10 branch then given 10.3 worked.

[Bug target/104469] ICE: in extract_insn, at recog.cc:2769 (unrecognizable insn) with -mavx and __builtin_convertvector()

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/104468] with -O -g, quadratic compile time of function with __attribute__(("00")) that passes large structs by value

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
(In reply to Erik Carstensen from comment #3)
> Do we know that some suspected underlying issue is fixed, or could it be
> that the window of slowness (struct size ∈ [17,80]) just has moved?

There is g:716a5836928ee6d8fb884d9a2fbc1b1386ec8994 which removed some
quadraticness regarding to large structures and name lookup.  But that was C++
...

I don't know of anything specific otherwise.  We did do some compile-time
improvements in var-tracking and GCC 11 shows

 var-tracking dataflow  :   2.67 ( 41%)   0.00 (  0%)   2.66 ( 41%)
   96k (  2%)
 var-tracking emit  :   2.62 ( 40%)   0.00 (  0%)   2.63 ( 40%)
0  (  0%)

so that might be it.  Maybe that's possible to backport as well.

[Bug tree-optimization/104479] New: [12 Regression] cond_op is combined without considering single_use

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 104479
   Summary: [12 Regression] cond_op is combined without
considering single_use
   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: crazylht at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-*-* i?86-*-*

cat test.c

void
mc_weight (unsigned int* __restrict dst, unsigned int* __restrict src,
   int i_width,int i_scale, unsigned int* __restrict y)
{
  for(int x = 0; x < i_width; x++)
dst[x] =  src[x] >> 3 > 255 ? src[x] >> 3 : y[x];
}

gcc -march=icelake-server -O3


gcc11.2 

vpsrld  ymm0, YMMWORD PTR [rsi+rax], 3
vpcmpud k1, ymm0, ymm2, 2
vmovdqu32   ymm1{k1}, YMMWORD PTR [r8+rax]
vpcmpud k1, ymm0, ymm2, 6
vpblendmd   ymm0{k1}, ymm1, ymm0
vmovdqu YMMWORD PTR [rcx+rax], ymm0

gcc 12

vmovdqu ymm1, YMMWORD PTR [rsi+rax]
vpsrld  ymm2, ymm1, 3
vpcmpud k1, ymm2, ymm3, 2
vmovdqu32   ymm0{k1}, YMMWORD PTR [r8+rax]
vpcmpud k1, ymm2, ymm3, 6
vmovdqa ymm2, ymm0
vpsrld  ymm2{k1}, ymm1, 3
vmovdqu YMMWORD PTR [rcx+rax], ymm2

It's because in match.pd

---cut
(for uncond_op (UNCOND_BINARY)
 cond_op (COND_BINARY)
 (simplify
  (vec_cond @0 (view_convert? (uncond_op@4 @1 @2)) @3)
  (with { tree op_type = TREE_TYPE (@4); }
   (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
&& is_truth_type_for (op_type, TREE_TYPE (@0)))
(view_convert (cond_op @0 @1 @2 (view_convert:op_type @3))
 (simplify
  (vec_cond @0 @1 (view_convert? (uncond_op@4 @2 @3)))
  (with { tree op_type = TREE_TYPE (@4); }
   (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
&& is_truth_type_for (op_type, TREE_TYPE (@0)))
(view_convert (cond_op (bit_not @0) @2 @3 (view_convert:op_type @1)))
---end---

uncond_op + vec_cond is combined to cond_op w/o considering uncond_op result
could be used by others, which caused unoptimal codegen.

[Bug c++/104470] internal compiler error: Segmentation fault compiling std::variant with -std=c++20

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

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

--- Comment #2 from Andrew Pinski  ---
here is the full backtrace:
In file included from t.cc:2:
/home/apinski/upstream-gcc/include/c++/12.0.1/variant: In substitution of
‘template template using __accepted_type =
std::variant<_Types>::__to_type<__accepted_index<_Tp> > [with _Tp = _Tp&&;
 = typename std::enable_if, Bar
>::__not_self<_Tp&&>, void>::type; _Types = {Foo, Bar}]’:
t.cc:21:15:   required from here
/home/apinski/upstream-gcc/include/c++/12.0.1/variant:1384:43: internal
compiler error: Segmentation fault
 1384 | using __accepted_type = __to_type<__accepted_index<_Tp>>;
  |   ^~~~
0x11fceef crash_signal
/home/apinski/src/upstream-gcc-git/gcc/gcc/toplev.cc:322
0xba5a12 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:19883
0xbb95df tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:19316
0xbc306e tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:13423
0xbc3292 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:13405
0xbb4a9e tsubst(tree_node*, tree_node*, int, tree_node*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:15461
0xbc4197 tsubst_decl
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:14815
0xbb3792 instantiate_template_1
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:21470
0xbb4b7f instantiate_template(tree_node*, tree_node*, int)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:21529
0xbb4b7f instantiate_alias_template
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:21567
0xbb4b7f tsubst(tree_node*, tree_node*, int, tree_node*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:15462
0xbd278e rewrite_tparm_list
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:29006
0xbddce4 alias_ctad_tweaks
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:29484
0xb9e9aa deduction_guides_for
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:29646
0xb9ec34 do_class_deduction
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:29777
0xb9ec34 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/pt.cc:29934
0xa84b86 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/decl.cc:7947
0xb767e4 cp_parser_init_declarator
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:22811
0xb51428 cp_parser_simple_declaration
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:15284
0xb531d0 cp_parser_declaration_statement
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/parser.cc:14365
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/100038] -Warray-bound triggers false positives

[foom at fuhm dot net via Gcc-bugs]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #8 from James Y Knight  ---
Here's a shorter test-case, reproduces with g++-11 -O2 -Warray-bounds:
```
struct SparseBitVectorElement {
  long Bits[2];
  int find_first() const;
};

int SparseBitVectorElement::find_first() const {
  for (unsigned i = 0; i < 2; ++i)
if (Bits[i])
  return i; // 
  __builtin_unreachable(); // Illegal empty element
}
```

The "__builtin_unreachable" at the end of the function seems to be the trigger
for the issue -- presumably because the compiler decides to omit the loop end
condition as being unnecessary.


Trying the above on godbolt, it appears that it no longer occurs on gcc trunk
for this test-case. But, I don't know if that was intentionally fixed or just
happens not to trigger here. (I haven't tried compiling LLVM with a gcc trunk
snapshot to see if all similar warnings have gone away.)

[Bug target/104455] Cannot select -march=armv7-a using GCC 11

[noloader at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jeffrey Walton  ---
(In reply to Richard Earnshaw from comment #1)
> What's the configuration of the compiler?  Eg, the output of gcc -v

Thanks Richard. I set-up a Debian Qemu/Chroot for armhf. I can now duplicate
the problem.

#  cat test.S 
.globl return_magic
.type  return_magic,%function

return_magic:

movw r0, #0x1234
movt r0, #0x5678
bl   0

# g++ -g2 -O3 -Wa,--noexecstack -march=armv7-a test.S -c
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU

# gcc --version -v
Using built-in specs.
COLLECT_AS_OPTIONS='--version'
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/11/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-16'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-sjlj-exceptions --with-arch=armv7-a+fp --with-float=hard
--with-mode=thumb --disable-werror --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-16) 
gcc (Debian 11.2.0-16) 11.2.0
Copyright (C) 2021 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.


COLLECT_GCC_OPTIONS='--version' '-v'  '-mfloat-abi=hard' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+fp' '-march=armv7-a+fp' '-dumpdir' 'a-'
 /usr/lib/gcc/arm-linux-gnueabihf/11/cc1 -quiet -v -imultilib . -imultiarch
arm-linux-gnueabihf help-dummy -quiet -dumpdir a- -dumpbase help-dummy
-mfloat-abi=hard -mtls-dialect=gnu -mthumb -mlibarch=armv7-a+fp
-march=armv7-a+fp -version --version -o /tmp/ccdbsVZx.s
GNU C17 (Debian 11.2.0-16) version 11.2.0 (arm-linux-gnueabihf)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='--version' '-v'  '-mfloat-abi=hard' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+fp' '-march=armv7-a+fp' '-dumpdir' 'a-'
 as -v -march=armv7-a -mfloat-abi=hard -meabi=5 --version -o /tmp/ccYLSQQS.o
/tmp/ccdbsVZx.s
GNU assembler version 2.37.90 (arm-linux-gnueabihf) using BFD version (GNU
Binutils for Debian) 2.37.90.20220207
GNU assembler (GNU Binutils for Debian) 2.37.90.20220207
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-linux-gnueabihf'.
COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabihf/11/:/usr/lib/gcc/arm-linux-gnueabihf/11/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/11/:/usr/lib/gcc/arm-linux-gnueabihf/
LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabihf/11/:/usr/lib/gcc/arm-linux-gnueabihf/11/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/11/../../../:/lib/arm-linux-gnueabihf/:/lib/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/
COLLECT_GCC_OPTIONS='--version' '-v'  '-mfloat-abi=hard' '-mtls-dialect=gnu'
'-mthumb' '-mlibarch=armv7-a+fp' '-march=armv7-a+fp' '-dumpdir' 'a.'
 /usr/lib/gcc/arm-linux-gnueabihf/11/collect2 -plugin
/usr/lib/gcc/arm-linux-gnueabihf/11/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/arm-linux-gnueabihf/11/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc4oCuRH.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=gnu
--as-needed -m armelf_linux_eabi -pie --version
/usr/lib/gcc/arm-linux-gnueabihf/11/../../../arm-linux-gnueabihf/Scrt1.o
/usr/lib/gcc/arm-linux-gnueabihf/11/../../../arm-linux-gnueabihf/crti.o
/usr/lib/gcc/arm-linux-gnueabihf/11/crtbeginS.o
-L/usr/lib/gcc/arm-linux-gnueabihf/11
-L/usr/lib/gcc/arm-linux-gnueabihf/11/../../../arm-linux-gnueabihf
-L/usr/lib/gcc/arm-linux-gnueabihf/11/../../.. -L/lib/arm-linux-gnueabihf

[Bug rtl-optimization/104438] Combine optimization opportunity exposed after pro_and_epilogue

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug rtl-optimization/104438] Combine optimization opportunity exposed after pro_and_epilogue

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Hongtao.liu  ---
The opportunity disappear after r12-7125.

[Bug c++/104470] internal compiler error: Segmentation fault compiling std::variant with -std=c++20

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

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

--- Comment #1 from Andrew Pinski  ---
>When I switch to c++17 mode compiler does not crash.

yes because C++17 does not support deduction of template arguments of template
alias's while C++20 does. Note clang does not implement that yet.

[Bug target/104474] [12 Regression] ICE: in output_constant_pool_2, at varasm.cc:4062 with -mcpu=neoverse-512tvb -msve-vector-bits=512

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug target/104474] [12 Regression] ICE: in output_constant_pool_2, at varasm.cc:4062 with -mcpu=neoverse-512tvb -msve-vector-bits=512

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:41582f88ec01c5ce2f85ebc4ac2743eb426d6e33

commit r12-7159-g41582f88ec01c5ce2f85ebc4ac2743eb426d6e33
Author: Andrew Pinski 
Date:   Wed Feb 9 14:56:58 2022 -0800

[COMMITTED] Fix PR aarch64/104474: ICE with vector float initializers and
non-consts.

The problem here is that the aarch64 back-end was placing const0_rtx
into the constant vector RTL even if the mode was a floating point mode.
The fix is instead to use CONST0_RTX and pass the mode to select the
correct zero (either const_int or const_double).

Committed as obvious after a bootstrap/test on aarch64-linux-gnu with
no regressions.

PR target/104474

gcc/ChangeLog:

* config/aarch64/aarch64.cc
(aarch64_sve_expand_vector_init_handle_trailing_constants):
Use CONST0_RTX instead of const0_rtx for the non-constant elements.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/sve/pr104474-1.c: New test.
* gcc.target/aarch64/sve/pr104474-2.c: New test.
* gcc.target/aarch64/sve/pr104474-3.c: New test.

[Bug target/104451] [9/10/11/12 Regression] ICE: in emit_move_insn, at expr.cc:4010 with -O -mxop -mavx512f

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.3.1, 11.2.1, 12.0, 9.4.1
 Status|NEW |RESOLVED
  Known to fail|10.3.1, 11.2.1, 12.0, 9.4.1 |
 Resolution|--- |FIXED

--- Comment #9 from Andrew Pinski  ---
.

[Bug c++/104476] [10/11/12 Regression] using-decl shadowed by member function when in incomplete-class context

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|11.3|10.4

[Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2022-02-09
 Blocks||88443
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Both warnings trigger for the same reason.  The second one is for the
__atomic_or_fetch_4() call in basic block 4 below with the invalid pointer as
the first argument (184B).

   [local count: 1073741824]:
  _1 = this_10(D)->d;
  _2 = &_1->m_mutex;  <<< address of a member can
never be null
  MEM[(struct __as_base  &)] ={v} {CLOBBER};
  if (_2 != 0B)   <<< must be true
goto ; [90.00%]
  else
goto ; [10.00%]  <<< never taken

   [local count: 107374184]:
  if (enable_12(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 53687092]:
  __atomic_or_fetch_4 (184B, 64, 0); [tail call]   <<< warning here
  goto ; [100.00%]

The call is emitted as a result of the test in bb 2.  That in turn is the
result of the test for null in the QMutexLocker ctor:

inline explicit QMutexLocker(Mutex *mutex) noexcept
{
m = mutex;
if (__builtin_expect(!!(mutex), true)) {
mutex->lock();
isLocked = true;
}
}

The test should be pointless in setThrottled() where the ctor is invoked
because the address of no member can be null:

void QFutureInterfaceBase::setThrottled(bool enable)
{
QMutexLocker lock(>m_mutex);
if (enable) {
switch_on(d->state, Throttled);

The invalid call first appears in the dom2 dump so I'm guessing it's the result
of the prior thread1 pass.

The test (and the warning) can be avoided by asserting that in setThrottled()
like so:

if (!d) __builtin_unreachable ();
QMutexLocker lock(>m_mutex);

GCC folds equality tests involving the addresses of members, except for the
first one when it involves a pointer access (below), presumably out of an
overabundance of caution, in case the pointer is null (GCC 4.1 eliminated all
tests but that's changed since then).  The warning GCC issues indicates it
considers the address to be nonnull regardless (that's new in GCC 12).

$ cat t.c && gcc -O2 -S -Wall -march=haswell -fdump-tree-optimized=/dev/stdout
t.c
struct A { int x, y; };

void f (struct A *p)
{
  if (!>y)  // -Waddress
__builtin_abort ();// eliminated
}

void g (struct A *p)
{
  if (!>x)  // -Waddress
__builtin_abort ();// not eliminated
}
t.c: In function ‘f’:
t.c:5:7: warning: the comparison will always evaluate as ‘true’ for the address
of ‘y’ will never be NULL [-Waddress]
5 |   if (!>y)  // -Waddress
  |   ^
t.c:1:19: note: ‘y’ declared here
1 | struct A { int x, y; };
  |   ^
t.c: In function ‘g’:
t.c:11:7: warning: the comparison will always evaluate as ‘true’ for the
address of ‘x’ will never be NULL [-Waddress]
   11 |   if (!>x)  // -Waddress
  |   ^
t.c:1:16: note: ‘x’ declared here
1 | struct A { int x, y; };
  |^

;; Function f (f, funcdef_no=0, decl_uid=2479, cgraph_uid=1, symbol_order=0)

void f (struct A * p)
{
   [local count: 1073741824]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=2482, cgraph_uid=2, symbol_order=1)

void g (struct A * p)
{
  int * _1;

   [local count: 1073741824]:
  _1 = _2(D)->x;
  if (_1 == 0B)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug target/104469] ICE: in extract_insn, at recog.cc:2769 (unrecognizable insn) with -mavx and __builtin_convertvector()

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-02-09
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |9.5
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #1 from Uroš Bizjak  ---
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 36b35f68349..b2f56345c65 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -9223,7 +9223,7 @@ (define_expand "vec_unpacks_float_lo_v4si"
 (define_expand "vec_unpacks_float_hi_v8si"
   [(set (match_dup 2)
(vec_select:V4SI
- (match_operand:V8SI 1 "vector_operand")
+ (match_operand:V8SI 1 "register_operand")
  (parallel [(const_int 4) (const_int 5)
 (const_int 6) (const_int 7)])))
(set (match_operand:V4DF 0 "register_operand")

[Bug analyzer/104224] Testcases for analyzer "uninit" from fedora-devel

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from David Malcolm  ---
I've added further test coverage for "uninit" based on a discussion with Steve
Grubb, as r12-7157-g91b27d984ce174.

Closing this one out.

[Bug target/104458] [11/12 Regression] ICE: SIGSEGV in gen_udivmodhiqi3 -> copy_rtx with -O1 -m8bit-idiv

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|11.3|10.4
 Resolution|--- |FIXED

--- Comment #5 from Uroš Bizjak  ---
Fixed for gcc-10.4, gcc-11.3 and gcc-12.

[Bug target/104462] ICE: in extract_constrain_insn_cached, at recog.cc:2682 with -mavx512fp16 -mno-xsave

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
Fixed for gcc-11.4+.

[Bug target/104458] [11/12 Regression] ICE: SIGSEGV in gen_udivmodhiqi3 -> copy_rtx with -O1 -m8bit-idiv

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:983b7bcdd048650b193aad6018042b21626b89eb

commit r10-10444-g983b7bcdd048650b193aad6018042b21626b89eb
Author: Uros Bizjak 
Date:   Wed Feb 9 23:40:55 2022 +0100

i386: Force inputs to a register to avoid lowpart_subreg failure [PR104458]

Input operands can be in the form of:

(subreg:DI (reg:V2SF 96) 0)

which chokes lowpart_subreg. Force inputs to a register, which is
preferable even when the input operand is from memory.

2022-02-09  Uroš Bizjak  

gcc/ChangeLog:

PR target/104458
* config/i386/i386-expand.c (ix86_split_idivmod):
Force operands[2] and operands[3] into a register..

gcc/testsuite/ChangeLog:

PR target/104458
* gcc.target/i386/pr104458.c: New test.

[Bug target/104462] ICE: in extract_constrain_insn_cached, at recog.cc:2682 with -mavx512fp16 -mno-xsave

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Uros Bizjak :

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

commit r11-9549-gf8a496d7a28c3dda868c201621b001825ea6cef9
Author: Uros Bizjak 
Date:   Wed Feb 9 23:25:27 2022 +0100

i386: -mno-xsave should disable all relevant ISA flags [PR104462]

2022-02-09  Uroš Bizjak  

gcc/ChangeLog:

PR target/104462
* common/config/i386/i386-common.c (OPTION_MASK_ISA2_XSAVE_UNSET):
Also include OPTION_MASK_ISA2_AVX2_UNSET.

[Bug target/104458] [11/12 Regression] ICE: SIGSEGV in gen_udivmodhiqi3 -> copy_rtx with -O1 -m8bit-idiv

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:11fc7d98a25128d016b8f6f453c193878faf2570

commit r11-9548-g11fc7d98a25128d016b8f6f453c193878faf2570
Author: Uros Bizjak 
Date:   Wed Feb 9 20:18:10 2022 +0100

i386: Force inputs to a register to avoid lowpart_subreg failure [PR104458]

Input operands can be in the form of:

(subreg:DI (reg:V2SF 96) 0)

which chokes lowpart_subreg. Force inputs to a register, which is
preferable even when the input operand is from memory.

2022-02-09  Uroš Bizjak  

gcc/ChangeLog:

PR target/104458
* config/i386/i386-expand.c (ix86_split_idivmod):
Force operands[2] and operands[3] into a register..

gcc/testsuite/ChangeLog:

PR target/104458
* gcc.target/i386/pr104458.c: New test.

(cherry picked from commit 2b399dbabd48639ab4daac462c9d82c6cf3f99cc)

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

[svante.signell at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Svante Signell  ---
> If you make all-target-libgo all dependencies are respected.

Sorry but that is not how things work:
all-target-libgo: maybe-all-target-libffi
is outside any conditionals, but 
all-target-libgo: maybe-all-target-libbacktrace
all-target-libgo: maybe-all-target-libatomic
are inside the conditional
@unless gcc-bootstrap
@endunless gcc-bootstrap
in src/Makefile.in :(
and therefore not included in the generated build/Makefile.

The unless/endunless condition does not seem to be met in the generated
build/Makefile.

As far as I've searched, no understandable explanation of 
@unless/@endunless gcc-bootstrap is found in the gcc-12 tree either. No
explanation in Makefile.tpl

I found only a commit for binutils-gdb:
https://isrc.iscas.ac.cn/gitlab/mirrors/sourceware.org/git_binutils-gdb/-/commit/4119873a48042e532f7485b84cca83ea0bf1fcf6
but that one is not very informative :(

moving
all-target-libgo: maybe-all-target-libbacktrace
all-target-libgo: maybe-all-target-libatomic
next to
all-target-libgo: maybe-all-target-libffi
in Makefile.in all works fine.

Generating a new version of Makefile.in by:
(cd source; autogen Makefile.def)
does not solve the problem: the same buggy build/Makefile is created.

This is not a Debian problem, it is an upstream bug, as far as I've found.

It seems like everything not linux-any is left unsupported, not a nice
situation... Your choice!

And patching gnu.h to not support split-stack any longer is really not nice.
Don't you ever build gcc for GNU/Hurd? If not maybe I can help to set up such a
build environment. Just let me know!!

Thanks!

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

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

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r12-7153-gf3ffea93ef31c03ad8cdcb54e71ec868b57b264f
Author: Harald Anlauf 
Date:   Sun Feb 6 21:47:20 2022 +0100

Fortran: try simplifications during reductions of array constructors

gcc/fortran/ChangeLog:

PR fortran/66193
* arith.cc (reduce_binary_ac): When reducing binary expressions,
try simplification.  Handle case of empty constructor.
(reduce_binary_ca): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/66193
* gfortran.dg/array_constructor_55.f90: New test.

[Bug fortran/77693] ICE in rtl_for_decl_init, at dwarf2out.c:17378

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Patch at: https://gcc.gnu.org/pipermail/fortran/2022-February/057529.html

[Bug analyzer/103658] missing -Wanalyzer-use-of-uninitialized-value at -O1 and below for an array access

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

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from David Malcolm  ---
The analyzer is merging the paths after each conditional by default, which can
be disabled via -fno-analyzer-state-merge as noted in comment #2 above.

I don't plan to change this behavior as this appears to be an artificially
constructed testcase rather than real-world code; resolving this as WONTFIX.

[Bug analyzer/103658] missing -Wanalyzer-use-of-uninitialized-value at -O1 and below for an array access

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

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

--- Comment #2 from David Malcolm  ---
Note that with -fno-analyzer-state-merge, -fanalyzer warns without optimization
and shows the conditionals you hoped to see:

./xgcc -B. -S -fanalyzer /tmp/foo.c -fno-analyzer-state-merge 
/tmp/foo.c: In function 'f':
/tmp/foo.c:9:11: warning: use of uninitialized value 'a[]' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
9 |   return a[i + j];
  |  ~^~~
  'f': events 1-6
|
|3 |   int a[3];
|  |   ^
|  |   |
|  |   (1) region created on stack here
|..
|7 |   if (i < 1) i = 1;
|  |  ~   ~
|  |  | |
|  |  | (3) ...to here
|  |  (2) following 'true' branch (when 'i <= 0')...
|8 |   if (j < 1) j = 1;
|  |  ~   ~
|  |  | |
|  |  | (5) ...to here
|  |  (4) following 'true' branch (when 'j <= 0')...
|9 |   return a[i + j];
|  |  
|  |   |
|  |   (6) use of uninitialized value 'a[]' here
|

Not sure why it's printing  for the index though.

[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented

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

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

--- Comment #1 from Jonathan Wakely  ---
On further reflection, I'm not convinced the standard really intends to make
the pointer type a reference. That's weird. Returning a pointer as a pointer
makes a lot more sense.

[Bug c++/104476] [10/11/12 Regression] using-decl shadowed by member function when in incomplete-class context

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11/12 Regression]  |[10/11/12 Regression]
   |using-decl shadowed by  |using-decl shadowed by
   |member function when in |member function when in
   |incomplete-class context|incomplete-class context

--- Comment #3 from Patrick Palka  ---
(In reply to Patrick Palka from comment #2)
> Looks like it started with r11-8033.

which has also been backported as r10-9849.

[Bug libstdc++/104442] atomic::wait incorrectly loops in case of spurious notification when __waiter is shared

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Thomas Rodgers
:

https://gcc.gnu.org/g:5669a60e2fcc90afaa16fe20391cdcf18ab398d7

commit r11-9547-g5669a60e2fcc90afaa16fe20391cdcf18ab398d7
Author: Thomas Rodgers 
Date:   Wed Feb 9 12:29:19 2022 -0800

libstdc++: Fix deadlock in atomic wait [PR104442]

This issue was observed as a deadlock in
29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is
"laundered" (e.g. type T* does not suffice as a waitable address for the
platform's native waiting primitive), the address waited is that of the
_M_ver member of __waiter_pool_base, so several threads may wait on the
same address for unrelated atomic objects. As noted in the PR, the
implementation correctly exits the wait for the thread whose data
changed, but not for any other threads waiting on the same address.

As noted in the PR the __waiter::_M_do_wait_v member was correctly exiting
but the other waiters were not reloading the value of _M_ver before
re-entering the wait.

Moving the spin call inside the loop accomplishes this, and is
consistent with the predicate accepting version of __waiter::_M_do_wait.

libstdc++-v3/ChangeLog:

PR libstdc++/104442
* include/bits/atomic_wait.h (__waiter::_M_do_wait_v): Move spin
 loop inside do loop so that threads failing the wait, reload
 _M_ver.

(cherry picked from commit 4cf3c339815cdfa636b25a512f91b63d7c313fd6)

[Bug libstdc++/104442] atomic::wait incorrectly loops in case of spurious notification when __waiter is shared

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Thomas Rodgers :

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

commit r12-7151-g4cf3c339815cdfa636b25a512f91b63d7c313fd6
Author: Thomas Rodgers 
Date:   Wed Feb 9 12:29:19 2022 -0800

libstdc++: Fix deadlock in atomic wait [PR104442]

This issue was observed as a deadlock in
29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is
"laundered" (e.g. type T* does not suffice as a waitable address for the
platform's native waiting primitive), the address waited is that of the
_M_ver member of __waiter_pool_base, so several threads may wait on the
same address for unrelated atomic objects. As noted in the PR, the
implementation correctly exits the wait for the thread whose data
changed, but not for any other threads waiting on the same address.

As noted in the PR the __waiter::_M_do_wait_v member was correctly exiting
but the other waiters were not reloading the value of _M_ver before
re-entering the wait.

Moving the spin call inside the loop accomplishes this, and is
consistent with the predicate accepting version of __waiter::_M_do_wait.

libstdc++-v3/ChangeLog:

PR libstdc++/104442
* include/bits/atomic_wait.h (__waiter::_M_do_wait_v): Move spin
 loop inside do loop so that threads failing the wait, reload
 _M_ver.

[Bug c++/104476] [11/12 Regression] using-decl shadowed by member function when in incomplete-class context

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92918
   Keywords|needs-bisection |

--- Comment #2 from Patrick Palka  ---
Looks like it started with r11-8033.

[Bug c/104468] with -O -g, quadratic compile time of function with __attribute__(("00")) that passes large structs by value

[erik.carstensen at intel dot com via Gcc-bugs]

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

--- Comment #3 from Erik Carstensen  ---
Do we know that some suspected underlying issue is fixed, or could it be that
the window of slowness (struct size ∈ [17,80]) just has moved?

[Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Wstringop-overflow +|[12 Regression]
   |atomics incorrect warning   |Wstringop-overflow +
   |on dynamic object   |atomics incorrect warning
   ||on dynamic object
  Component|c++ |tree-optimization
   Target Milestone|--- |12.0
   Keywords||diagnostic, needs-reduction

[Bug c++/104476] [11/12 Regression] using-decl shadowed by member function when in incomplete-class context

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.3.0, 4.9.0, 5.1.0
 Ever confirmed|0   |1
Summary|using-decl shadowed by  |[11/12 Regression]
   |member function when in |using-decl shadowed by
   |incomplete-class context|member function when in
   ||incomplete-class context
   Target Milestone|--- |11.3
   Keywords||needs-bisection
  Known to fail||11.2.0, 12.0, 4.4.7
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-02-09

--- Comment #1 from Andrew Pinski  ---
Confirmed, a regression from GCC 10.x.

[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #5)
> "A type trait to detect reference binding to temporary"
> https://wg21.link/p2255r2 is the current direction to resolve this.

Which is now recorded as PR 104477.

[Bug target/104474] [12 Regression] ICE: in output_constant_pool_2, at varasm.cc:4062 with -mcpu=neoverse-512tvb -msve-vector-bits=512

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

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

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

[Bug target/104478] [12 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6862 with -mcpu=neoverse-v1 -frounding-math -msve-vector-bits=256

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
The patch which fixes PR 104474 fixes this one too.

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

[Bug target/104478] [12 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6862 with -mcpu=neoverse-v1 -frounding-math -msve-vector-bits=256

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
My bet this is the same issue as PR 104474.

[Bug target/104478] New: [12 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6862 with -mcpu=neoverse-v1 -frounding-math -msve-vector-bits=256

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104478
   Summary: [12 Regression] ICE: in native_encode_rtx, at
simplify-rtx.cc:6862 with -mcpu=neoverse-v1
-frounding-math -msve-vector-bits=256
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -mcpu=neoverse-v1 -frounding-math
-msve-vector-bits=256 testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:6:10: internal compiler error: in native_encode_rtx, at
simplify-rtx.cc:6862
6 |   return (F){0, 6270, 0, 0, 0, 0, 0, 0, 3229, 0, 40};
  |  ^
0x7aefdc native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
/repo/gcc-trunk/gcc/simplify-rtx.cc:6862
0x110fe2c native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
/repo/gcc-trunk/gcc/simplify-rtx.cc:6900
0x1110ad9 simplify_const_vector_subreg
/repo/gcc-trunk/gcc/simplify-rtx.cc:7249
0x11249bb simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<2u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.cc:7370
0x1126a91 simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<2u, unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.cc:7602
0x14d4ef0 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode,
poly_int<2u, unsigned long>)
/repo/gcc-trunk/gcc/rtl.h:3534
0x14d4ef0 aarch64_expand_sve_const_vector
/repo/gcc-trunk/gcc/config/aarch64/aarch64.cc:5545
0x14d6fa2 aarch64_expand_mov_immediate(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/aarch64/aarch64.cc:6075
0x19bf387 gen_movvnx8qi(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/aarch64/aarch64-sve.md:662
0xd5e634 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/repo/gcc-trunk/gcc/recog.h:407
0xd5e634 emit_move_insn_1(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.cc:3955
0xd5ea8d emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.cc:4125
0x14d2005 aarch64_sve_expand_vector_init_handle_trailing_constants
/repo/gcc-trunk/gcc/config/aarch64/aarch64.cc:21171
0x14d3957 aarch64_sve_expand_vector_init
/repo/gcc-trunk/gcc/config/aarch64/aarch64.cc:21293
0x14d3b33 aarch64_sve_expand_vector_init
/repo/gcc-trunk/gcc/config/aarch64/aarch64.cc:21333
0x14d3e32 aarch64_sve_expand_vector_init(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/aarch64/aarch64.cc:21377
0x19e03bc ???
/repo/gcc-trunk/gcc/config/aarch64/aarch64-sve.md:2639
0xd6c418 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/repo/gcc-trunk/gcc/recog.h:407
0xd6c418 store_constructor
/repo/gcc-trunk/gcc/expr.cc:7319
0xd6ebe8 expand_constructor
/repo/gcc-trunk/gcc/expr.cc:8657
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7143-20220209111047-ged3fea09b18-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/12.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7143-20220209111047-ged3fea09b18-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220209 (experimental) (GCC)

[Bug target/104474] [12 Regression] ICE: in output_constant_pool_2, at varasm.cc:4062 with -mcpu=neoverse-512tvb -msve-vector-bits=512

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This patch should fix it but have not tested it yet:
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 02ecb2154ea..d9f10301c52 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -21201,7 +21201,7 @@
aarch64_sve_expand_vector_init_handle_trailing_constants
{
  rtx x = builder.elt (i + nelts_reqd - n_trailing_constants);
  if (!valid_for_const_vector_p (elem_mode, x))
-   x = const0_rtx;
+   x = CONST0_RTX (elem_mode);
  v.quick_push (x);
}
   rtx const_vec = v.build ();

[Bug target/104441] [12 Regression] vzeroupper is placed at the wrong place

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:354349e7d59323559d0e372484f10358bd86a54f

commit r12-7149-g354349e7d59323559d0e372484f10358bd86a54f
Author: H.J. Lu 
Date:   Wed Feb 9 11:48:58 2022 -0800

x86: Compile PR target/104441 tests with -march=x86-64

Compile PR target/104441 tests with -march=x86-64 to fix test failures
when GCC is configured with --with-arch=native --with-cpu=native.

PR target/104441
* gcc.target/i386/pr104441-1a.c: Compile with -march=x86-64.
* gcc.target/i386/pr104441-1b.c: Likewise.

[Bug c++/104477] [C++23] Implement P2255R2, type trait to detect reference binding to temporary

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

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

Jason Merrill  changed:

   What|Removed |Added

 Blocks||98940
   Last reconfirmed||2022-02-09
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

[Bug c++/104477] New: [C++23] Implement P2255R2, type trait to detect reference binding to temporary

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

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

Bug ID: 104477
   Summary: [C++23] Implement P2255R2, type trait to detect
reference binding to temporary
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2255r2.html

The library type traits std::reference_{constructs,converts}_from_temporary
will need a compiler intrinsic to implement.

Apparently clang already has a __reference_binds_to_temporary with similar but
not identical semantics; I think let's see if they plan to adjust that builtin
or add a new one before we settle on a name.

[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision

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

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

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

https://gcc.gnu.org/g:499f8d4c2bc585b985882b4716f35b4c1553ce32

commit r12-7148-g499f8d4c2bc585b985882b4716f35b4c1553ce32
Author: Jakub Jelinek 
Date:   Wed Feb 9 20:45:31 2022 +0100

c: Fix up __builtin_assoc_barrier handling in the C FE [PR104427]

The following testcase ICEs, because when creating PAREN_EXPR for
__builtin_assoc_barrier the FE doesn't do the usual tweaks for
EXCESS_PRECISION_EXPR or C_MAYBE_CONST_EXPR.  I believe that the
declared effect of the builtin is just association barrier, so
e.g. excess precision should be still handled like if it wasn't
there.

The following patch uses build_unary_op to handle those.

2022-02-09  Jakub Jelinek  

PR c/104427
* c-parser.cc (c_parser_postfix_expression)
: Use parser_build_unary_op
instead of build1_loc to build PAREN_EXPR.
* c-typeck.cc (build_unary_op): Handle PAREN_EXPR.
* c-fold.cc (c_fully_fold_internal): Likewise.

* gcc.dg/pr104427.c: New test.

[Bug target/104474] [12 Regression] ICE: in output_constant_pool_2, at varasm.cc:4062 with -mcpu=neoverse-512tvb -msve-vector-bits=512

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|[12 Regression] ICE: in |[12 Regression] ICE: in
   |output_constant_pool_2, at  |output_constant_pool_2, at
   |varasm.cc:4062 with |varasm.cc:4062 with
   |-mcpu=neoverse-512tvb   |-mcpu=neoverse-512tvb
   |-frounding-math |-msve-vector-bits=512
   |-msve-vector-bits=512   |
 Ever confirmed|0   |1
   Last reconfirmed||2022-02-09

--- Comment #1 from Andrew Pinski  ---
Confirmed, the problem is the backend replaces the non-constant parts with
(const_int 0) rather than zero in the mode.
You can also reproduce the failure with just -mcpu=neoverse-512tvb
-msve-vector-bits=512 and:
typedef float __attribute__((__vector_size__ (64))) F;

F
foo (float t)
{
  return (F){t, 0, 0, 0, 0, 0, 0, 5, 0, t};
}

[Bug c++/104476] New: using-decl shadowed by member function when in incomplete-class context

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

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

Bug ID: 104476
   Summary: using-decl shadowed by member function when in
incomplete-class context
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

We reject the following valid testcase:

struct A {
  static void f();
};

struct B : A
{
  using A::f; // #1
  static void f(int); // #2
  auto g() -> decltype(f());  // Call should be accepted via #1, instead
rejected
};

with

:9:25: error: no matching function for call to ‘B::f()’
:8:15: note: candidate: ‘static void B::f(int)’
:8:15: note:   candidate expects 1 argument, 0 provided
:9:25: error: no matching function for call to ‘B::f()’
:8:15: note: candidate: ‘static void B::f(int)’
:8:15: note:   candidate expects 1 argument, 0 provided

Yet if we swap the order of the declarations #1 and #2, then we accept the
testcase.

[Bug c++/104475] New: Wstringop-overflow + atomics incorrect warning on dynamic object

[thiago at kde dot org via Gcc-bugs]

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

Bug ID: 104475
   Summary: Wstringop-overflow + atomics incorrect warning on
dynamic object
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

Created attachment 52399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52399=edit
qfutureinterface.cpp preprocessed

In:
static inline int switch_on(QAtomicInt , int which)
{
return a.fetchAndOrRelaxed(which) | which;
}

static inline int switch_off(QAtomicInt , int which)
{
return a.fetchAndAndRelaxed(~which) & ~which;
}

void QFutureInterfaceBase::setThrottled(bool enable)
{
QMutexLocker lock(>m_mutex);
if (enable) {
switch_on(d->state, Throttled);
} else {
switch_off(d->state, Throttled);
if (!(d->state.loadRelaxed() & suspendingOrSuspended))
d->pausedWaitCondition.wakeAll();
}
}

Compiling the attached preprocessed sources with:

g++ -Wall -Wextra -march=haswell -O2 -c -o /dev/null qfutureinterface.cpp.ii

Produces:

In member function ‘std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::fetch_or(__int_type, std::memory_order) [with _ITp
= int]’,
inlined from ‘static T QAtomicOps::fetchAndOrRelaxed(std::atomic&,
typename QAtomicAdditiveType::AdditiveT) [with T = int; X = int]’ at
/home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/thread/qatomic_cxx11.h:449:33,
inlined from ‘T QBasicAtomicInteger::fetchAndOrRelaxed(T) [with T =
int]’ at
/home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/thread/qbasicatomic.h:168:36,
inlined from ‘int switch_on(QAtomicInt&, int)’ at
/home/tjmaciei/src/qt/qt6/qtbase/src/corelib/thread/qfutureinterface.cpp:59:31,
inlined from ‘void QFutureInterfaceBase::setThrottled(bool)’ at
/home/tjmaciei/src/qt/qt6/qtbase/src/corelib/thread/qfutureinterface.cpp:71:18:
/home/tjmaciei/dev/gcc/include/c++/12.0.1/bits/atomic_base.h:648:33: warning:
‘unsigned int __atomic_or_fetch_4(volatile void*, unsigned int, int)’ writing 4
bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
  648 |   { return __atomic_fetch_or(&_M_i, __i, int(__m)); }
  |~^~
In member function ‘std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::fetch_and(__int_type, std::memory_order) [with _ITp
= int]’,
inlined from ‘static T QAtomicOps::fetchAndAndRelaxed(std::atomic&,
typename QAtomicAdditiveType::AdditiveT) [with T = int; X = int]’ at
/home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/thread/qatomic_cxx11.h:425:34,
inlined from ‘T QBasicAtomicInteger::fetchAndAndRelaxed(T) [with T =
int]’ at
/home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/thread/qbasicatomic.h:159:37,
inlined from ‘int switch_off(QAtomicInt&, int)’ at
/home/tjmaciei/src/qt/qt6/qtbase/src/corelib/thread/qfutureinterface.cpp:64:32,
inlined from ‘void QFutureInterfaceBase::setThrottled(bool)’ at
/home/tjmaciei/src/qt/qt6/qtbase/src/corelib/thread/qfutureinterface.cpp:73:19:
/home/tjmaciei/dev/gcc/include/c++/12.0.1/bits/atomic_base.h:638:34: warning:
‘unsigned int __atomic_fetch_and_4(volatile void*, unsigned int, int)’ writing
4 bytes into a region of size 0 overflows the destination
[-Wstringop-overflow=]
  638 |   { return __atomic_fetch_and(&_M_i, __i, int(__m)); }
  |~~^~

GCC Git commit 1ce5395977f37e8d0c03394f7b932a584ce85cc7, built today.

[Bug target/104474] [12 Regression] ICE: in output_constant_pool_2, at varasm.cc:4062 with -mcpu=neoverse-512tvb -frounding-math -msve-vector-bits=512

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/104474] New: [12 Regression] ICE: in output_constant_pool_2, at varasm.cc:4062 with -mcpu=neoverse-512tvb -frounding-math -msve-vector-bits=512

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104474
   Summary: [12 Regression] ICE: in output_constant_pool_2, at
varasm.cc:4062 with -mcpu=neoverse-512tvb
-frounding-math -msve-vector-bits=512
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -mcpu=neoverse-512tvb -frounding-math
-msve-vector-bits=512 testcase.c 
testcase.c:7:1: internal compiler error: in output_constant_pool_2, at
varasm.cc:4062
7 | }
  | ^
0x847ae5 output_constant_pool_2
/repo/gcc-trunk/gcc/varasm.cc:4062
0x147dc85 output_constant_pool_2
/repo/gcc-trunk/gcc/varasm.cc:4120
0x147deec output_constant_pool_1
/repo/gcc-trunk/gcc/varasm.cc:4188
0x1489dec output_constant_pool_contents
/repo/gcc-trunk/gcc/varasm.cc:4345
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7143-20220209111047-ged3fea09b18-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/12.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7143-20220209111047-ged3fea09b18-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220209 (experimental) (GCC)

[Bug target/104462] ICE: in extract_constrain_insn_cached, at recog.cc:2682 with -mavx512fp16 -mno-xsave

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

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

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

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

commit r12-7147-g2f9ab267e725ddf2b6b44113e4fc4fb8b2a6adfb
Author: Uros Bizjak 
Date:   Wed Feb 9 20:19:45 2022 +0100

i386: -mno-xsave should disable all relevant ISA flags [PR104462]

2022-02-09  Uroš Bizjak  

gcc/ChangeLog:

PR target/104462
* common/config/i386/i386-common.cc (OPTION_MASK_ISA2_XSAVE_UNSET):
Also include OPTION_MASK_ISA2_AVX2_UNSET.

gcc/testsuite/ChangeLog:

PR target/104462
* gcc.target/i386/pr104462.c: New test.

[Bug target/104458] [11/12 Regression] ICE: SIGSEGV in gen_udivmodhiqi3 -> copy_rtx with -O1 -m8bit-idiv

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

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

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

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

commit r12-7146-g2b399dbabd48639ab4daac462c9d82c6cf3f99cc
Author: Uros Bizjak 
Date:   Wed Feb 9 20:18:10 2022 +0100

i386: Force inputs to a register to avoid lowpart_subreg failure [PR104458]

Input operands can be in the form of:

(subreg:DI (reg:V2SF 96) 0)

which chokes lowpart_subreg. Force inputs to a register, which is
preferable even when the input operand is from memory.

2022-02-09  Uroš Bizjak  

gcc/ChangeLog:

PR target/104458
* config/i386/i386-expand.cc (ix86_split_idivmod):
Force operands[2] and operands[3] into a register..

gcc/testsuite/ChangeLog:

PR target/104458
* gcc.target/i386/pr104458.c: New test.

[Bug rtl-optimization/104459] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -funswitch-loops -fno-tree-dce

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
See e.g. https://gcc.gnu.org/legacy-ml/gcc-patches/2010-10/msg00059.html

[Bug target/97040] incorrect fused multiply add/subtract instruction generated from C code

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r12-7145-geefec38c992e3622a69de9667e91f0cafbff03cc
Author: Jeff Law 
Date:   Wed Feb 9 14:10:53 2022 -0500

Avoid using predefined insn name for instruction with different semantics

This isn't technically a regression, but it only impacts the v850 target
and
fixes a long standing code correctness issue.

As outlined in slightly more detail in the PR, the v850 is using the
pattern
name "fnmasf4" and "fnmssf4" to generate fnmaf.s and fnmsf.s instructions
 respectively.

Unfortunately fnmasf4 is expected to produce (-a * b) + c and
fnmssf4 (-a * b) - c.  Those v850 instructions actually negate the entire
result.

The fix is trivial.  Use a different pattern name so that the combiner can
still generate those instructions, but prevent those instructions from
being
used to implement GCC's notion of what fnmas and fnmss should be.

This fixes pr97040 as well as a handful of testsuite failures for the v3e5
multilib.

gcc/
PR target/97040
* config/v850/v850.md (*v850_fnmasf4): Renamed from fnmasf4.
(*v850_fnmssf4): Renamed from fnmssf4

[Bug rtl-optimization/104459] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -funswitch-loops -fno-tree-dce

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

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

--- Comment #3 from Jakub Jelinek  ---
On the other side, df-scan.cc does in 3 other spots:
  /* By adding the ref directly, df_insn_rescan my not find any
 differences even though the block will have changed.  So we need
 to mark the block dirty ourselves.  */
  if (!DEBUG_INSN_P (DF_REF_INSN (ref)))
df_set_bb_dirty (bb);
and
  /* The block must be marked as dirty now, rather than later as in
 df_insn_rescan and df_notes_rescan because it may not be there at
 rescanning time and the mark would blow up.
 DEBUG_INSNs do not make a block's data flow solution dirty (at
 worst the LUIDs are no longer contiguous).  */
  if (bb != NULL && NONDEBUG_INSN_P (insn))
df_set_bb_dirty (bb);
and
  if (!DEBUG_INSN_P (insn))
df_set_bb_dirty (bb);
so I wonder if another fix wouldn't be just not call df_set_bb_dirty on
DEBUG_INSN_P in df_insn_change_bb.  But what do I know about df :(.

[Bug target/97040] incorrect fused multiply add/subtract instruction generated from C code

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

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

--- Comment #2 from Jeffrey A. Law  ---
So a bit more background.  I was doing some maintenance work on the v850 a few
years back and noticed an issue with e3v5 testing and FMAs.  I poked around a
bit and had largely ruled out the generic bits of FMA generation as the
problem.  But I was very short of time and didn't have reasonable docs on the
implementation of FMAs for the newer versions of the v850 (e3v5 was added long
after I did the original port).  Renesas's site isn't great for finding the
relevant docs as you have to map from something like e3v5 to a part within the
v850 family:(

SO I set it aside.  You report caused me to dig a bit further.  I finally found
a mapping from e3v5 to a specific part on Renesas's site (RH850G3KH) and was
able to review the specification of these instructions.

Again I managed to convince myself that our gimple FMA generation was correct. 
I also convinced myself that the RTL patterns for the v850 match the
documentation from Renesas.   Then it finally hit me.

The v850 patterns are using pattern names that require specific semantics.  ie,
if the expanders see a pattern fnma they expect that pattern will
implement very specific semantics.  In particular they expect that the negation
will apply to one of the arguments to the multiplication.   But the instruction
emitted in those patterns negates the final result.  ie, GCC expects this
semantic from the fnma pattern

  (fma (neg op0) (op1) (op2))

But the v850 chip implements

  (neg (fma (op0) (op1) (op2)))

So the bug is using the "fnma" and "fnms" names for those patterns.  The RTL is
fine, it's strictly a pattern naming issue.

[Bug tree-optimization/24021] VRP does not work with floating points

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #14 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #11)
> And also take into account different rounding modes if
> user wants that to be honored.

And that would eliminate the need to consider the possibility of double
rounding in case of intermediate extended precision (as with x87).

[Bug target/104409] -march=armv8.6-a+ls64 crashes, LS64 builtins causes ICE

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Zdenek Sojka from comment #4)
> Probably related crash: (with -fpack-struct)
That is recorded as PR 103147 already.

[Bug target/104409] -march=armv8.6-a+ls64 crashes, LS64 builtins causes ICE

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #4 from Zdenek Sojka  ---
Probably related crash: (with -fpack-struct)
$ echo > testcase.c
aarch64-unknown-linux-gnu-gcc -march=armv8.6-a+ls64 -fpack-struct testcase.c 
: internal compiler error: in aarch64_init_ls64_builtins_types, at
config/aarch64/aarch64-builtins.cc:1616
0x8645dc aarch64_init_ls64_builtins_types
/repo/gcc-trunk/gcc/config/aarch64/aarch64-builtins.cc:1616
0x8645dc aarch64_init_ls64_builtins
/repo/gcc-trunk/gcc/config/aarch64/aarch64-builtins.cc:1622
0x8645dc aarch64_general_init_builtins()
/repo/gcc-trunk/gcc/config/aarch64/aarch64-builtins.cc:1735
0x14b06b8 aarch64_init_builtins
/repo/gcc-trunk/gcc/config/aarch64/aarch64.cc:14335
0xb6d2bd c_define_builtins
/repo/gcc-trunk/gcc/c-family/c-common.cc:4221
0xb6d2bd c_common_nodes_and_builtins()
/repo/gcc-trunk/gcc/c-family/c-common.cc:4708
0xac0678 c_init_decl_processing()
/repo/gcc-trunk/gcc/c/c-decl.cc:4503
0xb07368 c_objc_common_init()
/repo/gcc-trunk/gcc/c/c-objc-common.cc:62
0xaac283 lang_dependent_init
/repo/gcc-trunk/gcc/toplev.cc:1848
0xaac283 do_compile
/repo/gcc-trunk/gcc/toplev.cc:2143
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 rtl-optimization/104459] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -funswitch-loops -fno-tree-dce

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The divergence starts during jump_after_combine.
With -g0, cfg_layout_merge_blocks is called on
(note 53 51 56 13 [bb 13] NOTE_INSN_BASIC_BLOCK)
and
(code_label 56 53 57 14 8 (nil) [0 uses])
(note 57 56 79 14 [bb 14] NOTE_INSN_BASIC_BLOCK)
while with -g on:
(note 91 89 92 13 [bb 13] NOTE_INSN_BASIC_BLOCK)
(debug_insn 92 91 93 13 (var_location:SI n (clobber (const_int 0 [0])))
"pr104459.c":29:17 -1
 (nil))
(debug_insn 93 92 135 13 (debug_marker) "pr104459.c":31:17 -1
 (nil))
(debug_insn 135 93 96 13 (var_location:SI D#3 (clobber (const_int 0 [0]))) -1
 (nil))
(debug_insn 96 135 97 13 (var_location:SI y (debug_expr:SI D#3))
"pr104459.c":31:19 -1
 (nil))
and
(code_label 97 96 98 14 8 (nil) [0 uses])
(note 98 97 99 14 [bb 14] NOTE_INSN_BASIC_BLOCK)
(debug_insn 99 98 100 14 (var_location:SI y (clobber (const_int 0 [0]))) -1
 (nil))
(debug_insn 100 99 102 14 (debug_marker) "pr104459.c":22:33 -1
 (nil))
(debug_insn 102 100 133 14 (var_location:SI q (clobber (const_int 0 [0])))
"pr104459.c":22:33 -1
 (nil))

That function calls update_bb_for_insn_chain for note 98 through 102 for -g and
note 57 through note 57 for -g0.
547   end = NEXT_INSN (end);
548   for (insn = begin; insn != end; insn = NEXT_INSN (insn))
549 if (!BARRIER_P (insn))
550   df_insn_change_bb (insn, bb);
which means that for -g0 df_insn_change_bb isn't called, while for -g it is.
df_insn_change_bb in turn calls df_set_bb_dirty and that sets bb(14)->flags |=
BB_MODIFIED.
Unfortunately, cfgcleanup.cc uses the BB_MODIFIED flag to decide on some stuff:
try_forward_edges has:
  bool may_thread = first_pass || (b->flags & BB_MODIFIED) != 0;
and
  may_thread |= (target->flags & BB_MODIFIED) != 0;
and try_crossjump_bb has:
  /* If nothing changed since the last attempt, there is nothing
 we can do.  */
  if (!first_pass
  && !((e->src->flags & BB_MODIFIED)
   || (fallthru->src->flags & BB_MODIFIED)))
continue;
and
  /* If nothing changed since the last attempt, there is nothing
 we can do.  */
  if (!first_pass
  && !((e->src->flags & BB_MODIFIED)
   || (e2->src->flags & BB_MODIFIED)))
continue;
Seems this has been introduced in
https://gcc.gnu.org/legacy-ml/gcc-patches/2010-08/txt00014.txt
but before that we were using equally problematic df_get_bb_dirty.
As BB_MODIFIED is only used in those places:
cfgcleanup.cc:  bool may_thread = first_pass || (b->flags & BB_MODIFIED) !=
0;
cfgcleanup.cc:may_thread |= (target->flags & BB_MODIFIED) != 0;
cfgcleanup.cc:&& !((e->src->flags & BB_MODIFIED)
cfgcleanup.cc: || (fallthru->src->flags & BB_MODIFIED)))
cfgcleanup.cc:&& !((e->src->flags & BB_MODIFIED)
cfgcleanup.cc: || (e2->src->flags & BB_MODIFIED)))
df-core.cc:  bb->flags |= BB_MODIFIED;
I think best would be to introduce df_set_bb_dirty_for_debug or similar variant
to df_set_bb_dirty that wouldn't set the BB_MODIFIED flag, and use that in
df_insn_change_bb.

[Bug tree-optimization/104466] Inlining functions with restrict parameters can inhibit lim (e.g. in 554.roms_r)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||60712

--- Comment #3 from Andrew Pinski  ---
Isn't this a dup of bug 60712?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60712
[Bug 60712] "restrict" qualifier ignored on local variable or after inlining

[Bug ipa/104457] ipa-cp with autofdo: internal compiler error in update_specialized_profile, at ipa-cp.c:4422

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

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

--- Comment #2 from Martin Jambor  ---
I have made some substantial changes to how profile_counts are updated in
IPA-CP, so trying the current master is definitely a good idea.  It might just
work and even if it does not, fixing it there would probably be quite a bit
easier.

If it persists even on master, please attach the dump generated by
-fdump-ipa-cp-details - I would have a look by one generated by GCC 10 too but
much less enthusiastically ;-)

I would be fine demoting the assert to gcc_checking_assert.

[Bug target/104409] -march=armv8.6-a+ls64 crashes, LS64 builtins causes ICE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

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

[Bug target/104473] [12 Regression] ICE: free(): invalid pointer with -march=armv8.7-a or -march=armv8.8-a for g++

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 104409. The problem is LS64 types are not being done correctly.

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

[Bug target/104473] New: [12 Regression] ICE: free(): invalid pointer with -march=armv8.7-a or -march=armv8.8-a for g++

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104473
   Summary: [12 Regression] ICE: free(): invalid pointer with
-march=armv8.7-a or -march=armv8.8-a for g++
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Compiler output: (empty testcase)
$ echo > testcase.C

$ aarch64-unknown-linux-gnu-g++ -march=armv8.7-a testcase.C 
free(): invalid pointer
testcase.C:1: internal compiler error: Aborted
0x143819f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:322
0x2272914 diagnostic_finish(diagnostic_context*)
/repo/gcc-trunk/gcc/diagnostic.cc:321
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ aarch64-unknown-linux-gnu-g++ -march=armv8.8-a testcase.C -wrapper
valgrind,-q
==30775== Invalid write of size 8
==30775==at 0xBD0018: pushclass(tree_node*) (class.cc:8069)
==30775==by 0xDD7C12: begin_class_definition(tree_node*)
(semantics.cc:3467)
==30775==by 0xC5EDF5: cxx_simulate_record_decl(unsigned int, char const*,
array_slice) (decl.cc:16689)
==30775==by 0x18529AF: aarch64_init_ls64_builtins_types
(aarch64-builtins.cc:1610)
==30775==by 0x18529AF: aarch64_init_ls64_builtins
(aarch64-builtins.cc:1622)
==30775==by 0x18529AF: aarch64_general_init_builtins()
(aarch64-builtins.cc:1735)
==30775==by 0x179D458: aarch64_init_builtins() (aarch64.cc:14335)
==30775==by 0xE6641D: c_define_builtins (c-common.cc:4221)
==30775==by 0xE6641D: c_common_nodes_and_builtins() (c-common.cc:4708)
==30775==by 0xC5D185: cxx_init_decl_processing() (decl.cc:4452)
==30775==by 0xCA45F9: cxx_init() (lex.cc:328)
==30775==by 0xBA1293: lang_dependent_init (toplev.cc:1848)
==30775==by 0xBA1293: do_compile (toplev.cc:2143)
==30775==by 0xBA1293: toplev::main(int, char**) (toplev.cc:2310)
==30775==by 0xBA32BE: main (main.cc:39)
==30775==  Address 0x514bc70 is 0 bytes inside a block of size 1 alloc'd
==30775==at 0x483F835: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==30775==by 0x23043D7: xrealloc (xmalloc.c:179)
==30775==by 0xBD018F: pushclass(tree_node*) (class.cc:8063)
==30775==by 0xDD7C12: begin_class_definition(tree_node*)
(semantics.cc:3467)
==30775==by 0xC5EDF5: cxx_simulate_record_decl(unsigned int, char const*,
array_slice) (decl.cc:16689)
==30775==by 0x18529AF: aarch64_init_ls64_builtins_types
(aarch64-builtins.cc:1610)
==30775==by 0x18529AF: aarch64_init_ls64_builtins
(aarch64-builtins.cc:1622)
==30775==by 0x18529AF: aarch64_general_init_builtins()
(aarch64-builtins.cc:1735)
==30775==by 0x179D458: aarch64_init_builtins() (aarch64.cc:14335)
==30775==by 0xE6641D: c_define_builtins (c-common.cc:4221)
==30775==by 0xE6641D: c_common_nodes_and_builtins() (c-common.cc:4708)
==30775==by 0xC5D185: cxx_init_decl_processing() (decl.cc:4452)
==30775==by 0xCA45F9: cxx_init() (lex.cc:328)
==30775==by 0xBA1293: lang_dependent_init (toplev.cc:1848)
==30775==by 0xBA1293: do_compile (toplev.cc:2143)
==30775==by 0xBA1293: toplev::main(int, char**) (toplev.cc:2310)
==30775==by 0xBA32BE: main (main.cc:39)
...

$ aarch64-unknown-linux-gnu-g++ -march=armv8.9-a testcase.C 
cc1plus: error: unknown value 'armv8.9-a' for '-march'
cc1plus: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a
armv8.4-a armv8.5-a armv8.6-a armv8.7-a armv8.8-a armv8-r armv9-a; did you mean
'armv8.1-a'?

$ aarch64-unknown-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-g++
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7143-20220209111047-ged3fea09b18-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/12.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7143-20220209111047-ged3fea09b18-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220209 (experimental) (GCC)

[Bug tree-optimization/24021] VRP does not work with floating points

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #13 from Andrew Macleod  ---

> etc. which would be great if it could use frange.  Though, I think we also
> run here into the problem that match.pd right now avoids the ranger because
> it could reliably only allow walks from uses to SSA_NAME_DEF_STMTs and not
> the other direction.

That only happens with pointers and the non-null property right now, and even
that is going away to start GCC13. I have the prototype underway now.

.
> One thing to consider is that at runtime, not all arithmetics might be as
> precise as what mpfr does at compile time, so in some cases it should expect
> a few ulps or maybe even more than that as possible errors (especially for
> library functions).  And also take into account different rounding modes if
> user wants that to be honored.
> 

We'll leave those to the experts :-)

> As for exceptions, I guess one thing is that ranger computes ranges and
> another thing is that optimization based on that will sometimes need to punt
> if it could optimize away visible side-effects the user cares about.

yeah, like with no-delete-null-pointer, there may be flag checking required for
some things.

[Bug c++/104472] New: ICE: SIGSEGV in cxx_eval_internal_function with __builtin_convertvector()

[zsojka at seznam dot cz via Gcc-bugs]

ure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7128-20220209090954-gc6bb1db76b3-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220209 (experimental) (GCC)

[Bug tree-optimization/24021] VRP does not work with floating points

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #12 from Andrew Macleod  ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jeffrey A. Law from comment #7)
> > Very cool.  ANd no, I'm not enough of an expert on the FP side to shepherd
> > that though.  I would expect it to be exceptionally tricky on the solver
> > side.
> 
> The solver, or ranger/gori, should be isolated from changes.  The main goal
> is to make ranger work with generic vrange's, not iranges or franges.  Once
> I'm done with the abstraction, it should only be value-range.* (class
> frange) and range-ops* that should be affected.  That's the theory anyhow
> ;-).

Yeah, once we get things in place, there will be a skeleton frange class
representation that does some set of basic operations.

One or more floating point experts are welcome then to flush out additional
representational requirements in the frange class and range-op implementations
of any tree-codes operations.   There shouldn't be any changed required
anywhere else. VRP/threader/relations/folding/etc are all driven by range-ops.

And we are of course happy to help when the time comes and GCC13 opens up and
the abstraction code goes in.  If someone is really keen, they may be able to
work on a development branch a bit earlier than that... 

I also have a short list of practical floating point considerations I collected
a couple of years ago. So I don't lose it:

finite
non-zero/positive/negative
normalized
in the range [-1,1] (for trig functions)
which I would expect to come from adding some domain/range knowledge from
standard math functions, and propagating range info from integer stuff from
which floating point values are derived, on top of the usual stuff.

e.g. in embedded world floating-point values from peripherals would commonly
come from some PWM feature via integer division by a constant denominator,
which could tell us a fair bit (even more if it could use builtin expect
information about the numerator).

as far as existing consumers for this info - I'm not sure if glibc still has
special finite versions of functions, but those could be used based on range
info. likewise, knowing a value is normal or in a bounded range could allow for
'relaxed' versions of library functions to be used. there should also be some
inline sequences or other code transforms that are controlled by
finite-math-only and also enabled for provably finite values.

[Bug tree-optimization/24021] VRP does not work with floating points

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
Various match.pd patterns use predicates like:
(simplify
 (mult @0 real_zerop@1)
 (if (!tree_expr_maybe_nan_p (@0)
  && (!HONOR_NANS (type) || !tree_expr_maybe_infinite_p (@0))
  && (!HONOR_SIGNED_ZEROS (type) || tree_expr_nonnegative_p (@0)))
  @1))

/* In IEEE floating point, x*1 is not equivalent to x for snans.
   Likewise for complex arithmetic with signed zeros.  */
(simplify
 (mult @0 real_onep)
 (if (!tree_expr_maybe_signaling_nan_p (@0)
  && (!HONOR_SIGNED_ZEROS (type)
  || !COMPLEX_FLOAT_TYPE_P (type)))
  (non_lvalue @0)))

etc. which would be great if it could use frange.  Though, I think we also run
here into the problem that match.pd right now avoids the ranger because it
could reliably only allow walks from uses to SSA_NAME_DEF_STMTs and not the
other direction.
But of course those few simplifications are simple enough that they could be
also repeated somewhere in the e?vrp code.

One thing to consider is that at runtime, not all arithmetics might be as
precise as what mpfr does at compile time, so in some cases it should expect a
few ulps or maybe even more than that as possible errors (especially for
library functions).  And also take into account different rounding modes if
user wants that to be honored.

As for exceptions, I guess one thing is that ranger computes ranges and another
thing is that optimization based on that will sometimes need to punt if it
could optimize away visible side-effects the user cares about.

[Bug ipa/104377] Unreachable code in create_specialized_node of ipa-prop.c?

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

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

--- Comment #3 from Martin Jambor  ---
By the way, it would be good to invent some (slightly?) more intuitive API for
ipa_param_adjustments adjustments, merging and similar operations.  I simply
left it for later when I hoped I would have a better idea what API would be
best for the code that needs it.

[Bug c/104471] New: ICE with -nostdinc: NULL directory in find_file

[gscfq--- via Gcc-bugs]

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

Bug ID: 104471
   Summary: ICE with -nostdinc: NULL directory in find_file
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(related to pr80753 and pr80755)


$ cat z1.c
#if __has_include ()
#endif


$ gcc-12-20220206 -c z1.c -nostdinc
z1.c:1:20: error: no include path in which to search for stdlib.h
1 | #if __has_include ()
  |^~
cc1: internal compiler error: NULL directory in find_file
0x7c8de2 c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level,
cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1])
../../gcc/c-family/c-common.cc:6670
0x1e12599 cpp_error_at(cpp_reader*, cpp_diagnostic_level, unsigned int, char
const*, ...)
../../libcpp/errors.cc:302
0x1e17833 _cpp_find_file
../../libcpp/files.cc:516
0x1e18eba _cpp_has_header
../../libcpp/files.cc:2149
0x1e284f7 builtin_has_include
../../libcpp/macro.cc:429
0x1e284f7 _cpp_builtin_macro_text
../../libcpp/macro.cc:677
0x1e28769 builtin_macro
../../libcpp/macro.cc:762
0x1e25e73 enter_macro_context
../../libcpp/macro.cc:1588
0x1e27b60 cpp_get_token_1
../../libcpp/macro.cc:3018
0x1e149a4 _cpp_parse_expr
../../libcpp/expr.cc:1334
0x1e0eb43 do_if
../../libcpp/directives.cc:2060
0x1e10450 _cpp_handle_directive
../../libcpp/directives.cc:557
0x1e20c88 _cpp_lex_token
../../libcpp/lex.cc:3410
0x1e279ff cpp_get_token_1
../../libcpp/macro.cc:2930
0x7e553d c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc/c-family/c-lex.cc:483
0x74bb81 c_lex_one_token
../../gcc/c/c-parser.cc:279
0x788454 c_parser_peek_token(c_parser*)
../../gcc/c/c-parser.cc:483
0x788454 c_parse_file()
../../gcc/c/c-parser.cc:23317
0x7f7812 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1238

[Bug ipa/104377] Unreachable code in create_specialized_node of ipa-prop.c?

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

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

--- Comment #2 from Martin Jambor  ---
(In reply to Feng Xue from comment #1)
> 
> OK. I does missed something. Here we could not hold assumption that
> ipcp_decision_stage() only sees raw cgraph node, since sometime in the
> future some new ipa pass may be added prior to ipa-cp, and this pass
> introduces clone node.

Right, initially IPA-SRA was developed as a pass before IPA-CP and it
may well be that we decide to swap the order again.

> 
> However, there is a questionable point about the code snippet
> 
> if (!node->can_change_signature
> || old_adj->op != IPA_PARAM_OP_COPY
> || (!known_csts[old_adj->base_index]
> && ipa_is_param_used (info, old_adj->base_index)))
> 
> In ipa-cp, known_csts is for the node, has no relation to the node's origin
> node, but here it is accessed via index of the latter (old_adj->base_index),
> will this cause out-of-bound error?

I think the code is correct. Assume IPA-SRA running before IPA-CP, and
we're compiling a function with two argument, with indices 0 and 1.

Analysis phases of both passes run before the IPA (WPA) phases of
either.  This is important to keep in mind.

IPA SRA removes the first one with index zero as useless, IPA-CP wants
to remove the second one with index 1, possibly because it is constant
everywhere.  In oder to that it has to combine the pre-existing
adjustments with its own changes.

Before create_specialized_node, the pass checks whether previous
passes did not kill some parameters and stops caring about them, but
it does not re-index anything, all lattices, jump functions,
everything, still keep their positions (and thus indices) they got in
the analysis phase.

Then create_specialized_node hits this loop.  For i=0 encounters an
old_adj element that actually describes the parameter which originally
had index 1.  The pass looks up in base_index what the original
(pre-IPA) index of the parameter was (1) and uses those to look up in
its own structures whether it wants to remove it or not.

Bounds should be always OK, base_index should never be greater than
the original pre-IPA number of parameters (-1) and known_csts should
always have just as many parameters.

Does that make sense?

[Bug c++/104470] New: internal compiler error: Segmentation fault compiling std::variant with -std=c++20

[serpent7776 at gmail dot com via Gcc-bugs]

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

Bug ID: 104470
   Summary: internal compiler error: Segmentation fault compiling
std::variant with -std=c++20
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: serpent7776 at gmail dot com
  Target Milestone: ---

Created attachment 52396
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52396=edit
Preprocessed source

I encountered an internal compiler error while compiling the following code in
c++20 mode (no other flags are needed):

#include 

template 
struct Foo
{
T value;
};

template 
struct Bar
{
T value;
};

template 
using V = std::variant, Bar>;

int main()
{
V e = Foo("a");
}

When I switch to c++17 mode compiler does not crash.

I tested it on g++ 10.3.0 on FreeBSD 12.3-RELEASE-p1, but I can also reproduce
it on trunk version here https://godbolt.org/z/vn5Ws14Ma

Full error:

# g++10 -std=c++20 ice.ii
In file included from ice.cpp:1:
/usr/local/lib/gcc10/include/c++/variant: In substitution of 'template template using __accepted_type =
std::variant<_Types>::__to_type<__accepted_index<_Tp> > [with _Tp = _Tp&&;
 = typename std::enable_if, Bar
>::__not_self<_Tp&&>, void>::type; _Types = {Foo, Bar}]':
ice.cpp:20:15:   required from here
/usr/local/lib/gcc10/include/c++/variant:1335:36: internal compiler error:
Segmentation fault
 1335 |  using __accepted_type = __to_type<__accepted_index<_Tp>>;
  |^~~~
libbacktrace could not find executable to open

[Bug tree-optimization/24021] VRP does not work with floating points

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #10 from Vincent Lefèvre  ---
(In reply to Vincent Lefèvre from comment #9)
> Subnormals might also need to be considered as special cases: "Whether and
> in what cases subnormal numbers are treated as zeros is implementation
> defined." will be added to C23 (some behaviors are dictated by the hardware,
> e.g. ARM in some non-IEEE configurations), but I've asked for clarification
> in the CFP mailing-list.

Some details in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2797.htm

[Bug tree-optimization/24021] VRP does not work with floating points

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #9 from Vincent Lefèvre  ---
(In reply to Aldy Hernandez from comment #6)
> As I've mentioned, I'm hoping some floating expert can take this across to
> goal line, as my head will start spinning as soon as we start talking about
> NANs and such.  The range-op work will likely require floating specialized
> knowledge.

Subnormals might also need to be considered as special cases: "Whether and in
what cases subnormal numbers are treated as zeros is implementation defined."
will be added to C23 (some behaviors are dictated by the hardware, e.g. ARM in
some non-IEEE configurations), but I've asked for clarification in the CFP
mailing-list.

[Bug tree-optimization/24021] VRP does not work with floating points

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

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

--- Comment #8 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #7)
> Very cool.  ANd no, I'm not enough of an expert on the FP side to shepherd
> that though.  I would expect it to be exceptionally tricky on the solver
> side.

The solver, or ranger/gori, should be isolated from changes.  The main goal is
to make ranger work with generic vrange's, not iranges or franges.  Once I'm
done with the abstraction, it should only be value-range.* (class frange) and
range-ops* that should be affected.  That's the theory anyhow ;-).

[Bug c++/25689] missed diagnostic about assignment used as truth value.

[zhaoweiliew at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Zhao Wei Liew  ---
Created attachment 52395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52395=edit
Test patch (seeking feedback)

Hi! I wrote a small patch to fix this issue, but I think that it has much room
for improvement, though I'm not very sure how. Could anyone take a look and
give me feedback on how I could improve the patch?

Here's an example code snippet. I've commented the expected and actual
diagnostic results beside the lines of code.

struct A {
  A& operator=(int);
  operator bool();
};

void f(A a, A b)
{
  if (a = 0); // GCC warns after patch (correct)
  if (a.operator=(0)) {} // GCC warns after patch (incorrect, but doesn't sound
like a major issue)
  if (a = b) {} // GCC does not warn before & after patch (incorrect)
}

Specifically, there are 2 issues:
1. GCC warns for `if (a.operator=(0))`
2. GCC does not warn for `if (a = b)` where the default copy/move assignment
operator is used.

Thanks!

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

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

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

--- Comment #7 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #3)
> Shall it treat the fields that partially fall into the range and partially
> don't as padding (ignore them)

In short yes, but...

What a wacky class hierarchy.

So, when laying out C5, we first choose C2 as its primary base class; C4 is not
eligible because its direct C1 base is at offset 8 (in C4) to avoid conflicting
with C2's C1.

So then C5's C1 direct base is also at offset 8 to avoid C2's C1.

Then we place the C4 virtual base, which can also go at offset 8, because its
C1 will end up at offset 16 in C5.

But the C5 base of C9 doesn't include the C4 vbase, so when we look at C4 vbase
we see that it overlaps the end and yes, we can safely ignore it.

It would be possible to make a hierarchy where a one-byte vbase shares the
padding byte with C1:

struct smol { char c; };
struct C5 : virtual smol, virtual C4, C1 {};

Now smol and C1 are both one byte at offset 8, so we only know to ignore smol
if we know whether we're supposed to look at vbases or not.  So we might
wrongly treat that byte as data in C9 when it's actually padding.

I'd think it should be possible to handle this without a langhook by looking at
the BINFOs at the same time, i.e. within a base field, ignore BINFO_VIRTUAL_P
with non-0 offset.

[Bug target/104469] New: ICE: in extract_insn, at recog.cc:2769 (unrecognizable insn) with -mavx and __builtin_convertvector()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104469
   Summary: ICE: in extract_insn, at recog.cc:2769 (unrecognizable
insn) with -mavx and __builtin_convertvector()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -mavx testcase.c
testcase.c: In function 'foo':
testcase.c:6:1: warning: AVX512F vector return without AVX512F enabled changes
the ABI [-Wpsabi]
6 | {
  | ^
testcase.c:8:1: error: unrecognizable insn:
8 | }
  | ^
(insn 8 7 9 2 (set (reg:V4SI 84)
(vec_select:V4SI (mem/c:V8SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
(const_int -128 [0xff80])) [3 v+0 S32 A256])
(parallel [
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
]))) "testcase.c":7:10 -1
 (nil))
during RTL pass: vregs
testcase.c:8:1: internal compiler error: in extract_insn, at recog.cc:2769
0x769df8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x769e7b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0x75872d extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2769
0x100efe2 instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.cc:1611
0x100efe2 instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.cc:1985
0x100efe2 execute
/repo/gcc-trunk/gcc/function.cc:2034
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7128-20220209090954-gc6bb1db76b3-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7128-20220209090954-gc6bb1db76b3-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220209 (experimental) (GCC)

[Bug rtl-optimization/104400] [12 Regression] v850e lra/reload failure after recent change

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-02-09
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jeffrey A. Law  ---
NP on the timing.  My biggest concern (as always) is whether or not this is a
generic issue or a bug in the v850 target files.  The former is obviously much
more important.

If it starts to look like a target issue, then feel free to punt it to me. 
While I don't know the v850 fp bits, I have retained a fair amount of generic
v850 knowledge over the decades :-)

[Bug tree-optimization/24021] VRP does not work with floating points

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #7 from Jeffrey A. Law  ---
Very cool.  ANd no, I'm not enough of an expert on the FP side to shepherd that
though.  I would expect it to be exceptionally tricky on the solver side.

Probably the most useful things I've come across would be knowing if a
particular value can or can not have certain special values.  ie, [qs]NaN,
+-0.0, +-Inf.  Knowing how an value relates to 0 is also quite helpful.  ie, >
0, < 0 and the like.

[Bug debug/104460] [RISCV] Incorrect DW_AT_high_pc for assembly source with linker relaxation

[joseph.faulls at imgtec dot com via Gcc-bugs]

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

Joseph Faulls  changed:

   What|Removed |Added

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

--- Comment #4 from Joseph Faulls  ---
(In reply to Andrew Pinski from comment #3)
> Gcc is not responsible for debug info that is done for the .s file, please
> report that issue to binutils: https://sourceware.org/bugzilla/

Sure. Thanks for the reply.

[Bug debug/104460] [RISCV] Incorrect DW_AT_high_pc for assembly source with linker relaxation

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

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

--- Comment #3 from Andrew Pinski  ---
Gcc is not responsible for debug info that is done for the .s file, please
report that issue to binutils: https://sourceware.org/bugzilla/

[Bug tree-optimization/24021] VRP does not work with floating points

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||jeffreyalaw at gmail dot com,
   ||richard.guenther at gmail dot 
com

--- Comment #6 from Aldy Hernandez  ---
Preview of what's to come.

Implementing a bare bones frange class and associated relational operators in
range-ops we can get:

void link_error();
void func();

int foo(float f)
{
  if (f > 3.0)
{
  func();
  if (f < 2.0)
link_error();
}
}

Folding statement: if (f_2(D) > 3.0e+0)
Not folded
Folding statement: func ();
Not folded
Folding statement: if (f_2(D) < 2.0e+0)
Folding predicate f_2(D) < 2.0e+0 to 0
Folded into: if (0 != 0)

And we can also get symbolics:

int bar(float f, float g)
{
  if (f > g)
{
  func();
  if (f < g)
link_error();
}
}

Folding statement: if (f_2(D) < g_3(D))
 folding with relation f_2(D) > g_3(D)
Folding predicate f_2(D) < g_3(D) to 0
Folded into: if (0 != 0)

My proof of concept has ranger dumps looking like:

=== BB 2 
Imports: f_2(D)  
Exports: f_2(D)  
f_2(D)  float VARYING
 :
if (f_2(D) > 3.0e+0)
  goto ; [INV]
else
  goto ; [INV]

2->3  (T) f_2(D) :  float (3.0e+0, +Inf]
2->5  (F) f_2(D) :  float [-Inf, 3.0e+0]


Interestingly, since the threader uses ranger, I had to turn off the threader
for the above snippets, because ethread gets the first one before evrp even
gets a whack at it:

  [1] Registering jump thread: (2, 3) incoming edge;  (3, 5) nocopy; 
path: 2->3->5 SUCCESS
Removing basic block 3
;; basic block 3, loop depth 0
;;  pred:  
func ();
if (f_2(D) < 2.0e+0)
  goto ; [INV]
else
  goto ; [INV]
;;  succ:   4
;;  5

As I've mentioned, I'm hoping some floating expert can take this across to goal
line, as my head will start spinning as soon as we start talking about NANs and
such.  The range-op work will likely require floating specialized knowledge.

[Bug c++/104432] [12 Regression] ICE in operator() from filter_memfn_lookup since r12-6080

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Fixed.

[Bug c++/104432] [12 Regression] ICE in operator() from filter_memfn_lookup since r12-6080

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-7134-gee50b4383a0dca88172c3a821418344bd7391956
Author: Patrick Palka 
Date:   Wed Feb 9 11:33:04 2022 -0500

c++: memfn lookup consistency and using-decls [PR104432]

In filter_memfn_lookup, we weren't correctly recognizing and matching up
member functions introduced via a non-dependent using-decl.  This caused
us to crash in the below testcases in which we correctly pruned the
overload set for the non-dependent call ahead of time, but then at
instantiation time filter_memfn_lookup failed to match the selected
function (introduced in each case by a non-dependent using-decl) to the
corresponding function from the new lookup set.  Such member functions
need special handling in filter_memfn_lookup because they look exactly
the same in the old and new lookup sets, whereas ordinary member
functions that're defined in the (dependent) current class become more
specialized in the new lookup set.

This patch reworks the matching logic in filter_memfn_lookup so that it
handles (member functions introduced by) non-dependent using-decls
correctly, and is hopefully simpler overall.

PR c++/104432

gcc/cp/ChangeLog:

* call.cc (build_new_method_call): When a non-dependent call
resolves to a specialization of a member template, always build
the pruned overload set using the member template, not the
specialization.
* pt.cc (filter_memfn_lookup): New parameter newtype.  Simplify
and correct how members from the new lookup set are matched to
those from the old one.
(tsubst_baselink): Pass binfo_type as newtype to
filter_memfn_lookup.

gcc/testsuite/ChangeLog:

* g++.dg/template/non-dependent19.C: New test.
* g++.dg/template/non-dependent19a.C: New test.
* g++.dg/template/non-dependent20.C: New test.

[Bug c++/103524] [meta-bug] modules issue

[johelegp at gmail dot com via Gcc-bugs]

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

Bug 103921 Summary: [modules] ICE dependent expression in explicit-specifier of 
instantiation of imported template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103921

   What|Removed |Added

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

[Bug c++/103752] [12 Regression][ICE][modules] with import

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Johel Ernesto Guerrero Peña  ---
*** Bug 103921 has been marked as a duplicate of this bug. ***

[Bug c++/103921] [modules] ICE dependent expression in explicit-specifier of instantiation of imported template

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

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

--- Comment #5 from Johel Ernesto Guerrero Peña  ---
Resolved by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103752#c2.

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

[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

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

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

--- Comment #21 from Vladimir Makarov  ---
(In reply to Iain Sandoe from comment #20)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Vladimir Makarov from comment #13)
> > > I think there are two code spots whose pitfalls resulted in the PR.
> 
> > > --- a/gcc/config/rs6000/rs6000.c
> > > +++ b/gcc/config/rs6000/rs6000.c
> > > @@ -8202,7 +8202,7 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx 
> > > x,
> > > int strict)
> > >  {
> > >bool large_toc_ok;
> > > 
> > > -  if (DEFAULT_ABI == ABI_V4 && flag_pic)
> > > +  if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN) && 
> > > flag_pic)
> > > return false;
> 
> On testing, this is not sufficient - one ends up with ICEs when we reject a
> valid (UNSPEC-wrapped) address here.  So I think that the slightly more
> elaborate target changes are required - but the LRA change seems fine!
> 
> ... reg-straps on this old h/w take > 1 day .. so some more time will be
> needed for a complete answer.

Ian, you have my approval for LRA changes in advance for committing them into
the master and the branches when the overall patch is ready.  Thank you for
working on machine-dependent parts of the patch.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 102562 Summary: [12 Regression][modules] Failing 
g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102562

   What|Removed |Added

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

[Bug c++/102562] [12 Regression][modules] Failing g++.dg/modules/xtreme-header tests since r12-4067-gc46ecb0112e91c8

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

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
This seems to have been fixed in December.

[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

--- Comment #28 from Vladimir Makarov  ---
Could somebody benchmark the following patch on zen2 470.lbm.

diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index 9cee17479ba..76619aca8eb 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -5084,7 +5089,9 @@ lra_constraints (bool first_p)
 (x, lra_get_allocno_class (i)) == NO_REGS))
|| contains_symbol_ref_p (x
  ira_reg_equiv[i].defined_p = false;
-   if (contains_reg_p (x, false, true))
+   if (contains_reg_p (x, false, true)
+   || (CONST_DOUBLE_P (x)
+   && maybe_ge (GET_MODE_SIZE (GET_MODE (x)), 8)))
  ira_reg_equiv[i].profitable_p = false;
if (get_equiv (reg) != reg)
  bitmap_ior_into (equiv_insn_bitmap,
_reg_info[i].insn_bitmap);

If it improves the performance, I'll commit this patch.

The expander unconditionally uses memory pool for double constants.  I think
the analogous treatment could be done for equiv double constants in LRA.

I know only x86_64 permits 64-bit constants as immediate for moving them into
general regs.  As double fp operations is not done in general regs in the most
cases, they should be moved into fp regs and this is costly as Jan wrote.  So
it has sense to prohibit using equiv double constant values in LRA
unconditionally.  If in the future we have a target which can move double
immediate into fp regs we can introduce some target hooks to deal with equiv
double constant.  But right now I think there is no need for the new hook.

[Bug c++/103752] [12 Regression][ICE][modules] with import

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

 CC||johelegp at gmail dot com

--- Comment #4 from Johel Ernesto Guerrero Peña  ---
Do you think this also fixed Bug 103921?

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 103752 Summary: [12 Regression][ICE][modules] with import 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103752

   What|Removed |Added

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

[Bug c++/103752] [12 Regression][ICE][modules] with import

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.