[Bug target/109026] m32c-elf: ICE while building Modula-2 components

[jbglaw--- via Gcc-bugs]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

Version|hsa |13.0

--- Comment #1 from Jan-Benedict Glaw  ---
Don't know how much effort to put into this. m32c has some very old PRs which
look rather trivial, with no maintainer listed, so it's maybe ... dead already?

[Bug target/109026] New: m32c-elf: ICE while building Modula-2 components

[jbglaw--- via Gcc-bugs]

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

Bug ID: 109026
   Summary: m32c-elf: ICE while building Modula-2 components
   Product: gcc
   Version: hsa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

This sneaked in with the Modula-2 merge:

[all 2023-03-05 01:12:42] test -d
/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/gcc/m2/gm2-libs ||
/bin/bash ../../gcc/gcc/../mkinstalldirs
/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/gcc/m2/gm2-libs
[all 2023-03-05 01:12:42] echo "GM2_FOR_TARGET
/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/ "
[all 2023-03-05 01:12:42] GM2_FOR_TARGET
/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/ 
[all 2023-03-05 01:12:42] echo "GCC_FOR_TARGET
/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/xgcc
-B/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/ "
[all 2023-03-05 01:12:42] GCC_FOR_TARGET
/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/xgcc
-B/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/ 
[all 2023-03-05 01:12:42] /bin/bash ../../gcc/gcc/m2/tools-src/makeSystem -fpim
\
[all 2023-03-05 01:12:42]  ../../gcc/gcc/m2/gm2-libs/SYSTEM.def \
[all 2023-03-05 01:12:42]  ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod \
[all 2023-03-05 01:12:42]  -I../../gcc/gcc/m2/gm2-libs \
[all 2023-03-05 01:12:42] 
"/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/./gcc/ "
/var/lib/laminar/run/gcc-m32c-elf/34/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def
[all 2023-03-05 01:12:43] during RTL pass: pro_and_epilogue
[all 2023-03-05 01:12:43] : In function '_M2_SYSTEM_init':
[all 2023-03-05 01:12:43] : internal compiler error: in
leaf_function_p, at final.cc:4054
[all 2023-03-05 01:12:43] 0x605999 leaf_function_p()
[all 2023-03-05 01:12:43]   ../../gcc/gcc/final.cc:4054
[all 2023-03-05 01:12:43] 0x109cd8c m32c_leaf_function_p
[all 2023-03-05 01:12:43]   ../../gcc/gcc/config/m32c/m32c.cc:4018
[all 2023-03-05 01:12:43] 0x109cd8c m32c_emit_prologue()
[all 2023-03-05 01:12:43]   ../../gcc/gcc/config/m32c/m32c.cc:4072
[all 2023-03-05 01:12:43] 0x14ebbfa gen_prologue()
[all 2023-03-05 01:12:43]   ../../gcc/gcc/config/m32c/prologue.md:26
[all 2023-03-05 01:12:43] 0x1099955 target_gen_prologue
[all 2023-03-05 01:12:43]   ../../gcc/gcc/config/m32c/blkmov.md:359
[all 2023-03-05 01:12:43] 0xa3c9b7 make_prologue_seq
[all 2023-03-05 01:12:43]   ../../gcc/gcc/function.cc:5841
[all 2023-03-05 01:12:43] 0xa3cb63 thread_prologue_and_epilogue_insns()
[all 2023-03-05 01:12:43]   ../../gcc/gcc/function.cc:6073
[all 2023-03-05 01:12:43] 0xa3d292 rest_of_handle_thread_prologue_and_epilogue
[all 2023-03-05 01:12:43]   ../../gcc/gcc/function.cc:6572
[all 2023-03-05 01:12:43] 0xa3d292 execute
[all 2023-03-05 01:12:43]   ../../gcc/gcc/function.cc:6655
[all 2023-03-05 01:12:43] Please submit a full bug report, with preprocessed
source (by using -freport-bug).
[all 2023-03-05 01:12:43] Please include the complete backtrace with any bug
report.
[all 2023-03-05 01:12:43] See  for instructions.

Should be reproducible with:
.../gcc/configure --enable-werror-always --enable-languages=all --disable-gcov
--disable-shared --disable-threads --target=m32c-elf --without-headers
make V=1 all-gcc

My most recent build log is at
http://toolchain.lug-owl.de/laminar/jobs/gcc-m32c-elf, the above is taken from
http://toolchain.lug-owl.de/laminar/jobs/gcc-m32c-elf/34 (which is based on
g:6010189923908501ca5b02bd1f4aee05d2283118).

