[Bug other/109086] __builtin_strcmp generates wrong code if expand_simple_binop assigns new pseudo-register for result

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |xry111 at gcc dot 
gnu.org
 Target|loongarch   |
Summary|Bug of builtin_strcmp in|__builtin_strcmp generates
   |the case of using the   |wrong code if
   |adddi3 instruction patterns |expand_simple_binop assigns
   ||new pseudo-register for
   ||result
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-03-15
 Ever confirmed|0   |1
  Component|rtl-optimization|other

[Bug other/109086] __builtin_strcmp generates wrong code if expand_simple_binop assigns new pseudo-register for result

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

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

--- Comment #11 from Richard Biener  ---
OK, so the issue is that expand_simple_binop will not necessarily return a
register and emit_cmp_and_jump_insns eventually mangles things.

The proposed fix looks OK, but please add a comment like

 /* Force the result into a register.  */

[Bug c/109123] Bogus warning: pointer used after 'realloc' -Wuse-after-free with -O2

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

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

--- Comment #9 from Richard Biener  ---
Created attachment 54668
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54668&action=edit
patch

The diagnostic pass (pass_warn_access) is already split into two modes,
unfortunately the -Wuse-after-free part only runs on the late optimized IL
(for whatever reasons ...).

Enabling it only for the early passes regresses a few cases but also resolves
some XFAILs (and your testcase), so it might be the best thing to do.

I'm testing the attached.

[Bug c/109139] New: ice in make_decl_rtl, at varasm.cc:1442

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109139
   Summary: ice in make_decl_rtl, at varasm.cc:1442
   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: ---

This C code:

const int COMPARE_CANDIDATE;
char ipmi_ek_compare_link_record1_0, ipmi_ek_compare_link_record2_0;
void ipmi_ek_compare_link() {
  for (; ipmi_ek_compare_link_record1_0;)
for (; ipmi_ek_compare_link_record2_0;) {
  int link[COMPARE_CANDIDATE];
}
}

when compiled by today's gcc trunk, does this:

$ ~/gcc/results.20230315/bin/gcc -c -w -O1 -ftrivial-auto-var-init=zero
bug896.c 
during RTL pass: expand
bug896.c: In function ‘ipmi_ek_compare_link’:
bug896.c:6:11: internal compiler error: in make_decl_rtl, at varasm.cc:1442
6 |   int link[COMPARE_CANDIDATE];
  |   ^~~~
0x7c9502 make_decl_rtl(tree_node*)
../../trunk.year/gcc/varasm.cc:1442

It worked yesterday:

$ ~/gcc/results.20230314/bin/gcc -c -w -O1 -ftrivial-auto-var-init=zero
bug896.c 
$ 

The git range seems to be g:e17936f842d28854 .. g:a9ae16db8cbb2c0e.

[Bug sanitizer/109134] UBSan signed integer overflow check missing

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

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

--- Comment #1 from Richard Biener  ---
Having that extra TYPE_OVERFLOW_SANITIZED really isn't sustainable.  But the
main issue is that the instrumentation happens after (some) folding has taken
place.

We probably also have still code second-guessing TYPE_OVERFLOW_UNDEFINED
if !TYPE_OVERFLOW_WRAPS or the other way around - it would be best to
transition to TYPE_OVERFLOW_BEHAVIOR () yielding an enum, there can
only be one of { wraps, undefined, traps, sanitized } and transforms
relying on undefined overflow shall not trigger when it's 'sanitized'.

If it were not for the second-guessing code then adjusting
TYPE_OVERFLOW_UNDEFINED to false when sanitizing should work (but
TYPE_OVERFLOW_WRAPS should still return false as well!).  It might
also work to magically switch back to undefined after instrumentation.

[Bug tree-optimization/109139] [13 Regression] ice in make_decl_rtl, at varasm.cc:1442

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |13.0
Summary|ice in make_decl_rtl, at|[13 Regression] ice in
   |varasm.cc:1442  |make_decl_rtl, at
   ||varasm.cc:1442
   Keywords|needs-bisection |ice-on-valid-code
   Last reconfirmed||2023-03-15

--- Comment #1 from Andrew Pinski  ---
Before we had:
  unsigned char link.9[0:18446744073709551615];
in the referenced variables
but after it is gone.

But it is still referened:
  MEM[(int[0:D.2753] *)&link.9] = .DEFERRED_INIT (0, 2, &"link"[0]);

release_ssa removes it but I have not looked into how.

Note the way ccp1 turns this VLA into a non-VLA might be an issue too ...

[Bug driver/109135] Wrong make utility called with LTO testsuite

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Steve Kargl from comment #4)
> On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot
> apl.washington.edu wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
> > 
> > --- Comment #3 from Steve Kargl  
> > ---
> > On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote:
> > > 
> > > --- Comment #1 from Andrew Pinski  ---
> > > This is not a testsuite issue but rather the issue is the lto code is 
> > > calling
> > > make ...
> > > 
> > 
> > That explains why groping around in gcc/testsuite for
> > a rogue make or MAKE was coming up empty.
> > 
> > I'm in the middle of doing a serial 'gmake check-fortran',
> > which takes a long time on my system.  Is there a way
> > to invoke only lto testing?
> 
> So, 'gmake check-fortran' finishes without any lto issues.
> It seems one must invoke the checking with 'gmake -j6 check-fortran'
> to get failures.
> 
> Looking in obj/gcc/Makefile at line 341 I see the comment
> 
> # Make sure the $(MAKE) variable is defined.
> 
> followed by no checking to see if MAKE is defined.

Makefile.in has

# Make sure the $(MAKE) variable is defined.
@SET_MAKE@

configure has

if eval test \$ac_cv_prog_make_${ac_make}_set = yes; then
  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
$as_echo "yes" >&6; }
  SET_MAKE=
else
  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
$as_echo "no" >&6; }
  SET_MAKE="MAKE=${MAKE-make}"
fi

from AC_PROG_MAKE_SET which seems to check whether make sets $MAKE.
That appearantly succeeds for you.  Do you "properly" do sth like

MAKE=gmake ../configure

so configure sees which make you are using?  I think if your gmake
doesn't set it then even recursive configure invocations from gmake
will resort to 'make'

but then I _think_ that gmake itself sets $MAKE (if it was not set?) for
sub-processes.  But maybe only if it thinks its recursive make?

[Bug tree-optimization/109139] [13 Regression] ice in make_decl_rtl, at varasm.cc:1442

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

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

--- Comment #2 from Andrew Pinski  ---
I am almost positive it is r13-6661-gbd6e566e9dc543cf4f6df69dcefb40bb8b4100f1 .

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
  Known to fail||12.2.1
  Known to work||12.2.0
   Priority|P3  |P1

--- Comment #8 from Richard Biener  ---
Honza, the reporter uses -march=znver1 - why did these backports affect
anything but zen4?

[Bug tree-optimization/109138] wrong code at -O1 and above on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |13.0

--- Comment #2 from Richard Biener  ---
So similar to PR107833, the solution might be similar as well.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Richard Biener from comment #8)
> Honza, the reporter uses -march=znver1 - why did these backports affect
> anything but zen4?


