[Bug tree-optimization/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2021-11-09
 Status|UNCONFIRMED |NEW
  Component|testsuite   |tree-optimization
 Target||arm
   Keywords||missed-optimization
 Ever confirmed|0   |1

--- Comment #11 from Richard Biener  ---
(In reply to Aldy Hernandez from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > (In reply to Aldy Hernandez from comment #7)
> > > > then size ivopts-4.o:
> > > >textdata bss dec hex filename
> > > >  38   0   0  38  26 ivopts-4.o
> > > > where the testcase expects text <= 36
> > > 
> > > Oh, this is an object size regression?  This test seems very fragile. 
> > > Jump threading will alter code size, so any change in the threading rules
> > > will likely have an effect on code size.  I suggest you add
> > > -fno-thread-jumps to the test and adjust the object-size test accordingly.
> > 
> > I tried that, it doesn't change the generated code.
> 
> The difference from before the commit til now is that there was a threading
> path that was valid but is now disallowed.  So adding -fno-thread-jumps
> won't have any effect since it won't cause the disallowed threading path to
> reappear.  What I'm saying is that the test should be calibrated to the new
> normal.
> 
> Of course, it could be that another pass should pick up the slack here, or
> that the restriction is too strict.  Richi, do you have some insight here?
> 
> At least for -Os  -mthumb -mfloat-abi=hard -mfpu=neon -mtls-dialect=gnu
> -mlibarch=armv7-a+mp+sec+neon-fp16 -march=armv7-a+mp+sec+neon-fp16, the
> difference in the threader is that we used to thread 6->4->3 in DOM2, but we
> no longer do so because doing so would rotate the loop:
> 
> a.c.127t.dom2:Path rotates loop:   Cancelling jump thread: (6, 4) incoming
> edge;  (4, 3) normal; 
> 
> I still think testing for some magic code size is fragile at best.

So it seems we intentionally allowed some loop header copying done by
the threader based on the idea that it knows when it can do so without
a code size penalty.  The loop header copying pass has

static bool
should_duplicate_loop_header_p (basic_block header, class loop *loop,
int *limit)
{
  gimple_stmt_iterator bsi;

  gcc_assert (!header->aux);

  /* Loop header copying usually increases size of the code.  This used not to
 be true, since quite often it is possible to verify that the condition is
 satisfied in the first iteration and therefore to eliminate it.  Jump
 threading handles these cases now.  */
  if (optimize_loop_for_size_p (loop)
  && !loop->force_vectorize)
{
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
 "  Not duplicating bb %i: optimizing for size.\n",
 header->index);
  return false;

and indeed for the testcase we have

Analyzing loop 1
Loop 1 is not do-while loop: latch is not empty.
  Not duplicating bb 4: optimizing for size.

and were probably expecting jump-threading to rotate the loop.  Now, the
forward threader is set up to eventually not destroy loop info but then
loop-header copying might be able to either use ranger to tell the
looping condition is always true [and the block to copy is empty] or
loop header copying could use the jump threading path code which might be
able to determine all this(?)

That said, for GCC 12 we probably need to look to allow those threadings,
but only once and for the forward threader?  The early threader doesn't
seem to discover this opportunity for some reason.

At the point we run jt_path_registry::cancel_invalid_paths do we have
any ideas about the size of the copying we do?

So the pattern we'd allow is a threading with entry being the single
entry edge into the loop and the exit being the other edge from the
single_exit source block of it.

I wonder why the late DOM threading doesn't catch this?  We'd allow
the threading there with

  if (cfun->curr_properties & PROP_loop_opts_done)
return false;

the late pass sees

   [local count: 200189151]:
  if (n_8(D) > 0)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 118111600]:
  ivtmp.9_16 = (unsigned int) array_9(D);
  _17 = (unsigned int) n_8(D);
  _18 = _17 * 4;
  _20 = ivtmp.9_16 + _18;
  goto ; [100.00%]

   [local count: 1073741824]:
  # sum_5 = PHI <0(3), sum_11(4)>
  # ivtmp.9_14 = PHI 
  if (ivtmp.9_14 != _20)
goto ; [89.00%]
  else
goto ; [11.00%]

so appearantly with IVCANON introducing a canonical IV ranger cannot
relate ivtmp.9_16 and _20 using the n_8(D) > 0 conditi

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

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

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

--- Comment #18 from Richard Biener  ---
The EVRP range_of_expr is not context sensitive and if EVRP is in effect the
EVRP active context is implicitely used, so when you try to ask for a different
context you won't get that contexts result but the active one which might
appear as "wrong result".

Not sure if that happens here but that's my guess.  And no, the EVRP
range_of_expr shouldn't return "wrong" results - but you can't ask it for
a context (the 'stmt' argument).

[Bug target/103151] New: ICE in extract_insn, at recog.c:2769 since r12-3407-g9e2a82e1f9d2c4af

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

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

Bug ID: 103151
   Summary: ICE in extract_insn, at recog.c:2769 since
r12-3407-g9e2a82e1f9d2c4af
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: crazylht at gmail dot com, hjl at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu

The following fails:

$ cat fp16.c
#include 
__m256h f11() {
  int i;
  __m256h z;
  z[i] = i;
  return z;
}

$ gcc fp16.c -c -O3 -mavx512fp16 -mxop -c
cat fp16.c: In function ‘f11’:
fp16.c:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 11 10 12 2 (set (reg:V16HF 89)
(if_then_else:V16HF (subreg:V16HF (reg:V16HI 94) 0)
(reg:V16HF 90)
(reg:V16HF 89))) "fp16.c":5:8 -1
 (nil))
during RTL pass: vregs
fp16.c:7:1: internal compiler error: in extract_insn, at recog.c:2769
0x755186 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0x7551a8 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:116
0x753313 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2769
0xbbe603 instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc/gcc/function.c:1611
0xbbe603 instantiate_virtual_regs
/home/marxin/Programming/gcc/gcc/function.c:1985
0xbbe603 execute
/home/marxin/Programming/gcc/gcc/function.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/103151] ICE in extract_insn, at recog.c:2769 since r12-3407-g9e2a82e1f9d2c4af

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-09
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
  Known to fail||12.0

[Bug testsuite/102690] [11/12 regression] g++.dg/warn/Warray-bounds-16.C fails

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.0|11.3
Summary|[12 regression] |[11/12 regression]
   |g++.dg/warn/Warray-bounds-1 |g++.dg/warn/Warray-bounds-1
   |6.C fails   |6.C fails
  Component|tree-optimization   |testsuite
   Priority|P3  |P1

--- Comment #6 from Richard Biener  ---
Yes.  Whatever solution we find for the testcase needs to be backported as
well.

[Bug fortran/103137] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8181 since r12-4967-gbcf3728abe848888

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |gfc_simplify_transpose, at  |gfc_simplify_transpose, at
   |fortran/simplify.c:8181 |fortran/simplify.c:8181
   ||since
   ||r12-4967-gbcf3728abe84
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r12-4967-gbcf3728abe84.

[Bug fortran/103138] [12 Regression] ICE in gfc_simplify_cshift, at fortran/simplify.c:2139 since r12-4967-gbcf3728abe848888

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |gfc_simplify_cshift, at |gfc_simplify_cshift, at
   |fortran/simplify.c:2139 |fortran/simplify.c:2139
   ||since
   ||r12-4967-gbcf3728abe84
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r12-4967-gbcf3728abe84.

[Bug fortran/103139] [12 Regression] ICE in fold_convert_loc, at fold-const.c:2573 since r12-4464-g017665f63047ce47

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |fold_convert_loc, at|fold_convert_loc, at
   |fold-const.c:2573   |fold-const.c:2573 since
   ||r12-4464-g017665f63047ce47
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-09

--- Comment #2 from Martin Liška  ---
Started with r12-4464-g017665f63047ce47.

[Bug libstdc++/103146] [12 Regression] libstdc++-v3 bootstrap failure on 32-bit BE powerpc since r12-4952

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/103148] ICE in vect_analyze_loop, at tree-vect-loop.c:3155

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Fixed with g:51152076338bc60b8bda8f061be2db97ea5b78de.