[Bug target/69639] [10/11/12/13 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #18 from nightstrike  ---
(In reply to nightstrike from comment #9)
> This affects 8-trunk on x86_64 cygwin, as well.  The default size of the
> stack for cc1 is:
> 
> $ peflags -x /tmp/b2/gcc/cc1.exe
> /tmp/b2/gcc/cc1.exe: stack reserve size  : 12582912 (0xc0) bytes
> 
> 
> Setting it to 0xd0 and 0xe0 also fail.  Setting it to 0xf0
> works.  I didn't go further than that to see where between 14 and 15 megs it
> starts working.
> 
> Can we just boost the default stack size of cc1.exe by a couple megs for
> affected hosts?

It looks like Dave Korn already did it here:
https://gcc.gnu.org/legacy-ml/gcc-patches/2010-12/msg00256.html

But 12 isn't enough.  We need 15 (or I guess 16 if you like powers of 2).

[Bug rtl-optimization/109009] Shrink Wrap missed opportunity

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

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

--- Comment #2 from Surya Kumari Jangala  ---
For the working testcase:

long
foo (long i, long cond)
{
  if (cond)
bar ();
  return i;
}

The input RTL to the shrink wrap pass is:

BB2:
   set r100, compare(r4, 0)
   if r100 jump BB4 else jump BB3

BB3:
   set mem(r1+32), r3
   call bar()
   set r3, mem(r1+32)

BB4:
   return r3

The shrink wrap pass concludes that only BB3 requires a prolog and successfully
does shrink wrapping.

For the non-working case:
long
foo (long i, long cond)
{
  if (cond)
bar ();
  return i+1;
}

The input rtl to the shrink wrap pass is:

BB2:
   set r100, compare(r4, 0)
   set r31, r3
   if r100 jump BB4 else jump BB3

BB3:
   call bar()

BB4:
   set r3, r31+1
   return r3

The shrink wrap pass decides that both BB2 and BB3 require a prolog, and
finally the prolog is placed in BB2. Thus shrink wrapping fails for this test.

[Bug tree-optimization/109025] [13 Regression] ice in nested_in_vect_loop_p

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

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

--- Comment #3 from Andrew Pinski  ---
Note using &, | or ^ causes the ICE. Using + or - or * does not.

Here is more simplified testcase:
```
int func_4(int t, int b) {
  for (int tt1 = 0; tt1 < 128 ; tt1 ++)
  {
for (int tt = 0; tt < 128; tt ++)
  if (b)
t |= 3;
t |= 3;
  }
  return t;
}
```
The above should just optimized to `return t | 3;` really.
The ^/& case should be optimized too but it depends on if the number of loops
is even or odd and if b was non-zero or not.

[Bug tree-optimization/109025] [13 Regression] ice in nested_in_vect_loop_p

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/109025] [13 Regression] ice in nested_in_vect_loop_p

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

--- Comment #2 from Andrew Pinski  ---
Confirmed, reduced a little further and valid well defined code:
```
int func_4(int t, int b) {
  for (int tt1 = 0; tt1 < 1024 ; tt1 ++)
  {
for (int tt = 0; tt < 1024; tt ++)
  if (b)
t ^= 10;
t ^= 10;
  }
  return t;
}
```

[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #10 from sandra at gcc dot gnu.org ---
The ABS_EXPR test is also failing on nios2.

[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

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

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

--- Comment #13 from Segher Boessenkool  ---
Hi!

Either this should not be P1, or the proposed patch is taking completely the
wrong direction.  P1 means there is a regression.  There is no regression in
combine, in fact the proposed patch would *cause* regressions on many targets!

I certainly welcome making the compound_operation stuff behave better, but the
key point there is *better*, random changes that have not been tested on most
archs (and will likely regress on many) are not okay.  This is stage 1 material
no matter what.

Maybe we need some new target macros saying to not use two shifts, and/or
zero_extract, or sign_extract, etc.  No machine newer than VAX (or was it PDP?)
has real hardware support for that, we are much better off expressing things
with machine instructions that *do* exist only.

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

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

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

--- Comment #13 from Segher Boessenkool  ---
(In reply to bugreporter66 from comment #10)
> Yes, it seems so. They've switched to POWER9 by default in Ubuntu 22.04, so
> it means that gcc itself (along with standard libraries) was compiled for
> POWER9 as well. It used to be POWER8 in the previous releases.

Power9 *only*, actually.

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

[bugreporter66 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from bugreporter66 at gmail dot com ---
Yep, thanks.

At least I've learned how to debug with QEMU and GDB and I think building
without -static should still produce code compatible with POWER8 for the actual
target, but not for QEMU linux-user emulation (which obviously requires it).

This link I found was helpful in getting GDB and QEMU working together:
https://mariokartwii.com/showthread.php?tid=1998=9867#pid9867

[Bug c/109025] ice in nested_in_vect_loop_p

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C code seems to be:

g_86, g_472, g_1844, func_4_p_8;
func_4() {
  int *l_3175 = _86;
  for (; g_1844; g_1844 -= 1) {
g_472 = 1;
for (; g_472; g_472 += 1)
  if (func_4_p_8)
*l_3175 ^= 10;
*l_3175 ^= 10;
  }
}

[Bug c/109025] New: ice in nested_in_vect_loop_p

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109025
   Summary: ice in nested_in_vect_loop_p
   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 54586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54586=edit
C source code

The attached C code, when compiled by recent gcc and compiler flag -O3,
does this:

runData/keep/in.35565.c: In function ‘func_1.isra’:
runData/keep/in.35565.c:187:16: internal compiler error: Segmentation fault
0xdb5149 crash_signal(int)
../../trunk.d1/gcc/toplev.cc:314
0x10424d1 nested_in_vect_loop_p(loop*, _stmt_vec_info*)
../../trunk.d1/gcc/tree-vectorizer.h:1648
0x10424d1 vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*, _slp_tree*,
_
slp_instance*, vec*)
../../trunk.d1/gcc/tree-vect-loop.cc:6943

The bug first seems to occur sometime between git hash g:4acc4c2be84d6607,
dated 20221101 and g:d0a3d55ae4a2656f, dated 20221201.

I have a reduction running.

[Bug fortran/108937] Intrinsic IBITS(I,POS,LEN) fails when LEN equals to BIT_SIZE(I).

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

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

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

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

commit r12-9222-gbb68c20e1f3c673ed00e0e1abd468d8f19cd2072
Author: Harald Anlauf 
Date:   Mon Feb 27 21:37:11 2023 +0100

Fortran: fix corner case of IBITS intrinsic [PR108937]

gcc/fortran/ChangeLog:

PR fortran/108937
* trans-intrinsic.cc (gfc_conv_intrinsic_ibits): Handle corner case
LEN argument of IBITS equal to BITSIZE(I).

gcc/testsuite/ChangeLog:

PR fortran/108937
* gfortran.dg/ibits_2.f90: New test.

(cherry picked from commit 6cce953ebec274f1468d5d3a0697cf05bb43b8f6)

[Bug fortran/96024] [10/11/12/13 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159

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

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

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

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

commit r12-9221-g3f1ae4deb9c1524b2b1a5c9c4e751ea1c0f7478d
Author: Harald Anlauf 
Date:   Tue Feb 21 22:06:33 2023 +0100

Fortran: reject invalid CHARACTER length of derived type components
[PR96024]

gcc/fortran/ChangeLog:

PR fortran/96024
* resolve.cc (resolve_component): The type of a CHARACTER length
expression must be INTEGER.

gcc/testsuite/ChangeLog:

PR fortran/96024
* gfortran.dg/pr96024.f90: New test.

(cherry picked from commit 31303c9b5bab200754cdb7ef8cd91ae4918f3018)

[Bug fortran/96025] [10/11/12/13 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437

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

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

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

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

commit r12-9220-gabd1571d2340b5c86ba4d51ef9affc743e764ba8
Author: Harald Anlauf 
Date:   Mon Feb 20 21:28:09 2023 +0100

Fortran: improve checking of character length specification [PR96025]

gcc/fortran/ChangeLog:

PR fortran/96025
* parse.cc (check_function_result_typed): Improve type check of
specification expression for character length and return status.
(parse_spec): Use status from above.
* resolve.cc (resolve_fntype): Prevent use of invalid specification
expression for character length.

gcc/testsuite/ChangeLog:

PR fortran/96025
* gfortran.dg/pr96025.f90: New test.

(cherry picked from commit 6c1b825b3d6499dfeacf7c79dcf4b56a393ac204)

[Bug c++/108550] [10/11/12 Regression] the type 'const auto' of 'constexpr' variable is not literal

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 107938 Summary: [11/12 Regression] ICE directly returning `this` of 
`extern` variable in template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107938

   What|Removed |Added

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

[Bug c++/107938] [11/12 Regression] ICE directly returning `this` of `extern` variable in template since r11-557

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/108550] [10/11/12 Regression] the type 'const auto' of 'constexpr' variable is not literal

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/106259] [10/11 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in diag_mismatched_tags, at |diag_mismatched_tags, at
   |cp/parser.cc:33896  |cp/parser.cc:33896

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

[Bug c++/108550] [10/11/12 Regression] the type 'const auto' of 'constexpr' variable is not literal

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

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

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

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

commit r12-9219-gd6419c18056ae27741e961cd2dab9d120bfe746a
Author: Marek Polacek 
Date:   Sat Mar 4 13:14:01 2023 -0500

c++: variable template and targ deduction [PR108550]

In this test, we get a bogus error because we failed to deduce the auto in
constexpr auto is_pointer_v = is_pointer::value;
to bool.  Then ensure_literal_type_for_constexpr_object thinks the object
isn't literal and an error is reported.

This is another case of the interaction between tf_partial and 'auto',
where the auto was not reduced so the deduction failed.  In more detail:
we have

  Wrap1()

in the code and we need to perform OR -> fn_type_unification.  The targ
list is incomplete, so we do
  tsubst_flags_t ecomplain = complain | tf_partial | tf_fndecl_type;
  fntype = tsubst (TREE_TYPE (fn), explicit_targs, ecomplain,
NULL_TREE);
where TREE_TYPE (fn) is struct integral_constant  (void).  Then
we substitute the return type, which results in tsubsting
is_pointer_v.
is_pointer_v is a variable template with a placeholder type:

  template 
  constexpr auto is_pointer_v = is_pointer::value;

so we find ourselves in lookup_and_finish_template_variable.  tf_partial is
still set, so finish_template_variable -> instantiate_template -> tsubst
won't reduce the level of auto.  But then we do mark_used which eventually
calls do_auto_deduction which clears tf_partial, because we want to replace
the auto now.  But we hadn't reduced auto's level so this fails.  And
since we're not in an immediate context, we emit a hard error.

I suppose that when we reach lookup_and_finish_template_variable it's
probably time to clear tf_partial.  (I added an assert and our testsuite
doesn't have a test whereby we get to lookup_and_finish_template_variable
while tf_partial is still active.)

PR c++/108550

gcc/cp/ChangeLog:

* pt.cc (lookup_and_finish_template_variable): Clear tf_partial.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ70.C: New test.
* g++.dg/cpp1y/var-templ71.C: New test.
* g++.dg/cpp1y/var-templ72.C: New test.

[Bug c/108880] [11/12 Regression] slow compilation with "-fsanitize=undefined"

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

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

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

https://gcc.gnu.org/g:6ab4c8759754f34f5285924652238c829960cd4c

commit r12-9218-g6ab4c8759754f34f5285924652238c829960cd4c
Author: Marek Polacek 
Date:   Wed Feb 22 15:17:03 2023 -0500

c-family: avoid compile-time-hog in c_genericize [PR108880]

This fixes a compile-time hog with UBSan.  This only happened in cc1 but
not cc1plus.  The problem is ultimately that c_genericize_control_stmt/
STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
nodes, so it kept on recursing for a long time.  We should be able to
use the pset that c_genericize created.  We just need to use walk_tree
instead of walk_tree_w_d so that the pset is explicit.

PR c/108880

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_genericize_control_stmt) :
Pass
pset to walk_tree_1.
(c_genericize): Call walk_tree with an explicit pset.

gcc/testsuite/ChangeLog:

* c-c++-common/ubsan/pr108880.c: New test.

(cherry picked from commit 1370014f2ea02ec185cf1199027575916f79fe63)

[Bug c++/106259] [10/11/12 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896

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

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

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

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

commit r12-9217-g3a2310d4b229e707bbc5440150bf180e0499273a
Author: Marek Polacek 
Date:   Wed Mar 1 14:28:46 2023 -0500

c++: ICE with -Wmismatched-tags and member template [PR106259]

-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,

  template struct A { };
  class A a;

it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A.  At the end of c_parse_file we go through the table and
warn about the class-key mismatches.  In this PR we crash though; we
have

  template struct A {
template struct W { };
  };
  struct A::W w; // #1

where while parsing A and #1 we've stashed
   A
   A::W
   A::W
into class2loc.  Then in class_decl_loc_t::diag_mismatched_tags TYPE
is A::W, and specialization_of gets us A::W, which
is not in class2loc, so we crash on gcc_assert (cdlguide).  But it's
OK not to have found A::W, we should just look one "level" up,
that is, A::W.

It's important to handle class specializations, so e.g.

  template<>
  struct A {
template
class W { };
  };

where W's class-key is different than in the primary template above,
so we should warn depending on whether we're looking into A
or into a different instantiation.

PR c++/106259

gcc/cp/ChangeLog:

* parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first
lookup of SPEC didn't find anything, try to look for
most_general_template.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmismatched-tags-11.C: New test.

(cherry picked from commit 71afd0628419c5d670701cb35bc9860380c7d9fb)

[Bug c++/107574] [10/11 Regression] ICE: tree check in cp_fold_convert with ptr to member field cast inside a class not completed and inherent since r9-50-gd760b06868d660bc

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
Summary|[10/11/12 Regression] ICE:  |[10/11 Regression] ICE:
   |tree check in   |tree check in
   |cp_fold_convert with ptr to |cp_fold_convert with ptr to
   |member field cast inside a  |member field cast inside a
   |class not completed and |class not completed and
   |inherent since  |inherent since
   |r9-50-gd760b06868d660bc |r9-50-gd760b06868d660bc

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

[Bug c++/107574] [10/11/12 Regression] ICE: tree check in cp_fold_convert with ptr to member field cast inside a class not completed and inherent since r9-50-gd760b06868d660bc

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

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

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

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

commit r12-9216-gb7b50918fe52206e188c8c60c60e0d6a516e8572
Author: Marek Polacek 
Date:   Thu Feb 2 18:15:37 2023 -0500

c++: can't eval PTRMEM_CST in incomplete class [PR107574]

Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
been completed yet, but that doesn't work:

/* We can't lower this until the class is complete.  */
if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
  return cst;

and then this unlowered PTRMEM_CST is used as EXPR in

tree op1 = build_nop (ptrdiff_type_node, expr);

and we crash in a subsequent cp_fold_convert which gets
type=ptrdiff_type_node,
expr=PTRMEM_CST and does

  else if (TREE_CODE (expr) == PTRMEM_CST
   && same_type_p (TYPE_PTRMEM_CLASS_TYPE (type),
   PTRMEM_CST_CLASS (expr)))

where TYPE_PTRMEM_CLASS_TYPE (type) is going to crash since the type
is ptrdiff_type_node.  We could just add a TYPE_PTRMEM_P check before
accessing TYPE_PTRMEM_CLASS_TYPE but I think it's nicer to explain why
we couldn't evaluate the expression.

PR c++/107574

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_constant_expression): Emit an error when
a PTRMEM_CST cannot be evaluated.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/ptrmem-cst1.C: New test.

(cherry picked from commit de81e06273c613d7e06cbe2c8d9e72826c638056)

[Bug c++/107938] [11/12 Regression] ICE directly returning `this` of `extern` variable in template since r11-557

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

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

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

https://gcc.gnu.org/g:445082ff3cb7f9d30021adf338e9ab6038c3e412

commit r12-9215-g445082ff3cb7f9d30021adf338e9ab6038c3e412
Author: Marek Polacek 
Date:   Thu Feb 23 17:54:47 2023 -0500

c++: ICE with constexpr variable template [PR107938]

Since r11-557, cp_finish_decl can call check_initializer even in
a template for a constexpr initializer.  That ultimately leads to
convert_for_assignment and check_address_or_pointer_of_packed_member,
where we crash, because it doesn't expect that the CALL_EXPR is
a function object.  Q has a constexpr operator(), but since we're
in a template, q(0) is a CALL_EXPR whose CALL_EXPR_FN is just
a VAR_DECL; it hasn't been converted to Q::operator(, 0) yet.
I propose to robustify check_address_or_pointer_of_packed_member.

var-templ74.C has an XFAIL, subject to 107939.

I noticed that our -Waddress-of-packed-member tests weren't testing
member functions, added thus.  (I was tempted to check
FUNCTION_POINTER_TYPE_P but that doesn't include METHOD_TYPE.)

PR c++/107938

gcc/c-family/ChangeLog:

* c-warn.cc (check_address_or_pointer_of_packed_member): Check
POINTER_TYPE_P.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ73.C: New test.
* g++.dg/cpp1y/var-templ74.C: New test.
* g++.dg/warn/Waddress-of-packed-member3.C: New test.

(cherry picked from commit ea718febab2a1f6e58806738abf70f1c73c6a308)

[Bug c++/109017] ICE on unexpanded pack from C++20 explicit-template-parameter lambda syntax

[hiraditya at msn dot com via Gcc-bugs]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #1 from AK  ---
Example from twitter: https://twitter.com/seanbax/status/1631689332007337985
which had discussion on similar bug.

```
template struct outer1_t {
  void g() {
// Compiles for mysterious reasons.
int array[] { [](){
  int i = Is2;
  return i;
}.template operator()() ... };
  }
};

int main() {
  // Compiles OKAY when this is commented out.
  // ICEs when it's compiled.
  outer1_t<1, 5, 10>().g();
}
```

clang issues a compiler error: https://godbolt.org/z/7f6E55svM

```
:6:15: error: initializer contains unexpanded parameter pack 'Is2'
  int i = Is2;
```

[Bug libstdc++/109024] New: [C++23][ranges][repeat_view] The default ctor unuseable

[yronglin777 at gmail dot com via Gcc-bugs]

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

Bug ID: 109024
   Summary: [C++23][ranges][repeat_view] The default ctor
unuseable
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yronglin777 at gmail dot com
  Target Milestone: ---

The default ctor of std::ranges::repeat_view was unuseable.

https://godbolt.org/z/jxKMxEn7E

[P2474R2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2474r2.html
```
repeat_view() requires default_initializable = default;
```

```
#include 
#include 

void fn() {
std::ranges::repeat_view v;
}
```

```
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20230304/include/c++/13.0.1/ranges: In
instantiation of 'constexpr std::ranges::repeat_view<_Tp,
_Bound>::repeat_view() requires  default_initializable<_Tp> [with _Tp = int;
_Bound = std::unreachable_sentinel_t]':
:5:35:   required from here
/opt/compiler-explorer/gcc-trunk-20230304/include/c++/13.0.1/ranges:7395:37:
error: could not convert '0' from 'int' to 'std::ranges::__detail::__box'
 7395 | __detail::__box<_Tp> _M_value = _Tp();
  | ^
  | |
  | int
Compiler returned: 1
```

[Bug c++/109021] accept size parameter in extern C

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #2 from Martin Uecker  ---
True. But we could still take it as a hint about where this is not useful to
users to diagnose this as an error.

[Bug fortran/106856] [12/13 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> Submitted: https://gcc.gnu.org/pipermail/fortran/2023-March/059003.html

As discussed in this thread, this version of the patch works for

subroutine s1 (x)
  class(*):: x
  allocatable :: x
  dimension   :: x(:)
  if (allocated (x)) print *, size (x)
end

subroutine s2 (x)
  class(*):: x
  allocatable :: x(:)
  if (allocated (x)) print *, size (x)
end

but still ICEs for the variations / line permutations

subroutine s3 (x)
  class(*):: x(:)
  allocatable :: x
  if (allocated (x)) print *, size (x)
end

subroutine s4 (x)
  class(*):: x
  dimension   :: x(:)
  allocatable :: x
  if (allocated (x)) print *, size (x)
end

I think Mikael's findings in the thread fix this.

[Bug c++/109021] accept size parameter in extern C

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
extern "C" just changes the language linkage but does not change the language
which the declaration is written in.

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #54584|0   |1
is obsolete||

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

Small fix for a theoretical problem in the patch.

[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from qingzhe huang  ---
I gdb a little bit and I feel this issue is fixable. See the comparison of
"unq" and "function" below is not compatible because "function" is
"IDENTIFIER_NODE" and "unq" is "VIEW_CONVERT_EXPR". If we check and convert
"unq", we will find they are matching. 



(gdb) info b
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x00d0bafc in
tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) at
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/pt.cc:20608
breakpoint already hit 1 time
(gdb) l 20608
20603   (function, args, complain, in_decl, true,
20604integral_constant_expression_p));
20605   if (unq == error_mark_node)
20606 RETURN (error_mark_node);
20607   
20608   if (unq != function)
20609 {
20610   char const *const msg
20611 = G_("%qD was not declared in this scope, "
20612  "and no declarations were found by "
(gdb) p IDENTIFIER_POINTER(function)
$16 = 0x770c42c0 "g"
(gdb) p IDENTIFIER_POINTER(DECL_NAME(TREE_OPERAND(unq,0)))
$17 = 0x770c42c0 "g"
(gdb) p TREE_CODE(function)
$18 = IDENTIFIER_NODE
(gdb) p TREE_CODE(unq)
$19 = VIEW_CONVERT_EXPR
(gdb)

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

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

Untested patch to just extend the popcount handling to clz, ctz and ffs, though
for now only if they have corresponding optabs implemented.  This improves the
__builtin_clzll testcase above, but doesn't help with ctz or ffs.
Those will need to be added incrementally.

[Bug d/109023] New: d: Add option to include imported modules in the compilation

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

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

Bug ID: 109023
   Summary: d: Add option to include imported modules in the
compilation
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

The reference D compiler has an option `-i` that enables "include imports"
mode, where the compiler will include imported modules in the compilation, as
if they were given on the command line.

Possibly some considerations:

- This option might need to implicitly mean `-fwhole-program', as we don't want
link-time errors to occur as a result of library symbols being in multiple DSOs
(or do we?).

- Would it complicate matters if the same DRT constructor/destructors end up in
multiple DSOs?

- Excluding libphobos and libdruntime modules from being compiled imports would
avoid the main pitfalls I can think of occurring.

[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Known to work||8.5.0

--- Comment #19 from Georg-Johann Lay  ---
(In reply to CVS Commits from comment #18)
> https://gcc.gnu.org/g:2639f9d2313664e6b4ed2f8131fefa60aeeb0518
> 
> commit r13-6424-g2639f9d2313664e6b4ed2f8131fefa60aeeb0518
> Author: Vladimir N. Makarov 
> Date:   Thu Mar 2 16:29:05 2023 -0500
> 
> IRA: Use minimal cost for hard register movement

Thank you; the code looks clean now. (For my test case from comment #16 I
needed -fno-split wide-types which is a different story).

Is there any chance your fix will be back-ported?

[Bug libstdc++/109022] New: Low performance of std::map constructor for already sorted data of std::pair

[marekr22 at wp dot pl via Gcc-bugs]

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

Bug ID: 109022
   Summary: Low performance of std::map constructor for already
sorted data of std::pair
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marekr22 at wp dot pl
  Target Milestone: ---

Performance of constructor accepting iterators to sorted data of
std::pair is much lower then inserting same data for
std::pair (matches value_type of std::map).

Here is benchmark showing the issue:
```
#include 
#include 
#include 
#include 
#include 

constexpr size_t DataSizeStart = 8 << 0;
constexpr size_t DataSizeStop = 8 << 3;

using TestData = std::vector>;
using TestDataConst = std::vector>;

std::string makeStringFor(size_t x)
{
  std::ostringstream out;
  out << std::setfill('0') << std::setw(6) << x;
  return out.str();
}

TestData sortedData(size_t n)
{
  TestData r;
  r.reserve(n);
  size_t i = 0;
  std::generate_n(std::back_inserter(r), n, []() {
return std::pair{makeStringFor(++i), i};
  });
  return r;
}

TestData shuffledData(size_t n)
{
  auto data = sortedData(n);
  std::random_device rd;
  std::mt19937 g(rd());

  std::shuffle(data.begin(), data.end(), g);
  return data;
}

TestDataConst sortedConstData(size_t n)
{
  auto r = sortedData(n);
  return {r.begin(), r.end()};
}

TestDataConst shuffledConstData(size_t n)
{
  auto r = shuffledData(n);
  return {r.begin(), r.end()};
}

template
static void CreateMapInsert(benchmark::State& state) {
  auto n = state.range(0);
  auto data = Data(n);
  for (auto _ : state) {
benchmark::DoNotOptimize(data);
std::map m;

for (auto& p : data) {
  m.insert(m.end(), p);
}
benchmark::DoNotOptimize(m);
  }
}
BENCHMARK(CreateMapInsert)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
//
BENCHMARK(CreateMapInsert)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
BENCHMARK(CreateMapInsert)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
//
BENCHMARK(CreateMapInsert)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);

template
static void CreateMapDirectly(benchmark::State& state) {
  auto n = state.range(0);
  auto data = Data(n);
  for (auto _ : state) {
benchmark::DoNotOptimize(data);
std::map m{data.begin(), data.end()};
benchmark::DoNotOptimize(m);
  }
}
BENCHMARK(CreateMapDirectly)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
//
BENCHMARK(CreateMapDirectly)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
BENCHMARK(CreateMapDirectly)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
//
BENCHMARK(CreateMapDirectly)->RangeMultiplier(2)->Range(DataSizeStart,
DataSizeStop);
```

Live demo gcc 12.2: https://quick-bench.com/q/H8lqugNgMG-sWQ6cKBsdB7EBRpU
Note that CreateMapInsert performs best since it feeds to
constructos to iterators to std::pair while
CreateMapInsert performs badly (looks like time complexity is
worse) adn only diffrence is that it provides iterators to std::.

Same issue is observed for clang 14.0 and libstdc++:
https://quick-bench.com/q/6VA3vRdKmqPEYrvTnFFla4gxwXk
but it is not a problem on clang 14.0 and libc++:
https://quick-bench.com/q/-S-lX3N8Y-8vL9CCl-5bW5jolWA

here is result for sing size input data (easier to read):
https://quick-bench.com/q/kbDOPA8PNZFfrzUH_-70cJgApeE

Issue was observed when filing answer on
https://stackoverflow.com/a/75535056/1387438

[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from qingzhe huang  ---
I find another argument from decltype in cppreference
(https://en.cppreference.com/w/cpp/language/decltype#Explanation)

quote:
Because no temporary object is created, the type need not be complete or have
an available destructor, and can be abstract. This rule doesn't apply to
sub-expressions: in decltype(f(g())), g() must have a complete type, but f()
need not.

Does this mean that here "f" needs not be available when "g" is int which is
always complete? So, in our example the function "g" (aka "f" here) needs not
be available.

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
And, similarly to the fallback for ctz there should be fallback for ffs.
I'll handle this for GCC 14.

[Bug c++/109021] New: accept size parameter in extern C

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 109021
   Summary: accept size parameter in extern C
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

A problem I encounter sometimes when using newer C headers in C++ is
with functions that have array argument with a size parameter:

extern "C" void foo(int N, char buf[N]);

I think g++ should accept this in general or only for extern "C".

At least for 1D arrays this should be easy as it could simply ignore the size 
and only emit a diagnostic with -pedantic.

[Bug c++/102524] [modules] Missing diagnostic when an exported namespace is empty

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

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

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
Clang no longer warns. This was resolved with
https://github.com/cplusplus/draft/commit/f3ffeb4f05fe4302d8ecee129e72f4e99e10dc02,
which striked the quoted sentence.

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

[johelegp at gmail dot com via Gcc-bugs]

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

Bug 102524 Summary: [modules] Missing diagnostic when an exported namespace is 
empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102524

   What|Removed |Added

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

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Then you can't expect it to work on power8...

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

[bugreporter66 at gmail dot com via Gcc-bugs]

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

--- Comment #10 from bugreporter66 at gmail dot com ---
Yes, it seems so. They've switched to POWER9 by default in Ubuntu 22.04, so it
means that gcc itself (along with standard libraries) was compiled for POWER9
as well. It used to be POWER8 in the previous releases.

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

--- Comment #7 from Jakub Jelinek  ---
Also, I wonder why vect_recog_popcount_pattern handles only popcount, can't it
handle clz/ctz as well?
I mean for
void
foo (long long *p, long long *q)
{
  for (int i = 0; i < 2048; ++i)
p[i] = __builtin_popcountll (q[i]);
}

void
bar (long long *p, long long *q)
{
  for (int i = 0; i < 2048; ++i)
p[i] = __builtin_clzll (q[i]);
}
with -O3 -mavx512{bw,cd,vl,dq,bitalg,vpopcntdq} we have in *.optimized in the
inner loop nice:
  vect__4.7_40 = MEM  [(long long int *)q_12(D) +
ivtmp.25_1 * 1];
  vect_patt_24.8_41 = .POPCOUNT (vect__4.7_40);
  MEM  [(long long int *)p_13(D) + ivtmp.25_1 * 1] =
vect_patt_24.8_41;
but in the other loop
  vect__4.36_39 = MEM  [(long long int *)q_12(D) +
ivtmp.56_1 * 1];
  vect__4.37_41 = MEM  [(long long int *)q_12(D) + 64B
+ ivtmp.56_1 * 1];
  vect__5.38_42 = VIEW_CONVERT_EXPR(vect__4.36_39);
  vect__5.38_43 = VIEW_CONVERT_EXPR(vect__4.37_41);
  _44 = .CLZ (vect__5.38_42);
  _45 = .CLZ (vect__5.38_43);
  vect__6.39_46 = VEC_PACK_TRUNC_EXPR <_44, _45>;
  vect__8.40_47 = [vec_unpack_lo_expr] vect__6.39_46;
  vect__8.40_48 = [vec_unpack_hi_expr] vect__6.39_46;
  MEM  [(long long int *)p_13(D) + ivtmp.56_1 * 1] =
vect__8.40_47;
  MEM  [(long long int *)p_13(D) + 64B + ivtmp.56_1 *
1] = vect__8.40_48;
So, we need to handle twice as many vectors regardless of unrolling, perform
twice vector V8DI->V8DI clz, then pack it and immediately unpack it again.

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
I believe that instruction is power9 only, on the other side
_GLOBAL__sub_I_eh_alloc.cc doesn't come from the code you were compiling, but
from libstdc++.a(eh_alloc.o).
So, it depends on how the gcc you are using has been compiled.
If it is from an Ubuntu package, you need to report it to Ubuntu.

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

[bugreporter66 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from bugreporter66 at gmail dot com ---
Created attachment 54583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54583=edit
Screenshot with GDB+disassembly

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

[bugreporter66 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from bugreporter66 at gmail dot com ---
After disassembling the instruction in question is stxv at 100034b0:

10003470 <_GLOBAL__sub_I_eh_alloc.cc>:
10003470:   15 10 40 3c lis r2,4117
10003474:   00 7c 42 38 addir2,r2,31744
10003478:   a6 02 08 7c mflrr0
1000347c:   f0 ff c1 fb std r30,-16(r1)
10003480:   f8 ff e1 fb std r31,-8(r1)
10003484:   10 00 01 f8 std r0,16(r1)
10003488:   d1 ff 21 f8 stdur1,-48(r1)
1000348c:   01 00 e0 3f lis r31,1
10003490:   d0 02 00 f0 xxspltib vs0,0
10003494:   00 00 c0 3b li  r30,0
10003498:   00 00 00 60 nop
1000349c:   00 1c ff 63 ori r31,r31,7168
100034a0:   00 00 00 60 nop
100034a4:   f0 c7 22 39 addir9,r2,-14352
100034a8:   78 fb e3 7f mr  r3,r31
100034ac:   28 c8 e2 fb std r31,-14296(r2)
100034b0:   05 00 09 f4 stxvvs0,0(r9)
100034b4:   15 00 09 f4 stxvvs0,16(r9)
100034b8:   00 00 00 60 nop
100034bc:   10 c8 c2 fb std r30,-14320(r2)
100034c0:   29 6a 07 48 bl  10079ee8 <__libc_malloc+0x8>

[Bug middle-end/109006] [13 Regression] Python Exception : There is no member or method named m_vecdata. since r13-6332

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed by Jonathan's patches.

[Bug middle-end/109006] [13 Regression] Python Exception : There is no member or method named m_vecdata. since r13-6332

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

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

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

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

commit r13-6478-g4ee2f419fe4dbb21dfb0622cc7c0e46a2261
Author: Jakub Jelinek 
Date:   Sat Mar 4 11:24:04 2023 +0100

Remove remaining traces of m_vecdata from comments [PR109006]

The following patch adjusts remaining references to the removed m_vecdata
array from vec.h in various comments.

2023-03-04  Jakub Jelinek  

PR middle-end/109006
* vec.cc (test_auto_alias): Adjust comment for removal of
m_vecdata.
* read-rtl-function.cc (function_reader::parse_block): Likewise.
* gdbhooks.py: Likewise.

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

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

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

--- Comment #6 from Jakub Jelinek  ---
That doesn't tell anything, you need to stepi through the function to reach the
problematic instruction and disas $pc-32,$pc+32 around it or so.

[Bug c++/109020] New: Lambdas have different DWARF signature than the function they are in

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 109020
   Summary: Lambdas have different DWARF signature than the
function they are in
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
CC: rguenther at suse dot de
  Target Milestone: ---

== Input ==

$ cat x.cpp
#include 
static void ff(uint64_t b) { [&](){}(); }
int main() { ff(0); }
$ g++ x.cpp -g
$ gdb a.out
(gdb) b ff

== Observed ==

ff(uint64_t)
ff(unsigned long)::{lambda()#1}::operator()() const

== Expectation ==

ff(unsigned long)
ff(unsigned long)::{lambda()#1}::operator()() const

[or]

ff(uint64_t)
ff(uint64_t)::{lambda()#1}::operator()() const

== Additional info ==

I am filing this for gcc since I believe this might have to do with DWARF
generation rather than gdb being funky.

Using built-in specs.
COLLECT_GCC=g++-13
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit,rust,m2
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --enable-offload-defaulted
--without-cuda-driver --enable-host-shared --enable-checking=release
--disable-werror --with-gxx-include-dir=/usr/include/c++/13
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-13 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230127 (experimental) [revision
ca8fb0096713a8477614ef874f16ba5bf16c48bc] (SUSE Linux)

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

[bugreporter66 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from bugreporter66 at gmail dot com ---
Created attachment 54582
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54582=edit
Screenshot with QEMU+GDB

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

[bugreporter66 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from bugreporter66 at gmail dot com ---
I did the remote debugging as suggested by Andrew Pinski and it seems to fail
somewhere in _GLOBAL__sub_i_eh_alloc.cc

After connecting to qemu from gdb I issued step command and the program was
terminated with SIGILL (illegal instruction) single stepping until exit from
that function (which has no line number information).

I am attaching the screenshot.

[Bug testsuite/108973] [10/11/12 Regression] Sufficiently narrow terminal window causes selftest failure

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[13 Regression] |[10/11/12 Regression]
   |Sufficiently narrow |Sufficiently narrow
   |terminal window causes  |terminal window causes
   |selftest failure|selftest failure
   Target Milestone|13.0|10.5

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.  Just tried 10 branch and it ICEs in self-tests with
COLUMNS=41 as well:
$ ./xgcc -B ./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-checking=yes
--enable-languages=c,c++,fortran : (reconfigured) 
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.4.1 20220628 (GCC) 
$ COLUMNS=41 ./xgcc -B./ -B/usr/local/x86_64-pc-linux-gnu/bin/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -L/usr/src/gcc-10/obj/gcc/../ld -xc
-nostdinc /dev/null -S -o /dev/null -fself-test=../../gcc/testsuite/selftests
../../gcc/diagnostic-show-locus.c:3949: test_add_location_if_nearby: FAIL:
ASSERT_STREQ (" struct same_line { double x; double y; ;\n" " 
~^\n", pp_formatted_text (dc.printer)) val1=" struct
same_line { double x; double y; ;
  ~^
" val2=" truct same_line { double x; double y; ;
 ~^

"
cc1: internal compiler error: in fail_formatted, at selftest.c:63
0x21a3a86 diagnostic_impl
../../gcc/selftest.h:1309
0x21a541a internal_error(char const*, ...)
../../gcc/selftest.h:1711
0x21a5678 fancy_abort(char const*, int, char const*)
../../gcc/selftest.h:1778
0x219d50b selftest::fail_formatted(selftest::location const&, char const*, ...)
../../gcc/selftest.h:63
0x219d5fa selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
../../gcc/selftest.h:92
0x21b2fb6 test_add_location_if_nearby
../../gcc/../libcpp/include/cpplib.h:3949
0x21dd17a selftest::for_each_line_table_case(void (*)(selftest::line_table_case
const&))
../../gcc/../libcpp/include/cpplib.h:3573
0x21b95ea selftest::diagnostic_show_locus_c_tests()
../../gcc/../libcpp/include/cpplib.h:5022
0x20d83f9 selftest::run_tests()
../../gcc/wide-int-bitmask.h:96
0x11ae133 toplev::run_self_tests()
../../gcc/flags.h:2351
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/107465] [10/11/12 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression] Bogus
   |Bogus warning: promoted |warning: promoted bitwise
   |bitwise complement of an|complement of an unsigned
   |unsigned value is always|value is always nonzero
   |nonzero |

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/108702] [13 Regression] ICE in get_partitioning_class, at symtab.cc:2096 since r13-4161-g32d16fe9d7e347bc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug c/107465] [10/11/12/13 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero

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

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

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

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

commit r13-6476-g3ec9a8728086ad86a2d421e067329f305f40e005
Author: Jakub Jelinek 
Date:   Sat Mar 4 10:21:45 2023 +0100

c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling
[PR107465]

There can be too many extensions and seems I didn't get everything right in
the previously posted patch.

The following incremental patch ought to fix that.
The code can deal with quite a few sign/zero extensions at various spots
and it is important to deal with all of them right.
On the argument that contains BIT_NOT_EXPR we have:
MSB bits#4 bits#3 BIT_NOT_EXPR bits#2 bits#1 LSB
where bits#1 is one or more bits (TYPE_PRECISION (TREE_TYPE (arg0))
at the end of the function) we don't know anything about, for the purposes
of this warning it is VARYING that is inverted with BIT_NOT_EXPR to some
other
VARYING bits;
bits#2 is one or more bits (TYPE_PRECISION (TREE_TYPE (op0)) -
TYPE_PRECISION (TREE_TYPE (arg0)) at the end of the function)
which are known to be 0 before the BIT_NOT_EXPR and 1 after it.
bits#3 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0))
at the end of function to the TYPE_PRECISION (TREE_TYPE (op0)) at the
end of the function to TYPE_PRECISION (TREE_TYPE (op0)) at the start
of the function, which are either zero extension or sign extension.
And bits#4 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0))
at the start of the function to TYPE_PRECISION (result_type), which
again can be zero or sign extension.

Now, vanilla trunk as well as the previously posted patch mishandles the
case where bits#3 are sign extended (as bits#2 are known to be all set,
that means bits#3 are all set too) but bits#4 are zero extended and are
thus all 0.

The patch fixes it by tracking the lowest bit which is known to be clear
above the known to be set bits (if any, otherwise it is precision of
result_type).

2023-03-04  Jakub Jelinek  

PR c/107465
* c-warn.cc (warn_for_sign_compare): Don't warn for unset bits
above innermost zero extension of BIT_NOT_EXPR result.

* c-c++-common/Wsign-compare-2.c (f18): New test.

[Bug c/107465] [10/11/12/13 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero

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

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

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

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

commit r13-6475-gdaaf74a714c41c8dbaf9954bcc58462c63062b4f
Author: Jakub Jelinek 
Date:   Sat Mar 4 10:18:37 2023 +0100

c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling [PR107465]

The following patch fixes multiple bugs in warn_for_sign_compare related to
the BIT_NOT_EXPR related warnings.
My understanding is that what those 3 warnings are meant to warn (since
1995
apparently) is the case where we have BIT_NOT_EXPR of a zero-extended
value, so in result_type the value is something like:
0b (e.g. ~ of a 8->16 bit zero extension)
0b (e.g. ~ of a 8->16 bit zero extension
then zero extended to 32 bits)
0b (e.g. ~ of a 8->16 bit zero extension
then sign extended to 32 bits)
and the intention of the warning is to warn when this is compared against
something that has some 0 bits at the place where the above has guaranteed
1 bits, either ensured through comparison against constant where we know
the bits exactly, or through zero extension from some narrower type where
again we know at least some upper bits are zero extended.
The bugs in the warning code are:
1) misunderstanding of the {,c_common_}get_narrower APIs - the unsignedp
   it sets is only meaningful if the function actually returns something
   narrower (in that case it says whether the narrower value is then
   sign (0) or zero (1) extended to the originally passed value.
   Though op0 or op1 at this point might be already narrower than
   result_type, and if the function doesn't return anything narrower,
   it all depends on whether the passed in op{0,1} had TYPE_UNSIGNED
   type or not
2) the code didn't check at all whether the BIT_NOT_EXPR operand
   was actually zero extended (i.e. that it was narrower and unsignedp
   was set to 1 for it), all it did is check that unsignedp from the
   call was 1.  But that isn't well defined thing, if the argument
   is returned as is, the function sets unsignedp to 0, but if there
   is e.g. a useless cast to the same or compatible type in between,
   it can return 1 if the cast is unsigned; now, if BIT_NOT_EXPR
   operand is not zero extended, we know nothing at all about any bits
   in the operand containing BIT_NOT_EXPR, so there is nothing to warn
   about
3) the code was actually testing both operands after calling
   c_common_get_narrower on them and on the one with BIT_NOT_EXPR
   again for constants; I think that is just wrong in case the BIT_NOT_EXPR
   operand wouldn't be fully folded, the warning makes sense only if the
   other operand not having BIT_NOT_EXPR in it is constant
4) as can be seen from the above bit pattern examples, the upper bits above
   (in the patch arg0) aren't always all 1s, there could be some zero
extension
   above it and from it one would have 0s, so that needs to be taken into
   account for the choice which constant bits to test for being always set
   otherwise warning is emitted, or for the zero extension guaranteed zero
   bits
5) the patch also simplifies the handling, we only do it if one but not
   both operands are BIT_NOT_EXPR after first {,c_common_}get_narrower,
   so we can just use std::swap to ensure it is the first one
6) the code compared bits against HOST_BITS_PER_LONG, which made sense
   back in 1995 when the values were stored into long, but now that they
   are HOST_WIDE_INT should test HOST_BITS_PER_WIDE_INT (or we could
rewrite
   the stuff to wide_int, not done in the patch)

2023-03-04  Jakub Jelinek  

PR c/107465
* c-warn.cc (warn_for_sign_compare): If c_common_get_narrower
doesn't return a narrower result, use TYPE_UNSIGNED to set
unsignedp0
and unsignedp1.  For the one BIT_NOT_EXPR case vs. one without,
only check for constant in the non-BIT_NOT_EXPR operand, use
std::swap
to simplify the code, only warn if BIT_NOT_EXPR operand is extended
from narrower unsigned, fix up computation of mask for the constant
cases and for unsigned other operand case handle differently
BIT_NOT_EXPR result being sign vs. zero extended.

* c-c++-common/Wsign-compare-2.c: New test.
* c-c++-common/pr107465.c: New test.

[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits

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

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

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

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

commit r13-6474-gdb1405ddf566fe6129328229579b3f98a574b34c
Author: Jakub Jelinek 
Date:   Sat Mar 4 10:14:33 2023 +0100

c-family: Account for integral promotions of left shifts for
-Wshift-overflow warning [PR107846]

The r13-1100-gacb1e6f43dc2bbedd124 change added match.pd narrowing
of left shifts, and while I believe the C++ FE calls the warning on
unfolded
trees, the C FE folds them and so left shifts where integral promotion
happened and so were done in int type will be usually narrowed back to
char/signed char/unsigned char/short/unsigned short left shifts if the
shift count is constant and fits into the precision of the var being
shifted.
One possibility would be to restrict the match.pd optimization to GIMPLE
only, another don't fold in C FE before this warning (well, we need to
fold the shift count operand to constant if possible), the following patch
just takes integral promotion into account in the warning code.

2023-03-04  Jakub Jelinek  

PR c/107846
* c-warn.cc: Include langhooks.h.
(maybe_warn_shift_overflow): Set type0 to what TREE_TYPE (op0)
promotes to rather than TREE_TYPE (op0) itself, if TREE_TYPE (op0)
is narrower than type0 and unsigned, use wi::min_precision with
UNSIGNED and fold_convert op0 to type0 before emitting the warning.

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

[Bug c++/108702] [13 Regression] ICE in get_partitioning_class, at symtab.cc:2096 since r13-4161-g32d16fe9d7e347bc

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

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

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

https://gcc.gnu.org/g:9d5730dee4f42e94004b38f8f4862c0b1f4d964c

commit r13-6473-g9d5730dee4f42e94004b38f8f4862c0b1f4d964c
Author: Jakub Jelinek 
Date:   Sat Mar 4 09:51:31 2023 +0100

c++: Don't defer local statics initialized with constant expressions
[PR108702]

The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P2647R1
was implemented we agreed to make it valid.

Now, as reported, the testcase compiles fine, but doesn't actually link
because the static variable isn't defined anywhere, and with -flto ICEs
because of this problem.  This is because we never
varpool_node::finalize_decl those vars, the constant expression in which
the DECL_EXPR is present for the static VAR_DECL is folded (constant
evaluated) into just the address of the VAR_DECL.
Now, similar testcase included below (do we want to include it in the
testsuite too?) works fine, because in
cp_finish_decl -> make_rtl_for_nonlocal_decl
we have since PR70353 fix:
  /* We defer emission of local statics until the corresponding
 DECL_EXPR is expanded.  But with constexpr its function might never
 be expanded, so go ahead and tell cgraph about the variable now.  */
  defer_p = ((DECL_FUNCTION_SCOPE_P (decl)
  && !var_in_maybe_constexpr_fn (decl))
 || DECL_VIRTUAL_P (decl));
and so don't defer them in constexpr/consteval functions.  The following
patch calls rest_of_decl_compilation which make_rtl_for_nonlocal_decl
didn't
call when encountering DECL_EXPRs of such vars during constant evaluation
if they weren't finalized yet.

2023-03-04  Jakub Jelinek  

PR c++/108702
* constexpr.cc: Include toplev.h.
(cxx_eval_constant_expression) : When seeing a
local
static initialized by constant expression outside of a constexpr
function which has been deferred by make_rtl_for_nonlocal_decl,
call rest_of_decl_compilation on it.

* g++.dg/ext/stmtexpr19.C: Use dg-do link rather than dg-do
compile.

[Bug testsuite/108973] [13 Regression] Sufficiently narrow terminal window causes selftest failure

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

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

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

https://gcc.gnu.org/g:739e7ebb3d378ece25d64b39baae47c584253498

commit r13-6472-g739e7ebb3d378ece25d64b39baae47c584253498
Author: Jakub Jelinek 
Date:   Sat Mar 4 09:48:17 2023 +0100

diagnostics: Fix up selftests with $COLUMNS < 42 [PR108973]

As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS < 42.
Guarding each self-test with if (get_terminal_width () > 41) or similar
would be a maintainance nightmare (PR has a patch to do so without
reformatting to make it work for $COLUMNS in [30, 41] inclusive, but
I'm afraid going down to $COLUMNS 1 would mean marking everything).
Furthermore, the self-tests don't really emit stuff to the terminal,
but into a buffer, so using get_terminal_width () for it seems
inappropriate.  The following patch makes sure test_diagnostic_context
constructor uses exactly 80 columns wide caret max width, of course
some tests override it already if they want to test for behavior in
narrower
cases.

2023-03-04  Jakub Jelinek  

PR testsuite/108973
* selftest-diagnostic.cc
(test_diagnostic_context::test_diagnostic_context): Set
caret_max_width to 80.