(X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3.
(X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

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

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

--- Comment #16 from Richard Biener  ---
I've pushed the more aggressive .DEFERRED_INIT removal so the issue might be
only latent now.

[Bug target/109004] [10/11/12/13 Regression] wrong code for -O2 (any above -O0) with g++ 11.3 for POWER9 (cross-compiler on x86_64 host)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
You haven't told what you think is a bug and what you think is correct
behavior.
I've tried to compile using 12.2.1 20221121
g++ -o test_p64-test{0,.ii} -mcpu=power9 -O0 -fpie -pie
g++ -o test_p64-test{2,.ii} -mcpu=power9 -O2 -fpie -pie
./test_p64-test0 > 0
./test_p64-test2 > 2
diff -up 0 2
g++ -o test_p64-test{0,.ii} -mcpu=power8 -O0 -fpie -pie
g++ -o test_p64-test{2,.ii} -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -mcpu=power9 -O2 -fpie -pie
./test_p64-test0 > 0
./test_p64-test2 > 2
diff -up 0 2
And neither shows any differences.
Attaching a screenshot is a very bad idea, one can't copy from it.  Only
preprocessed source should be attached, the rest should go in text here,
describe what to run and what is correct and what is wrong (best testcases just
abort if they don't behave as expected and exit with 0 otherwise).

[Bug tree-optimization/109139] [13 Regression] ice in make_decl_rtl, at varasm.cc:1442

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Will have a look.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

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

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

--- Comment #17 from Jakub Jelinek  ---
I think the rest is discussed in PR109093...

[Bug tree-optimization/109138] wrong code at -O1 and above on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> So similar to PR107833, the solution might be similar as well.

Actually it is closer related to PR 68083 .

[Bug fortran/58331] [OOP] Bogus rank checking with explicit-/assumed-size arrays and CLASS

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

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

--- Comment #9 from Tobias Burnus  ---
COARRAYS:

(In reply to anlauf from comment #7)
> I tried other testcases that use coarrays, but e.g. the following scalar
> coarray case produces an ICE later on.  I believe this is a pre-existing
> separate issue.

A coarray 'ca' can either be a local variable (the usual case), a remove
reference (then with '[indx]' in the expr) - or, like here, the full thing.

In gfc_conv_intrinsic_to_class, the gfc_conv_expr_reference 'destroys' the
coarray part. I think we need something like 'gfc_conv_variable' — and I bet
that we need to ensure all combinations work:

(scalar,array w/o and w/ descriptor) → (assumed rank, array w/o and w/
descriptor) - where the 'to class' (and, obviously, the 'from' was well) are
coarrays.

Besides intrinsic types -> class(*), we should also check check
type(t) -> ('class(t)' and 'class(*)')

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
On Wed, 15 Mar 2023, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
> 
> --- Comment #9 from Andrew Pinski  ---
> (In reply to Richard Biener from comment #8)
> > Honza, the reporter uses -march=znver1 - why did these backports affect
> > anything but zen4?
> 
> 
> (X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3.
> (X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3.

But Zen1 uses a split AVX pipe so I'm not sure that's the best idea?

Anway, I'd revert this change completely on the branch and only
keep the znver4 effects.

[Bug modula2/109125] [13 regression] SIGBUS in m2pim_ldtoa_ldtoa

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Gaius Mulley  ---
[...]
> Version 2 of the patch catches some more cases found in the iso libraries.

I've tried that one last night and most of the failures are gone.
Thanks for the super-fix patch.

Some failures remain, however, both 32 and 64-bit again:

+FAIL: gm2/isolib/run/pass/readreal.mod execution,  -O 
+FAIL: gm2/isolib/run/pass/readreal.mod execution,  -O -g 
+FAIL: gm2/isolib/run/pass/readreal.mod execution,  -O3 -fomit-frame-pointer 
+FAIL: gm2/isolib/run/pass/readreal.mod execution,  -O3 -fomit-frame-pointer
-finline-functions 
+FAIL: gm2/isolib/run/pass/readreal.mod execution,  -Os 
+FAIL: gm2/isolib/run/pass/readreal.mod execution,  -g 
+FAIL: gm2/isolib/run/pass/real3.mod execution,  -O 
+FAIL: gm2/isolib/run/pass/real3.mod execution,  -O -g 
+FAIL: gm2/isolib/run/pass/real3.mod execution,  -O3 -fomit-frame-pointer 
+FAIL: gm2/isolib/run/pass/real3.mod execution,  -O3 -fomit-frame-pointer
-finline-functions 
+FAIL: gm2/isolib/run/pass/real3.mod execution,  -Os 
+FAIL: gm2/isolib/run/pass/real3.mod execution,  -g 

+FAIL: gm2/pim/run/pass/cycles.mod execution,  -O 
+FAIL: gm2/pim/run/pass/cycles.mod execution,  -O -g 
+FAIL: gm2/pim/run/pass/cycles.mod execution,  -O3 -fomit-frame-pointer 
+FAIL: gm2/pim/run/pass/cycles.mod execution,  -O3 -fomit-frame-pointer
-finline-functions 
+FAIL: gm2/pim/run/pass/cycles.mod execution,  -Os 
+FAIL: gm2/pim/run/pass/cycles.mod execution,  -g 
+FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O 
+FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O -g 
+FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O3
-fomit-frame-pointer 
+FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O3
-fomit-frame-pointer -finline-functions 
+FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -Os 
+FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -g 
+FAIL: gm2/pimlib/logitech/run/pass/realinput.mod execution,  -O 
+FAIL: gm2/pimlib/logitech/run/pass/realinput.mod execution,  -O -g 
+FAIL: gm2/pimlib/logitech/run/pass/realinput.mod execution,  -O3
-fomit-frame-pointer 
+FAIL: gm2/pimlib/logitech/run/pass/realinput.mod execution,  -O3
-fomit-frame-pointer -finline-functions 
+FAIL: gm2/pimlib/logitech/run/pass/realinput.mod execution,  -Os 
+FAIL: gm2/pimlib/logitech/run/pass/realinput.mod execution,  -g 
+FAIL: gm2/pimlib/logitech/run/pass/realinput2.mod execution,  -O 
+FAIL: gm2/pimlib/logitech/run/pass/realinput2.mod execution,  -O -g 
+FAIL: gm2/pimlib/logitech/run/pass/realinput2.mod execution,  -O3
-fomit-frame-pointer 
+FAIL: gm2/pimlib/logitech/run/pass/realinput2.mod execution,  -O3
-fomit-frame-pointer -finline-functions 
+FAIL: gm2/pimlib/logitech/run/pass/realinput2.mod execution,  -Os 
+FAIL: gm2/pimlib/logitech/run/pass/realinput2.mod execution,  -g 
+FAIL: gm2/pimlib/logitech/run/pass/realinput3.mod execution,  -O 
+FAIL: gm2/pimlib/logitech/run/pass/realinput3.mod execution,  -O -g 
+FAIL: gm2/pimlib/logitech/run/pass/realinput3.mod execution,  -O3
-fomit-frame-pointer 
+FAIL: gm2/pimlib/logitech/run/pass/realinput3.mod execution,  -O3
-fomit-frame-pointer -finline-functions 
+FAIL: gm2/pimlib/logitech/run/pass/realinput3.mod execution,  -Os 
+FAIL: gm2/pimlib/logitech/run/pass/realinput3.mod execution,  -g 
+FAIL: gm2/types/run/pass/varient4.mod execution,  -O 
+FAIL: gm2/types/run/pass/varient4.mod execution,  -O -g 
+FAIL: gm2/types/run/pass/varient4.mod execution,  -O3 -fomit-frame-pointer 
+FAIL: gm2/types/run/pass/varient4.mod execution,  -O3 -fomit-frame-pointer
-finline-functions 
+FAIL: gm2/types/run/pass/varient4.mod execution,  -Os 
+FAIL: gm2/types/run/pass/varient4.mod execution,  -g 

I've had a look at the readreal.mod one: gm2.log shows

enter a real number: RTExceptions.mod:649:35: In invalidloc
RTExceptions.mod:649:35:invalid address referenced
executed
/var/gcc/regression/master/11.4-gcc/build/gcc/testsuite/gm2/readreal.x0 with
result fail

This seems to be the same failure in all affected cases.

However, when I compile that testcase manually, the exception is
different:

enter a real number: EXCEPTIONS.mod:65:56: In RAISE
EXCEPTIONS.mod:65:56:IOChan: ChanId specified is invalid
[New Thread 1 (LWP 1)]

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfec18838 in __lwp_sigqueue () from /lib/libc.so.1
1: x/i $pc
=> 0xfec18838 <__lwp_sigqueue+8>:   
bcc,a   %icc, 0xfec18848 <__lwp_sigqueue+24>
   0xfec1883c <__lwp_sigqueue+12>:  mov  %g0, %o0
(gdb) bt
#0  0xfec18838 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfeb56a54 in raise () from /lib/libc.so.1
#2  0xfeb27fe0 in abort () from /lib/libc.so.1
#3  0x0002bb60 in m2pim_M2RTS_HALT (exitcode=-1)
at
/vol/gcc/src/hg/master/local/libgm2/libm2pim/../../gcc/m2/gm2-libs/M2RTS.mod:238
#4  0x00037284 in m2pim_RTExceptions_DefaultErrorCatch ()
at
/vol/gcc/s

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

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

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

--- Comment #18 from Jakub Jelinek  ---
I'd like to understand what is the difference between those .DEFERRED_INITs on
unused vars and normal vars.
If I try
typedef int V __attribute__((vector_size (16)));

__attribute__((noipa)) void
foo ()
{
  V v;
  V *p = &v;
  asm ("" : "+r" (p));
  *p = (V) {};
  asm volatile ("" : : : "r12", "r13", "r14");
}

__attribute__((noipa)) void
bar ()
{
  V v;
  V *p = &v;
  asm ("" : "+r" (p));
  *p = (V) {};
  asm volatile ("" : : : "r12", "r13");
}

int
main ()
{
  foo ();
  bar ();
}

with either -O2 -mavx or -O2 -mavx -fno-omit-frame-pointer, then everything is
properly aligned.

[Bug tree-optimization/109138] [10/11/12/13 Regression] wrong code at -O1 and above on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.5
Summary|wrong code at -O1 and above |[10/11/12/13 Regression]
   |on x86_64-linux-gnu |wrong code at -O1 and above
   ||on x86_64-linux-gnu

--- Comment #4 from Jakub Jelinek  ---
Started with r5-4606-g956623c1378de3c48e77b

[Bug other/109086] __builtin_strcmp generates wrong code if expand_simple_binop assigns new pseudo-register for result

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:45641f3a99281bb0a429649741a29c2aace4c63e

commit r13-6690-g45641f3a99281bb0a429649741a29c2aace4c63e
Author: Xi Ruoyao 
Date:   Wed Mar 15 15:34:52 2023 +0800

builtins: Move the character difference into result instead of reassigning
result [PR109086]

expand_simple_binop() is allowed to allocate a new pseudo-register and
return it, instead of forcing the result into the provided
pseudo-register.  This can cause a problem when we expand the unrolled
loop for __builtin_strcmp: the compiler always generates code for all n
iterations of the loop, so "result" will be an alias of the
pseudo-register allocated and used in the last iteration; but at runtime
the loop can break early, causing this pseudo-register uninitialized.

Emit a move instruction in the iteration to force the difference into
one register which has been allocated before the loop, to avoid this
issue.

gcc/ChangeLog:

PR other/109086
* builtins.cc (inline_string_cmp): Force the character
difference into "result" pseudo-register, instead of reassign
the pseudo-register.

[Bug other/109086] __builtin_strcmp generates wrong code if expand_simple_binop assigns new pseudo-register for result

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #13 from Xi Ruoyao  ---
Pushed the patch with a comment explaining the if (result != diff) block.

[Bug tree-optimization/109139] [13 Regression] ice in make_decl_rtl, at varasm.cc:1442

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

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

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

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

commit r13-6691-g0fc541efc340535d212cd685176bd9592905de8a
Author: Richard Biener 
Date:   Wed Mar 15 09:47:18 2023 +0100

tree-optimization/109139 - fix .DEFERRED_INIT removal

The following make sure to strip MEMs when looking for unused
decls on the LHS of .DEFERRED_INIT.

PR tree-optimization/109139
* tree-ssa-live.cc (remove_unused_locals): Look at the
base address for unused decls on the LHS of .DEFERRED_INIT.

* gcc.dg/torture/pr109139.c: New testcase.

[Bug tree-optimization/109139] [13 Regression] ice in make_decl_rtl, at varasm.cc:1442

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/109138] [10/11/12/13 Regression] wrong code at -O1 and above on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
I don't think this has anything to do with reassoc though.
The testcase looks incorrect to me.
Because d is defined in the scope of the outer loop's body, for b == 0 a is -1U
and
so the inner loop does nothing, d is set to 1, a is set to 0 and then d goes
out of scope.
Then for b = 1, a scope with d variable is entered but the variable is again
uninitialized, a <= 0 is true, and we use the uninitialized variable.
fixup_cfg1 dump shows this nicely with the clobber in there:

   :
  b = 0;
  goto ; [INV]

   :
  d.0_1 = d;
  if (d.0_1 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
L:
  a.1_2 = a;
  if (a.1_2 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  d = 1;
  a.2_3 = a;
  _4 = a.2_3 + 1;
  a = _4;
  d = {CLOBBER(eol)};
  b = b + 1;

   :
  if (b <= 1)
goto ; [INV]
  else
goto ; [INV]

   :
  D.2753 = 0;
  return D.2753;

[Bug bootstrap/107299] [13 regression] ICE in stage 1 after r13-3307-g8efc38347a7444

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
So the build issue is fixed.  If there's another issue please open a new
bugreport for it.

[Bug target/109140] New: ICE when building qemu (qemu-user, MIPS component) on sparc64-unknown-linux-gnu with -march=niagara4

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 109140
   Summary: ICE when building qemu (qemu-user, MIPS component) on
sparc64-unknown-linux-gnu with -march=niagara4
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
  Target Milestone: ---
  Host: sparc64-unknown-linux-gnu
Target: sparc64-unknown-linux-gnu
 Build: sparc64-unknown-linux-gnu

Hit when building QEMU 7.2.0's qemu-user component for mips on sparc64. This
one is reproducible with cross.

It needs -O2 -mcpu=niagara4 at least and -O2 -march=ultrasparc is fine.

```
$ sparc64-unknown-linux-gnu-gcc target_mips_tcg_lmmi_helper.c.i -O2
-mcpu=niagara4 -c
../target/mips/tcg/lmmi_helper.c: In function ‘helper_pcmpgtb’:
../target/mips/tcg/lmmi_helper.c:554:1: error: unrecognizable insn:
(insn 9 8 10 2 (set (reg:DI 118)
(unspec:DI [
(ltu:V8QI (subreg:V8QI (reg/v:DI 115 [ ft ]) 0)
(subreg:V8QI (reg/v:DI 114 [ fs ]) 0))
] UNSPEC_FUCMP)) "../target/mips/tcg/lmmi_helper.c":551:18 -1
 (nil))
during RTL pass: vregs
../target/mips/tcg/lmmi_helper.c:554:1: internal compiler error: in
extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

$ sparc64-unknown-linux-gnu-gcc --version
sparc64-unknown-linux-gnu-gcc (Gentoo Hardened 12.2.1_p20230304 p13) 12.2.1
20230304
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
```

Attached the preprocessed source, not yet reduced or bisected, but I'll be
doing both later.

[Bug target/109140] ICE when building qemu (qemu-user, MIPS component) on sparc64-unknown-linux-gnu with -march=niagara4

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
Created attachment 54669
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54669&action=edit
target_mips_tcg_lmmi_helper.c.i.xz

[Bug target/109140] ICE when building qemu (qemu-user, MIPS component) on sparc64-unknown-linux-gnu with -march=niagara4

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #2 from Sam James  ---
Created attachment 54670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54670&action=edit
reduced.i

Attached reduced version.

```
# sparc64-unknown-linux-gnu-gcc reduced.i -O2 -mcpu=niagara4 -c
reduced.i:3:1: warning: no semicolon at end of struct or union
3 | } LMIValue;
  | ^
reduced.i:6:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
6 | helper_pcmpgtb() {
  | ^~
reduced.i: In function ‘helper_pcmpgtb’:
reduced.i:10:1: error: unrecognizable insn:
   10 | }
  | ^
(insn 24 23 25 2 (set (reg:DI 130)
(unspec:DI [
(gtu:V8QI (reg:V8QI 125)
(reg:V8QI 119))
] UNSPEC_FUCMP)) "reduced.i":9:55 -1
 (nil))
during RTL pass: vregs
reduced.i:10:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
```

[Bug target/109140] ICE when building qemu (qemu-user, MIPS component) on sparc64-unknown-linux-gnu with -march=niagara4

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #3 from Sam James  ---
I'll bisect later but someone is free to beat me if they want. I think 11 was
fine, but need to check.

[Bug tree-optimization/106904] [12 Regression] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure

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

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

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

https://gcc.gnu.org/g:97d599e09b0fd389a7cbac8867e56977ec97900f

commit r12-9254-g97d599e09b0fd389a7cbac8867e56977ec97900f
Author: Richard Biener 
Date:   Wed Dec 7 14:42:24 2022 +0100

tree-optimization/106904 - bogus -Wstringopt-overflow with vectors

The following avoids CSE of &ps->wp to &ps->wp.hwnd confusing
-Wstringopt-overflow by making sure to produce addresses to the
biggest container from vectorization.  For this I introduce
strip_zero_offset_components which turns &ps->wp.hwnd into
&(*ps) and use that to base the vector data references on.
That will also work for addresses with variable components,
alternatively emitting pointer arithmetic via calling
get_inner_reference and gimplifying that would be possible
but likely more intrusive.

This is by no means a complete fix for all of those issues
(avoiding ADDR_EXPRs in favor of pointer arithmetic might be).
Other passes will have similar issues.

In theory that might now cause false negatives.

PR tree-optimization/106904
* tree.h (strip_zero_offset_components): Declare.
* tree.cc (strip_zero_offset_components): Define.
* tree-vect-data-refs.cc (vect_create_addr_base_for_vector_ref):
Strip zero offset components before building the address.

* gcc.dg/Wstringop-overflow-pr106904.c: New testcase.

(cherry picked from commit f8d136e50e6f82cba793483d910a2b2643108508)

[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors

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

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

--- Comment #3 from Richard Biener  ---
The diagnostic is correct I think - I wonder why I do not see it on
x86_64-linux.  It probably depends on the glibc version (I have 2.31)

[Bug tree-optimization/107451] [11/12 Regression] Segmentation fault with vectorized code since r11-6434

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

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

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

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

commit r12-9255-gc722c6b061a5e909267eae53ffe5910fbe0a7d5e
Author: Richard Biener 
Date:   Thu Dec 22 09:36:17 2022 +0100

tree-optimization/107451 - SLP load vectorization issue

When vectorizing SLP loads with permutations we can access excess
elements when the load vector type is bigger than the group size
and the vectorization factor covers less groups than necessary
to fill it.  Since we know the code will only access up to
group_size * VF elements in the unpermuted vector we can simply
fill the rest of the vector with whatever we want.  For simplicity
this patch chooses to repeat the last group.

PR tree-optimization/107451
* tree-vect-stmts.cc (vectorizable_load): Avoid loading
SLP group members from group numbers in excess of the
vectorization factor.

* gcc.dg/torture/pr107451.c: New testcase.

(cherry picked from commit 7b2cf5041460859ca4f58e5da1308b7ef9129d8b)

[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

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

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

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

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

commit r12-9256-gb955080a5ab8690902f7cc99a770f9c3da171d6f
Author: Richard Biener 
Date:   Tue Jan 31 15:45:43 2023 +0100

middle-end/108500 - replace recursive domtree DFS traversal

The following replaces the recursive DFS traversal of the dominator
tree in assign_dfs_numbers with a tree traversal using the fact
that we have recorded parents.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

This makes r13-5325 somewhat obsolete, though not computing the
DFS numbers at all is beneficial in the cases where we perform
immediate CFG manipulations.

OK for trunk and later branch(es)?

Thanks,
Richard.

PR middle-end/108500
* dominance.cc (assign_dfs_numbers): Replace recursive DFS
with tree traversal algorithm.

(cherry picked from commit 97258480438db77e52f4b3947fa2c075b09d3fe1)

[Bug tree-optimization/108724] [11/12 Regression] Poor codegen when summing two arrays without AVX or SSE

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

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

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

https://gcc.gnu.org/g:21e7145aaf582c263e69a3ee05dfa9d42bdbd1aa

commit r12-9258-g21e7145aaf582c263e69a3ee05dfa9d42bdbd1aa
Author: Richard Biener 
Date:   Fri Feb 10 11:07:30 2023 +0100

tree-optimization/108724 - vectorized code getting piecewise expanded

This fixes an oversight to when removing the hard limits on using
generic vectors for the vectorizer to enable both SLP and BB
vectorization to use those.  The vectorizer relies on vector lowering
to expand plus, minus and negate to bit operations but vector
lowering has a hard limit on the minimum number of elements per
work item.  Vectorizer costs for the testcase at hand work out
to vectorize a loop with just two work items per vector and that
causes element wise expansion and spilling.

The fix for now is to re-instantiate the hard limit, matching what
vector lowering does.  For the future the way to go is to emit the
lowered sequence directly from the vectorizer instead.

PR tree-optimization/108724
* tree-vect-stmts.cc (vectorizable_operation): Avoid
using word_mode vectors when vector lowering will
decompose them to elementwise operations.

* gcc.target/i386/pr108724.c: New testcase.

(cherry picked from commit dc87e1391c55c666c7ff39d4f0dea87666f25468)

[Bug tree-optimization/108821] [11/12 Regression] LIM reissuing a violatile store when it cannot/should not

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

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

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

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

commit r12-9261-gdbbbaed64f39aae57f5f167174121c1be9d18282
Author: Richard Biener 
Date:   Fri Feb 17 12:36:44 2023 +0100

tree-optimization/108821 - store motion and volatiles

The following fixes store motion to not re-issue volatile stores
to preserve TBAA behavior since that will result in the number
of volatile accesses changing.

PR tree-optimization/108821
* tree-ssa-loop-im.cc (sm_seq_valid_bb): We can also not
move volatile accesses.

* gcc.dg/tree-ssa/ssa-lim-24.c: New testcase.

(cherry picked from commit 4c4f0f7acd6b96ee744ef598cbea5c7046a33654)

[Bug target/108950] [11/12 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr'; error: type mismatch in 'widen_sum_expr') since r11-418-g584

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

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

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

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

commit r12-9262-gf4e4108dd005084fc1c88bba14fda6b200e70daa
Author: Richard Biener 
Date:   Tue Feb 28 15:34:27 2023 +0100

tree-optimization/108950 - widen-sum reduction ICE

When we end up with a widen-sum with an invariant smaller operand
the reduction code uses a wrong vector type for it, causing
IL checking ICEs.  The following fixes that and the inefficiency
of using a widen-sum with a widenend invariant operand as well
by actually performing the check the following comment wants.

PR tree-optimization/108950
* tree-vect-patterns.cc (vect_recog_widen_sum_pattern):
Check oprnd0 is defined in the loop.
* tree-vect-loop.cc (vectorizable_reduction): Record all
operands vector types, compute that of invariants and
properly update their SLP nodes.

* gcc.dg/vect/pr108950.c: New testcase.

(cherry picked from commit e3837b6f6c28a1d2cea3a69efbda795ea3fb8816)

[Bug tree-optimization/108625] [11/12 Regression] forwprop introduces new UB

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

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

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

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

commit r12-9257-ge19e9c36abc7fff9c628cf744e55e4c0e686ea53
Author: Richard Biener 
Date:   Thu Feb 2 11:09:26 2023 +0100

middle-end/108625 - wrong folding due to misinterpreted !

The following fixes a problem with ! handling in genmatch which isn't
conservative enough when intermediate simplifications push to the
sequence but the final operation appears to just pick an existing
(but in this case newly defined in the sequence) operand.  The easiest
fix is to disallow adding to the sequence when processing !.

PR middle-end/108625
* genmatch.cc (expr::gen_transform): Also disallow resimplification
from pushing to lseq with force_leaf.
(dt_simplify::gen_1): Likewise.

* gcc.dg/pr108625.c: New testcase.

(cherry picked from commit 605d1297b91c2c7c23ccfe669e66dda5791d1f55)

[Bug tree-optimization/108793] [12 Regression] ICE: verify_gimple failed since r12-3136-g3673dcf6d6baeb67

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

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

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

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

commit r12-9259-g0a3642dde799ee2be9f2b60ec361191176390005
Author: Richard Biener 
Date:   Mon Feb 20 12:58:50 2023 +0100

tree-optimization/108793 - niter compute type mismatch

When computing the number of iterations until wrap types are mixed up,
eventually leading to checking ICEs with a pointer bitwise inversion.
The following uses niter_type for the calculation.

PR tree-optimization/108793
* tree-ssa-loop-niter.cc (number_of_iterations_until_wrap):
Use convert operands to niter_type when computing num.

* gcc.dg/torture/pr108793.c: New testcase.

(cherry picked from commit a7e706df2280de4a42f68b6c44401e4348d3593c)

[Bug tree-optimization/108430] [12 Regression] Wrong code with -msve-vector-bits=512 since r13-707-g68e0063397

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
  Known to fail|13.0|
   Target Milestone|13.0|12.3
Summary|[13 Regression] Wrong code  |[12 Regression] Wrong code
   |with -msve-vector-bits=512  |with -msve-vector-bits=512
   |since r13-707-g68e0063397   |since r13-707-g68e0063397
   Priority|P1  |P2

[Bug tree-optimization/108816] [12 Regression] ICE in operator[], at vec.h:889

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

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

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

https://gcc.gnu.org/g:02ff8c8ebcb7f9b0885946d17ff12523e7522b71

commit r12-9260-g02ff8c8ebcb7f9b0885946d17ff12523e7522b71
Author: Richard Biener 
Date:   Mon Feb 20 10:59:15 2023 +0100

tree-optimization/108816 - vect versioning check split confusion

The split of the versioning condition assumes the definition is
in the condition block which is ensured by the versioning code.
But that only works when we actually have to insert any statements
for the versioning condition.  The following adjusts the guard
accordingly and asserts this condition.

PR tree-optimization/108816
* tree-vect-loop-manip.cc (vect_loop_versioning): Adjust
versioning condition split prerequesite, assert required
invariant.

* gcc.dg/torture/pr108816.c: New testcase.

(cherry picked from commit 63471c5008819bbf6ec32a6f4d8701fe57b96fa9)

[Bug testsuite/108898] [13 Regression] Test introduced by r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d failed on i386

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-15
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
It looks like a mismatch of epilogue vectorization expectation?  Adding
--param vect-epilogues-nomask=0 to all gets

FAIL: gcc.dg/vect/vect-simd-clone-16b.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-16e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-17b.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-17e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-18b.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-18e.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 3

and dropping yields

FAIL: gcc.dg/vect/vect-simd-clone-16.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-16f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r]
[^\\n]* = foo\\.simdclone" 2

and the logs show we see 3 all the times.  If you tried to match what
targets do automatically that's a lost cause - I suggest to disable
epilog vectorization instead in all testcases.

[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

   Target Milestone|--- |13.0
Version|12.2.1  |13.0

[Bug c++/108563] [10/11/12 Regression] [concepts] ICE (segfault) when requiring sizeof(variable_tempalate_v) since r10-7441-ga7ea3d2ced786c45

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
   |[concepts] ICE (segfault)   |[concepts] ICE (segfault)
   |when requiring  |when requiring
   |sizeof(variable_tempalate_v |sizeof(variable_tempalate_v
   |) since   |) since
   |r10-7441-ga7ea3d2ced786c45  |r10-7441-ga7ea3d2ced786c45
  Known to work||13.0
   Target Milestone|--- |10.5
   Priority|P3  |P2

[Bug c++/108566] [11/12 Regression] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name with anonymous struct inside an anonymous

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
   Priority|P3  |P2
   Target Milestone|--- |11.4

[Bug target/108807] [11/12/13 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after r11-6857-gb29225597584b6 on power 9 BE

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.4
   Keywords||wrong-code
   Priority|P3  |P2

[Bug target/109069] [12/13 Regression] Vector truncation test program produces incorrect result since r12-6537-g080a06fcb076b3

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |12.3

[Bug tree-optimization/108500] [11 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.2.1
Summary|[11/12 Regression] -O   |[11 Regression] -O
   |-finline-small-functions|-finline-small-functions
   |results in "internal|results in "internal
   |compiler error: |compiler error:
   |Segmentation fault" on a|Segmentation fault" on a
   |very large program (700k|very large program (700k
   |function calls) |function calls)
   Priority|P3  |P2
  Known to fail|12.2.1  |12.2.0

[Bug tree-optimization/108793] [12 Regression] ICE: verify_gimple failed since r12-3136-g3673dcf6d6baeb67

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.2.1
  Known to fail||12.2.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/108816] [12 Regression] ICE in operator[], at vec.h:889

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||12.2.1

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

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

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

Bug 106904 Summary: [12 Regression] Incorrect -Wstringop-overflow with partial 
memcpy() into a nested structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106904

   What|Removed |Added

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

[Bug tree-optimization/106904] [12 Regression] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||12.2.0
  Known to work||12.2.1

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

[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

  Known to work||11.3.1
  Known to fail||12.2.1

--- Comment #4 from Sam James  ---
so far:
11.3.1 20230303 is OK.
12.2.1 20230304 isn't.

[Bug tree-optimization/109141] New: failure to diagnose -Wuse-after-free early

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

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

Bug ID: 109141
   Summary: failure to diagnose -Wuse-after-free early
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc.dg/Wuse-after-free-2.c contains

int warn_cond_loop (char *p)
{
  char *q = p;

  /*  -fno-tree-loop-distribute-patterns ensures this does not get converted
  into rawmemchr (making q and p unrelated).  Also, -fno-ivopts is required
  for some targets, to not lose track of the pointer.  */
  while (*q)
++q;

  free (p); // { dg-message "call to 'free'" }
  return *q;// { dg-warning "pointer 'q' used after 'free'" }
}

which only is diagnosed in the late access warning pass.  If you enable
-Wuse-after-free in the early passes it isn't diagnosed even though the
IL isn't very different.  This looks like an issue in handling PHIs
in pointer query?

[Bug c++/109142] New: auto tmp=*(data_type*)&v: expected primary-expression before ')' token

[steve_green at qq dot com via Gcc-bugs]

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

Bug ID: 109142
   Summary: auto tmp=*(data_type*)&v: expected
primary-expression before ')' token
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steve_green at qq dot com
  Target Milestone: ---

code that trigger errors:
https://github.com/ELC-lang/ELC/blob/74495c6e72bc61566d29442ea469e02b4fe223f1/parts/header_file/files/elc/random
The specific location where the error was triggered:
https://github.com/ELC-lang/ELC/blob/74495c6e72bc61566d29442ea469e02b4fe223f1/parts/_share/basic_environment/_body.hpp#L427


```text
C:\Users\steve02081504\Documents\workstation\ELC_workdirs\ELC>x86_64-w64-mingw32-g++
-v
Using built-in specs.
COLLECT_GCC=E:\msys\mingw64\bin\x86_64-w64-mingw32-g++.exe
COLLECT_LTO_WRAPPER=E:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-12.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib
--enable-bootstrap --enable-checking=release --with-arch=nocona
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev10, Built by MSYS2 project'
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++
--with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Rev10, Built by MSYS2 project)
C:\Users\steve02081504\Documents\workstation\ELC_workdirs\ELC>x86_64-w64-mingw32-g++
-x c++ -std=c++23 .\parts\header_file\files\elc\random
In file included from
.\parts\header_file\files\elc\_files/base_defs/_body.hpp:33,
 from .\parts\header_file\files\elc\base_defs:50,
 from .\parts\header_file\files\elc\random:33:
.\parts\header_file\files\elc\_files/base_defs/../../../../../_share/basic_environment/_body.hpp:
In function 'constexpr auto elc::defs::basic_environment::get_precision(T)':
.\parts\header_file\files\elc\_files/base_defs/../../../../../_share/basic_environment/_body.hpp:427:49:
error: expected primary-expression before ')' token
  427 | auto tmp=*(data_type*)&v;
  | ^
.\parts\header_file\files\elc\_files/base_defs/../../../../../_share/basic_environment/_body.hpp:
In function 'constexpr auto
elc::defs::basic_environment::base_get_exponent(T)':
.\parts\header_file\files\elc\_files/base_defs/../../../../../_share/basic_environment/_body.hpp:442:49:
error: expected primary-expression before ')' token
  442 | auto tmp=*(data_type*)&v;
  | ^
```

[Bug tree-optimization/109141] failure to diagnose -Wuse-after-free early

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-15
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Eh, and we diagnose late because of a bug in pass_waccess::use_after_inval_p.
We have

 [local count: 118111600]:
# q_12 = PHI 
free (p_4(D));

late but early the PHI is in an earlier block.  With the above we run into

  if (bitmap_set_bit (m_bb_uids_set, inval_bb->index))
/* The first time this basic block is visited assign increasing ids
   to consecutive statements in it.  Use the ids to determine which
   precedes which.  This avoids the linear traversal on subsequent
   visits to the same block.  */
for (auto si = gsi_start_bb (inval_bb); !gsi_end_p (si);
 gsi_next_nondebug (&si)) 
  {
gimple *stmt = gsi_stmt (si);
unsigned uid = inc_gimple_stmt_max_uid (m_func);
gimple_set_uid (stmt, uid);
  }

  return gimple_uid (inval_stmt) < gimple_uid (use_stmt);

but we never set UIDs for PHIs so the answer here is random.

[Bug testsuite/108898] [13 Regression] Test introduced by r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d failed on i386

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

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

--- Comment #4 from Andrew Stubbs  ---
I did not know there was a way to do that! I'll add this to my to-do list.

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
What happens is that finish_template_type is called once from unused_function
with
is_member_function_pointer TEMPLATE_DECL as name and args
 

arg:0 
arg:1 >
pr109083.ii:86:64 start: pr109083.ii:86:64 finish:
pr109083.ii:86:66>
pr109083.ii:86:60 start: pr109083.ii:86:60 finish:
pr109083.ii:86:66>>>
(in my case of reduced preprocessed source), calls lookup_template_class, finds
nothing in
9943  entry = type_specializations->find_with_hash (&elt, hash);
and so creates
10082 t = make_class_type (TREE_CODE (template_type));
etc.
Next time finish_template_type is called from fail_here with the same
TEMPLATE_DECL as name and args
 

arg:0 
arg:1 >
pr109083.ii:92:64 start: pr109083.ii:92:64 finish:
pr109083.ii:92:66>
pr109083.ii:92:60 start: pr109083.ii:92:60 finish:
pr109083.ii:92:66>>>
but this type the previously created specialization from unused_function is
returned.

So, shall template_args_equal or whatever it calls be changed so that it
doesn't consider these to be equal?  If so, what compilation memory effects
will it have?

[Bug tree-optimization/109138] [10/11/12/13 Regression] wrong code at -O1 and above on x86_64-linux-gnu

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

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

--- Comment #6 from Zhendong Su  ---
Oh, good catch, Jakub! And sorry for the noise.

[Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface

[jeff.science at gmail dot com via Gcc-bugs]

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

Jeff Hammond  changed:

   What|Removed |Added

 CC||jeff.science at gmail dot com

--- Comment #8 from Jeff Hammond  ---
For what it's worth, ISO/IEC DIS 1539-1:2022 (E) now contains the following:

All standard procedures in the intrinsic module ISO_C_BINDING, other than
C_F_POINTER and C_F_PROCPOINTER, are now pure.

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #3 from Jakub Jelinek  ---
I think this started with r0-116872-gf330f5991ef0182d59ab.

[Bug target/108933] [10/11/12/13 Regression] Missing bswap detection

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
As mentioned in the other PR, this isn't a bswap.  If the bswap pass should
optimize this, there would need to be a new optab for this and corresponding
internal function,
which bswap patch could use if the optab is defined.

[Bug c++/109142] auto tmp=*(data_type*)&v: expected primary-expression before ')' token

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
As requested when you created the bug, please read https://gcc.gnu.org/bugs/
and provide the preprocessed source, not a URL.

[Bug target/107453] [13 Regression] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #9 from Xi Ruoyao  ---
Confirm fixed for LoongArch.

[Bug tree-optimization/109143] New: PTA compile-time hog with many calls

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

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

Bug ID: 109143
   Summary: PTA compile-time hog with many calls
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Here's another testcase that made me produce r13-6584-g413ec1d12c50f8 but which
is still slow in PTA.

[Bug tree-optimization/109143] PTA compile-time hog with many calls

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2023-03-15

--- Comment #1 from Richard Biener  ---
Created attachment 54671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54671&action=edit
unincluded preprocessed source

Here's the testcase unincluded, it can at least build with GCC 12 and 13.

The main issue is the ESCAPED set leaking into many sets, but not directly
but rather sets getting bigger and eventually also get ESCAPED but common
members are not pruned, so ESCAPED isn't optimally used as representative
for its contents.

GCC 12.2.1 shows

 tree PTA   : 227.39 ( 93%)   0.40 ( 23%) 227.78 ( 92%)
 7617k (  1%)
 TOTAL  : 245.51  1.72247.33   
 1128M

while recent trunk is improved to around 70s for tree PTA.  Forcefully
pruning ESCAPED bits from sets containing ESCAPED gets it down to 3s.

[Bug c++/108179] [11/12/13 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

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

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

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

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

commit r13-6693-g3ea64aad06a2b32739028bae03b9b9a5691d2d30
Author: Jason Merrill 
Date:   Fri Mar 10 14:55:27 2023 -0500

c++: passing one ttp to another [PR108179]

I kept trying to improve our choice of how many levels of outer_args to
add,
when really the problem was that outer_args are for PARM and for this
reverse deduction we should be adding the outer arguments for ARG.

I spent quite a while trying to get DECL_CONTEXT set consistently on
template template parameters that have gone through
reduce_template_parm_level before I realized I could just use
current_scope().

PR c++/108179
PR c++/104107
PR c++/95036

gcc/cp/ChangeLog:

* pt.cc (coerce_template_template_parms): Use args from
DECL_CONTEXT (arg_tmpl) instead of outer_args.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp35.C: New test.

[Bug c++/104107] [10 Regression] parsing crashes on class template instantiation since r9-6853-g17838af989014f5e

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

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

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

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

commit r13-6693-g3ea64aad06a2b32739028bae03b9b9a5691d2d30
Author: Jason Merrill 
Date:   Fri Mar 10 14:55:27 2023 -0500

c++: passing one ttp to another [PR108179]

I kept trying to improve our choice of how many levels of outer_args to
add,
when really the problem was that outer_args are for PARM and for this
reverse deduction we should be adding the outer arguments for ARG.

I spent quite a while trying to get DECL_CONTEXT set consistently on
template template parameters that have gone through
reduce_template_parm_level before I realized I could just use
current_scope().

PR c++/108179
PR c++/104107
PR c++/95036

gcc/cp/ChangeLog:

* pt.cc (coerce_template_template_parms): Use args from
DECL_CONTEXT (arg_tmpl) instead of outer_args.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp35.C: New test.

[Bug c++/95036] [10 Regression] ICE with variadic template template parameters

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

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

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

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

commit r13-6693-g3ea64aad06a2b32739028bae03b9b9a5691d2d30
Author: Jason Merrill 
Date:   Fri Mar 10 14:55:27 2023 -0500

c++: passing one ttp to another [PR108179]

I kept trying to improve our choice of how many levels of outer_args to
add,
when really the problem was that outer_args are for PARM and for this
reverse deduction we should be adding the outer arguments for ARG.

I spent quite a while trying to get DECL_CONTEXT set consistently on
template template parameters that have gone through
reduce_template_parm_level before I realized I could just use
current_scope().

PR c++/108179
PR c++/104107
PR c++/95036

gcc/cp/ChangeLog:

* pt.cc (coerce_template_template_parms): Use args from
DECL_CONTEXT (arg_tmpl) instead of outer_args.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp35.C: New test.

[Bug c++/58538] Injected class-name treated as type-name instead of template-name when used as a template-argument for a template template-parameter

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

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

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

https://gcc.gnu.org/g:40c1352c5a4530350012d6a922435cf491663daa

commit r13-6694-g40c1352c5a4530350012d6a922435cf491663daa
Author: Jason Merrill 
Date:   Tue Mar 14 23:16:21 2023 -0400

c++: injected class name as default ttp arg [PR58538]

This function needs to handle this case like convert_template_argument.

PR c++/58538

gcc/cp/ChangeLog:

* semantics.cc (check_template_template_default_arg): Check
maybe_get_template_decl_from_type_decl.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp7.C: Remove expected error.

[Bug c++/108179] [11/12/13 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

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

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

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

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

commit r13-6692-g5ccbf162511b896672a72934c3cafd37a42d6438
Author: Jason Merrill 
Date:   Tue Mar 14 22:07:45 2023 -0400

c++: coerce_template_template_parms interface tweak

This should have no semantic effect, but is a prerequisite for the PR108179
fix to follow.

PR c++/108179

gcc/cp/ChangeLog:

* pt.cc (coerce_template_template_parms): Take the arg and parm
templates directly.
(coerce_template_template_parm): Adjust.
(template_template_parm_bindings_ok_p): Adjust.
(convert_template_argument): Adjust.

[Bug c++/108179] [11/12 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[11/12/13 regression] ICE   |[11/12 regression] ICE
   |related to template |related to template
   |template parameters in  |template parameters in
   |tsubst, at cp/pt.cc:15782   |tsubst, at cp/pt.cc:15782

--- Comment #5 from Jason Merrill  ---
Fixed for 13 so far.

[Bug c++/108179] [11/12 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

[s at stu dot scot via Gcc-bugs]

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

--- Comment #6 from stu t  ---
Thank you for looking into this! :)

[Bug target/109130] 464.h264ref regressed by 6.5% on a Neoverse-N1 CPU with PGO, LTO, -Ofast and -march=native

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

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

--- Comment #1 from Tamar Christina  ---
I can't reproduce that. on a Neoverse-N1 I see between those two commits:

./bench-compare.sh 2fc55f51f99 bad177e8487
A   1457 files
D   0 files
M   0 files
Extracted 'loose/2fc55f51f99:2fc55f51f99'
A   1457 files
D   0 files
M   0 files
Extracted 'loose/bad177e8487:bad177e8487'

difference: 0.083458946886789971215830257097%

Compiled with -Ofast -march=native -g -flto=auto and PGO enabled. as extracted
from
https://lnt.opensuse.org/db_default/v4/SPEC/34263?show_stddev=yes&show_all=yes&show_all_samples=yes&num_comparison_runs=0&test_filter=&test_min_value_filter=&aggregation_fn=min&MW_confidence_lv=0.05&compare_to=34183&baseline=23835&submit=Update

our non PGO runs also didn't see a regression.

[Bug c++/109142] auto tmp=*(data_type*)&v: expected primary-expression before ')' token

[steve_green at qq dot com via Gcc-bugs]

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

--- Comment #2 from steve02081504  ---
Created attachment 54672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54672&action=edit
cpp file

Here's the pre-processed file you want,hope it helps

[Bug c++/68608] [concepts] ICE with explicit class instantiation

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
dup

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

[Bug c++/67491] [meta-bug] concepts issues

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

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

Bug 68608 Summary: [concepts] ICE with explicit class instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68608

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/96164] Constraints and explicit template instantiation

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ryan.burn at gmail dot com

--- Comment #8 from Patrick Palka  ---
*** Bug 68608 has been marked as a duplicate of this bug. ***

[Bug c/109113] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Started with my r8-6028-gb4923738ef57a441f6f9
struct A { int a; };
struct B { int b; struct A c[]; };
struct C { int d; struct B e[]; };
const struct B f = { .c = { 1 } };
struct C g = { .e = { f } };
struct C h = { .e = { f, f } };

The question is if we want to accept the g initializer and reject just the h
one, or reject both.  g compiles fine though and could be useful...

[Bug modula2/109125] [13 regression] SIGBUS in m2pim_ldtoa_ldtoa

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

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

--- Comment #5 from Gaius Mulley  ---
readreal.mod requires the input file testnumber to be in the same directory as
the executable invocation.

Or manually create a text file containing:

cat << EOF > testnumber
12.3456
EOF

[Bug d/109144] New: d: Closure fields don't get same alignment as local variable

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

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

Bug ID: 109144
   Summary: d: Closure fields don't get same alignment as local
variable
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

Between the variable declaration, and building its associated field in a
closure, the decl alignment gets lost, so this fails.

---
void main()
{
align(128) byte var;
assert((cast(size_t) &var) % 128 == 0);
var = 73;
assert((() => var)() == 73);
}

[Bug modula2/109125] [13 regression] SIGBUS in m2pim_ldtoa_ldtoa

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Gaius Mulley  ---
> readreal.mod requires the input file testnumber to be in the same directory as
> the executable invocation.
>
> Or manually create a text file containing:
>
> cat << EOF > testnumber
> 12.3456
> EOF

Got it, thanks.  It's another unaligned access:

Thread 2 received signal SIGBUS, Bus error.
[Switching to Thread 1 (LWP 1)]
0x00037a40 in m2pim_dtoa_strtod (s=0x54c90 "12.3456", error=0xffbfe96f)
at /vol/gcc/src/hg/master/local/libgm2/libm2pim/dtoa.cc:124
124 *error = (errno != 0);
1: x/i $pc
=> 0x37a40 :   st  %g2, [ %i1 ]
(gdb) bt
#0  0x00037a40 in m2pim_dtoa_strtod (s=0x54c90 "12.3456", error=0xffbfe96f)
at /vol/gcc/src/hg/master/local/libgm2/libm2pim/dtoa.cc:124
#1  0x000263b0 in m2iso_RealIO_ReadReal (cid=0x594a0, real=@0x4e3a8: 0)
at
/vol/gcc/src/hg/master/local/libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/RealIO.mod:75
#2  0x00021cac in _M2_readreal_init (argc=1, argv=0xffbfebcc, envp=0xffbfebd4)
at
/vol/gcc/src/hg/master/local/gcc/testsuite/gm2/isolib/run/pass/readreal.mod:31
#3  0x0002d560 in m2pim_M2Dependent_ConstructModules (
applicationmodule=, libname=, argc=1, 
argv=0xffbfebcc, envp=0xffbfebd4)
at
/vol/gcc/src/hg/master/local/libgm2/libm2pim/../../gcc/m2/gm2-libs/M2Dependent.mod:813
#4  0x00022660 in _M2_init (argc=1, argv=0xffbfebcc, envp=0xffbfebd4)
at
/vol/gcc/src/hg/master/local/gcc/testsuite/gm2/isolib/run/pass/readreal.mod:18
#5  0x000226d8 in main (argc=1, argv=0xffbfebcc, envp=0xffbfebd4)
at
/vol/gcc/src/hg/master/local/gcc/testsuite/gm2/isolib/run/pass/readreal.mod:18
(gdb) p/x $i1
$1 = 0xffbfe96f

[Bug c/109113] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field, at varasm.cc:5521

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

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

--- Comment #8 from Jakub Jelinek  ---
And C++ ICEs on this starting with r8-4783-gd68ddd2b35078ab61f164b268b
(again, accepts the g case).
C++ used to ICE on
struct C i = { .e = { { .b = 0, .c = { 1 } }, f } };
since that revision but since r8-5342-ga8c55cacaf8fa1e90f9e26c it also rejects
it.

[Bug modula2/109125] [13 regression] SIGBUS in m2pim_ldtoa_ldtoa

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug testsuite/109145] New: new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

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

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

Bug ID: 109145
   Summary: new test case gcc.dg/tree-ssa/forwprop-39.c from
r13-6624-geb337d28c32b1b fails
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:eb337d28c32b1b460cc85b3c00f8418ca535c77b, r13-6624-geb337d28c32b1b

I am seeing this failing only on our older power 7 machines.

make  -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/forwprop-39.c"
FAIL: gcc.dg/tree-ssa/forwprop-39.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/forwprop-39.c scan-tree-dump-not forwprop1 "COMPLEX_EXPR"
FAIL: gcc.dg/tree-ssa/forwprop-39.c scan-tree-dump-not optimized
"REALPART_EXPR"
# of unexpected failures3

commit eb337d28c32b1b460cc85b3c00f8418ca535c77b
Author: Richard Biener 
Date:   Tue Mar 7 11:04:55 2023 +0100

tree-optimization/109046 - re-combine complex loads

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

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

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

--- Comment #4 from Richard Biener  ---
I wonder why we instantiate from unused_function (but don't diagnose) at all?

[Bug target/109072] [12/13 Regression] SLP costs for vec duplicate too high since g:4963079769c99c4073adfd799885410ad484cbbe

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #4 from dave.anglin at bell dot net ---
I currently have 2.36.

[Bug driver/109135] Wrong make utility called with LTO testsuite

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

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

--- Comment #7 from Steve Kargl  ---
On Wed, Mar 15, 2023 at 08:35:41AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
> 
> --- Comment #6 from Richard Biener  ---
> (In reply to Steve Kargl from comment #4)
> > On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot
> > apl.washington.edu wrote:
> > 
> > Looking in obj/gcc/Makefile at line 341 I see the comment
> > 
> > # Make sure the $(MAKE) variable is defined.
> > 
> > followed by no checking to see if MAKE is defined.
> 
> Makefile.in has
> 
> # Make sure the $(MAKE) variable is defined.
> @SET_MAKE@
> 
> configure has
> 
> if eval test \$ac_cv_prog_make_${ac_make}_set = yes; then
>   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
> $as_echo "yes" >&6; }
>   SET_MAKE=
> else
>   { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> $as_echo "no" >&6; }
>   SET_MAKE="MAKE=${MAKE-make}"
> fi
> 
> from AC_PROG_MAKE_SET which seems to check whether make sets $MAKE.
> That appearantly succeeds for you.  Do you "properly" do sth like
> 
> MAKE=gmake ../configure
> 
> so configure sees which make you are using?  I think if your gmake

No. I simply use '../configure ; gmake -j6 bootstrap'.
This has worked for years.  I'm currently using GNU
make 4.3. If MAKE is not being set to gmake, then I
would expect bootstrap to fail. 

I plan to run gmake with debugging output, and need to
check gmake.info to see how to dump the environment
information.

> doesn't set it then even recursive configure invocations from gmake
> will resort to 'make'
> 
> but then I _think_ that gmake itself sets $MAKE (if it was not set?) for
> sub-processes.  But maybe only if it thinks its recursive make?

I suppose I'll start using the 'MAKE=gmake ..' form or some variation
as I use tcsh.

[Bug c++/109083] [10/11/12/13 Regression] Incorrect static_assert shown in diagnostics

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

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

--- Comment #5 from Jakub Jelinek  ---
We don't instantiate in that case, just look up a specialization which might be
or might not be later instantiated (which is when it is diagnosed).
One way to fix this would be to drop locations from the expressions in the
template arguments if we use them from multiple spots.  But that could result
in less accurate diagnostics.

[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-03-15

--- Comment #1 from Richard Biener  ---
Humm, argument passing oddity?  Or probably "old" glibc complex.h header not
using __builtin_complex for CMPLXF (...)?  It seems to pass for me with a
cross and using native x86-64 complex.h headers ...

My complex.h has

#if defined __USE_ISOC11 && __GNUC_PREREQ (4, 7)
/* Macros to expand into expression of specified complex type.  */
# define CMPLX(x, y) __builtin_complex ((double) (x), (double) (y))
# define CMPLXF(x, y) __builtin_complex ((float) (x), (float) (y))
# define CMPLXL(x, y) __builtin_complex ((long double) (x), (long double) (y))
#endif 

can you have a look or at least attach preprocessed source?  Can you
check if changing the testcase to use __builtin_complex (..) fixes it?

[Bug analyzer/105909] RFE: SARIF output could contain metadata about limitations of the analysis

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

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

--- Comment #1 from David Malcolm  ---
Perhaps via 3.58 notification object:
https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317894
which: "describes a condition encountered during the execution of an analysis
tool which is relevant to the operation of the tool itself, as opposed to being
relevant to an artifact being analyzed by the tool."

See "Appendix I. (Informative) Detecting incomplete result sets":
 
https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317946

[Bug testsuite/109146] New: Tail call prevention in frame-address.c is not correct

[david.spickett at linaro dot org via Gcc-bugs]

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

Bug ID: 109146
   Summary: Tail call prevention in frame-address.c is not correct
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.spickett at linaro dot org
  Target Milestone: ---

With recent changes over in clang, it's now able to see through the tail call
prevention used in
https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/gcc.c-torture/execute/frame-address.c.

The fix is pretty simple, `==` instead of `!=` will prevent the tail call.

Briefly, clang is now able to work out that if the called function returns 0,
the caller also returns 0, same for 1. Therefore, you can tail call the callee.

check_fa_work returns 0, 0 != 0 is False, so check_fa_mid returns 0
check_fa_work returns 1, 1 != 0 is True, so check_fa_mid returns 1

As far as I can tell, gcc does not do this, yet:
https://godbolt.org/z/v36zGP7f3

So it's worth fixing before gcc also starts to do this.

[Bug testsuite/109146] Tail call prevention in frame-address.c is not correct

[david.spickett at linaro dot org via Gcc-bugs]

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

--- Comment #1 from David Spickett  ---
Correction. https://godbolt.org/z/fW5nsWE5e shows the issue when "!=" is used,
the previous link used "==" instead.

[Bug c++/109142] auto tmp=*(data_type*)&v: expected primary-expression before ')' token

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #3 from Jonathan Wakely  ---
Thanks

[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #5 from Mikael Pettersson  ---
I can reproduce with a cross to sparc64-linux-gnu hosted on x86_64-linux-gnu.

git bisect between 11.3.0 (good) and 12.2.0 (bad) identified:

2b8453c401b699ed93c085d0413ab4b5030bcdb8 is the first bad commit
commit 2b8453c401b699ed93c085d0413ab4b5030bcdb8
Author: liuhongt 
Date:   Mon Sep 6 13:48:49 2021 +0800

Enable auto-vectorization at O2 with very-cheap cost model.

which tells me the issue is pre-existing.

[Bug target/109140] ICE (during RTL pass: internal compiler error: in extract_insn, at recog.cc:2791) when building qemu on sparc64-unknown-linux-gnu with -march=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Mikael Pettersson  ---
With -O2 -ftree-vectorize -mcpu=niagara4 the ICE reproduces with gcc-10.4.0 but
not with gcc-9.5.0.

[Bug c++/109142] auto tmp=*(data_type*)&v: expected primary-expression before ')' token

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

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

--- Comment #4 from Xi Ruoyao  ---
template 
using data_type = decltype([](){return 1;}());

template 
auto get_precision(T v) {
  auto tmp = *(data_type *)&v;
  return tmp;
}

Clang and MSVC accept this with C++20, though I'm not sure if it's really valid
(I'm not familiar with latest C++ spec development).

[Bug c++/109142] auto tmp=*(data_type*)&v: expected primary-expression before ')' token

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||107430
   Keywords||c++-lambda

--- Comment #5 from Andrew Pinski  ---
We have a few bug reports about lambdas inside a decltype part used in a
template alias; I suspect this is a dup of one of those.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430
[Bug 107430] [meta-bug] lambda in decltype