[Bug target/103151] ICE in extract_insn with __m256h and variable vec insert and -O1 -mavx512fp16 -mxop since r12-3407-g9e2a82e1f9d2c4af

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
Mine.

[Bug tree-optimization/103152] New: wrong code at -O1 on x86_64-linux-gnu

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

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

Bug ID: 103152
   Summary: wrong code at -O1 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression.

[577] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211109 (experimental) [master r12-5011-g2abd924f91e] (GCC) 
[578] % 
[578] % gcctk -O0 small.c; ./a.out
[579] % 
[579] % gcctk -O1 small.c
[580] % ./a.out
Aborted
[581] % 
[581] % cat small.c
struct {
  int a:1;
} b;
int *c = (int *)&b, d;
int main() {
  d = c && (b.a = (d < 0) ^ 3);
  if (d != 1)
__builtin_abort();
  return 0;
}

[Bug tree-optimization/103152] [11/12 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-5890-g7d9767cb8eea0f21

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-09
Summary|wrong code at -O1 on|[11/12 Regression] wrong
   |x86_64-linux-gnu|code at -O1 on
   ||x86_64-linux-gnu since
   ||r11-5890-g7d9767cb8eea0f21

--- Comment #1 from Martin Liška  ---
Started with r11-5890-g7d9767cb8eea0f21.

[Bug tree-optimization/103152] [11/12 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-5890-g7d9767cb8eea0f21

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
   Keywords||wrong-code

--- Comment #2 from Andrew Pinski  ---
Mine.

[Bug tree-optimization/103152] [11/12 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-5890-g7d9767cb8eea0f21

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

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

--- Comment #3 from Andrew Pinski  ---
This is another signed one bit integer issue.

[Bug tree-optimization/103152] [12 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-5890-g7d9767cb8eea0f21

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||12.0
  Known to work||11.1.0, 11.2.0
   Target Milestone|11.3|12.0
Summary|[11/12 Regression] wrong|[12 Regression] wrong code
   |code at -O1 on  |at -O1 on x86_64-linux-gnu
   |x86_64-linux-gnu since  |since
   |r11-5890-g7d9767cb8eea0f21  |r11-5890-g7d9767cb8eea0f21

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Liška from comment #1)
> Started with r11-5890-g7d9767cb8eea0f21.

Yes and no.
Tthis was actually fixed for GCC 11 by r11-7587-b610c30453d8 (you can confirm
that if you want).

I messed up r12-4276-882d806c1a8 and added an extra TYPE_PRECISION (type) != 1
which should not have been there. Removing the extra TYPE_PRECISION (type) != 1
check fixes this issue too.

[Bug tree-optimization/103152] [12 Regression] wrong code at -O1 on x86_64-linux-gnu since r12-1055-gb6bdd7a4cb41ee0

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Martin Liška from comment #1)
> > Started with r11-5890-g7d9767cb8eea0f21.
> 
> Yes and no.
> Tthis was actually fixed for GCC 11 by r11-7587-b610c30453d8 (you can
> confirm that if you want).

Note the latent issue (been since ?-1:0 was added to GCC 9) on GCC 10 and 9
were fixed by r10-10177-g4111b36079fe and r9-9765-g77867cd8185 (and didn't have
the issue which I accidently did for the trunk). So this is trunk only issue
still.

[Bug testsuite/103042] gcc.dg/vect/complex/bb-slp-complex-add-pattern-unsigned-long.c etc. FAIL

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

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

--- Comment #7 from Tamar Christina  ---
> gcc/testsuite/gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-double.c

This one running is odd, it's guarded by vect_double which doesn't match
sparc-*-*-*.  That should be unresolved now.

[Bug tree-optimization/103152] [12 Regression] wrong code at -O1 on x86_64-linux-gnu since r12-1055-gb6bdd7a4cb41ee0

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 51754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51754&action=edit
Patch which I will commit after bootstrap/test

Here is the patch which I am testing to remove the accidenly committed check. 
I did check to make sure it fixed the problem.

Note the problem showed up recently due to threading differences I think; it
has been definitely latent others.

[Bug target/99657] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/583786.html
   Keywords||patch

--- Comment #9 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583786.html

[Bug c++/103153] New: The recursive call in C++ leads to crashes of GCC.

[xiaxm at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 103153
   Summary: The recursive call in C++ leads to crashes of GCC.
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiaxm at smail dot nju.edu.cn
  Target Milestone: ---

The following code can be well compiled, however when execute it, GCC crashes
with segmentation fault.


#include 
#include 
int main(){
   try{
   throw -1;
   }
   catch(int e){
   main();
   }
   return 0;
}


Segmentation fault (core dumped)

gcc version 9.3.0 on Ubuntu 20.04

[Bug c++/103153] The recursive call in C++ leads to crashes of GCC.

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-11-09

--- Comment #1 from Martin Liška  ---
Well, the code causes a stack overflow, it's invalid if I see correctly.

[Bug c++/103153] The recursive call in C++ leads to crashes of GCC.

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

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

--- Comment #2 from Martin Liška  ---
g++ pr103153.C && valgrind ./a.out
==1687== Memcheck, a memory error detector
==1687== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1687== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info
==1687== Command: ./a.out
==1687== 
==1687== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==1687== 
==1687== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==1687==  Access not within mapped region at address 0x1FFE801FE8
==1687== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==1687==at 0x4B9D520: get_cie_encoding (unwind-dw2-fde.c:300)
==1687==  If you believe this happened as a result of a stack
==1687==  overflow in your program's main thread (unlikely but
==1687==  possible), you can try to increase the size of the
==1687==  main thread stack using the --main-stacksize= flag.
==1687==  The main thread stack size used in this run was 8388608.
==1687== Stack overflow in thread #1: can't grow stack to 0x1ffe801000

[Bug c++/103153] The recursive call in C++ leads to crashes of GCC.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
"however when execute it"

Yes because the code has an infinite stack usage.

[Bug c++/103153] The recursive call in C++ leads to crashes of GCC.

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

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

--- Comment #4 from Jakub Jelinek  ---
The code is invalid both because of the endless recursion into which it runs
and because in C++ main can't be called.  See
https://eel.is/c++draft/basic.start.main#3

[Bug ipa/103132] [12 Regression] ICE in remap_gimple_stmt at tree-inline.c:1828 since r12-4920-g1ece90ffa9ce63b4

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r12-5045-gdf8690f28379795a44aa4b6c737df08828168b6a
Author: Martin Jambor 
Date:   Tue Nov 9 11:32:20 2021 +0100

ipa: Fix segfault when remapping debug_binds with expressions (PR 103132)

My initial implementation of the method
ipa_param_body_adjustments::remap_with_debug_expressions was based on
the assumption that if it was asked to remap an expression (as opposed
to a simple SSA_NAME), the expression would not contain an SSA_NAME
operand which is to be debug-reset.  While that is true for when
called from ipa_param_body_adjustments::prepare_debug_expressions, it
turns out it is not true when invoked from remap_gimple_stmt in
tree-inline.c.  This patch adds a simple logic to handle such cases
and simply map the entire value to NULL_TREE in those cases.

gcc/ChangeLog:

2021-11-08  Martin Jambor  

PR ipa/103132
* ipa-param-manipulation.c (replace_with_mapped_expr): Early
return with error_mark_mode when part of expression is mapped to
NULL.
(ipa_param_body_adjustments::remap_with_debug_expressions): Set
mapped value to NULL if walk_tree returns error_mark_mode.

gcc/testsuite/ChangeLog:

2021-11-08  Martin Jambor  

PR ipa/103132
* gcc.dg/ipa/pr103132.c: New test.

[Bug c++/103153] The recursive call in C++ leads to crashes of GCC.

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Xinmeng Xia from comment #0)
> The following code can be well compiled, however when execute it, GCC
> crashes with segmentation fault.

No, your program crashes, GCC doesn't.

Any use of main is undefined in C++, especially calling it. This program is
just broken and of course it crashes.

[Bug ipa/103132] [12 Regression] ICE in remap_gimple_stmt at tree-inline.c:1828 since r12-4920-g1ece90ffa9ce63b4

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
Fixed.  Thanks for testing and sorry for the breakage.

[Bug libgcc/103004] [12 regression] r12-4416 breaks backtrace on PPC64 Big-endian

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

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

--- Comment #2 from Jonathan Wakely  ---
I see this on powerpc64le-unknown-linux-gnu:

./md-unwind-support.h:398:6: warning: no previous prototype for
‘ppc_backchain_fallback’ [-Wmissing-prototypes]

[Bug libgcc/103004] [12 regression] r12-4416 breaks backtrace on PPC64 Big-endian

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I think the warning should be fixed with following, just need to test it:

--- libgcc/config/rs6000/linux-unwind.h.jj  2021-10-15 11:59:16.227682621
+0200
+++ libgcc/config/rs6000/linux-unwind.h 2021-11-09 11:42:06.840353422 +0100
@@ -395,7 +395,8 @@ struct frame_layout
 };


-void ppc_backchain_fallback (struct _Unwind_Context *context, void *a)
+static void
+ppc_backchain_fallback (struct _Unwind_Context *context, void *a)
 {
   struct frame_layout *current;
   struct trace_arg *arg = a;

[Bug fortran/103154] New: Crashing gfortran due to bad type parameter specification

[b.j.braams at cwi dot nl via Gcc-bugs]

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

Bug ID: 103154
   Summary: Crashing gfortran due to bad type parameter
specification
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.j.braams at cwi dot nl
  Target Milestone: ---

The following code is bad, it uses the undeclared variable k. This causes
gfortran to crash with an error message requesting the issue to be reported. I
obey.

Version information:
bash-5.0$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.1 20210422 (Red Hat 10.3.1-1) (GCC) 

Command line invocation acting on file Test.f90
bash-5.0$ gfortran Test.f90

System response
internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1120
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The file Test.f90 that triggers the internal error:
bash-5.0$ cat Test.f90
module Test
  implicit none
  type :: Test_Type (n)
 integer, len :: n
  end type Test_Type
contains
  subroutine Sub ()
! Crashing gfortran 9.3.1
type (Test_Type(n=k)) :: foo
return
  end subroutine Sub
end module Test

[Bug debug/103134] Redundant DW_AT_entry_pc tags for inlined functions

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-09

--- Comment #1 from Richard Biener  ---
Might be something for DWZ, I'm not sure it's easy enough to determine this
from dwarf2out.c

[Bug fortran/103137] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8181 since r12-4967-gbcf3728abe848888

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/103138] [12 Regression] ICE in gfc_simplify_cshift, at fortran/simplify.c:2139 since r12-4967-gbcf3728abe848888

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |12.0

[Bug fortran/103139] [12 Regression] ICE in fold_convert_loc, at fold-const.c:2573 since r12-4464-g017665f63047ce47

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P4

[Bug debug/103135] DW_AT_high_pc 0 offset for inlined functions with a singled instruction

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-09
 Ever confirmed|0   |1
 CC||aoliva at gcc dot gnu.org
 Target||x86_64-*-*

--- Comment #1 from Richard Biener  ---
The issue is likely that we have combined the bit test and the compare:

(note 77 86 78 2 t4.c:4 NOTE_INSN_INLINE_ENTRY)
(note 78 77 87 2 t4.c:6 NOTE_INSN_BEGIN_STMT)
(note 87 78 56 2 (var_location i (nil) [uninit]) NOTE_INSN_VAR_LOCATION)
(insn:TI 56 87 24 2 (set (reg:CCZ 17 flags)
(compare:CCZ (and:QI (reg:QI 4 si [orig:83 val.1_2 ] [83])
(const_int 1 [0x1]))
(const_int 0 [0]))) "t4.c":13:5 502 {*testqi_1_maybe_si}
 (nil))
(jump_insn 24 56 25 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 33)
(pc))) "t4.c":13:5 855 {*jcc}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 536870916 (nil)))

