[Bug ipa/106124] [11/12 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] ICE   |[11/12 Regression] ICE in
   |in  |dwarf2out_abstract_function
   |dwarf2out_abstract_function |, at dwarf2out.cc:23254
   |, at dwarf2out.cc:23254 |
  Known to work||13.0

--- Comment #7 from Richard Biener  ---
Worked around on trunk sofar.

[Bug ipa/106124] [11/12/13 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

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

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

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

https://gcc.gnu.org/g:36330e2e95564a360e6dbcfb4e7566d5c2177415

commit r13-6925-g36330e2e95564a360e6dbcfb4e7566d5c2177415
Author: Richard Biener 
Date:   Mon Mar 27 16:40:15 2023 +0200

ipa/106124 - ICE with -fkeep-inline-functions and OpenMP

The testcases in this bug reveal cases where an early generated
type is collected because it was unused but gets attempted to
be recreated later when a late DIE for a function (an OpenMP
reduction) is created.  That's unexpected and possibly the fault
of OpenMP but the following allows the re-creation of the context
type to succeed.

PR ipa/106124
* dwarf2out.cc (lookup_type_die): Reset TREE_ASM_WRITTEN
so we can re-create the DIE for the type if required.

* g++.dg/gomp/pr106124.C: New testcase.

[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Xi Ruoyao from comment #5)
> The test fails on loongarch64-linux-gnu.  foo is kept in 114t.threadfull1,
> but removed in 135t.forwprop3.
> 
> Does this mean something is wrong for LoongArch, or we should simply check
> the tree dump in a later pass (for e.g. 254t.optimized)?

I guess it depends on LOGICAL_OP_NON_SHORT_CIRCUIT, can you try
--param logical-op-non-short-circuit=1 and see if that helps?

[Bug c/109328] Build fail in RISC-V port

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #1 from JuzheZhong  ---
https://github.com/compiler-explorer/compiler-explorer/issues/4900#issuecomment-1488009231

[Bug ipa/106124] [11/12/13 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 28 Mar 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106124
> 
> --- Comment #4 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #3)
> > I suppose that's the OMP reduction function and that's always(?) inlined?
> 
> The reduction "function" is something artificial which holds some expressions
> for the
> OpenMP reductions; we just need to attach those statements to some decl for
> name lookup purposes.
> The problem is what to do with lambdas defined inside of those expressions, or
> e.g. nested functions for the C case:
> int q;
> 
> #pragma omp declare reduction (x : int : omp_out += omp_in + ({ int a = 1; 
> void
> foo () { a++; } foo (); a; }))
> 
> void bar (int *, int *);
> 
> void
> foo ()
> {
>   int r = 0, s = 0;
>   #pragma omp parallel reduction (x : r, s)
>   bar (&r, &s);
> }
> 
> ICEs too.  Lambdas are there certainly valid, we try to pretend the artificial
> functions don't really exist for the debug info purposes, but apparently not
> sufficiently.

Set DECL_IGNORED?

[Bug c/109328] New: Build fail in RISC-V port

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 109328
   Summary: Build fail in RISC-V port
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

[ERROR]   
/opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/riscv-vector-builtins.def:380:10:
fatal error: riscv-vector-type-indexer.gen.def: No such file or d
irectory
[ERROR]make[3]: ***
[/opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/t-riscv:29:
riscv-vector-builtins-shapes.o] Error 1
[ERROR]make[3]: *** Waiting for unfinished jobs
[ERROR]   
/opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/riscv-vector-builtins.def:380:10:
fatal error: riscv-vector-type-indexer.gen.def: No such file or d
irectory
[ERROR]make[3]: ***
[/opt/.build/riscv64-unknown-linux-gnu/src/gcc/gcc/config/riscv/t-riscv:42:
riscv-vector-builtins-bases.o] Error

Reported by compiler explorer port who is trying to support RISC-V trunk GCC in
compiler explorer.