and thus no instruction remains in the inlined instance.  For reference, at
GIMPLE we still have

  [t4.c:4:12] # DEBUG INLINE_ENTRY isodd
  [t4.c:6:2] # DEBUG BEGIN_STMT
  [t4.c:6:11] _6 = val.1_2 & 1;
  [t4.c:13:6] # DEBUG i => NULL
  [t4.c:13:5] if (_6 != 0)

and the assembly is

testb   $1, %sil
je  .L2

so it's basically "unfortunate" combination of the CC set with the
bit test location.  Alex, is there a "feature" we have to capture
this somehow?

[Bug fortran/103137] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8181 since r12-4967-gbcf3728abe848888

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug middle-end/103143] [12 Regression] ICE due to infinite recursion in pointer-query.cc

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug ipa/103155] New: [12 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:813

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103155
   Summary: [12 Regression] ICE in get_expr_operands, at
tree-ssa-operands.c:813
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51755&action=edit
Partially reduced testcase

g++-12.0.0-alpha20211107 snapshot (g:962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6)
ICEs when compiling the following line, extracted from
libstdc++-v3/testsuite/performance/ext/pb_ds/priority_queue_text_pop_mem.cc, w/
-std=c++20 -O3 -fopenacc -g --param ipa-cp-eval-threshold=0
-Ilibstdc++-v3/testsuite/util:

#include 

% g++-12.0.0 -std=c++20 -O3 -fopenacc -g --param ipa-cp-eval-threshold=0
-Ilibstdc++-v3/testsuite/util -c tvl87d85.cc
during IPA pass: inline
In function 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::pointer
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_create(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type&, std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator]':
cc1plus: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:813
0x839310 operands_scanner::get_expr_operands(tree_node**, int)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-operands.c:813
0x13198e9 operands_scanner::get_expr_operands(tree_node**, int)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-operands.c:834
0x131a53f operands_scanner::parse_ssa_operands()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-operands.c:990
0x131b3eb operands_scanner::build_ssa_operands()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-operands.c:1005
0x131b4ff update_stmt_operands(function*, gimple*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-ssa-operands.c:1147
0xe52a56 update_stmt_if_modified
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/gimple-ssa.h:185
0xe52a56 update_stmt_if_modified
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/gimple-ssa.h:182
0xe52a56 update_modified_stmt
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/gimple-iterator.c:44
0xe52a56 gsi_insert_after(gimple_stmt_iterator*, gimple*, gsi_iterator_update)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/gimple-iterator.c:544
0xe4932f gimple_seq_add_stmt(gimple**, gimple*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/gimple.c:1315
0x11fe566 remap_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-inline.c:2014
0x1203003 copy_bb
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-inline.c:2054
0x1204622 copy_cfg_body
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-inline.c:3088
0x1204622 copy_body
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-inline.c:3341
0x1207693 tree_function_versioning(tree_node*, tree_node*,
vec*, ipa_param_adjustments*, bool,
bitmap_head*, basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/tree-inline.c:6369
0xcdf5ec cgraph_node::materialize_clone()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/cgraphclones.c:1141
0xccd8a5 cgraph_node::get_untransformed_body()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/cgraph.c:3907
0xcdf47f cgraph_node::materialize_clone()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/cgraphclones.c:
0xccd8a5 cgraph_node::get_untransformed_body()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/cgraph.c:3907
0xf28857 maybe_materialize_called_clones
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/ipa-inline-transform.c:720

Partially reduced contents of that file is in attachment.

[Bug debug/103135] DW_AT_high_pc 0 offset for inlined functions with a singled instruction

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Isn't this TER in action?

[Bug debug/103135] DW_AT_high_pc 0 offset for inlined functions with a singled instruction

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

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

--- Comment #3 from Jakub Jelinek  ---
And, I'm afraid there is nothing in DWARF that would allow locations at
sub-instruction boundaries.  Each insn has to have just one location, so either
it gets the location of the and, or location of the comparison, but can't have
both.

[Bug tree-optimization/103144] vectorizer failed to recognize shift>>=1 in loop as shift>>i

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-09
 Blocks||53947
 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
There are two choices.

1) implement more general induction support and vectorize it as

shiftv = { shift, shift >>1, shift>>2, shift>>3 };
for (int64_t i = 0; i != 64; i++)
{
  pdst[i] = psrc[i] + shiftv;
  shiftv >>= {4, 4, 4, 4};
}

(I think I've seen related bugreports doing bit-flip "induction" with XOR)

2) add the ability to have patterns for PHIs and do what you suggest,
pattern-replacing the shift PHI def with a non-PHI pattern shift >> i
after doing cycle analysis - then the PHI and the shift >>= 1 should become
!STMT_VINFO_RELEVANT.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug libstdc++/103146] [12 Regression] libstdc++-v3 bootstrap failure on 32-bit BE powerpc since r12-4952

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/103151] ICE in extract_insn with __m256h and variable vec insert and -O1 -mavx512fp16 -mxop since r12-3407-g9e2a82e1f9d2c4af

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.0|---
 Target||x86_64-*-*

[Bug target/93453] PPC: rldimi not taken into account to avoid shift+or

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

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

--- Comment #3 from Segher Boessenkool  ---
Splitters run after all RTL transforms, so anything that can be done on the
split result has to be done manually.  This does not scale.  Splitters are
not suitable for this kind of thing.

You can do define_insns to recognise some special case rl*imi patterns we do
not yet recognise.

[Bug other/103157] New: 'gengtype': 'typedef' causing infinite-recursion code to be generated

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

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

Bug ID: 103157
   Summary: 'gengtype': 'typedef' causing infinite-recursion code
to be generated
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

As we found in the course of PR101204, there are ways that certain use of
'typedef' with GTY-marked types causes 'gengtype' to generate
infinite-recursion code.

[Bug other/103157] 'gengtype': 'typedef' causing infinite-recursion code to be generated

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

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

--- Comment #1 from Andrew Pinski  ---
There is a dup of this bug already

[Bug other/103157] 'gengtype': 'typedef' causing infinite-recursion code to be generated

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r12-5047-gc71cb26a9e841888f52e4bfcaad94c8f8ecb4fdb
Author: Thomas Schwinge 
Date:   Tue Nov 9 10:55:15 2021 +0100

Get rid of infinite recursion for 'typedef' used with GTY-marked
'gcc/diagnostic-spec.h:nowarn_map' [PR101204, PR103157]

Reproduced with clang version 10.0.0-4ubuntu1:

gtype-desc.c:11333:1: warning: all paths through this function will
call itself [-Winfinite-recursion]

... as well as some GCC's '-O2 -fdump-tree-optimized':

void gt_pch_nx(int_hash*,
gt_pointer_operator, void*) ([...])
{
  :

  :
  goto ;

}

That three-arguments 'gt_pch_nx' function as well as two one-argument
'gt_ggc_mx', 'gt_pch_nx' functions now turn empty:

[...]
 void
-gt_ggc_mx (int_hash& x_r ATTRIBUTE_UNUSED)
+gt_ggc_mx (struct xint_hash_t& x_r ATTRIBUTE_UNUSED)
 {
-  int_hash * ATTRIBUTE_UNUSED x = &x_r;
-  gt_ggc_mx (&((*x)));
+  struct xint_hash_t * ATTRIBUTE_UNUSED x = &x_r;
 }
[...]
 void
-gt_pch_nx (int_hash& x_r ATTRIBUTE_UNUSED)
+gt_pch_nx (struct xint_hash_t& x_r ATTRIBUTE_UNUSED)
 {
-  int_hash * ATTRIBUTE_UNUSED x = &x_r;
-  gt_pch_nx (&((*x)));
+  struct xint_hash_t * ATTRIBUTE_UNUSED x = &x_r;
 }
[...]
 void
-gt_pch_nx (int_hash* x ATTRIBUTE_UNUSED,
+gt_pch_nx (struct xint_hash_t* x ATTRIBUTE_UNUSED,
ATTRIBUTE_UNUSED gt_pointer_operator op,
ATTRIBUTE_UNUSED void *cookie)
 {
-gt_pch_nx (&((*x)), op, cookie);
 }
[...]

gcc/
PR middle-end/101204
PR other/103157
* diagnostic-spec.h (typedef xint_hash_t): Turn into...
(struct xint_hash_t): ... this.
* doc/gty.texi: Update.

[Bug middle-end/101204] [12 Regression] infinite recursion in gtype-desc.c since r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r12-5047-gc71cb26a9e841888f52e4bfcaad94c8f8ecb4fdb
Author: Thomas Schwinge 
Date:   Tue Nov 9 10:55:15 2021 +0100

Get rid of infinite recursion for 'typedef' used with GTY-marked
'gcc/diagnostic-spec.h:nowarn_map' [PR101204, PR103157]

Reproduced with clang version 10.0.0-4ubuntu1:

gtype-desc.c:11333:1: warning: all paths through this function will
call itself [-Winfinite-recursion]

... as well as some GCC's '-O2 -fdump-tree-optimized':

void gt_pch_nx(int_hash*,
gt_pointer_operator, void*) ([...])
{
  :

  :
  goto ;

}

That three-arguments 'gt_pch_nx' function as well as two one-argument
'gt_ggc_mx', 'gt_pch_nx' functions now turn empty:

[...]
 void
-gt_ggc_mx (int_hash& x_r ATTRIBUTE_UNUSED)
+gt_ggc_mx (struct xint_hash_t& x_r ATTRIBUTE_UNUSED)
 {
-  int_hash * ATTRIBUTE_UNUSED x = &x_r;
-  gt_ggc_mx (&((*x)));
+  struct xint_hash_t * ATTRIBUTE_UNUSED x = &x_r;
 }
[...]
 void
-gt_pch_nx (int_hash& x_r ATTRIBUTE_UNUSED)
+gt_pch_nx (struct xint_hash_t& x_r ATTRIBUTE_UNUSED)
 {
-  int_hash * ATTRIBUTE_UNUSED x = &x_r;
-  gt_pch_nx (&((*x)));
+  struct xint_hash_t * ATTRIBUTE_UNUSED x = &x_r;
 }
[...]
 void
-gt_pch_nx (int_hash* x ATTRIBUTE_UNUSED,
+gt_pch_nx (struct xint_hash_t* x ATTRIBUTE_UNUSED,
ATTRIBUTE_UNUSED gt_pointer_operator op,
ATTRIBUTE_UNUSED void *cookie)
 {
-gt_pch_nx (&((*x)), op, cookie);
 }
[...]

gcc/
PR middle-end/101204
PR other/103157
* diagnostic-spec.h (typedef xint_hash_t): Turn into...
(struct xint_hash_t): ... this.
* doc/gty.texi: Update.

[Bug middle-end/101204] [12 Regression] infinite recursion in gtype-desc.c since r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #9 from Thomas Schwinge  ---
This is now resolved; PR103157 remains open for resolving the actual 'gengtype'
issue.

[Bug c++/88232] Please implement -Winfinite-recursion

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
Such a '-Winfinite-recursion' diagnostic would've been helpful for
PR101204/PR103157 (meaning: prevented/flagged that issue early, via a GCC
build-time '-Werror' diagnostic).

[Bug tree-optimization/100253] [10 Regression] wrong code with -O2 -fno-tree-bit-ccp -ftree-slp-vectorize (unaligned movdqa)

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

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

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

https://gcc.gnu.org/g:92ffe7c3b6ffee8fd6ef92a5b3b4cc09263b01ee

commit r10-10260-g92ffe7c3b6ffee8fd6ef92a5b3b4cc09263b01ee
Author: Richard Biener 
Date:   Thu Apr 29 11:52:08 2021 +0200

tree-optimization/100253 - fix bogus aligned vectorized loads/stores

At some point DR_MISALIGNMENT was supposed to be -1 when the
access was not element aligned.  That's obviously not true at this
point so this adjusts both store and load vectorizing to no longer
assume this which in turn allows simplifying the code.

2021-04-29  Richard Biener  

PR tree-optimization/100253
* tree-vect-stmts.c (vectorizable_load): Do not assume
element alignment when DR_MISALIGNMENT is -1.
(vectorizable_store): Likewise.

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

[Bug middle-end/100672] wrong code with vector shift and unary minus

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

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

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

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

commit r10-10261-ge8311f59c6e2fa1f5aacc3da5e95739886ebdee7
Author: Richard Biener 
Date:   Wed May 19 13:35:07 2021 +0200

middle-end/100672 - fix bogus right shift folding

This fixes the bogus use of TYPE_PRECISION on vector types
from optimizing -((int)x >> 31) into (unsigned)x >> 31.

2021-05-19  Richard Biener  

PR middle-end/100672
* fold-const.c (fold_negate_expr_1): Use element_precision.
(negate_expr_p): Likewise.

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

(cherry picked from commit 8d51039cb7c807ed84ff7df5416a1e3ba07a5e63)

[Bug tree-optimization/102714] [10 Regression] A volatile-related problem cased by ipa inline pass

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

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

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

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

commit r10-10262-g8d016315a95cf4d9b72ee8f299e466457ca154b3
Author: Richard Biener 
Date:   Wed Oct 13 09:13:36 2021 +0200

ipa/102714 - IPA SRA eliding volatile

The following fixes the volatileness check of IPA SRA which was
looking at the innermost reference when checking TREE_THIS_VOLATILE
but the reference to check is the outermost one.

2021-10-13  Richard Biener  

PR ipa/102714
* ipa-sra.c (ptr_parm_has_nonarg_uses): Fix volatileness
check.

* gcc.dg/ipa/pr102714.c: New testcase.

(cherry picked from commit 23cd18c60c8188e3d68eda721cdb739199e85e5b)

[Bug tree-optimization/102714] [10 Regression] A volatile-related problem cased by ipa inline pass

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.3.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||10.3.1

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

[Bug tree-optimization/100253] [10 Regression] wrong code with -O2 -fno-tree-bit-ccp -ftree-slp-vectorize (unaligned movdqa)

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to fail|10.3.1  |10.3.0
  Known to work||10.3.1

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

[Bug ipa/103155] [12 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:813

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
Hm, I can't reproduce the problem, both for the partially reduced testcase and
the including line.

[Bug fortran/103154] Crashing gfortran due to bad type parameter specification since r8-3181-g87f3a5cfb59347cd

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-09
Summary|Crashing gfortran due to|Crashing gfortran due to
   |bad type parameter  |bad type parameter
   |specification   |specification since
   ||r8-3181-g87f3a5cfb59347cd
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r8-3181-g87f3a5cfb59347cd.

[Bug debug/101378] Negative DW_AT_data_member_location

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

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

--- Comment #4 from Jonathan Wakely  ---
The C++ standard forbids two objects of the same type having the same address.
That is true for the empty base-class optimization and it's true for
[[no_unique_address]].

[intro.object]

> Two objects with overlapping lifetimes that are not bit-fields may have the
> same address if one is nested within the other, or if at least one is a
> subobject of zero size and they are of different types; otherwise, they have
> distinct addresses and occupy disjoint bytes of storage.

There is a footnote that says:

> Under the “as-if” rule an implementation is allowed to store two objects at
> the same machine address or not store an object at all if the program cannot
> observe the difference.

But I don't think GCC does that, because if some property that is reflected in
the debuginfo would allow you to observe the difference, then it's not allowed.

[Bug debug/101378] Negative DW_AT_data_member_location

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

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

--- Comment #5 from Jonathan Wakely  ---
... and if the type is visible outside a single translation unit, then it needs
to follow the layout mandated by the ABI anyway, or it would violate the
One-Definition Rule.

[Bug fortran/103158] New: ICE on arithmetic with type parameter

[b.j.braams at cwi dot nl via Gcc-bugs]

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

Bug ID: 103158
   Summary: ICE on arithmetic with type parameter
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.j.braams at cwi dot nl
  Target Milestone: ---

(Different from Bug fortran/103154 reported a bit earlier, but perhaps
related.)

The following code triggers an internal compiler error. I believe that the code
is correct, and ice is anyway undesirable. Compilation proceeds fine if the
declaration expression x(0:n-1) is replaced by x(n), also fine if x(0:n) is
declared, but code triggers ice again for declaration x(2*n). Any arithmetic on
the length parameter n seems to trigger the ice.

Version information:
bash-5.0$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.1 20210422 (Red Hat 10.3.1-1) (GCC) 

Command line invocation for file Test.f90 and system response:
bash-5.0$ gfortran Test.f90
Test.f90:15:20:

   15 |   end subroutine foo
  |1
internal compiler error: in gfc_conv_expr_op, at fortran/trans-expr.c:3782
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Content of file Test.f90:
bash-5.0$ cat Test.f90
module test
  implicit none
  private
  public :: foo
  type, public :: test_type (n)
 integer, len :: n = 0
 integer :: x(0:n-1)
  end type test_type
contains
  subroutine foo (k)
integer, intent (in) :: k
type (test_type(n=k)) :: tt0
tt0%x = 0
return
  end subroutine foo
end module test

[Bug middle-end/100672] wrong code with vector shift and unary minus

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

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

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

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

commit r9-9820-gcc589cc7923b048b2722980cac69463b6f2e1941
Author: Richard Biener 
Date:   Wed May 19 13:35:07 2021 +0200

middle-end/100672 - fix bogus right shift folding

This fixes the bogus use of TYPE_PRECISION on vector types
from optimizing -((int)x >> 31) into (unsigned)x >> 31.

2021-05-19  Richard Biener  

PR middle-end/100672
* fold-const.c (fold_negate_expr_1): Use element_precision.
(negate_expr_p): Likewise.

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

(cherry picked from commit 8d51039cb7c807ed84ff7df5416a1e3ba07a5e63)

[Bug middle-end/100672] wrong code with vector shift and unary minus

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail|9.3.1   |9.3.0
  Known to work||9.3.1

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

[Bug debug/103134] Redundant DW_AT_entry_pc tags for inlined functions

[wcohen at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Will Cohen  ---
Filed a dwz bug (https://sourceware.org/bugzilla/show_bug.cgi?id=28568) as an
alternative was to address the redundant DW_AT_entry_pc.

[Bug c++/100652] Unexpanded parameter pack in partial specialization of variable template not rejected

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

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

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

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

commit r12-5052-ga19f09cb03d7f69377e6d12162e5d6df78a82849
Author: Patrick Palka 
Date:   Tue Nov 9 09:09:12 2021 -0500

c++: unexpanded pack in var tmpl partial spec [PR100652]

Here we're failing to spot a bare parameter pack appearing in the argument
list of a variable template partial specialization because we only look for
them within the decl's TREE_TYPE, which is sufficient for class templates
but not for variable templates.

PR c++/100652

gcc/cp/ChangeLog:

* pt.c (push_template_decl): Check for bare parameter packs in
the argument list of a variable template partial specialization.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ69.C: New test.

[Bug c++/85846] [Concepts] Concept as value in initializer: bogus declared-as-implicit-template error

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

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

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

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

commit r12-5053-ga22d910305a5232694ff48ead37a7f53e46b7202
Author: Patrick Palka 
Date:   Tue Nov 9 09:09:43 2021 -0500

c++: bogus error w/ tentative type parse of concept-id [PR98394]

Here when tentatively parsing the if condition as a declaration, we try
to treat C<1> as the start of a constrained placeholder type, which we
quickly reject because C doesn't accept a type as its first argument.
But since we're parsing tentatively, we shouldn't emit an error in this
case.

In passing, also fix PR85846 by only overriding 'tentative' to false when
given a concept-name, and not also when given a concept-id that has an
empty
argument list.

PR c++/98394
PR c++/85846

gcc/cp/ChangeLog:

* parser.c (cp_parser_placeholder_type_specifier): Declare
static.  Don't override tentative to false when tmpl is a
concept-id with empty argument list.  Don't emit a "does not
constrain a type" error when tentative.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-pr98394.C: New test.
* g++.dg/cpp2a/concepts-pr85846.C: New test.

[Bug c++/98394] Concept with auto... template parameter pack in if-statement causes compilation error

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

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

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

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

commit r12-5053-ga22d910305a5232694ff48ead37a7f53e46b7202
Author: Patrick Palka 
Date:   Tue Nov 9 09:09:43 2021 -0500

c++: bogus error w/ tentative type parse of concept-id [PR98394]

Here when tentatively parsing the if condition as a declaration, we try
to treat C<1> as the start of a constrained placeholder type, which we
quickly reject because C doesn't accept a type as its first argument.
But since we're parsing tentatively, we shouldn't emit an error in this
case.

In passing, also fix PR85846 by only overriding 'tentative' to false when
given a concept-name, and not also when given a concept-id that has an
empty
argument list.

PR c++/98394
PR c++/85846

gcc/cp/ChangeLog:

* parser.c (cp_parser_placeholder_type_specifier): Declare
static.  Don't override tentative to false when tmpl is a
concept-id with empty argument list.  Don't emit a "does not
constrain a type" error when tentative.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-pr98394.C: New test.
* g++.dg/cpp2a/concepts-pr85846.C: New test.

[Bug c++/100652] Unexpanded parameter pack in partial specialization of variable template not rejected

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12.

[Bug c++/98394] Concept with auto... template parameter pack in if-statement causes compilation error

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-09
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.3

[Bug c++/85846] [Concepts] Concept as value in initializer: bogus declared-as-implicit-template error

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |11.3
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug c++/103159] New: -Wuninitialized should not depend on optimization level

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

Bug ID: 103159
   Summary: -Wuninitialized should not depend on optimization
level
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

Consider the following:

```
% cat undef.cxx
#include 

class C
{
int I;
public:
int getI() { return I; }
};

int main()
{
C c;
std::cout << c.getI() << std::endl;

return 0;
}
```

It is counter-intuitive to explicitely use -O2 to have a warning reported.
Compare the output of:

```
% g++ -o undef -Wuninitialized undef.cxx && ./undef
0
```

While:

```
% g++ -O2 -o undef -Wuninitialized undef.cxx && ./undef
undef.cxx: In function ‘int main()’:
undef.cxx:7:25: warning: ‘c.C::I’ is used uninitialized in this function
[-Wuninitialized]
7 | int getI() { return I; }
  | ^
0
```

[Bug debug/101378] Negative DW_AT_data_member_location

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #6 from Richard Biener  ---
Still the DWARF looks incorrect.

[Bug c++/103159] -Wuninitialized should not depend on optimization level

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Mathieu Malaterre  ---
Just to be sure, here is the actual command I had been starring at for a while:

```
% g++ -o undef -fsanitize=undefined -Wuninitialized undef.cxx && ./undef
21845
```

Maybe I got confused with `-fsanitize=undefined` and (maybe?) g++ behavior at
default -O0 really does initialize all members in the class...

In any case my usual rule of thumb is to remove optimization flag when doing
debug/high warning level compilation.

[Bug debug/101378] Negative DW_AT_data_member_location

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

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

--- Comment #7 from Jakub Jelinek  ---
I must say I don't understand why we do that PCC_BITFIELD_TYPE_MATTERS stuff in
dwarf2out.c (field_byte_offset) for non-bitfields, I don't understand why
byte_position (decl) wouldn't work just fine.  After all, stor-layout.c also
doesn't do anything special for PCC_BITFIELD_TYPE_MATTERS unless DECL_BIT_FIELD
or DECL_BIT_FIELD_TYPE.  At least for C/C++, bitfields should have reasonable
type sizes one can actually use (Ada has aggregate bitfields I think though),
while non-bitfields can be e.g. the C++ classes that have TYPE_SIZE
BITS_PER_UNIT, but DECL_SIZE of 0, which is why we are getting those negative
offsets.

2021-11-09  Jakub Jelinek  

PR debug/101378
* dwarf2out.c (field_byte_offset): Do the PCC_BITFIELD_TYPE_MATTERS
handling only for DECL_BIT_FIELD decls.

* g++.dg/debug/dwarf2/pr101378.C: New test.

--- gcc/dwarf2out.c.jj  2021-11-05 10:19:46.339457342 +0100
+++ gcc/dwarf2out.c 2021-11-09 15:01:51.425437717 +0100
@@ -19646,6 +19646,7 @@ field_byte_offset (const_tree decl, stru
  properly dynamic byte offsets only when PCC bitfield type doesn't
  matter.  */
   if (PCC_BITFIELD_TYPE_MATTERS
+  && DECL_BIT_FIELD (decl)
   && TREE_CODE (DECL_FIELD_OFFSET (decl)) == INTEGER_CST)
 {
   offset_int object_offset_in_bits;
--- gcc/testsuite/g++.dg/debug/dwarf2/pr101378.C.jj 2021-11-09
15:17:39.504975396 +0100
+++ gcc/testsuite/g++.dg/debug/dwarf2/pr101378.C2021-11-09
15:17:28.067137556 +0100
@@ -0,0 +1,13 @@
+// PR debug/101378
+// { dg-do compile { target c++11 } }
+// { dg-options "-gdwarf-5 -dA" }
+// { dg-final { scan-assembler-times "0\[^0-9x\\r\\n\]*
DW_AT_data_member_location" 1 } }
+// { dg-final { scan-assembler-times "1\[^0-9x\\r\\n\]*
DW_AT_data_member_location" 1 } }
+// { dg-final { scan-assembler-times "2\[^0-9x\\r\\n\]*
DW_AT_data_member_location" 1 } }
+// { dg-final { scan-assembler-not "-1\[^0-9x\\r\\n\]*
DW_AT_data_member_location" } }
+
+struct E {};
+struct S
+{
+  [[no_unique_address]] E e, f, g;
+} s;

fixes this for me.

[Bug c++/103114] [12 Regression] ICE in build_complex, at tree.c:2470 since r12-4764-ga84b9d5373c7e67f

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

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

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

https://gcc.gnu.org/g:0318df0ae63e47f6b2f30e96205d00dcb3696538

commit r12-5054-g0318df0ae63e47f6b2f30e96205d00dcb3696538
Author: Jakub Jelinek 
Date:   Tue Nov 9 15:29:36 2021 +0100

c++: Fix ICE on complex constant with -frounding-math [PR103114]

The FE uses build_complex which assumes that fold_convert will fold
value to a constant.  With -frounding-math that isn't guaranteed though.
So, the patch instead fold_build2s COMPLEX_EXPR, which will result
in build_complex if both arguments are constants, and otherwise
will build COMPLEX_EXPR.
build_zero_cst is an optimization for fold_convert (type,
integer_zero_node).

2021-11-09  Jakub Jelinek  

PR c++/103114
* parser.c (cp_parser_userdef_numeric_literal): Use fold_build2
with COMPLEX_EXPR arg instead of build_complex, use build_zero_cst
instead of fold_convert from integer_zero_node.

* g++.dg/ext/complex10.C: New test.

[Bug c++/103114] [12 Regression] ICE in build_complex, at tree.c:2470 since r12-4764-ga84b9d5373c7e67f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed now.

[Bug debug/101378] Negative DW_AT_data_member_location

[pedro at palves dot net via Gcc-bugs]

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

--- Comment #8 from Pedro Alves  ---
Thank you, I missed the "same type" constraint.  It's also mentioned at
https://en.cppreference.com/w/cpp/language/attributes/no_unique_address .

Indeed, if I use distinct empty types, GCC and Clang lay them at the same
address:

$ cat foo3.cc 
#include 
#include 

struct Empty1 {};
struct Empty2 {};
struct Empty3 {};

struct S
{
  [[no_unique_address]] Empty1 empty1;
  [[no_unique_address]] Empty2 empty2;
  [[no_unique_address]] Empty3 empty3;
} s;

int main ()
{
  printf ("&s.empty1 = %p\n", &s.empty1);
  printf ("&s.empty2 = %p\n", &s.empty2);
  printf ("&s.empty3 = %p\n", &s.empty3);
  printf ("s = %p\n", &s);
  printf ("offset empty1 = %ld\n", offsetof (struct S, empty1));
  printf ("offset empty2 = %ld\n", offsetof (struct S, empty2));
  printf ("offset empty3 = %ld\n", offsetof (struct S, empty3));
  return 0;
}

$ ./foo3 
&s.empty1 = 0x55a5dc7aa031
&s.empty2 = 0x55a5dc7aa031
&s.empty3 = 0x55a5dc7aa031
s = 0x55a5dc7aa031
offset empty1 = 0
offset empty2 = 0
offset empty3 = 0

$ readelf -dw foo3| grep data_member_location
   DW_AT_data_member_location: -1
   DW_AT_data_member_location: -1
   DW_AT_data_member_location: -1

So (-1, -1, -1) in the DWARF and (0, 0, 0) at run time.

[Bug debug/101473] debug_line info depends on toolchain path

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #22 from Richard Biener  ---
So fixed for GCC 12.

[Bug c++/103159] -Wuninitialized should not depend on optimization level

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||24639
Summary|Some -Wuninitialized|-Wuninitialized should not
   |warning still depend on |depend on optimization
   |optimization level  |level

--- Comment #2 from Richard Biener  ---
I'm sure there is a duplicate request.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/103159] -Wuninitialized should not depend on optimization level

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mathieu Malaterre  ---
Please note that the documentation currently does not detail the need/impact of
optimization for this flag:

* https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wuninitialized

Maybe just updating the documentation would be enough. Thanks for
consideration.

[Bug c++/103159] Some -Wuninitialized warnings still depend on optimization level -

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

Mathieu Malaterre  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Mathieu Malaterre  ---
Nevermind, I managed to mis-read the documentation.

```
Because these warnings depend on optimization, the exact variables or elements
for which there are warnings depend on the precise optimization options and
version of GCC used.
```

Sorry for the noise.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[mathieu.malaterre at gmail dot com via Gcc-bugs]

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

Bug 103159 Summary: Some -Wuninitialized warnings still depend on optimization 
level -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103159

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug debug/101378] Negative DW_AT_data_member_location

[pedro at palves dot net via Gcc-bugs]

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

--- Comment #9 from Pedro Alves  ---
> 2021-11-09  Jakub Jelinek  
> 
>   PR debug/101378
>   * dwarf2out.c (field_byte_offset): Do the PCC_BITFIELD_TYPE_MATTERS
>   handling only for DECL_BIT_FIELD decls.
> 
> ...
> 
> fixes this for me.

I gave the patch a try, and all the testcases posted in this bugzilla now show
correct DWARF AFAICT.

Thank you!

[Bug libstdc++/103146] [12 Regression] libstdc++-v3 bootstrap failure on 32-bit BE powerpc since r12-4952

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

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

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

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

commit r12-5057-gd9ebf0ce0845046cdd0cb40c598072bd1d91362c
Author: Jonathan Wakely 
Date:   Tue Nov 9 09:34:23 2021 +

libstdc++: Do not use 64-bit DARN on 32-bit powerpc [PR103146]

We need to use the 64-bit DARN to detect failure without bias, but it's
not available in 32-bit mode.

libstdc++-v3/ChangeLog:

PR libstdc++/103146
* src/c++11/random.cc: Check __powerpc64__ not __powerpc__.

[Bug libstdc++/103146] [12 Regression] libstdc++-v3 bootstrap failure on 32-bit BE powerpc since r12-4952

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
It should be fixed, but I don't have a power64 BE machine with a new-enough
glibc to check it. Please reopen this bug if it's still a problem.

[Bug target/102957] [riscv64] ICE on bogus -march value

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

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

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

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

commit r12-5062-gabe562bb01479ea2c8952ad98714f3225527aa7e
Author: Kito Cheng 
Date:   Mon Nov 8 22:45:49 2021 +0800

[PR/target 102957] Allow Z*-ext extension with only 2 char.

We was assume the Z* extension should be more than 2 char, so we put an
assertion there, but it should just an error or warning rather than an
assertion, however RISC-V has add `Zk` extension, which just 2 char, so
actually, we should just allow that.

gcc/ChangeLog

PR target/102957
* common/config/riscv/riscv-common.c (multi_letter_subset_rank):
Remove
assertion for Z*-ext.

gcc/testsuite/ChangeLog

* gcc.target/riscv/pr102957.c: New.

[Bug bootstrap/103160] New: [12 regression] typo in r12-5060 breaks bootstrap

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

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

Bug ID: 103160
   Summary: [12 regression] typo in r12-5060 breaks bootstrap
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:7798ae1a15055fe956978453ea62932d680ace72, r12-5060

g++  -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I/home/seurer/gcc/git/gcc-test/gcc
-I/home/seurer/gcc/git/gcc-test/gcc/.
-I/home/seurer/gcc/git/gcc-test/gcc/../include
-I/home/seurer/gcc/git/gcc-test/gcc/../libcpp/include
-I/home/seurer/gcc/git/gcc-test/gcc/../libcody
-I/home/seurer/gcc/git/build/gcc-test/./gmp -I/home/seurer/gcc/git/gcc-test/gmp
-I/home/seurer/gcc/git/build/gcc-test/./mpfr/src
-I/home/seurer/gcc/git/gcc-test/mpfr/src
-I/home/seurer/gcc/git/gcc-test/mpc/src 
-I/home/seurer/gcc/git/gcc-test/gcc/../libdecnumber
-I/home/seurer/gcc/git/gcc-test/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/seurer/gcc/git/gcc-test/gcc/../libbacktrace
-I/home/seurer/gcc/git/build/gcc-test/./isl/include
-I/home/seurer/gcc/git/gcc-test/isl/include  -o ipa-modref.o -MT ipa-modref.o
-MMD -MP -MF ./.deps/ipa-modref.TPo
/home/seurer/gcc/git/gcc-test/gcc/ipa-modref.c
/home/seurer/gcc/git/gcc-test/gcc/ipa-modref.c: In function 'void
{anonymous}::analyze_parms(modref_summary*, modref_summary_lto*, bool,
vec&, int, int)':
/home/seurer/gcc/git/gcc-test/gcc/ipa-modref.c:2491:2: error: 'lags' was not
declared in this scope
  lags |= past;
  ^~~~
/home/seurer/gcc/git/gcc-test/gcc/ipa-modref.c:2491:2: note: suggested
alternative: 'flags'
  lags |= past;
  ^~~~
  flags
make[2]: *** [Makefile:1138: ipa-modref.o] Error 1



commit 7798ae1a15055fe956978453ea62932d680ace72
Author: Jan Hubicka 
Date:   Tue Nov 9 16:48:09 2021 +0100

Merge IPA solution with local one in ipa-modref

[Bug target/102957] [riscv64] ICE on bogus -march value

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

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

--- Comment #3 from Kito Cheng  ---
Wait another week for make sure stable and backport to gcc-11 and gcc-10
branch.

[Bug bootstrap/103160] [12 regression] typo in r12-5060 breaks bootstrap

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug bootstrap/103160] [12 regression] typo in r12-5060 breaks bootstrap

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

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

--- Comment #1 from Jonathan Wakely  ---
Fixed at g:78dd0de956cbc5a021d3c5e3eb39308c3207936e

[Bug bootstrap/103160] [12 regression] typo in r12-5060 breaks bootstrap

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103161] New: [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

Bug ID: 103161
   Summary: [12 Regression] Better ranges cause
builtin-sprintf-warn-16.c failure
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

On a variety of platforms builtin-sprintf-warn-16.c has started failing since
converting strlen to use Ranger.

Tests that now fail, but worked before (6 tests):

or1k-sim: gcc.dg/tree-ssa/builtin-sprintf-warn-16.c  (test for warnings, line
142)
or1k-sim: gcc.dg/tree-ssa/builtin-sprintf-warn-16.c  (test for warnings, line
243)
or1k-sim: gcc.dg/tree-ssa/builtin-sprintf-warn-16.c (test for excess errors)

The excess errors and line 142 failure are due to getting tighter ranges out of
Ranger which seems to have confused the wrap-around bits in the sprintf
warnings.

A reduced testcase for or1k-elf that you can trigger with a cross:

# 0 "k.c"
# 0 ""
# 0 ""
# 1 "k.c"






typedef unsigned int size_t;
typedef unsigned int wchar_t;

void sink (void*);
void* get_value (void);
# 22 "k.c"
extern char buf[1];






typedef signed long long sint128_t;
typedef unsigned long long uint128_t;


const sint128_t sint128_max
  = (sint128_t)1 << (sizeof sint128_max * 8 - 2);
const sint128_t uint128_max = (uint128_t)-1;


void test_width_var (void)
{

  {


extern unsigned w;
if (w < 5 || (unsigned)-1 - 7 < w)
  w = 5;

__builtin_sprintf (buf + 1, "%*u", w, *(int*)get_value ()); sink (buf);
  }
}


The relevant bits from the .strlen dump:

Old:
! j.c:52: __builtin_sprintf: objsize = 0, fmtstr = "%*u"
!   Directive 1 at offset 0: "%*u", width in range [0, 2147483648]
! Result: 1, 1, 2147483648, 2147483648 (1, 1, 2147483648, 2147483648)
Directive 2 at offset 3: "", length = 1

New:
! k.c:52: __builtin_sprintf: objsize = 0, fmtstr = "%*u"
!   Directive 1 at offset 0: "%*u", width in range [5, 4294967288]
! Result: 5, 5, -1, 4294967288 (5, 5, -1, -1)
Directive 2 at offset 3: "", length = 1


AFAICT we've got a tighter range from Ranger, which in turn is confusing some
of the wrap-around logic.

Martin, can you take a look a this?

[Bug libstdc++/103162] New: overconstrained std::pmr::memory_resource allocate/deallocate methods

[florin.iucha at amd dot com via Gcc-bugs]

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

Bug ID: 103162
   Summary: overconstrained std::pmr::memory_resource
allocate/deallocate methods
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florin.iucha at amd dot com
  Target Milestone: ---

std::pmr::memory_resource::allocate() is annotated with
__attribute__((__returns_nonnull__)) and
std::pmr::memory_resource::deallocate() is annotated with
__attribute__((__nonnull__)) .

Looking at https://en.cppreference.com/w/cpp/memory/memory_resource/allocate it
is not clear why the annotation is required.

I have implemented several specialized memory resources, which sometimes can be
used to manage pools in CPU space, sometimes from pools in other memory spaces,
where allocating from 0 is perfectly acceptable.

Checking https://eel.is/c++draft/mem.res.class, there's no mention of "null" in
the context of allocate/deallocate .

This attribute can be helpful to catch bugs in specialized memory resources in
general, but specifically in my case it is tripping the address sanitizer when
I'm returning null.

[Bug debug/101378] Negative DW_AT_data_member_location

[pedro at palves dot net via Gcc-bugs]

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

--- Comment #10 from Pedro Alves  ---
I've now compared GDB testsuite runs with current GCC, unpatched vs patched, no
regressions.

[Bug tree-optimization/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure

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

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

--- Comment #1 from Jeffrey A. Law  ---
I suspect the same underlying issue is affecting the test on line #243 as well.

[Bug libstdc++/103162] overconstrained std::pmr::memory_resource allocate/deallocate methods

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

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

--- Comment #1 from Jonathan Wakely  ---
"A derived class shall implement this function to return a pointer to allocated
storage (6.7.5.5.2) with a size of at least bytes, aligned to the specified
alignment."

And 6.7.5.5.2 says:

"An allocation function attempts to allocate the requested amount of storage.
If it is successful, it returns the address of the start of a block of storage
whose length in bytes is at least as large as the requested size. [...]
If the request succeeds, the value returned by a replaceable allocation
function is a non-null pointer value ([basic.compound]) p0 different from any
previously returned value p1, [...]"

It says it's non-null.

The attribute is not there to catch bugs in memory resources, it's there to
tell the compiler that the returned pointer is not null, and so it can optimize
accordingly.

In an environment where 0 is a valid address, does
-fno-delete-null-pointer-checks make any difference?

[Bug bootstrap/102831] [12 regression] Spurious -Wparentheses etc. warnings

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

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

--- Comment #8 from Peter Bergner  ---
(In reply to Martin Sebor from comment #7)
> (In reply to Peter Bergner from comment #6)
> 
> If it's reliably reproducible (ideally with a cross), can you attach a
> translation unit and the options to use to reproduce it with?

It's somewhat repeatable. :-(  If I cd into $BUILD_DIR/gcc and execute the
command from my build log that ICEs, that will 100% always ICE.  However, if I
add -save-temps it will not ICE and adding -E and compiling the resulting .ii
file will not ICE either.  In addition, if I cd to my home dir and execute the
failing command line, with only changing the -I. options to -I/$BUILD_DIR/gcc,
then it also does not ICE.  It seems only executing the command in the correct
build directory seems to work.  I have been able to recreate the issue on the
gcc compile farm machine gcc135.  You can recreate the ICE with the following
command.  I believe you should be able to access that directory.

[bergner@gcc135 gcc]$ pwd
/home/bergner/gcc/build/gcc-fsf-mainline-pr103127-base-regtest-2/gcc

[bergner@gcc135 gcc]$
/home/bergner/gcc/build/gcc-fsf-mainline-pr103127-base-regtest-2/./prev-gcc/xg++
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr103127-base-regtest-2/./prev-gcc/
-nostdinc++
-I/home/bergner/gcc/build/gcc-fsf-mainline-pr103127-base-regtest-2/prev-powerpc64le-linux/libstdc++-v3/include/powerpc64le-linux

-I/home/bergner/gcc/build/gcc-fsf-mainline-pr103127-base-regtest-2/prev-powerpc64le-linux/libstdc++-v3/include
 -I/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/libstdc++-v3/libsupc++
-fno-PIE -S -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I./
-I/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/gcc/.
-I/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/gcc/../include
-I/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/gcc/../libcpp/include 
/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/gcc/lra-lives.c

In file included from
/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/gcc/lra-lives.c:43:
/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/gcc/lra-lives.c: In function
‘bool process_bb_lives(basic_block, int&, bool)’:
/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/gcc/sparseset.h:215:20: error:
suggest parentheses around assignment used as truth value [-Werror=parentheses]
  215 |&& (((ITER) = sparseset_iter_elm (SPARSESET)) || 1);
\
  |^
/home/bergner/gcc/gcc-fsf-mainline-pr103127-base/gcc/lra-lives.c:1033:7: note:
in expansion of macro ‘EXECUTE_IF_SET_IN_SPARSESET’
 1033 |   EXECUTE_IF_SET_IN_SPARSESET (unused_set, j)
  |   ^~~

[Bug c++/99631] decltype of non-type template-parameter shouldn't be const

[n60wb42d2 at relay dot firefox.com via Gcc-bugs]

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

n60wb42d2 at relay dot firefox.com changed:

   What|Removed |Added

 CC||n60wb42d2 at relay dot 
firefox.com

--- Comment #4 from n60wb42d2 at relay dot firefox.com ---
(In reply to Jonathan Wakely from comment #1)
> I'm not sure "rejects-valid" is appropriate, as it only fails to compile
> because of the static assert (i.e. you've asked for it).

Here it `rejects-valid`:

```c++
struct param{};

template
struct t;
template<>
struct t{};

template
auto test()
{
(void)t{};
}

int main()
{
test();
}
```
```
:11:5: error: invalid use of incomplete type 'struct t'
   11 | (void)t{};
```

https://godbolt.org/z/MKxx1dobT

[Bug fortran/103154] [PDT] Crashing gfortran due to bad type parameter specification since r8-3181-g87f3a5cfb59347cd

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|Crashing gfortran due to|[PDT] Crashing gfortran due
   |bad type parameter  |to bad type parameter
   |specification since |specification since
   |r8-3181-g87f3a5cfb59347cd   |r8-3181-g87f3a5cfb59347cd
   Priority|P3  |P4

--- Comment #2 from anlauf at gcc dot gnu.org ---
Very likely a duplicate.