[Bug tree-optimization/109301] [13 Regression] ICE in format_helper, at real.h:233 since r13-1763

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #39 from Richard Biener  ---
(In reply to Andrew Macleod from comment #37)
> Created attachment 54780 [details]
> in progress patch
> 
> Well call me a liar. 
> 
> It took me a while to understand why, but if we leave it to single
> dependencies only, the impact is relatively linear.  I wrote a bunch of
> code, then deleted most of it as I found the engine was bypassing my code
> and doing it on its own.
> 
> The attached patch is the core.  It actually works to a depth of 5
> recomputations. my sample of:
>   int a = left * 2;
>   int b = a - 4;
>   int c = b % 7;
>   func (a,b ,c);
>   int d = c * 4;
>   if (left == 20)
> {
>   func (b,c,d);
> 
> produces 
>:
>   func (36, 1, 4);
> 
> IT also changes your program somewhat.
>  
> Try applying it and see if it does what you want. It bootstraps, regression
> are running.. but based on the minimal code impact, I wouldn't expect
> incorrect failures.
> 
> Performance impact on building GCC is barely half a percent in VRP, and
> 0.05% overall compile time.  pretty minimal.
> 
> Im still working with it to tweak it, I just wanted you to be able to see if
> it helps.  I presume we dont want to add a new --param this late in the
> game.   But it seems we can set a reasonable number and not run into much
> trouble.

There is no problem with adding --params, and those are always better than
magic numbers.

Btw, I originally wondered why we don't re-compute zone1_12 because it's
in the imports of the successor (OK, the empty successors single successor
block) and expected those to trigger re-computes.

[Bug tree-optimization/109301] [13 Regression] ICE in format_helper, at real.h:233 since r13-1763

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

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

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

https://gcc.gnu.org/g:8dd57939c20b5e218404a838f514429f8e414dea

commit r13-6924-g8dd57939c20b5e218404a838f514429f8e414dea
Author: Jakub Jelinek 
Date:   Wed Mar 29 08:33:30 2023 +0200

tree-ssa-math-opts: Move PROP_gimple_opt_math from sincos pass to powcabs
[PR109301]

The following testcase ICEs since the sincos and vect pass order has
been swapped.  It is not valid to replace vector sqrt (sqrt (x)) with
pow (x, 0.25) because build_real on vector type is invalid (could be
handled by using build_uniform_cst and adjusting type passed to
build_real) but more importantly because nothing checks if we can
actually do vector pow.
While we have pow_optab, apparently no target defines it, so it doesn't
seem to be worth bothering with for now and the patch just punts on
non-scalar sqrts.
I think the other simplifications next to it are fine, as they mostly
use CBRT which doesn't even have internal function (so is a builtin
only and therefore always scalar), or have already pow in the IL (which
doesn't have optab and shouldn't be thus vector either).
It is true that with  we do vectorize some calls to
pow or cbrt (but don't handle others strangely), but those aren't using
internal functions but simd clones and so match.pd doesn't know anything
about those (at least for now).

The following patch fixes it by mostly restoring the state before
r13-1763 where canonicalize_math_p () was true only until the end of the
pass which transformed pow or pow-like calls before vectorization (formerly
sincos pass, now it is powcabs pass).
powcabs is a pass in the spot sincos was happening before, so the
only change was defer the sin+cos simplification into cexpi to a later
new pass (except for the name moving with it) and none of the
canonicalize_math_p () guarded simplification in match.pd seem to rely
on those sin+cos -> cexpi simplifications and canonicalize_math_p is
the only user of this property.

2023-03-29  Jakub Jelinek  
Richard Biener  

PR tree-optimization/109301
* tree-ssa-math-opts.cc (pass_data_cse_sincos): Change
properties_provided from PROP_gimple_opt_math to 0.
(pass_data_expand_powcabs): Change properties_provided from 0 to
PROP_gimple_opt_math.

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

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

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

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

commit r13-6923-gc9954996cd647daf0ba03e34dd279b97982f671f
Author: Richard Biener 
Date:   Tue Mar 28 15:20:22 2023 +0200

tree-optimization/109154 - improve if-conversion for vectorization

With multi-argument PHIs and now doing VN on the if-converted blocks
the optimization of CSEing condition and negated condition doesn't
work well anymore.  The following restores this a little bit for
the case of a single inverted condition into a COND_EXPR where
we can instead swap the COND_EXPR arms.  The same optimization
is already done for the case of two-argument PHIs.

This avoids one comparison/mask for the testcase at hand.

PR tree-optimization/109154
* tree-if-conv.cc (gen_phi_arg_condition): Handle single
inverted condition specially by inverting at the caller.
(gen_phi_arg_condition): Swap COND_EXPR arms if requested.

[Bug tree-optimization/109327] New: ICE on valid code at -O1 and above with "-fno-tree-ccp": Segmentation fault

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 109327
   Summary: ICE on valid code at -O1 and above with
"-fno-tree-ccp": Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a very recent regression. 

[554] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230329 (experimental) [master r13-6922-g91293ffb6af] (GCC)
[555] %
[555] % gcctk -O1 -fno-tree-ccp small.c
during GIMPLE pass: forwprop
small.c: In function ‘main’:
small.c:11:1: internal compiler error: Segmentation fault
   11 | }
  | ^
0xeeb24f crash_signal
../../gcc-trunk/gcc/toplev.cc:314
0xbab1a7 phi_nodes_ptr(basic_block_def*)
../../gcc-trunk/gcc/gimple.h:4684
0xbab1a7 gsi_start_phis(basic_block_def*)
../../gcc-trunk/gcc/gimple-iterator.cc:935
0xbab1a7 gsi_for_stmt(gimple*)
../../gcc-trunk/gcc/gimple-iterator.cc:620
0x10314f3 execute
../../gcc-trunk/gcc/tree-ssa-forwprop.cc:4070
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.
[556] %
[556] % cat small.c
int a;
void b(int c) {}
int main() {
  int d = 0, *e = &a;
  if (d) {
int *f = e;
while (a)
  b(e != f);
  }
  return 0;
}

[Bug middle-end/109326] Bad assembler code generation for valid C on 886-64

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Steve Thompson from comment #3)
> However I don't understand why olock_reset_op() is so large.  It's
> a trivial initializer for a descriptor with an array of olock_op_element
> structures appended.  There's no way it should look like what I quoted.  I'd
> be happy if I am experiencing a fever-dream over nothing due to ignorance,
> but I am not convinced that that is the case.  If I am wrong I will be very
> disappointed.

GCC unrolled the loop via vectorizing it.

[Bug middle-end/109326] Bad assembler code generation for valid C on 886-64

[susurrus.of.qualia at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Steve Thompson  ---
(In reply to Andrew Pinski from comment #1)
> init_olock_op_element_struct asm output looks fine to me:
> 
> movzwl  .LC0(%rip), %eax
> movq$0, (%rdi)
> movq$0, 8(%rdi)
> movl$0, 16(%rdi)
> movw%ax, 20(%rdi)
> 
> LC0 is:
> .LC0:
> .byte   6
> .byte   10
> 
> olock_fsm_event is fine too as it is just duplicating those basic blocks
> (the calls).
> 
> init_olock_op_struct looks fine really:
> movq%fs:0, %rax
> pxor%xmm0, %xmm0
> movups  %xmm0, (%rdi)
> addq$olock_tparams@tpoff, %rax
> 
> In Intel asm syntax:
> 
> mov rax, QWORD PTR fs:0
> pxorxmm0, xmm0
> movups  XMMWORD PTR [rdi], xmm0
> add rax, OFFSET FLAT:olock_tparams@tpoff
> 
> it is basically moving the TLS pointer to rax and then adding the offset for
> the variable.
> 
> I don't understand what exactly you are complaining about realy.

OK, I wasn't sure about the TLS accesses; adding -r to objdump helped clear
that up.  However I don't understand why olock_reset_op() is so large.  It's a
trivial initializer for a descriptor with an array of olock_op_element
structures appended.  There's no way it should look like what I quoted.  I'd be
happy if I am experiencing a fever-dream over nothing due to ignorance, but I
am not convinced that that is the case.  If I am wrong I will be very
disappointed.

[Bug c++/109321] [13 Regression] ICE in iterative_hash_template_arg, at cp/pt.cc:1727

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

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/109320] [13 Regression] ICE in coerce_template_parameter_pack, at cp/pt.cc:8795

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

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/109321] [13 Regression] ICE in iterative_hash_template_arg, at cp/pt.cc:1727

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

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

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

https://gcc.gnu.org/g:91293ffb6af18705ab7857dc47656bdd74a9ce31

commit r13-6922-g91293ffb6af18705ab7857dc47656bdd74a9ce31
Author: Jason Merrill 
Date:   Tue Mar 28 17:42:23 2023 -0400

c++: alias ctad refinements [PR109321]

The two hunks fix missing handling demonstrated by the two testcases:
first,
if we omit one alias template parm but include another, we need to rewrite
the deduced template args to reflect the new position of the included parm.
Second, if we can't deduce any template args for a parameter pack, it is
deduced to an empty pack.

PR c++/109321
PR c++/109320

gcc/cp/ChangeLog:

* pt.cc (alias_ctad_tweaks): Rewrite deduced args.
(type_targs_deducible_from): Handle null pack deduction.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias16.C: New test.
* g++.dg/cpp2a/class-deduction-alias17.C: New test.

[Bug c++/109320] [13 Regression] ICE in coerce_template_parameter_pack, at cp/pt.cc:8795

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

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

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

https://gcc.gnu.org/g:91293ffb6af18705ab7857dc47656bdd74a9ce31

commit r13-6922-g91293ffb6af18705ab7857dc47656bdd74a9ce31
Author: Jason Merrill 
Date:   Tue Mar 28 17:42:23 2023 -0400

c++: alias ctad refinements [PR109321]

The two hunks fix missing handling demonstrated by the two testcases:
first,
if we omit one alias template parm but include another, we need to rewrite
the deduced template args to reflect the new position of the included parm.
Second, if we can't deduce any template args for a parameter pack, it is
deduced to an empty pack.

PR c++/109321
PR c++/109320

gcc/cp/ChangeLog:

* pt.cc (alias_ctad_tweaks): Rewrite deduced args.
(type_targs_deducible_from): Handle null pack deduction.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-alias16.C: New test.
* g++.dg/cpp2a/class-deduction-alias17.C: New test.

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #15 from Sam James  ---
*** Bug 109325 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/109325] ICE in range_def_chain::in_chain_ when building opencv

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #3 from Sam James  ---
(In reply to Andrew Pinski from comment #2)
> Most likely a dup of bug 109274.

Yeah, patch works and indeed looks identical. Thanks.

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

[Bug middle-end/109326] Bad assembler code generation for valid C on 886-64

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

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

--- Comment #2 from Andrew Pinski  ---
Note if you are disassemblying the object file with objdump -d, you might want
to add the -r option to enable dumping of the relocations that are produced
too. In the init_olock_op_struct case you miss the relocation of the object
file because of that.

[Bug middle-end/109326] Bad assembler code generation for valid C on 886-64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-03-29

--- Comment #1 from Andrew Pinski  ---
init_olock_op_element_struct asm output looks fine to me:

movzwl  .LC0(%rip), %eax
movq$0, (%rdi)
movq$0, 8(%rdi)
movl$0, 16(%rdi)
movw%ax, 20(%rdi)

LC0 is:
.LC0:
.byte   6
.byte   10

olock_fsm_event is fine too as it is just duplicating those basic blocks (the
calls).

init_olock_op_struct looks fine really:
movq%fs:0, %rax
pxor%xmm0, %xmm0
movups  %xmm0, (%rdi)
addq$olock_tparams@tpoff, %rax

In Intel asm syntax:

mov rax, QWORD PTR fs:0
pxorxmm0, xmm0
movups  XMMWORD PTR [rdi], xmm0
add rax, OFFSET FLAT:olock_tparams@tpoff

it is basically moving the TLS pointer to rax and then adding the offset for
the variable.

I don't understand what exactly you are complaining about really.

[Bug c/109326] New: Bad assembler code generation for valid C on 886-64

[susurrus.of.qualia at gmail dot com via Gcc-bugs]

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

Bug ID: 109326
   Summary: Bad assembler code generation for valid C on 886-64
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: susurrus.of.qualia at gmail dot com
  Target Milestone: ---

Created attachment 54782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54782&action=edit
compiler output

I have a bit of code here that is compiling without warnings and producing what
appear to be gross errors in the assembler output for some functions. 
Pertinent info:

$ gcc10.4 -v
Using built-in specs.
COLLECT_GCC=gcc10.4
COLLECT_LTO_WRAPPER=/home/stevet/libexec/gcc/x86_64-pc-linux-gnu/10.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.4.0/configure --prefix=/home/stevet
--program-suffix=10.4 --enable-shared --enable-linker-build-id
--without-included-gettext --enable-threads=posix --enable-nls
--enable-bootstrap --enable-clocale=gnu --with-tune=generic
--enable-languages=c --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.4.0 (GCC) 

uname -a
Linux mx 5.18.0-4mx-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1~mx21+1
(2022-08-22) x86_64 GNU/Linux



Unit compilation command:
gcc10.4 -c  -D_POSIX_C_SOURCE=200112L -DOLOCK_192 -DARCH_64 -DLINUX -I./ -I./
-pthread -m64 -std=c99 -Wall -Wextra -Wno-implicit-fallthrough -Werror
-falign-functions=16 -falign-loops=1 -falign-jumps=1
-fno-inline-small-functions -fdiagnostics-color=never -fverbose-asm 
--save-temps  -O3 -ggdb  -o olock.o olock.c


it should be noted that the bad code generation seems lessened, but not
eliminated at -O2.  Similarly, the problems were slightly different between
gcc-10.2.1 and the most recent 10.x release.


First thing to note is the assembler generated for the relatively simple
olock_reset_op() function.  Near as I can tell, the asm bears exactly zero
relation to the C code of that function.  The mystery constant $0xa06 seems
notable and also appears in init_olock_op_element_struct().

init_olock_op_struct() begins with an access to %fs:0x0, which is then
clobbered by an add $0x0, %rax shortly thereafter.  Perhaps this is normal.

olock_fsm_event() doesn't look good either.  There are three callq *%reg
instances where there should be at most one.

I'm not sure about olock_op_allocator().  olock_opcode_acqs() looks suspicious,
but I'm not that well versed in x86 so I could be wrong.

If I knew that the dynamic linker would fixup the %fs:0x0 references to
something normal I'd have more confidence about the rest of the code, but it
looks like about half the functions aren't correct at this point.

I've not yet tested any of this code yet; it is still subject to revision while
I clean it up.  With this type of algorithm it is unfortunately necessary to
have mostly correct code before even thinking about testing it.  This version
is close to that point.

As I note I can only attach one file, I'll include the assembler output for the
troublesome olock_reset_op() function for reference.

216 0290 :
217  290:   0f b7 57 10 movzwl 0x10(%rdi),%edx
218  294:   66 85 d2test   %dx,%dx
219  297:   0f 84 f4 04 00 00   je 791

220  29d:   8d 42 fflea-0x1(%rdx),%eax
221  2a0:   66 83 f8 0e cmp$0xe,%ax
222  2a4:   0f 86 e8 04 00 00   jbe792

223  2aa:   89 d1   mov%edx,%ecx
224  2ac:   48 8d 47 2c lea0x2c(%rdi),%rax
225  2b0:   66 c1 e9 04 shr$0x4,%cx
226  2b4:   83 e9 01sub$0x1,%ecx
227  2b7:   0f b7 c9movzwl %cx,%ecx
228  2ba:   48 8d 0c 49 lea(%rcx,%rcx,2),%rcx
229  2be:   48 c1 e1 07 shl$0x7,%rcx
230  2c2:   48 8d 8c 0f ac 01 00lea0x1ac(%rdi,%rcx,1),%rcx
231  2c9:   00 
232  2ca:   41 b9 06 0a 00 00   mov$0xa06,%r9d
233  2d0:   c7 40 f4 00 00 00 00movl   $0x0,-0xc(%rax)
234  2d7:   41 ba 06 0a 00 00   mov$0xa06,%r10d
235  2dd:   41 bb 06 0a 00 00   mov$0xa06,%r11d
236  2e3:   c7 40 0c 00 00 00 00movl   $0x0,0xc(%rax)
237  2ea:   be 06 0a 00 00  mov$0xa06,%esi
238  2ef:   41 b8 06 0a 00 00   mov$0xa06,%r8d
239  2f5:   48 05 80 01 00 00   add$0x180,%rax
240  2fb:   c7 80 a4 fe ff ff 00movl   $0x0,-0x15c(%rax)
241  302:   00 00 00 
242  305:   c7 80 bc fe ff ff 00movl   $0x0,-0x144(%rax)
243  30c:   00 00 00 
244  3

[Bug target/109256] Error: failed to link 'linked_maps2.bpf.o': Cannot allocate memory (12)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |MOVED

--- Comment #4 from Andrew Pinski  ---
Not a GCC bug in the end, so changed to move.

[Bug tree-optimization/109325] ICE in range_def_chain::in_chain_ when building opencv

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Most likely a dup of bug 109274.

[Bug tree-optimization/109325] ICE in range_def_chain::in_chain_ when building opencv

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
Created attachment 54781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54781&action=edit
warpers.cpp.ii.xz

Originally reported by Adrien Dessemond  at
https://bugs.gentoo.org/903505.

```
x86_64-pc-linux-gnu-g++ -m32 -mfpmath=sse -DCVAPI_EXPORTS -D_USE_MATH_DEFINES
-D__OPENCV_BUILD=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-I/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/stitching/include
-I/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0_build-abi_x86_32.x86/modules/stitching
-I/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/core/include
-I/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/flann/include
-I/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/imgproc/include
-I/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/features2d/include
-I/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/calib3d/include
-isystem
/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0_build-abi_x86_32.x86
-isystem /usr/include/eigen3  -O2 -pipe -march=native
-fdiagnostics-color=always -frecord-gcc-switches -Wreturn-type -ggdb3  
-fsigned-char -W -Wall -Wreturn-type -Wnon-virtual-dtor -Waddress
-Wsequence-point -Wformat -Wformat-security -Wmissing-declarations -Wundef
-Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized
-Wsuggest-override -Wno-delete-non-virtual-dtor -Wno-comment
-Wimplicit-fallthrough=3 -Wno-strict-overflow -fdiagnostics-show-option
-pthread -fomit-frame-pointer -ffunction-sections -fdata-sections  -msse -msse2
-msse3 -mssse3 -msse4.1 -mpopcnt -msse4.2 -mf16c -mfma -mavx -mfpmath=sse
-fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -std=c++11 -fPIC
-fdiagnostics-color=always -c warpers.cpp.ii
during GIMPLE pass: vrp
In file included from
/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/stitching/include/opencv2/stitching/detail/warpers.hpp:704,
 from
/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/stitching/include/opencv2/stitching/warpers.hpp:46,
 from
/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/stitching/include/opencv2/stitching.hpp:48,
 from
/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/stitching/src/precomp.hpp:59,
 from
/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/stitching/src/warpers.cpp:43:
/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/stitching/include/opencv2/stitching/detail/warpers_inl.hpp:
In member function ‘void
cv::detail::RotationWarperBase::detectResultRoiByBorder(cv::Size,
cv::Point&, cv::Point&) [with P = cv::detail::SphericalProjector]’:
/var/tmp/portage/media-libs/opencv-4.7.0/work/opencv-4.7.0/modules/stitching/include/opencv2/stitching/detail/warpers_inl.hpp:185:6:
internal compiler error: Segmentation fault
  185 | void RotationWarperBase::detectResultRoiByBorder(Size src_size,
Point &dst_tl, Point &dst_br)
  |  ^
0xd80b07 crash_signal
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/gcc-13-20230326/gcc/toplev.cc:314
0x1688195 range_def_chain::in_chain_p(tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/gcc-13-20230326/gcc/gimple-range-gori.cc:126
0x1683fb0 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/gcc-13-20230326/gcc/gimple-range-gori.cc:667
0x1688ae9 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/gcc-13-20230326/gcc/gimple-range-gori.cc:1174
0x1683599 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/gcc-13-20230326/gcc/gimple-range-gori.cc:726
0x16bdcb8 gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/gcc-13-20230326/gcc/gimple-range-gori.cc:1254
0x18050a9 gori_compute::compute_operand1_and_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/gcc-13-20230326/gcc/gimple-range-gori.cc:1274
0x168409f gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/gcc-13-20230326/gcc/gimple-range-gori.cc:723
0x1682e5a gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230326/

[Bug tree-optimization/109325] New: ICE in range_def_chain::in_chain_ when building opencv

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 109325
   Summary: ICE in range_def_chain::in_chain_ when building opencv
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x

[Bug target/109324] New: Genrecog reports "source missing a mode?" for H8

[jdx at o2 dot pl via Gcc-bugs]

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

Bug ID: 109324
   Summary: Genrecog reports "source missing a mode?" for H8
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdx at o2 dot pl
  Target Milestone: ---
Target: h8300-elf

Unfortunately, I barely understand .md files, but I think genrecog is a bit
overzealous. It would be nice if these warnings could be muted somehow.


build/genrecog.exe ../../../gcc/gcc/common.md
../../../gcc/gcc/config/h8300/h8300.md \
  insn-conditions.md > tmp-recog.cc
../../../gcc/gcc/config/h8300/testcompare.md:29:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:29:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:55:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:64:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:73:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:82:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:82:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:82:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:98:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:106:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:114:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:122:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:130:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:151:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:290:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:290:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:327:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:327:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:360:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:360:1: warning: operand 0 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:397:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/h8300/jumpcall.md:397:1: warning: operand 1 missing
mode?
../../../gcc/gcc/config/h8300/testcompare.md:175:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:175:1: warning: source missing a
mode?
../../../gcc/gcc/config/h8300/testcompare.md:175:1: warning: source missing a
mode?
Statistics for recog:
  Number of decisions:   3643
  longest path:76 (code:597)
  longest backtrack:9 (code:428)
Statistics for split_insns:
  Number of decisions:   1409
  longest path:58 (code:242)
  longest backtrack:4 (code:199)
Statistics for peephole2_insns:
  Number of decisions:119
  longest path:69 (code:  8)
  longest backtrack:3 (code: 10)
Shared 3609 out of 7559 states by creating 1052 new states, saving 2557

[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move

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

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

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

https://gcc.gnu.org/g:629ed996f32cb03dd712789eede1f7f2036e497b

commit r12-9351-g629ed996f32cb03dd712789eede1f7f2036e497b
Author: Jonathan Wakely 
Date:   Thu Dec 15 09:52:48 2022 +

libstdc++: Fix self-move for std::weak_ptr [PR108118]

I think an alternative fix would be something like:

  _M_ptr = std::exchange(rhs._M_ptr, nullptr);
  _M_refcount = std::move(rhs._M_refcount);

The standard's move-and-swap implementation generates smaller code at
all levels except -O0 and -Og, so it seems simplest to just do what the
standard says.

libstdc++-v3/ChangeLog:

PR libstdc++/108118
* include/bits/shared_ptr_base.h (weak_ptr::operator=):
Implement as move-and-swap exactly as specified in the standard.
* testsuite/20_util/weak_ptr/cons/self_move.cc: New test.

(cherry picked from commit 92eb0adc14a5f84acce7e5bc780b81b1544b24aa)

[Bug libstdc++/108554] [12 Regression] Warning "null pointer dereferece" raised when extracting a unique_ptr from a map and any "-O" flag

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 12.3

[Bug libstdc++/108554] [12 Regression] Warning "null pointer dereferece" raised when extracting a unique_ptr from a map and any "-O" flag

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

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

commit r12-9345-g2fdfa3768b25c85df39eaf9b850e130e42a4dd6f
Author: Jonathan Wakely 
Date:   Thu Jan 26 10:55:28 2023 +

libstdc++: Add returns_nonnull to non-inline std::map detail [PR108554]

std::map uses a non-inline function to rebalance its tree and the
compiler can't see that it always returns a valid pointer (assuming
valid inputs, which is a precondition anyway). This can result in
-Wnull-derefernce warnings for valid code, because the compiler thinks
there is a path where the function returns null.

Adding the returns_nonnull attribute tells the compiler that is can't
happen. While we're doing that, we might as well also add a nonnull
attribute to the rebalancing functions too.

libstdc++-v3/ChangeLog:

PR libstdc++/108554
* include/bits/stl_tree.h (_Rb_tree_insert_and_rebalance): Add
nonnull attribute.
(_Rb_tree_rebalance_for_erase): Add nonnull and returns_nonnull
attributes.
* testsuite/23_containers/map/modifiers/108554.cc: New test.

(cherry picked from commit 3376467ce090aa0966d59ca3aea35db4f17a4b47)

[Bug libstdc++/109299] [12 Regression] wrong warning on std::wstring with -O2 -std=c++20 -D_FORTIFY_SOURCE=2

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

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

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

https://gcc.gnu.org/g:00ac6fa3f2a54fb9cc17b7b7f51eae3c6bf7a1bd

commit r12-9330-g00ac6fa3f2a54fb9cc17b7b7f51eae3c6bf7a1bd
Author: Jonathan Wakely 
Date:   Tue Mar 28 10:50:40 2023 +0100

libstdc++: Tell GCC what basic_string::_M_is_local() means [PR109299]

This avoids a bogus warning about overflowing a buffer, because GCC
can't tell that we don't copy into the buffer unless it fits. By adding
a __builtin_unreachable() hint we inform the compiler about the
invariant that the buffer is only used when it's big enough.

This can also improve codegen, by eliminating dead code that GCC
couldn't tell was unreachable.

libstdc++-v3/ChangeLog:

PR libstdc++/109299
* include/bits/basic_string.h (basic_string::_M_is_local()): Add
hint for compiler that local strings fit in the local buffer.

(cherry picked from commit bf78b43873b0b7e8f9a430df38749b8b61f9c9b8)

[Bug libstdc++/109299] [12 Regression] wrong warning on std::wstring with -O2 -std=c++20 -D_FORTIFY_SOURCE=2

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
Fixed for 12.3

[Bug other/108413] copyrights for gcc 2023

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

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

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

https://gcc.gnu.org/g:83487e1f0c380859ed2dab2892afa8651d267fb3

commit r12-9327-g83487e1f0c380859ed2dab2892afa8651d267fb3
Author: Jonathan Wakely 
Date:   Mon Jan 16 10:15:41 2023 +

libstdc++: Fix copyright notice to use usual form [PR108413]

libstdc++-v3/ChangeLog:

PR libstdc++/108413
* include/c_compatibility/stdatomic.h: Change copyright line to
be consistent with other headers contributed under DCO terms.
* include/std/expected: Add full stop to copyright line.

(cherry picked from commit fa16c7d899022d0e671407cd7188b66bb84fefe6)

[Bug c++/109320] [13 Regression] ICE in coerce_template_parameter_pack, at cp/pt.cc:8795

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

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/109320] [13 Regression] ICE in coerce_template_parameter_pack, at cp/pt.cc:8795

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable

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

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

--- Comment #11 from Jonathan Wakely  ---
Fixed on trunk now.

[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-6918-gec12639c82e944d37200a744156e183ea19add00
Author: Jonathan Wakely 
Date:   Tue Mar 28 21:07:21 2023 +0100

libstdc++: Do not use facets cached in ios for ATL128 build [PR103387]

For the powerpc64le build with two different long double
representations, we cannot use the ios_base::_M_num_put and
ios_base::_M_num_get pointers, because they might have been initialized
in a translation unit using the other long double type. With the changes
to add __try_use_facet to GCC 13 the cache isn't really needed now, we
can just access the right facet in the locale directly, without needing
RTTI checks.

libstdc++-v3/ChangeLog:

PR libstdc++/103387
* include/bits/istream.tcc (istream::_M_extract(ValueT&)): Use
std::use_facet instead of cached _M_num_get facet.
(istream::operator>>(short&)): Likewise.
(istream::operator>>(int&)): Likewise.
* include/bits/ostream.tcc (ostream::_M_insert(ValueT)): Use
std::use_facet instead of cached _M_num_put facet.

[Bug debug/109161] Bad CTF generated for stub in function scope

[nix at esperi dot org.uk via Gcc-bugs]

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

Nix  changed:

   What|Removed |Added

 CC||nix at esperi dot org.uk

--- Comment #2 from Nix  ---
It definitely shouldn't hang for invalid input, but that sort of proof against
invalid input isn't even implemented for the deduplicator yet, let alone every
other thing that recurses over the type graph. It's on the todo list... and
it's not specific to objdump at all: ctf_dump (objdump/readelf),
ctf_type_rvisit, ctf_type_compat, even foundational libctf stuff like
ctf_type_resolve would hang if, say, we had a CTF_K_CONST node pointing to
itself, even indirectly. This does mean that anything we use to detect cycles
must be *cheap*.

Now I was assuming I could only implement cycle-detection efficiently for the
deduplicator (which would usually suffice, since linking is the first thing
that is usually done to compiler-generated CTF) -- but it occurs to me now that
I could use a similar technique in ctf_type_rvisit, which will handle ctf_dump:
I can probably do the same for the other recursive type-traversing functions,
and handle all of them with the same cycle-detection code, and then CTF
manipulation on raw object files would be safe against cycles too. The
algorithm in question (one of Hellman's more obscure) cannot guarantee
immediate detection of cycles, but it will always detect them eventually, which
is good enough for this application. That's the price we pay for spotting
cycles in constant space with almost no time overhead for the common, acyclic
case.

[Bug tree-optimization/109318] csmith: -fipa-cp seems to cause trouble

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction

--- Comment #4 from David Binderman  ---
Seems to break sometime between 20210704, with git hash d07092a61d5a6907
and 20211003, with git hash d91056851c5c60f2.

[Bug c++/109323] No error when neither of return_value or return_void is defined

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
Can you attach the testcase on what exactly you think is wrong instead of just
links to other sources?

[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #13 from Martin Uecker  ---

This fix seem too radical. It now prevents this from working even when there is
an explicit attribute but there is also a VLA bound.  Also I think it would be
nice if it worked without the explicit attribute at least in the simple cases
where this should be now problem.

__attribute__ ((noinline, access (read_only, 2, 1)))
int foo(int n, int buf[n])
{
buf[n] = 1;
return __builtin_dynamic_object_size(buf, 0);
}

int main() {
int n = 10;
int buf[n];
return foo(n, buf);
}

[Bug c++/109323] New: No error when neither of return_value or return_void is defined

[enricomaria.dean6elis at gmail dot com via Gcc-bugs]

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

Bug ID: 109323
   Summary: No error when neither of return_value or return_void
is defined
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enricomaria.dean6elis at gmail dot com
  Target Milestone: ---

Repro:

1. take the example here ->
https://en.cppreference.com/w/cpp/language/coroutines
2. remove the 3 `if (cond) co_return;` from `fibonacci_sequence`
3. remove `return_void` from `promise_type`
4. compile

Alternatively: https://godbolt.org/z/v3xd3b7TE, where both GCC and Clang
erroneously accept the code, whereas MSVC correcly rejects it.
(http://eel.is/c++draft/dcl.fct.def.coroutine#6)

I'm aware of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95517, but that makes
no reference to the fact that not declaring any of the two functions is
erroneous.

[Bug fortran/109322] New: -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[emr-gnu at hev dot psu.edu via Gcc-bugs]

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

Bug ID: 109322
   Summary: -fc-prototypes does not correctly translate
INTEGER(KIND=C_SIZE_T), and other sizes
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emr-gnu at hev dot psu.edu
  Target Milestone: ---

When generating C-prototypes, the gfortran compiler translates stdint.h
typedefs to their destination types at invocation time, rather than leaving
that to the C/C++ compiler in the translated code.  Example: C_SIZE_T is
translated to "long" rather than "size_t" in the generated prototype
structures. This holds true for function parameters and return values as well.

foo.f90:

MODULE FOO
 USE, INTRINSIC :: ISO_C_BINDING
 IMPLICIT NONE
 PUBLIC :: BAR
 TYPE, BIND(C) :: BAR
  INTEGER(KIND=C_SIZE_T) :: A = -1
  INTEGER(KIND=C_INT32_T) :: B = -1
  INTEGER(KIND=C_INT16_T) :: C = -1
  INTEGER(KIND=C_INT8_T) :: D = -1
 END TYPE
END MODULE

The above produces the following output:

> gfortran -fc-prototypes -fsyntax-only foo.f90

 typedef struct bar {
  long a;
  int b;
  short c;
  signed char d;
 } bar;


--

Expected output:

 typedef struct bar {
  size_t a;
  int32_t b;
  int16_t c;
  int8_t d;
 } bar;

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #37 from Andrew Macleod  ---
Created attachment 54780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54780&action=edit
in progress patch

Well call me a liar. 

It took me a while to understand why, but if we leave it to single dependencies
only, the impact is relatively linear.  I wrote a bunch of code, then deleted
most of it as I found the engine was bypassing my code and doing it on its own.

The attached patch is the core.  It actually works to a depth of 5
recomputations. my sample of:
  int a = left * 2;
  int b = a - 4;
  int c = b % 7;
  func (a,b ,c);
  int d = c * 4;
  if (left == 20)
{
  func (b,c,d);

produces 
   :
  func (36, 1, 4);

IT also changes your program somewhat.

Try applying it and see if it does what you want. It bootstraps, regression are
running.. but based on the minimal code impact, I wouldn't expect incorrect
failures.

Performance impact on building GCC is barely half a percent in VRP, and 0.05%
overall compile time.  pretty minimal.

Im still working with it to tweak it, I just wanted you to be able to see if it
helps.  I presume we dont want to add a new --param this late in the game.  
But it seems we can set a reasonable number and not run into much trouble.

[Bug c++/109321] [13 Regression] ICE in iterative_hash_template_arg, at cp/pt.cc:1727

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/109288] std/time/time_zone/get_info_local.cc failure with tzdata2023a

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/109299] [12/13 Regression] wrong warning on std::wstring with -O2 -std=c++20 -D_FORTIFY_SOURCE=2

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-6915-gbf78b43873b0b7e8f9a430df38749b8b61f9c9b8
Author: Jonathan Wakely 
Date:   Tue Mar 28 10:50:40 2023 +0100

libstdc++: Tell GCC what basic_string::_M_is_local() means [PR109299]

This avoids a bogus warning about overflowing a buffer, because GCC
can't tell that we don't copy into the buffer unless it fits. By adding
a __builtin_unreachable() hint we inform the compiler about the
invariant that the buffer is only used when it's big enough.

This can also improve codegen, by eliminating dead code that GCC
couldn't tell was unreachable.

libstdc++-v3/ChangeLog:

PR libstdc++/109299
* include/bits/basic_string.h (basic_string::_M_is_local()): Add
hint for compiler that local strings fit in the local buffer.

[Bug libstdc++/109288] std/time/time_zone/get_info_local.cc failure with tzdata2023a

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-6914-gcf19ef9eca82b01dd0a3a0a8e4c8bcec236eb2d9
Author: Jonathan Wakely 
Date:   Mon Mar 27 13:51:25 2023 +0100

libstdc++: Update tzdata to 2023a [PR109288]

Import the new 2023a tzdata.zi file and update the expiry dates of the
hardcoded lists of leapseconds to 2023-12-28.

With the new data, Africa/Egypt no longer has a single unbroken sys_info
from 2014-09-25 to chrono::year::max(). Only check up to 2014-09-01 so
that the test isn't sensitive to differences between 2022g and 2023a
data.

libstdc++-v3/ChangeLog:

PR libstdc++/109288
* include/std/chrono (__detail::__get_leap_second_info): Update
expiry date of hardcoded leapseconds list.
* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds()):
Likewise.
* src/c++20/tzdata.zi: Import new file from 2023a release.
* testsuite/std/time/time_zone/get_info_local.cc: Only check
transitions for Egypt up to 2014.

[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"

[alisdairm at me dot com via Gcc-bugs]

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

Alisdair Meredith  changed:

   What|Removed |Added

 CC||alisdairm at me dot com

--- Comment #9 from Alisdair Meredith  ---
Trying to make sense of the new C++23 deprecation in [depr.template.template],
I came up with the following, based on Example 3 in [temp.names]p6:

template  struct A {
   void f(int);
   template  void f(U);
};

template 
struct B {
   template  struct C { };
};

// deprecated: T::C is assumed to name a class template:
template  class TT = T::template C> 
struct D { };
D > db;

// recommended: T::C is assumed to name a class template:
template  class TT = T::C> 
struct E { };
E > db;


Currently, the recommended form does not compile, which I presume is a change
to become valid with P1787.  Likewise, the deprecated form does not warn — but
that is not surprising if the preferred form is not compiling yet!

Hope the example is useful.

[Bug tree-optimization/109318] csmith: -fipa-cp seems to cause trouble

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Seems broken with gcc-12-20211003.

Git hashes seem to be g:c3d3bb0f03dbd025 and g:d91056851c5c60f2

[Bug c++/109321] [13 Regression] ICE in iterative_hash_template_arg, at cp/pt.cc:1727

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-28
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r13-6555-g9e6170098d5e77:

commit 9e6170098d5e7756e85e880f8f4cb18e885a64fd
Author: Jason Merrill 
Date:   Wed Feb 8 22:06:22 2023 -0800

c++: fix alias CTAD [PR105841]

[Bug c++/109320] [13 Regression] ICE in coerce_template_parameter_pack, at cp/pt.cc:8795

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-28
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Started with r13-6553-g148cbb153dafd6:

commit 148cbb153dafd6b21d83c00787acd430aec68a3d
Author: Jason Merrill 
Date:   Thu Feb 9 12:51:51 2023 -0800

c++: add __is_deducible trait [PR105841]

[Bug c++/109319] [13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-28
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r13-4046-g6492cec069bccf:

commit 6492cec069bccf817ac5e984fb3eca407056a566
Author: Jakub Jelinek 
Date:   Tue Nov 15 08:00:21 2022 +0100

c++: Implement C++23 P2589R1 - - static operator[]

[Bug c++/109321] New: [13 Regression] ICE in iterative_hash_template_arg, at cp/pt.cc:1727

[gscfq--- via Gcc-bugs]

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

Bug ID: 109321
   Summary: [13 Regression] ICE in iterative_hash_template_arg, at
cp/pt.cc:1727
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20230226 and 20230312, with -std=c++20 or -std=c++23 :


$ cat z1.cc
struct A;
template struct B;
template using D = B;
void f () { D() = 0; }


$ g++-13-20230326 -c z1.cc -std=c++23
z1.cc: In substitution of 'template B()-> B requires 
__is_deducible (D, B) [with C = A]':
z1.cc:4:15:   required from here
z1.cc:4:15: internal compiler error: Segmentation fault
4 | void f () { D() = 0; }
  |   ^
0xe24a1f crash_signal
../../gcc/toplev.cc:314
0x88209c iterative_hash_template_arg(tree_node*, unsigned int)
../../gcc/cp/pt.cc:1727
0x762f71 sat_hasher::hash(sat_entry*)
../../gcc/cp/constraint.cc:2572
0x762f71 hash_table::find_slot(sat_entry*
const&, insert_option)
../../gcc/hash-table.h:435
0x762f71 satisfaction_cache::satisfaction_cache(tree_node*, tree_node*,
sat_info)
../../gcc/cp/constraint.cc:2668
0x765a71 satisfy_atom
../../gcc/cp/constraint.cc:2998
0x765a71 satisfy_constraint_r
../../gcc/cp/constraint.cc:3106
0x7665f3 satisfy_normalized_constraints
../../gcc/cp/constraint.cc:3131
0x7641da satisfy_declaration_constraints
../../gcc/cp/constraint.cc:3352
0x7641da constraint_satisfaction_value
../../gcc/cp/constraint.cc:3373
0x7a constraints_satisfied_p(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:3410
0x8afef5 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../gcc/cp/pt.cc:22534
0x7251cb add_template_candidate_real
../../gcc/cp/call.cc:3594
0x725e83 add_template_candidate
../../gcc/cp/call.cc:3688
0x725e83 add_candidates
../../gcc/cp/call.cc:6596
0x72d101 add_candidates
../../gcc/cp/call.cc:4911
0x72d101 perform_overload_resolution
../../gcc/cp/call.cc:4911
0x72d4e9 perform_dguide_overload_resolution(tree_node*, vec const*, int)
../../gcc/cp/call.cc:4976
0x88e581 do_class_deduction
../../gcc/cp/pt.cc:30590
0x88e581 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.cc:30715

[Bug c++/109320] New: [13 Regression] ICE in coerce_template_parameter_pack, at cp/pt.cc:8795

[gscfq--- via Gcc-bugs]

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

Bug ID: 109320
   Summary: [13 Regression] ICE in coerce_template_parameter_pack,
at cp/pt.cc:8795
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20230226 and 20230312, with -std=c++20 or -std=c++23 :


$ cat z1.cc
template
struct S {};
template
using u = S;
struct X {};
X a = u {};


$ g++-13-20230326 -c z1.cc -std=c++23
z1.cc:6:10: internal compiler error: Segmentation fault
6 | X a = u {};
  |  ^
0xe24a1f crash_signal
../../gcc/toplev.cc:314
0x8a3de1 coerce_template_parameter_pack
../../gcc/cp/pt.cc:8795
0x8a3de1 coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
../../gcc/cp/pt.cc:9067
0x8b10fd type_targs_deducible_from(tree_node*, tree_node*)
../../gcc/cp/pt.cc:30278
0x8b12b8 alias_ctad_tweaks
../../gcc/cp/pt.cc:30224
0x88d434 deduction_guides_for
../../gcc/cp/pt.cc:30375
0x88dae5 do_class_deduction
../../gcc/cp/pt.cc:30522
0x88dae5 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.cc:30715
0x8c2f20 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
../../gcc/cp/semantics.cc:3213
0x845d1c cp_parser_functional_cast
../../gcc/cp/parser.cc:32610
0x856d2b cp_parser_postfix_expression
../../gcc/cp/parser.cc:7703
0x86a60f cp_parser_unary_expression
../../gcc/cp/parser.cc:9141
0x83e79f cp_parser_cast_expression
../../gcc/cp/parser.cc:10045
0x83f07f cp_parser_binary_expression
../../gcc/cp/parser.cc:10147
0x83fa74 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10490
0x841bb7 cp_parser_constant_expression
../../gcc/cp/parser.cc:10785
0x842c31 cp_parser_initializer_clause
../../gcc/cp/parser.cc:25489
0x844aab cp_parser_initializer
../../gcc/cp/parser.cc:25429
0x874d2c cp_parser_init_declarator
../../gcc/cp/parser.cc:22994
0x84fd4f cp_parser_simple_declaration
../../gcc/cp/parser.cc:15402

[Bug c++/109319] New: [13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793

[gscfq--- via Gcc-bugs]

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

Bug ID: 109319
   Summary: [13 Regression] ICE in build_min_non_dep_op_overload,
at cp/tree.cc:3793
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20221106 and 20221120, with -std=c++23 :
(follow-up of pr108437)


$ cat z1.cc
struct S
{
  static int operator[] (int x) { int a[2]; return a[x]; }
};
template int f ()
{
  S s;
  ++s[0,1];
  return 0;
}


$ cat z2.cc
struct S
{
  static int operator[] (int x) { int a[2]; return a[x]; }
};
template int f ()
{
  S s;
  ++s[1,0];
  return 0;
}


$ g++-13-20230326 -c z1.cc -std=c++23
z1.cc: In function 'int f()':
z1.cc:8:6: warning: top-level comma expression in array subscript changed
meaning in C++23 [-Wcomma-subscript]
8 |   ++s[0,1];
  |  ^
z1.cc:8:10: internal compiler error: in build_min_non_dep_op_overload, at
cp/tree.cc:3793
8 |   ++s[0,1];
  |  ^
0x8de226 build_min_non_dep_op_overload(tree_node*, tree_node*, tree_node*,
vec*)
../../gcc/cp/tree.cc:3793
0x7ad99d grok_array_decl(unsigned int, tree_node*, tree_node*, vec**, int)
../../gcc/cp/decl2.cc:569
0x843ca4 cp_parser_postfix_open_square_expression
../../gcc/cp/parser.cc:8223
0x856671 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7814
0x86a60f cp_parser_unary_expression
../../gcc/cp/parser.cc:9141
0x83e79f cp_parser_cast_expression
../../gcc/cp/parser.cc:10045
0x86a707 cp_parser_unary_expression
../../gcc/cp/parser.cc:9055
0x83e79f cp_parser_cast_expression
../../gcc/cp/parser.cc:10045
0x83f07f cp_parser_binary_expression
../../gcc/cp/parser.cc:10147
0x83fa74 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10490
0x8411b2 cp_parser_expression
../../gcc/cp/parser.cc:10660
0x844837 cp_parser_expression_statement
../../gcc/cp/parser.cc:12816
0x851cbc cp_parser_statement
../../gcc/cp/parser.cc:12596
0x852d54 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12967
0x852e0f cp_parser_compound_statement
../../gcc/cp/parser.cc:12919
0x873958 cp_parser_function_body
../../gcc/cp/parser.cc:25335
0x873958 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25386
0x873e16 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:32012
0x874f90 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31929
0x874f90 cp_parser_init_declarator
../../gcc/cp/parser.cc:22789

[Bug c/107002] [13 Regression] ICE in column_range, at diagnostic-show-locus.cc:2236 since r13-2386-gbedfca647a9e9c1a

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed by the above patch

[Bug tree-optimization/109318] csmith: -fipa-cp seems to cause trouble

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Program seems fine with gcc-11-20210404, but goes wrong with gcc-12-20220403.

$ ~/gcc/results.20210404/bin/gcc -w -O1 -fipa-cp bug903.c
$ ./a.out
checksum = FC4F321
$ ~/gcc/results.20220403/bin/gcc -w -O1 -fipa-cp bug903.c
$ ./a.out
Segmentation fault (core dumped)
$ 

Git hashes are g:c3d3bb0f03dbd025 and
g:0364465e3708249ece810ca5d65164552595538c

[Bug c/107002] [13 Regression] ICE in column_range, at diagnostic-show-locus.cc:2236 since r13-2386-gbedfca647a9e9c1a

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:22c3a6c3c118283dfef1b9928dd21110098679b7

commit r13-6912-g22c3a6c3c118283dfef1b9928dd21110098679b7
Author: David Malcolm 
Date:   Tue Mar 28 14:34:49 2023 -0400

Don't emit -Wxor-used-as-pow on macro expansions [PR107002]

PR c/107002 reports an assertion failure from deep inside the
diagnostic_shows_locus when attempting to print fix-it hints relating
to -Wxor-used-as-pow.  The case involves macro expansions with
-ftrack-macro-expansion=0.

It doesn't seem to make much sense to emit this warning for macro
expansions, so this patch updates the warning not to (which seems
to also be clang's behavior).  The patch also adds some bulletproofing
to diagnostic-show-locus.cc to be more robust against such invalid
fix-it hints.

Doing so fixes the ICE.

gcc/c-family/ChangeLog:
PR c/107002
* c-common.h (check_for_xor_used_as_pow): Add "rhs_loc" param.
* c-warn.cc (check_for_xor_used_as_pow): Add "rhs_loc" param.
Reject cases where involving macro expansions.

gcc/c/ChangeLog:
PR c/107002
* c-typeck.cc (parser_build_binary_op): Update for new param of
check_for_xor_used_as_pow.

gcc/cp/ChangeLog:
PR c/107002
* parser.cc (cp_parser_binary_expression): Update for new param of
check_for_xor_used_as_pow.

gcc/ChangeLog:
PR c/107002
* diagnostic-show-locus.cc (column_range::column_range): Factor
out assertion conditional into...
(column_range::valid_p): ...this new function.
(line_corrections::add_hint): Don't attempt to consolidate hints
if it would lead to invalid column_range instances.

gcc/testsuite/ChangeLog:
PR c/107002
* c-c++-common/Wxor-used-as-pow-1.c: Add macro test.
* c-c++-common/Wxor-used-as-pow-pr107002-0.c: New test.
* c-c++-common/Wxor-used-as-pow-pr107002-1.c: New test.
* c-c++-common/Wxor-used-as-pow-pr107002-2.c: New test.

Signed-off-by: David Malcolm 

[Bug sanitizer/109313] Incorrect line number in Use-After-Scope report

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

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

--- Comment #1 from Andrew Pinski  ---
When ccp3 changes (correctly):
   [local count: 958878296]:
  .ASAN_MARK (POISON, &d, 4);
  [/app/example.cpp:6:24] b.1_2 = b;
  [/app/example.cpp:6:24] _3 = b.1_2 + 1;
  [/app/example.cpp:6:24] b = _3;
  [/app/example.cpp:6:18] if (_3 <= 0)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 55807731]:
  .ASAN_MARK (POISON, &d, 4);

   [local count: 114863531]:
  [/app/example.cpp:12:13] _5 = d;

Into:
   [local count: 958878296]:
  d_9 = .ASAN_POISON ();
  [/app/example.cpp:6:24] b.1_2 = b;
  [/app/example.cpp:6:24] _3 = b.1_2 + 1;
  [/app/example.cpp:6:24] b = _3;
  [/app/example.cpp:6:18] if (_3 <= 0)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 55807731]:
  d_6 = .ASAN_POISON ();

   [local count: 114863531]:
  # d_22 = PHI <[0:0] d_6(5), [0:0] d_9(4)>
  [/app/example.cpp:12:13] _5 = d_22;

The location of the load is missing and now is always a direct poison call
without any location info left over.

I am not sure how this would work out really ...

[Bug tree-optimization/109318] csmith: -fipa-cp seems to cause trouble

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
In gdb:

gdb) r 1
Starting program: /home/dcb36/csmith/a.out 1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00401630 in func_14 (p_15=-3035) at runData/keep/in.46087.c:217
217 (*l_1508) = func_16(l_22[0][6],
(safe_add_func_uint64_t_u_u((~((safe_div_func_uint64_t_u_u(func_28(&g_7,
g_12.f0, func_32(l_34[0][1])), ((l_1506[6] != (+(p_15 || l_1506[6]))) ||
p_15))) < 0xCFA7L)), p_15)), l_1508, l_1509, p_15);
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.35-20.fc36.x86_64
(gdb) bt
#0  0x00401630 in func_14 (p_15=-3035) at runData/keep/in.46087.c:217
#1  func_1 () at runData/keep/in.46087.c:177
#2  main (argc=, argv=)
at runData/keep/in.46087.c:764
(gdb)

[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||chenglulu at loongson dot cn,
   ||xry111 at gcc dot gnu.org

--- Comment #5 from Xi Ruoyao  ---
The test fails on loongarch64-linux-gnu.  foo is kept in 114t.threadfull1, but
removed in 135t.forwprop3.

Does this mean something is wrong for LoongArch, or we should simply check the
tree dump in a later pass (for e.g. 254t.optimized)?

[Bug c/109318] New: csmith: -fipa-cp seems to cause trouble

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109318
   Summary: csmith: -fipa-cp seems to cause trouble
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code, produced by csmith, does this:

$ ../results/bin/gcc -w -O1 bug903.c
$ ./a.out
checksum = FC4F321
$ ../results/bin/gcc -w -O1 -fipa-cp bug903.c
$ ./a.out
Segmentation fault (core dumped)
$ ./a.out 1
Segmentation fault (core dumped)
$ 

The bug seems to have existed since before 20220403.

[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable

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

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

--- Comment #9 from Jonathan Wakely  ---
This fixes the testcase, but I'll check for other problems using the cached
facets:

--- a/libstdc++-v3/include/bits/ostream.tcc
+++ b/libstdc++-v3/include/bits/ostream.tcc
@@ -69,7 +69,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
ios_base::iostate __err = ios_base::goodbit;
__try
  {
+#ifndef _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT
const __num_put_type& __np = __check_facet(this->_M_num_put);
+#else
+   const __num_put_type& __np
+ = use_facet<__num_put_type>(this->_M_ios_locale);
+#endif
if (__np.put(*this, *this, this->fill(), __v).failed())
  __err |= ios_base::badbit;
  }

The _M_num_put cache exists to avoid doing the RTTI check implied by use_facet
every time we use the stream. But that RTTI check has been removed for GCC 13
anyway. Since the cached facet is the cause of this bug, we can just ignore it
for powercp64le when we support two forms of long double.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #36 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #35)
> (In reply to Andrew Macleod from comment #34)
> > I will poke at whether its possible to cheaply handle a second (or third)
> > level for single dependency defs.
> 
> Will those include also binary ops which have one of the operands constant?
> I think that would be quite useful as well, in addition to unary ops/casts
> and the like.
> 

Yes, single dependency means single SSA name. and it may keep it linear in
cost...

[Bug libstdc++/109305] Allocator copy in basic_string::operator=

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Charles-Henri Gros from comment #7)
> For context, we're trying to detect cases where using "auto" unintentionally
> creates a copy (it's regrettably common).
> Here the copy is necessary to get a non-const value; that's definitely
> something we could consider. Thank you for your feedback.

Yes, it's necessary. If the copy was replaced with a reference to __str's
existing allocator, the next line of code would not compile:

include/bits/basic_string.h:1597:57: error: binding reference of type
‘std::allocator_traits >::allocator_type&’ {aka
‘std::allocator&’} to ‘const std::allocator’ discards qualifiers
 1597 | auto __ptr = _Alloc_traits::allocate(__alloc, __len
+ 1);
  | 
~~~^~~~

Maybe you can use that to detect unnecessary copies: would changing auto to
auto&& still compile?

(That's still incomplete, it might compile, but behave incorrectly, but at
least checking if it compiles would be a start!)

[Bug libstdc++/109305] Allocator copy in basic_string::operator=

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> Removing it would make the code less efficient and more complex.

In fact, I don't even see how it would be possible, except by making *another*
copy, e.g.

--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -1588,20 +1588,33 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
_M_destroy(_M_allocated_capacity);
_M_data(_M_use_local_data());
_M_set_length(0);
+   std::__alloc_on_copy(_M_get_allocator(),
+__str._M_get_allocator());
  }
else
  {
+   auto __backup_alloc = _M_get_allocator();
+   std::__alloc_on_copy(_M_get_allocator(),
+__str._M_get_allocator());
const auto __len = __str.size();
-   auto __alloc = __str._M_get_allocator();
-   // If this allocation throws there are no effects:
-   auto __ptr = _Alloc_traits::allocate(__alloc, __len + 1);
-   _M_destroy(_M_allocated_capacity);
+   pointer __ptr;
+   __try {
+ __ptr = _Alloc_traits::allocate(_M_get_allocator(),
+ __len + 1);
+   } __catch (...) {
+ std::__alloc_on_copy(_M_get_allocator(), __backup_alloc);
+ __throw_exception_again;
+   }
+   _Alloc_traits::deallocate(__backup_alloc, _M_data(),
+ _M_allocated_capacity + 1);
_M_data(__ptr);
_M_capacity(__len);
_M_set_length(__len);
  }
  }
-   std::__alloc_on_copy(_M_get_allocator(), __str._M_get_allocator());
+   else
+ std::__alloc_on_copy(_M_get_allocator(),
+  __str._M_get_allocator());
  }
 #endif
this->_M_assign(__str);

This makes the code much worse, and slower, and still has a copy (the
__backup_alloc) variable.

[Bug c/107002] [13 Regression] ICE in column_range, at diagnostic-show-locus.cc:2236 since r13-2386-gbedfca647a9e9c1a

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

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

--- Comment #4 from David Malcolm  ---
Created attachment 54778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54778&action=edit
Untested patch

(In reply to Jakub Jelinek from comment #3)
> David, any progress here?

I've currently testing the attached patch.

[Bug target/109317] New: -Os generates bigger code than -O2 on 32-bit ARM

[pali at kernel dot org via Gcc-bugs]

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

Bug ID: 109317
   Summary: -Os generates bigger code than -O2 on 32-bit ARM
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pali at kernel dot org
  Target Milestone: ---
Target: arm-linux-gnueabi

Simple loops like the one in the example below are better optimized for size on
32-bit ARM with -O2 option than -Os option.


$ cat test-arm.c
char *test1(char *ptr) {
  while (*ptr != '\0' || *(ptr+1) != '\0') ptr++;
  ptr++;
  return ptr;
}



$ arm-linux-gnueabi-gcc -O2 -c test-arm.c && arm-linux-gnueabi-objdump -d
test-arm.o

test-arm.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   e5d02000ldrbr2, [r0]
   4:   e281add r0, r0, #1
   8:   e352cmp r2, #0
   c:   1afbbne 0 
  10:   e5d02000ldrbr2, [r0]
  14:   e352cmp r2, #0
  18:   1af8bne 0 
  1c:   e12fff1ebx  lr



$ arm-linux-gnueabi-gcc -Os -c test-arm.c && arm-linux-gnueabi-objdump -d
test-arm.o

test-arm.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   e1a03000mov r3, r0
   4:   e5d32000ldrbr2, [r3]
   8:   e281add r0, r0, #1
   c:   e352cmp r2, #0
  10:   1afabne 0 
  14:   e5d02000ldrbr2, [r0]
  18:   e352cmp r2, #0
  1c:   1af7bne 0 
  20:   e12fff1ebx  lr



$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/12/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--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
--without-target-system-zlib --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv5te --with-float=soft --disable-werror
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi-
--includedir=/usr/arm-linux-gnueabi/include
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)

[Bug libstdc++/109305] Allocator copy in basic_string::operator=

[chgros at synopsys dot com via Gcc-bugs]

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

--- Comment #7 from Charles-Henri Gros  ---
For context, we're trying to detect cases where using "auto" unintentionally
creates a copy (it's regrettably common).
Here the copy is necessary to get a non-const value; that's definitely
something we could consider. Thank you for your feedback.

[Bug libstdc++/109305] Allocator copy in basic_string::operator=

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

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

--- Comment #6 from Jonathan Wakely  ---
For your reproducer, the allocator is std::allocator which is an empty
class and copying is a no-op. There is no efficiency concern whatsoever.

[Bug libstdc++/109305] Allocator copy in basic_string::operator=

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #5 from Jonathan Wakely  ---
Removing it would make the code less efficient and more complex.

If your allocator is expensive to copy, your allocator is bad and should be
fixed. They need to be cheap to copy.

[Bug libstdc++/109305] Allocator copy in basic_string::operator=

[marc-andre.laverdiere at synopsys dot com via Gcc-bugs]

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

--- Comment #4 from Marc-André Laverdière  ---
The comment is "If this allocation throws there are no effects:" and I didn't
understand the implications. Thanks for you spelled it out the logic behind it.
May I encourage you to update the comment?

As to why a local copy could be a problem, it's an efficiency (rather than
correctness) issue here. Removing unnecessary copies is always a plus. From the
explanations I got, that copy is necessary - or at least, removing it would be
complex.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #35 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #34)
> I will poke at whether its possible to cheaply handle a second (or third)
> level for single dependency defs.

Will those include also binary ops which have one of the operands constant?
I think that would be quite useful as well, in addition to unary ops/casts and
the like.

And as written above, we definitely should do something for GCC 14 about
floating to floating, floating to integral and integral to floating casts,
normal as well as reverse ops.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #34 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #33)
> (In reply to Andrew Macleod from comment #32)
> > We could in theory expand it to look at 2 levels if its a single operand...
> 
> Yeah, that would help here and could be worth it.
> 
> > which will help with some of these cases where there are casts, and keep the
> > performance degradation from being too bad.   I'm sure there will be cases
> > where a third would be handy :-P
> 
> And/or, could we go from seeing zone1_12 in an PHI arg and in that case walk
> a level or two or three to see if it is dependent on an SSA_NAME known to
> have specific range on the edge and if so, do those range queries using that
> range?

well, its knowing it has a specific ranges that is the not-cheap part. For
every one we find a useful range, therea re likely many queries that do not
fina anything useful.  and every level of indirection adds to that.

So we know zone1_12 uses _2, we can see that it is a recomputable value, but
without outgoing edge values cached, we have to actually calculate it.   Until
we calculate it, we dont know that its going to help us.. we just know it *can*
be recomputed, not that its useful.

Even if we limited it to just PHI arguments (which specializing is not easy
btw), that means every PHI argument could have additional 2nd level checks and
recomputations, many of which are not useful.

I will poke at whether its possible to cheaply handle a second (or third) level
for single dependency defs.

[Bug c++/109309] Untranslated text in diagnostic

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Should be fixed now.

[Bug c++/109309] Untranslated text in diagnostic

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

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

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

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

commit r13-6911-gaf45b17d0a8fe3e7ae08662008a1f41e48a4a3eb
Author: Jakub Jelinek 
Date:   Tue Mar 28 17:49:23 2023 +0200

c++: Allow translations of check_postcondition_result messages [PR109309]

As mentioned in the PR, constructing a message from two parts by
concatenating them prevents translations, unless one of the parts
is a keyword which should be never translated.

The following patch fixes that.

2023-03-28  Jakub Jelinek  

PR c++/109309
* contracts.cc: Include intl.h.
(check_postcondition_result): Don't form diagnostics from two
halves
of an English message to allow translations.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #33 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #32)
> We could in theory expand it to look at 2 levels if its a single operand...

Yeah, that would help here and could be worth it.

> which will help with some of these cases where there are casts, and keep the
> performance degradation from being too bad.   I'm sure there will be cases
> where a third would be handy :-P

And/or, could we go from seeing zone1_12 in an PHI arg and in that case walk a
level or two or three to see if it is dependent on an SSA_NAME known to have
specific range on the edge and if so, do those range queries using that range?

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #32 from Andrew Macleod  ---

The issues is here is pruning to avoid significant time growth.

  _1 = (float) l_11(D); 
  _2 = _1 < 0.0;
  zone1_12 = (int) _2;
  if (_1 < 0.0)
goto ; [INV]

_1 is an export from the block. In theory if there was a proper range-op entry
for a cast from float to int l_11 could also be an export.

We can recompute anything which directly uses an export from the block. _2 uses
_1 so we can recompute _2.We currently only support one level of
recomputation because recognition and computation grows between quadratically
and expoential based on the number of recomputations required, and
indentifying/evaluating the levels of indirection...

zone1_12 does not directly use an export, so GORI does not see it as something
which it can evaluate. To evaluate it, we have to see that _2 is recomputable,
reconmpute it, then recompute zone1_12.

This could in theory be an arbitrarily long range, and for performance reasons,
we limited it to 1 up until this point.

Note that is we had used _2:
if (_2 != 0)
   goto 
then _2 would be a export, and zone1_12 would be a recomputation and have the
approriate value.

I have plans to eventually rejig GORI to cache outgoing ranges on edges.  This
would allow us to recompute chains without the quadratic growth and we would
have all the recomputations we want, but at this point, we are only doing one
level

We could in theory expand it to look at 2 levels if its a single operand...
which will help with some of these cases where there are casts, and keep the
performance degradation from being too bad.   I'm sure there will be cases
where a third would be handy :-P

[Bug c++/107163] [10/11/12/13 Regression] huge Compile time increase when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r13-6910-g0e8fc610fb7112deb8c33c673a52983368dde9b7
Author: Jason Merrill 
Date:   Thu Mar 23 15:57:39 2023 -0400

c-family: -Wsequence-point and COMPONENT_REF [PR107163]

The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF
as sequenced in C++17, and COMPONENT_REF as well.  But this is unnecessary
for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual
evaluation, and in this testcase handling COMPONENT_REF as sequenced blows
up fast in a deep inheritance tree.  Instead, look through it.

PR c++/107163

gcc/c-family/ChangeLog:

* c-common.cc (verify_tree): Don't use sequenced handling
for COMPONENT_REF.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wsequence-point-5.C: New test.

[Bug target/109312] Missing __riscv_v_intrinsic

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #4 from Kito Cheng  ---
Fixed, let me know if you got any issue on RVV intrinsic, thanks :)

[Bug modula2/109315] typo: inconsistant

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Thanks will fix

[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable

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

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

--- Comment #8 from Jonathan Wakely  ---
And that's because we're using the ostream's cached _M_num_put but that is the
wrong one:

(gdb) step
std::basic_ostream >::_M_insert<__ieee128>
(this=0x101c0900 , __v=0.1005)
at
/home/test/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:66
66  sentry __cerb(*this);
(gdb) n
67  if (__cerb)
(gdb) 
69  ios_base::iostate __err = ios_base::goodbit;
(gdb) 
72  const __num_put_type& __np =
__check_facet(this->_M_num_put);
(gdb) p _M_num_put
$18 = (const std::basic_ios >::__num_put_type *)
0x101c1f98 <(anonymous namespace)::num_put_c>

[Bug target/109312] Missing __riscv_v_intrinsic

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:5a923516ae61ddc6dd863891db13189cbf392411

commit r13-6909-g5a923516ae61ddc6dd863891db13189cbf392411
Author: Kito Cheng 
Date:   Tue Mar 28 22:21:50 2023 +0800

RISC-V: Define __riscv_v_intrinsic [PR109312]

RVV intrinsic has defined a macro to identity the version of RVV
intrinsic spec, we missed that before, thanksful we are catch this
before release.

gcc/ChangeLog:

PR target/109312
* config/riscv/riscv-c.cc (riscv_ext_version_value): New.
(riscv_cpu_cpp_builtins): Define __riscv_v_intrinsic and
minor refactor.

gcc/testsuite/ChangeLog:

PR target/109312
* gcc.target/riscv/predef-__riscv_v_intrinsic.c: New test.

[Bug ipa/106124] [11/12/13 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

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

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #3)
> I suppose that's the OMP reduction function and that's always(?) inlined?

The reduction "function" is something artificial which holds some expressions
for the
OpenMP reductions; we just need to attach those statements to some decl for
name lookup purposes.
The problem is what to do with lambdas defined inside of those expressions, or
e.g. nested functions for the C case:
int q;

#pragma omp declare reduction (x : int : omp_out += omp_in + ({ int a = 1; void
foo () { a++; } foo (); a; }))

void bar (int *, int *);

void
foo ()
{
  int r = 0, s = 0;
  #pragma omp parallel reduction (x : r, s)
  bar (&r, &s);
}

ICEs too.  Lambdas are there certainly valid, we try to pretend the artificial
functions don't really exist for the debug info purposes, but apparently not
sufficiently.

[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable

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

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

--- Comment #7 from Jonathan Wakely  ---
OK, I see what's happening now:

Breakpoint 3.3, std::__gnu_cxx_ldbl128::num_put > >::num_put (
this=0x101c1f98 <(anonymous namespace)::num_put_c>, __refs=1)
at
/home/test/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2339
2339  num_put(size_t __refs = 0) : facet(__refs) { }
(gdb) p this
$9 = (std::__gnu_cxx_ldbl128::num_put > > * const) 0x101c1f98 <(anonymous
namespace)::num_put_c>
(gdb) cont
Continuing.

Breakpoint 3.4, std::__gnu_cxx_ldbl128::num_put > >::num_put (
this=0x101c25f8 <(anonymous namespace)::num_put_w>, __refs=1)
at
/home/test/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2339
2339  num_put(size_t __refs = 0) : facet(__refs) { }
(gdb) p this
$10 = (std::__gnu_cxx_ldbl128::num_put > > * const)
0x101c25f8 <(anonymous namespace)::num_put_w>
(gdb) cont
Continuing.

Breakpoint 3.1, std::__gnu_cxx_ieee128::num_put > >::num_put (
this=0x101c06b8 , __refs=1)
at
/home/test/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2339
2339  num_put(size_t __refs = 0) : facet(__refs) { }
(gdb) p this
$11 = (std::__gnu_cxx_ieee128::num_put > > * const) 0x101c06b8 
(gdb) cont
Continuing.

Breakpoint 3.2, std::__gnu_cxx_ieee128::num_put > >::num_put (
this=0x101c06f8 , __refs=1)
at
/home/test/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2339
2339  num_put(size_t __refs = 0) : facet(__refs) { }
(gdb) p this
$12 = (std::__gnu_cxx_ieee128::num_put > > * const)
0x101c06f8 
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) up
#1  0x10015640 in std::__gnu_cxx_ieee128::num_put > >::put (
this=0x101c1f98 <(anonymous namespace)::num_put_c>, __s=..., __io=...,
__fill=32 ' ', __v=0.1005)
at
/home/test/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:2468
2468  { return this->do_put(__s, __io, __fill, __v); }
(gdb) p this
$13 = (const std::__gnu_cxx_ieee128::num_put > > * const) 0x101c1f98
<(anonymous namespace)::num_put_c>


The facet used for the output is __gnu_cxx_ieee128::num_put but it has
the address of $9 which is a __gnu_cxx_ldbl128::num_put. So the wrong
pointer is being returned when accessing the facet.

[Bug c/107002] [13 Regression] ICE in column_range, at diagnostic-show-locus.cc:2236 since r13-2386-gbedfca647a9e9c1a

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
David, any progress here?
Should the diagnostic callers be more careful when passing multiple fixit
locations to make sure they don't overlap (I think in this case they are even
the exact same location), or should diagnostic-show-locus.cc recover from it?
Given the same location for both, they are equal:
(gdb) p last_correction->m_affected_bytes
$34 = {start = 1, finish = 4}
(gdb) p affected_bytes
$35 = {start = 1, finish = 4}
and so trying to create a column range for finish + 1 of the former to start -
1
of the latter is invalid.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #31 from Jakub Jelinek  ---
On the #c28 testcase, my #c23 patch seems to improve something only visible in
the details of the evrp dump:
 zone1_12 : [irange] int [0, 1] NONZERO 0x1
-2->3  (T) _1 : [frange] float [-Inf, -0.0 (-0x0.0p+0)]
+2->3  (T) _1 : [frange] float [-Inf,
-1.40129846432481707092372958328991613128026194187651577176e-45 (-0x0.8p-148)]
+2->3  (T) _2 : [irange] _Bool [1, 1]
 2->4  (F) _1 : [frange] float [-0.0 (-0x0.0p+0), +Inf] +-NAN
So, at least it knows that _2 = _1 < 0.0; is true on that edge, which is a
progress.
But seems it doesn't know that zone1_12 = (int) _2; is also int [1, 1] there
and so
the
  # iftmp.0_8 = PHI 
range would be int [1, 1] too.
I think we are here outside of the frange stuff and into GORI.

Andrew, could you please have a look?

[Bug rtl-optimization/109187] [13 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1736258160 at -O2 since r13-5154-g733a1b777f16cd

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

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #6 from Alexander Monakov  ---
Fixed on the trunk, thanks for the report.

[Bug rtl-optimization/109187] [13 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1736258160 at -O2 since r13-5154-g733a1b777f16cd

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Alexander Monakov :

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

commit r13-6907-gfb046e69f0ed2d637ea715ae71ad50131f30cb2d
Author: Alexander Monakov 
Date:   Tue Mar 28 16:00:37 2023 +0300

haifa-sched: fix autopref_rank_for_schedule comparator [PR109187]

Do not attempt to use a plain subtraction for generating a three-way
comparison result in autopref_rank_for_schedule qsort comparator, as
offsets are not restricted and subtraction may overflow.  Open-code
a safe three-way comparison instead.

gcc/ChangeLog:

PR rtl-optimization/109187
* haifa-sched.cc (autopref_rank_for_schedule): Avoid use of
overflowing
subtraction in three-way comparison.

gcc/testsuite/ChangeLog:

PR rtl-optimization/109187
* gcc.dg/pr109187.c: New test.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #30 from Jakub Jelinek  ---
But at least the zone1_100 stuff is unused in #c26, so improving #c28 there
wouldn't help.
  distbb_99 = distij_98 - radij_82;
  _27 = distbb_99 < 0.0;
  # RANGE [irange] const int [0, 1] NONZERO 0x1
  zone1_100 = (const int) _27;
  if (distbb_99 < 0.0)
_27 is only used by the dead zone1_100.

So, we have 2 different testcases now for 2 different issues.

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #14 from Andrew Macleod  ---
fixed.

[Bug tree-optimization/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r13-6906-gdd63bba0c8dc3a6ae06cfdc084bca7c68b8bbd39
Author: Andrew MacLeod 
Date:   Fri Mar 24 11:21:20 2023 -0400

Fix compute_operand when op1 == op2 symbolically.

First, class value_relation should not sanitize records. just create
what is asked.

Second., if there is not a relation record, compute_operand was
creating one for op1 == op2 if op1 and op2 were the same symbol.   This
is not the correct way to communicate the information, as that record
will continue to be passed along the GORI unwind chain.

Instead, simply pass that information locally to the opX_range routine
for only the current statement.

PR tree-optimization/109265
PR tree-optimization/109274
gcc/
* gimple-range-gori.cc (gori_compute::compute_operand_range): Do
not create a relation record is op1 and op2 are the same symbol.
(gori_compute::compute_operand1_range): Pass op1 == op2 to the
handler for this stmt, but create a new record only if this
statement
generates a relation based on the ranges.
(gori_compute::compute_operand2_range): Ditto.
* value-relation.h (value_relation::set_relation): Always create
the
record that is requested.

gcc/testsuite/
* gcc.dg/pr109274.c: New.
* gfortran.dg/pr109265.f90: New.

[Bug tree-optimization/109274] [13 Regression] ice in in_chain_p, at gimple-range-gori.cc:119 starting with r13-6787-g0963cb5fde158cce986

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r13-6906-gdd63bba0c8dc3a6ae06cfdc084bca7c68b8bbd39
Author: Andrew MacLeod 
Date:   Fri Mar 24 11:21:20 2023 -0400

Fix compute_operand when op1 == op2 symbolically.

First, class value_relation should not sanitize records. just create
what is asked.

Second., if there is not a relation record, compute_operand was
creating one for op1 == op2 if op1 and op2 were the same symbol.   This
is not the correct way to communicate the information, as that record
will continue to be passed along the GORI unwind chain.

Instead, simply pass that information locally to the opX_range routine
for only the current statement.

PR tree-optimization/109265
PR tree-optimization/109274
gcc/
* gimple-range-gori.cc (gori_compute::compute_operand_range): Do
not create a relation record is op1 and op2 are the same symbol.
(gori_compute::compute_operand1_range): Pass op1 == op2 to the
handler for this stmt, but create a new record only if this
statement
generates a relation based on the ranges.
(gori_compute::compute_operand2_range): Ditto.
* value-relation.h (value_relation::set_relation): Always create
the
record that is requested.

gcc/testsuite/
* gcc.dg/pr109274.c: New.
* gfortran.dg/pr109265.f90: New.

[Bug c/109316] New: incorrect "warning: declaration does not declare anything" for anonymous enums in structs, for -std=(gnu|c)-17

[jason.vas.dias at gmail dot com via Gcc-bugs]

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

Bug ID: 109316
   Summary: incorrect "warning: declaration does not declare
anything" for anonymous enums in structs, for
-std=(gnu|c)-17
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

Just a niggle:

I don't think this code should produce a warning,
but under GCC 12, with -std=gnu17 or -std=c17,
or without any '-std=' setting in C language mode,
 it does:

 'struct S { int a; enum { S_O_a = 0 }; }'; 

/tmp/b.c:1:37: warning: declaration does not declare anything
1 | struct S { int a; enum { S_O_a = 0 }; };
  |

Yes, I know the enumeration declaration does not 
add anything to the struct declaration, (intentionally!),
but in fact GCC HAS inserted DWARF debuginfo for the
enumerator 'S_O_a' in the debug_info section , which
can be used by code in which case the constant is 
interpolated into the output machine code, so something
HAS been declared here ...

[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings

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

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

Bug 107087 Summary: [13 Regression] bits/stl_algobase.h:431: warning: 'void* 
__builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 
2147483644 bytes from a region of size 4 [-Wstringop-overread]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087

   What|Removed |Added

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

[Bug tree-optimization/107087] [13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of siz

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/107087] [13 Regression] bits/stl_algobase.h:431: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' reading between 8 and 2147483644 bytes from a region of siz

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

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

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

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

commit r13-6905-g2b9d76c1af189b918a9970f471e6d2e2c08f7e7d
Author: Richard Biener 
Date:   Mon Mar 27 15:18:41 2023 +0200

tree-optimization/107087 - missed CCP after forwprop

When forwprop simplifies the CFG the 2nd order opportunities by
exposed degenerate PHIs are not realized.  The following improves
this by properly tracking executable edges and thus handling this
for non-cyclic CFGs at least.

This avoids the bogus diagnostic reported for the testcase in this PR.

PR tree-optimization/107087
* tree-ssa-forwprop.cc (pass_forwprop::execute): Track
executable regions to avoid useless work and to better
propagate degenerate PHIs.

* g++.dg/pr107087.C: New testcase.

[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #14 from Andrew Macleod  ---
The upcoming patch for 109274 should resolve this.

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

--- Comment #29 from Richard Biener  ---
For the testcase in comment#26 we see that if-conversion from

  if (distbb_170 >= 0.0)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 311875831]:
...
  if (distbb_170 < iftmp.0_97)
goto ; [20.00%]
  else
goto ; [80.00%]

   [local count: 62375167]:
...
   [local count: 528603100]:
  # prephitmp_153 = PHI <0.0(42), _158(44), chrg_init_70(41)>

produces

  _102 = distbb_170 >= 0.0;
  _109 = iftmp.0_97 > distbb_170;
  _104 = _102 & _109;
  _86 = iftmp.0_97 <= distbb_170;
  _87 = _86 & _102;
  _ifc__124 = _87 ? 0.0 : _158;
  _ifc__123 = _104 ? _158 : _ifc__124;
  _122 = distbb_170 < 0.0;
  prephitmp_153 = _122 ? chrg_init_70 : _ifc__123;

so from two comparisons it ends up generating four (two inverted) and
three COND_EXPRs.  There's optimization to explicitely negate but
the

  _85 = iftmp.0_97 > distbb_170
  _86 = ~_85;

that's originally created gets CSEd and then, when _109 is substituted,
folded to the inverted comparison (by match.pd:5069).  At least the
last COND_EXPR could have recovered the original compare by swapping
the COND_EXPR arms - best the if-conversion code emission should do
this itself.

It currently emits

_102 = distbb_170 >= 0.0;
_145 = distbb_170 >= 0.0;
_158 = chrg_init_70 * iftmp.3_159;
_109 = iftmp.0_97 > distbb_170;
_104 = _102 & _109;
_85 = iftmp.0_97 > distbb_170;
_86 = ~_85;
_87 = _86 & _102;
_ifc__124 = _87 ? 0.0 : _158;
_ifc__123 = _104 ? _158 : _ifc__124;
_122 = ~_145;
prephitmp_153 = _122 ? chrg_init_70 : _ifc__123;

so that micro-optimization would help us a little bit here.  I have a patch
in testing to do that.