[Bug rtl-optimization/88132] Compile time and memory hog w/ var-tracking on 32-bit targets

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #3 from Kewen Lin  ---
(In reply to Arseny Solokha from comment #2)
> I cannot reproduce it anymore w/ gcc 13.0.0 20221016 snapshot
> (g:6366e3e8847af98d4728d55951534769d034d02a) and w/ gcc 12.2.

Should we check the release branches gcc-10 and gcc-11? Or can we just
aggressively close this? since the original release gcc-9 which this PR was
opened against isn't an active branch any more and this issue doesn't exist on
latest branch gcc-12 and trunk?

[Bug fortran/107406] New: lock_type

[damian at archaeologic dot codes via Gcc-bugs]

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

Bug ID: 107406
   Summary: lock_type
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at archaeologic dot codes
  Target Milestone: ---

gfortran 12.2 accepts the code below if the "allocatable" attribute is removed:

% cat gfortran-lock-issue.f90 
  use iso_fortran_env
  type foo
type(lock_type), allocatable :: bar
  end type
  type(foo) foobar[*]
end

% gfortran -fcoarray=single gfortran-lock-issue.f90 
gfortran-lock-issue.f90:3:39:

3 | type(lock_type), allocatable :: bar
  |   1
Error: Allocatable component bar at (1) of type LOCK_TYPE must have a
codimension

The NAG compiler accepts the above code and I believe constraint C1608 in the
Fortran 2018 standard makes the above code valid.

Is this related to PR 92122?

[Bug c/107405] enums can be wrongly long in gcc-13 (in gnu99)

[jirislaby at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jiri Slaby  ---
(In reply to Jiri Slaby from comment #0)
> Reduced testcase:
> #include 
> enum { A = 0x, B = 1 << 31, };
> int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }

It's also interesting to me, that A is long even with gcc-12...

[Bug c/107405] New: enums can be long in gcc-13

[jirislaby at gmail dot com via Gcc-bugs]

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

Bug ID: 107405
   Summary: enums can be long in gcc-13
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jirislaby at gmail dot com
  Target Milestone: ---

While compiling the kernel (next/master -- 89bf6e28373beef9) with gcc-13, I
see:
drivers/block/mtip32xx/mtip32xx.c:722:25: error: format '%x' expects argument
of type 'unsigned int', but argument 3 has type 'long in' [-Werror=format=]

That is:
enum {
Many members, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/ata.h?id=4dc12f37a8e98e1dca5521c14625c869537b50b6#n25
};
...
#define PORT_IRQ_HANDLED \  
(PORT_IRQ_SDB_FIS | PORT_IRQ_LEGACY | \
 PORT_IRQ_TF_ERR | PORT_IRQ_IF_ERR | \
 PORT_IRQ_CONNECT | PORT_IRQ_PHYRDY)


...
u32 port_stat;
...
dev_warn(>pdev->dev,
  "Port stat errors %x unhandled\n",
  (port_stat & ~PORT_IRQ_HANDLED));

So port_stat is uint, ~PORT_IRQ_HANDLED is derived from enum, which should be
int from standard.

Reduced testcase:
#include 
enum { A = 0x, B = 1 << 31, };
int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }

$ gcc-13 -std=gnu99 x.c -Wall -O2 && ./a.out
x.c: In function ‘main’:
x.c:3:27: warning: format ‘%x’ expects argument of type ‘unsigned int’, but
argument 3 has type ‘long int’ [-Wformat=]
3 | int main() { printf("%lx %x %zu\n", A, B, sizeof(B)); }
  |  ~^~
  |   ||
  |   unsigned int long int
  |  %lx
 8000 8
$ gcc-12 -std=gnu11 x.c -Wall -O2 && ./a.out
 8000 4

[Bug target/106460] internal compiler error: output_operand: invalid expression as operand on -O1

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jiu Fu Guo :

https://gcc.gnu.org/g:978ec4825c2e5cb0ec03d857ea038440d566ff42

commit r13-3499-g978ec4825c2e5cb0ec03d857ea038440d566ff42
Author: Jiufu Guo 
Date:   Tue Jul 19 18:30:58 2022 +0800

rs6000: cannot_force_const_mem for HIGH code rtx[PR106460]

As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is
tried
to store into constant pool and ICE occur.  But actually, this rtx
represents
partial incomplete address and can not be put into a .rodata section.

This patch updates rs6000_cannot_force_const_mem to return true for rtx(s)
with
HIGH code, because these rtx(s) indicate part of address and are not ok for
constant pool.

Below are some examples:
(high:DI (const:DI (plus:DI (symbol_ref:DI ("xx") (const_int 12 [0xc])
(high:DI (symbol_ref:DI ("var_1")..)))

PR target/106460

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem): Return
true
for HIGH code rtx.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr106460.c: New test.

[Bug c++/95148] -Wtype-limits always-false warning triggered despite comparison being avoided

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
I think this counts as an example of bug 4210

[Bug rtl-optimization/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #5)
> I'm testing
> 
> modified   gcc/lra-constraints.cc
> @@ -4382,7 +4382,14 @@ curr_insn_transform (bool check_only_p)
>(op, (enum reg_class) goal_alt[i]) == NO_REGS)
>   || no_input_reloads_p))
> {
> - rtx tem = force_const_mem (mode, op);
> + rtx tem;
> +
> + /* PR 107057, for same constant pool, don't bother
> +force_const_mem again, just reuse the matched op.  */
> + if (goal_alt_matches[i] >= 0)
> +   tem = *curr_id->operand_loc[goal_alt_matches[i]];
> + else
> +   tem = force_const_mem (mode, op);
>  
>   change_p = true;
>   if (subreg != NULL_RTX)

It failed bootstrap since there's are matches ops with differnce mode

(define_insn "*fop_xf_4_i387"
  [(set (match_operand:XF 0 "register_operand" "=f,f")
(match_operator:XF 3 "binary_fp_operator"
   [(float_extend:XF
  (match_operand:MODEF 1 "nonimmediate_operand" "fm,0"))
(match_operand:XF 2 "register_operand" "0,f")]))]

I don't know if there're other usages, so for safety, i'll just invalid
goal_alt_matches when force_const_mem.

[Bug tree-optimization/107404] [12/13 Regression] Wrong code with -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
   Last reconfirmed||2022-10-26

--- Comment #1 from Andrew Pinski  ---
Note "-O3 -g0 -fno-tree-vrp -fno-tree-ccp -fno-ivopts -fno-thread-jumps 
-fno-tree-dominator-opts -fno-tree-vectorize" still fails but adding -fwrapv
allows it to pass.

Confirmed.

[Bug tree-optimization/107404] [12/13 Regression] Wrong code with -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.3

[Bug tree-optimization/107404] New: [12/13 Regression] Wrong code with -O3

[vsevolod.livinskiy at gmail dot com via Gcc-bugs]

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

Bug ID: 107404
   Summary: [12/13 Regression] Wrong code with -O3
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

Link to the Compiler Explorer: https://godbolt.org/z/jP6chErEY

The reproducer is a bit too big, but it's the best I was able to achieve with
Creduce, Cvise, and manual reduction. UBSan and ASan say that it is compliant
with the standard.

Reproducer:
#include 
unsigned long long a;
void b(unsigned long long *f, int p2) { *f ^= p2; }
long c;
char e, i;
short g, m;
long long ab[1][25][21][22];
unsigned long long aa[1][21][22];
unsigned long long ae[1][25][21][21];
long long ac[129360];
char ad[25][1][21];
char ah[1][25][1][21];
short af[100];
long max(long f, unsigned long p2) { return f < p2 ? p2 : f; }
const int (const int , const int ) { return f < p2 ? p2 : f; }
void foo(unsigned f, unsigned p2, char l, char p4, long long n[][25][21][22],
unsigned long long p6[][21][22], unsigned long long u[][25][21][21]) {
  long an;
  for (int j = 0; j < 4; j = p2)
for (short k = 0; k < 7; k += 2)
  for (short o = 0; o < (short)p2 + 21742; o = l) {
for (signed char p = 2; p < 9; p += p4)
  if (p6[j][o][p])
for (long q(3); 4 ? n[0][k][o][0] : 0;
 q += p6[0][o][0] ? p6[j][0][p] : 0)
  ac[j + q] = 5066799590;
for (long r(p4 - 16); r < 21; r += 4) {
  ad[k][o][r] = max(u[j][k][o][r], f + u[j][k][o][r]);
  long d = u[j][k][o][r];
  an = d < p2 ? p2 : d;
  e = ah[j][k][o][r] = an;
  af[o * r] = i;
}
for (short s(c); s < (short)p2; s = 2)
  for (short am(m); am; am = max2(3, p2))
for (long y = 0; y; y = 3)
  for (short t(0); t < max2(g, 0);)
;
  }
}
int main() {
  foo(7, 1558227751, 104, 16, ab, aa, ae);
  for (size_t v = 0; v < 5; ++v)
for (size_t w = 0; w < 1; ++w)
  for (size_t x = 0; x < 21; ++x)
b(, ad[v][w][x]);
  printf("%llu\n", a);
}

Error:
>$ g++ -O3 small.cpp && ./a.out 
28
>$ g++ -O0 small.cpp && ./a.out 
0

gcc version 13.0.0 20221025 (321f89e58510dd5df1b3dbe323344b987a7b11c6)

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

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

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

--- Comment #7 from Andrew Pinski  ---
Looks to be fixed.

[Bug target/107403] uint64_t bitfield operation is mishandled

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

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

--- Comment #4 from Andrew Pinski  ---
See https://gcc.gnu.org/legacy-ml/gcc/2017-10/msg00192.html

[Bug target/107403] uint64_t bitfield operation is mishandled

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92684
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 94631.

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

[Bug c/94631] Wrong codegen for arithmetic on bitfields

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

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

[Bug target/107403] uint64_t bitfield operation is mishandled

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

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

--- Comment #2 from Andrew Pinski  ---
Note gcc and clang have different implementation defined behavior here too.

[Bug target/107403] uint64_t bitfield operation is mishandled

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

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

--- Comment #1 from Andrew Pinski  ---
No this is correct.
i.y << 8ULL
Is all done in 56bit type as the type is greater than the size of int.

Note c allows this behavior while c++ does not.

[Bug target/107403] New: uint64_t bitfield operation is mishandled

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 107403
   Summary: uint64_t bitfield operation is mishandled
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x84

[hjl@gnu-cfl-1 tmp]$ cat foo.c
#include 
#include 

#define VAL (1ULL << 48)

struct foo
{
  uint64_t x : 8;
  uint64_t y : 56;
};

__attribute__ ((noinline))
uint64_t
func (struct foo i)
{
  return i.y << 8ULL;
}

int
main ()
{
  struct foo i;
  i.x = 0;
  i.y = VAL;
  uint64_t x = func (i);
  printf ("0x%llx\n", x);
  printf ("0x%llx\n", VAL);
  if (x != (VAL << 8ULL))
__builtin_abort ();
}
[hjl@gnu-cfl-1 tmp]$ gcc foo.c
[hjl@gnu-cfl-1 tmp]$ ./a.out 
0x0
0x1
Aborted (core dumped)
[hjl@gnu-cfl-1 tmp]$

[Bug tree-optimization/105723] [12/13 Regression] Optimization false positive warning (-Wstringop-overflow)

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Optimization false positive |[12/13 Regression]
   |warning |Optimization false positive
   |(-Wstringop-overflow)   |warning
   ||(-Wstringop-overflow)
   Target Milestone|--- |12.3

[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.4

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #21 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Segher Boessenkool from comment #16)
> > (In reply to Jakub Jelinek from comment #15)
> > > PowerPC I think does, not sure about s390.
> > 
> > Does what?
> 
> Published psABI which ought to specify how to pass/return _BitInt(N) and
> unsigned _BitInt(N).

psABI is an x86 thing?  But there are various ABIs for PowerPC that have
public documentation, six or so, and GCC has support for most of those.

None of them are "processor specific" (most are OS specific, instead), and
they differ in very fundamental things, in places.  They are much related
as well of course, either because there is an obvious choice, or history.

Many of those ABIs have not seen updates for decades, and are unlikely to
anymore.  OTOH the GCC support for them has been updated over time, there
often is only one sane choice anyway.

We'll make decisions on what ELFv2 will do for _Bitint when it is closer
in time than it is now.  The only interesting choice is whether values in
memory have undefined bits -- and they likely should, simply because all
other padding bits are undefined as well.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

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

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

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
> Steve,
> 
> what do you think about the following patch?  Not yet fully regtested.
> It should fix the issue much simpler by checking type compatibility:
> 
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 6050359d521..f4052eb7042 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -5139,6 +5141,9 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typespec
> *ts2)
>bool is_union1 = (ts1->type == BT_UNION);
>bool is_union2 = (ts2->type == BT_UNION);
>  
> +  if (ts2->type == BT_BOZ)
> +return (ts1->type == BT_INTEGER || ts1->type == BT_REAL);
> +
>if (is_class1
>&& ts1->u.derived->components
>&& ((ts1->u.derived->attr.is_class
> 
> Do you have a testcase that exercises BT_INTEGER and BT_REAL here?
> I thought that one of the pathes that reaches gfc_boz2int and gfc_boz2real
> might need the above.

Well, a boz is typeless, so it cannot be compatible with any other type.
So, I would assume, you could do 

if (ts1->type == BT_BOZ || ts2->type == BT_BOZ)
   return false;

There is a caveat in that Fortran 2023 is going to allow
things like

real :: x = z'1234'

if gfc_type_compatible is used in simple assignments, gfortran will
need to deal with that.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #20 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Segher Boessenkool from comment #16)
> > (In reply to Jakub Jelinek from comment #15)
> > > PowerPC I think does, not sure about s390.
> > 
> > Does what?
> 
> Have a public place to submit issues against the powerpc abis.

Only the ELFv2 ABI really (it's on github).  The rest doesn't have (public)
maintained documents at all.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > PowerPC I think does, not sure about s390.
> 
> Does what?

Published psABI which ought to specify how to pass/return _BitInt(N) and
unsigned _BitInt(N).

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > PowerPC I think does, not sure about s390.
> 
> Does what?

Have a public place to submit issues against the powerpc abis.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #17 from H.J. Lu  ---
See:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/38

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #16 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #15)
> PowerPC I think does, not sure about s390.

Does what?

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

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

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

Aldy Hernandez  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

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

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

--- Comment #3 from Aldy Hernandez  ---
Created attachment 53772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53772=edit
untested

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

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

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

--- Comment #2 from Aldy Hernandez  ---
This is interesting.  

quux() was analyzed and a global range was set that included the possibility of
+NAN, but when it was inlined into bar(), the assert making sure no NANs crept
in for -ffinite-math-only failed.

So the inlined function had a NAN, but the function where it was being inlined
into has -ffinite-math-only.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||uweigand at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
PowerPC I think does, not sure about s390.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #14 from H.J. Lu  ---
(In reply to jos...@codesourcery.com from comment #13)
> https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 to request such an ABI 
> for 32-bit x86.  I don't know if there are other psABIs with public issue 
> trackers where such issues can be filed (but we'll need some sensible 
> default anyway for architectures where we can't get an ABI properly 
> specified in an upstream-maintained ABI document).

ia32 psABI will follow x86-64 psABI.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #13 from joseph at codesourcery dot com  ---
On Tue, 25 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:

> The x86-64 psABI has been changed for this:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/8ca45392570e96920f8a15d903d6122f6d263cd0
> but the state of the padding bits isn't mentioned there anywhere.

I think the words "The value of the unused bits beyond the width of the 
\texttt{_BitInt(N)} value but within the size of the \texttt{_BitInt(N)} 
are unspecified when stored in memory or register." are what deals with 
padding (both padding within sizeof(_BitInt(N)) bytes, and bytes within a 
register or stack slot used for argument passing / return but outside 
sizeof(_BitInt(N)) bytes).

(Of course different architectures might make different choices for how to 
handle padding.)

I filed https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/300 in 
July to request an ABI for _BitInt on RISC-V.  I've just now filed 
https://github.com/ARM-software/abi-aa/issues/175 to request such an ABI 
for both 32-bit and 64-bit Arm, and 
https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 to request such an ABI 
for 32-bit x86.  I don't know if there are other psABIs with public issue 
trackers where such issues can be filed (but we'll need some sensible 
default anyway for architectures where we can't get an ABI properly 
specified in an upstream-maintained ABI document).

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #9 from anlauf at gcc dot gnu.org ---
Steve,

what do you think about the following patch?  Not yet fully regtested.
It should fix the issue much simpler by checking type compatibility:

diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 6050359d521..f4052eb7042 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -5139,6 +5141,9 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typespec
*ts2)
   bool is_union1 = (ts1->type == BT_UNION);
   bool is_union2 = (ts2->type == BT_UNION);

+  if (ts2->type == BT_BOZ)
+return (ts1->type == BT_INTEGER || ts1->type == BT_REAL);
+
   if (is_class1
   && ts1->u.derived->components
   && ((ts1->u.derived->attr.is_class

Do you have a testcase that exercises BT_INTEGER and BT_REAL here?
I thought that one of the pathes that reaches gfc_boz2int and gfc_boz2real
might need the above.

[Bug c++/107388] GCC should diagnose unsigned to signed conversion with -Wconversion

[nikolasklauser at berlin dot de via Gcc-bugs]

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

--- Comment #2 from Nikolas Klauser  ---
Shouldn't -Wconversion also enable -Wsign-conversion? -Wconversion sounds to me
like it should diagnose all conversions, especially since it's the same kind of
bug I want to catch by enabling the flags. In which case would I be interested
in different sizes but not different signs?

[Bug tree-optimization/107395] Missed warning opportunity on builtin string optimization

[nrk at disroot dot org via Gcc-bugs]

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

--- Comment #2 from nrk at disroot dot org ---
That c++ warning is unrelated to the bug report, it's warning about
initialization; which you can easily replace them with { 'h' } and { 'h', 'i' }
to silence; but not warning about the fact that non-null-terminated byte array
is being passed to function which expects a string.

https://godbolt.org/z/o3ov5qEoa

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[martin at martin dot st via Gcc-bugs]

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

--- Comment #8 from Martin Storsjö  ---
(In reply to Tomas Kalibera from comment #7)
> I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
> mailing list in May:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html
> 
> The patches still apply to current 10,11,12 and trunk. Please see the email
> linked above for more information.

Did you notice the review comment in July,
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/59.html?

[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
All releases I have (4.9.0) are affected by the crash.

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716 since r13-3411-gf4fda3eec408e1eb

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||aldyh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |verify_range, at|verify_range, at
   |value-range.cc:716  |value-range.cc:716 since
   ||r13-3411-gf4fda3eec408e1eb
   Last reconfirmed||2022-10-25

--- Comment #1 from Martin Liška  ---
Started with r13-3411-gf4fda3eec408e1eb.

[Bug tree-optimization/107395] Missed warning opportunity on builtin string optimization

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Note C++ warns about it:

$ g++ pr107395.c -c
pr107395.c: In function ‘size_t f()’:
pr107395.c:4:29: error: initializer-string for ‘char [1]’ is too long
[-fpermissive]
4 | char s[1] = "h";
  | ^~~
pr107395.c: In function ‘size_t f3()’:
pr107395.c:14:29: error: initializer-string for ‘char [2]’ is too long
[-fpermissive]
   14 | char s[2] = "hi";
  | ^~~~

[Bug fortran/103474] ICE in simplify_cobound, at fortran/simplify.c:4415

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Another part which is needed to avoid an ice-on-valid code:
(Note F2018:5.4.7(5): A subobject of a coarray is a coarray if ...)

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 69d0b57c688..ef8f042a7e4 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -5845,6 +5845,8 @@ gfc_get_corank (gfc_expr *e)
   if (ref->type == REF_ARRAY)
corank = ref->u.ar.as->corank;
   gcc_assert (ref->type != REF_SUBSTRING);
+  if (corank)
+   break;
 }

   return corank;

[Bug c++/107390] template-nested lambda type uniqueness

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-10-25
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-25

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Slightly reduced testcase (w/o assignment):

program p
  type t
 real :: a = 1.0
  end type
  type(t), parameter :: x = z'1'
  print *, x%a + 2
! print *, x%a
end

[Bug c++/107382] [13 Regression] ICE in cp_common_type, at cp/typeck.cc:436

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
The PR107383 fix fixes this too.

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

[Bug c++/107383] [13 Regression] ICE in cp_build_binary_op, at cp/typeck.cc:6181

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

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

--- Comment #3 from Jakub Jelinek  ---
*** Bug 107382 has been marked as a duplicate of this bug. ***

[Bug c++/107383] [13 Regression] ICE in cp_build_binary_op, at cp/typeck.cc:6181

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

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

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

--- Comment #13 from Alexander Monakov  ---
As for the Fortran testcases, the issue is again caused by the front-end
invoking decl_default_tls_model before assigning DECL_COMMON, this time in
fortran/trans-common.cc:build_common_decl.

So I guess I can be happy that the assert uncovered issues in three front-ends,
and adjust the code to avoid downgrading TLS model instead of asserting:

diff --git a/gcc/ipa-visibility.cc b/gcc/ipa-visibility.cc
index 3ed2b7cf6..bb86005e5 100644
--- a/gcc/ipa-visibility.cc
+++ b/gcc/ipa-visibility.cc
@@ -886,8 +886,8 @@ function_and_variable_visibility (bool whole_program)
  && vnode->ref_list.referring.length ())
{
  enum tls_model new_model = decl_default_tls_model (decl);
- gcc_checking_assert (new_model >= decl_tls_model (decl));
- set_decl_tls_model (decl, new_model);
+ if (new_model >= decl_tls_model (decl))
+   set_decl_tls_model (decl, new_model);
}
}
 }

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

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

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

Bug 106848 Summary: ICE when compiling module interface file with -g: error: 
type variant differs by TYPE_MAX_VALUE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106848

   What|Removed |Added

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

[Bug c++/106848] ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Should be fixed.

[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat

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

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

Bug 106848 Summary: ICE when compiling module interface file with -g: error: 
type variant differs by TYPE_MAX_VALUE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106848

   What|Removed |Added

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

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

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

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

Bug 102600 Summary: [modules] ICE Segmentation fault during GIMPLE pass evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102600

   What|Removed |Added

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

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

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

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

Bug 102600 Summary: [modules] ICE Segmentation fault during GIMPLE pass evrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102600

   What|Removed |Added

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

[Bug c++/102600] [modules] ICE Segmentation fault during GIMPLE pass evrp

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED

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

[Bug c++/107402] New: Parenthesized aggregate initialization should not initialize references

[ayzhao at google dot com via Gcc-bugs]

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

Bug ID: 107402
   Summary: Parenthesized aggregate initialization should not
initialize references
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ayzhao at google dot com
  Target Milestone: ---

The implementation of P0960R3 in
 and
 allowed for
initialization of references by creating and initializing a temporary of the
referered type. Therefore, statements such as

 const MyStruct& m(1, 1);
 int (&)[](1, 2, 3, 4); 

are accepted by GCC: 

A close reading of the C++ standard suggests that these expressions are not
allowed. Reference initialization via a temporary is described in
, and that only permits conversion by
constructor or conversion function (if the source or destination is of class
type) or implicit conversion, not arbitrary direct-initialization conversions
(which would include aggregate initialization)

[Bug c++/102600] [modules] ICE Segmentation fault during GIMPLE pass evrp

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

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

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

https://gcc.gnu.org/g:15d67c11ac0479b08e3badcafdee7e0a6f062349

commit r13-3491-g15d67c11ac0479b08e3badcafdee7e0a6f062349
Author: Patrick Palka 
Date:   Tue Oct 25 13:41:18 2022 -0400

c++ modules: enum TYPE_MIN/MAX_VALUE streaming [PR106848]

In the frontend, the TYPE_MIN/MAX_VALUE of ENUMERAL_TYPE is the same as
that of the enum's underlying type (see start_enum).  And the underlying
type of an enum is always known, even for an opaque enum that lacks a
definition.

But currently, we stream TYPE_MIN/MAX_VALUE of an enum only as part of
its definition.  So if the enum is declared but never defined, the
ENUMERAL_TYPE we stream in will have empty TYPE_MIN/MAX_VALUE fields
despite these fields being non-empty on stream out.

And even if the enum is defined, read_enum_def updates these fields only
on the main variant of the enum type, so for other variants (that we may
have streamed in earlier) these fields remain empty.  That these fields
are unexpectedly empty for some ENUMERAL_TYPEs is ultimately the cause
of the below two PRs.

This patch fixes this by making us stream TYPE_MIN/MAX_VALUE directly
for each ENUMERAL_TYPE rather than as part of the enum's definition, so
that we naturally also stream these fields for opaque enums (and each
enum type variant).

PR c++/106848
PR c++/102600

gcc/cp/ChangeLog:

* module.cc (trees_out::core_vals): Stream TYPE_MAX_VALUE and
TYPE_MIN_VALUE of ENUMERAL_TYPE.
(trees_in::core_vals): Likewise.
(trees_out::write_enum_def): Don't stream them here.
(trees_in::read_enum_def): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/enum-9_a.H: New test.
* g++.dg/modules/enum-9_b.C: New test.
* g++.dg/modules/enum-10_a.H: New test.
* g++.dg/modules/enum-10_b.C: New test.
* g++.dg/modules/enum-11_a.H: New test.
* g++.dg/modules/enum-11_b.C: New test.

[Bug c++/106848] ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE

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

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

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

https://gcc.gnu.org/g:15d67c11ac0479b08e3badcafdee7e0a6f062349

commit r13-3491-g15d67c11ac0479b08e3badcafdee7e0a6f062349
Author: Patrick Palka 
Date:   Tue Oct 25 13:41:18 2022 -0400

c++ modules: enum TYPE_MIN/MAX_VALUE streaming [PR106848]

In the frontend, the TYPE_MIN/MAX_VALUE of ENUMERAL_TYPE is the same as
that of the enum's underlying type (see start_enum).  And the underlying
type of an enum is always known, even for an opaque enum that lacks a
definition.

But currently, we stream TYPE_MIN/MAX_VALUE of an enum only as part of
its definition.  So if the enum is declared but never defined, the
ENUMERAL_TYPE we stream in will have empty TYPE_MIN/MAX_VALUE fields
despite these fields being non-empty on stream out.

And even if the enum is defined, read_enum_def updates these fields only
on the main variant of the enum type, so for other variants (that we may
have streamed in earlier) these fields remain empty.  That these fields
are unexpectedly empty for some ENUMERAL_TYPEs is ultimately the cause
of the below two PRs.

This patch fixes this by making us stream TYPE_MIN/MAX_VALUE directly
for each ENUMERAL_TYPE rather than as part of the enum's definition, so
that we naturally also stream these fields for opaque enums (and each
enum type variant).

PR c++/106848
PR c++/102600

gcc/cp/ChangeLog:

* module.cc (trees_out::core_vals): Stream TYPE_MAX_VALUE and
TYPE_MIN_VALUE of ENUMERAL_TYPE.
(trees_in::core_vals): Likewise.
(trees_out::write_enum_def): Don't stream them here.
(trees_in::read_enum_def): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/enum-9_a.H: New test.
* g++.dg/modules/enum-9_b.C: New test.
* g++.dg/modules/enum-10_a.H: New test.
* g++.dg/modules/enum-10_b.C: New test.
* g++.dg/modules/enum-11_a.H: New test.
* g++.dg/modules/enum-11_b.C: New test.

[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #23 from H.J. Lu  ---
Fixed for GCC 13 so far.

[Bug c++/107401] New: ICE in get_originating_module_decl, at cp/module.cc:18587

[gscfq--- via Gcc-bugs]

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

Bug ID: 107401
   Summary: ICE in get_originating_module_decl, at
cp/module.cc:18587
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With file g++.dg/parse/pr81247-a.C and pr81247-b.C :


$ g++-13-20221023 -c pr81247-a.C -fmodules-ts
pr81247-a.C:5:1: error: expected '{' before 'template'
5 | template < typename T > class A
  | ^~~~
'
pr81247-a.C: In instantiation of 'class A':
pr81247-a.C:12:13:   required from here
Segmentation fault
6 | { // { dg-error "redeclared as different" }
  | ^
0x11d299f crash_signal
../../gcc/toplev.cc:314
0x98b3c7 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3648
0x98b3c7 get_originating_module_decl(tree_node*)
../../gcc/cp/module.cc:18587
0x98b687 get_originating_module(tree_node*, bool)
../../gcc/cp/module.cc:18626
0x919fa6 dump_module_suffix
../../gcc/cp/error.cc:207
0x91acba dump_module_suffix
../../gcc/cp/error.cc:189
0x91acba dump_aggr_type
../../gcc/cp/error.cc:856
0x9294f6 decl_to_string
../../gcc/cp/error.cc:3297
0x9294f6 cp_printer
../../gcc/cp/error.cc:4471
0x22113c0 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.cc:1475
0x21f02f0 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.cc:1548
0x21f0a3a diagnostic_impl
../../gcc/diagnostic.cc:1712
0x21f1286 error(char const*, ...)
../../gcc/diagnostic.cc:2008
0x8d8196 duplicate_decls(tree_node*, tree_node*, bool, bool)
../../gcc/cp/decl.cc:1814
0x9cd5a3 pushdecl(tree_node*, bool)
../../gcc/cp/name-lookup.cc:3686
0x9d0012 do_pushdecl_with_scope
../../gcc/cp/name-lookup.cc:4769
0x9d022e pushdecl_namespace_level(tree_node*, bool)
../../gcc/cp/name-lookup.cc:6126
0xabb63a tsubst_friend_class
../../gcc/cp/pt.cc:11589
0xabb63a instantiate_class_template(tree_node*)
../../gcc/cp/pt.cc:12320
0xb2b3e6 complete_type(tree_node*)
../../gcc/cp/typeck.cc:138

[Bug c++/107400] New: ICE tree check: expected class 'type', have 'declaration' (template_decl) in get_originating_module_decl, at cp/module.cc:18587

[gscfq--- via Gcc-bugs]

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

Bug ID: 107400
   Summary: ICE tree check: expected class 'type', have
'declaration' (template_decl) in
get_originating_module_decl, at cp/module.cc:18587
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With file g++.dg/template/pr59930-3.C :
(gcc configured with --enable-checking=yes)


$ g++-13-20221023 -c pr59930-3.C
$
$ g++-13-20221023 -c pr59930-3.C -fmodules-ts
'
tree check: expected class 'type', have 'declaration' (template_decl) in
get_originating_module_decl, at cp/module.cc:18587
   17 | void method() const
  |  ^~
0x7019d3 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:8886
0x98b558 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3649
0x98b558 get_originating_module_decl(tree_node*)
../../gcc/cp/module.cc:18587
0x98b687 get_originating_module(tree_node*, bool)
../../gcc/cp/module.cc:18626
0x919fa6 dump_module_suffix
../../gcc/cp/error.cc:207
0x91acba dump_module_suffix
../../gcc/cp/error.cc:189
0x91acba dump_aggr_type
../../gcc/cp/error.cc:856
0x9262da dump_function_decl
../../gcc/cp/error.cc:1812
0x9294f6 decl_to_string
../../gcc/cp/error.cc:3297
0x9294f6 cp_printer
../../gcc/cp/error.cc:4471
0x22113c0 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.cc:1475
0x2211a20 pp_format_verbatim(pretty_printer*, text_info*)
../../gcc/pretty-print.cc:1536
0x2211af4 pp_verbatim(pretty_printer*, char const*, ...)
../../gcc/pretty-print.cc:1790
0x919caf print_instantiation_full_context
../../gcc/cp/error.cc:3710
0x92a3fa maybe_print_instantiation_context
../../gcc/cp/error.cc:3858
0x92a3fa cp_diagnostic_starter
../../gcc/cp/error.cc:3548
0x21f02fc diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.cc:1549
0x21f0a3a diagnostic_impl
../../gcc/diagnostic.cc:1712
0x21f1686 internal_error(char const*, ...)
../../gcc/diagnostic.cc:2112
0x7019d3 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:8886

[Bug c++/107399] New: ICE in cpp_maybe_module_directive, at libcpp/lex.cc:3454

[gscfq--- via Gcc-bugs]

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

Bug ID: 107399
   Summary: ICE in cpp_maybe_module_directive, at
libcpp/lex.cc:3454
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started wirh r11, using e.g. file g++.dg/modules/namespace-1_a.C :
(gcc configured with --enable-checking=yes)


$ g++-13-20221023 -c namespace-1_a.C -fmodules-ts
$
$ g++-13-20221023 -c namespace-1_a.C -fmodules-ts -C
namespace-1_a.C:6:1: internal compiler error: in cpp_maybe_module_directive, at
libcpp/lex.cc:3454
6 | {
  | ^
0x223f0b0 cpp_maybe_module_directive
../../libcpp/lex.cc:3449
0x223f0b0 _cpp_lex_token
../../libcpp/lex.cc:3638
0x22459df cpp_get_token_1
../../libcpp/macro.cc:2930
0xbbd86d c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc/c-family/c-lex.cc:490
0x9d8b66 cp_lexer_get_preprocessor_token
../../gcc/cp/parser.cc:940
0xa36fef cp_lexer_new_main
../../gcc/cp/parser.cc:736
0xa36fef c_parse_file()
../../gcc/cp/parser.cc:48854
0xbcfb01 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1247

[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake

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

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

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

https://gcc.gnu.org/g:1c64aba8cdf6509533f554ad86640f274cdbe37f

commit r13-3490-g1c64aba8cdf6509533f554ad86640f274cdbe37f
Author: H.J. Lu 
Date:   Wed Oct 19 12:53:35 2022 -0700

Always use TYPE_MODE instead of DECL_MODE for vector field

e034c5c8957 re PR target/78643 (ICE in convert_move, at expr.c:230)

fixed the case where DECL_MODE of a vector field is BLKmode and its
TYPE_MODE is a vector mode because of target attribute.  Remove the
BLKmode check for the case where DECL_MODE of a vector field is a vector
mode and its TYPE_MODE isn't a vector mode because of target attribute.

gcc/

PR target/107304
* expr.cc (get_inner_reference): Always use TYPE_MODE for vector
field with vector raw mode.

gcc/testsuite/

PR target/107304
* gcc.target/i386/pr107304.c: New test.

[Bug target/78643] [6 Regression] ICE in convert_move, at expr.c:230

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

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

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

https://gcc.gnu.org/g:1c64aba8cdf6509533f554ad86640f274cdbe37f

commit r13-3490-g1c64aba8cdf6509533f554ad86640f274cdbe37f
Author: H.J. Lu 
Date:   Wed Oct 19 12:53:35 2022 -0700

Always use TYPE_MODE instead of DECL_MODE for vector field

e034c5c8957 re PR target/78643 (ICE in convert_move, at expr.c:230)

fixed the case where DECL_MODE of a vector field is BLKmode and its
TYPE_MODE is a vector mode because of target attribute.  Remove the
BLKmode check for the case where DECL_MODE of a vector field is a vector
mode and its TYPE_MODE isn't a vector mode because of target attribute.

gcc/

PR target/107304
* expr.cc (get_inner_reference): Always use TYPE_MODE for vector
field with vector raw mode.

gcc/testsuite/

PR target/107304
* gcc.target/i386/pr107304.c: New test.

[Bug c++/107398] New: ICE in maybe_key_decl, at cp/module.cc:18834

[gscfq--- via Gcc-bugs]

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

Bug ID: 107398
   Summary: ICE in maybe_key_decl, at cp/module.cc:18834
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started wirh r11, using e.g. file g++.dg/cpp0x/lambda/lambda-mangle6.C :
(gcc configured with --enable-checking=yes)


$ g++-13-20221023 -c lambda-mangle6.C -fmodules-ts
lambda-mangle6.C:10:37: internal compiler error: in maybe_key_decl, at
cp/module.cc:18834
   10 | template int R::x = []{int i; return 1;}();
  | ^
0x9b303e maybe_key_decl(tree_node*, tree_node*)
../../gcc/cp/module.cc:18834
0xa052fb cp_parser_lambda_expression
../../gcc/cp/parser.cc:11033
0xa052fb cp_parser_primary_expression
../../gcc/cp/parser.cc:5766
0xa08d9e cp_parser_postfix_expression
../../gcc/cp/parser.cc:7717
0xa20fef cp_parser_unary_expression
../../gcc/cp/parser.cc:9081
0x9ebd2f cp_parser_cast_expression
../../gcc/cp/parser.cc:9985
0x9ec65f cp_parser_binary_expression
../../gcc/cp/parser.cc:10087
0x9ed404 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10427
0x9f0275 cp_parser_constant_expression
../../gcc/cp/parser.cc:10722
0x9f1791 cp_parser_initializer_clause
../../gcc/cp/parser.cc:25333
0x9f3f0b cp_parser_initializer
../../gcc/cp/parser.cc:25273
0xa2eb4c cp_parser_init_declarator
../../gcc/cp/parser.cc:22838
0xa32e1f cp_parser_single_declaration
../../gcc/cp/parser.cc:31903
0xa32f85 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.cc:31456
0xa33c8f cp_parser_explicit_template_declaration
../../gcc/cp/parser.cc:31729
0xa33c8f cp_parser_template_declaration_after_export
../../gcc/cp/parser.cc:31748
0xa36316 cp_parser_declaration
../../gcc/cp/parser.cc:14899
0xa372b8 cp_parser_translation_unit
../../gcc/cp/parser.cc:5076
0xa372b8 c_parse_file()
../../gcc/cp/parser.cc:48856
0xbcfb01 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1247

[Bug fortran/107397] New: [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654

[gscfq--- via Gcc-bugs]

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

Bug ID: 107397
   Summary: [10/11/12/13 Regression] ICE in gfc_arith_plus, at
fortran/arith.cc:654
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r10, r9 gives an error.
Started between 20190630 and 20190728.


$ cat z1.f90
program p
   type t
  real :: a = 1.0
   end type
   type(t), parameter :: x = z'1'
   x%a = x%a + 2
   x%a = x%a - 2
   x%a = x%a * 2
   x%a = x%a / 2
   x%a = x%a ** 2
end


$ gfortran-13-20221023 -c z1.f90
f951: internal compiler error: Segmentation fault
0xf43b3f crash_signal
../../gcc/toplev.cc:314
0x7c25fb gfc_arith_plus
../../gcc/fortran/arith.cc:654
0x7c0ee3 reduce_binary
../../gcc/fortran/arith.cc:1514
0x7c1352 eval_intrinsic
../../gcc/fortran/arith.cc:1701
0x83418c match_level_2
../../gcc/fortran/matchexp.cc:524
0x8342c2 match_level_3
../../gcc/fortran/matchexp.cc:551
0x8343b4 match_level_4
../../gcc/fortran/matchexp.cc:599
0x8343b4 match_and_operand
../../gcc/fortran/matchexp.cc:693
0x8345a2 match_or_operand
../../gcc/fortran/matchexp.cc:722
0x834672 match_equiv_operand
../../gcc/fortran/matchexp.cc:765
0x834744 match_level_5
../../gcc/fortran/matchexp.cc:811
0x833b11 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.cc:870
0x82b0f0 gfc_match(char const*, ...)
../../gcc/fortran/match.cc:1131
0x82ceb9 gfc_match_assignment()
../../gcc/fortran/match.cc:1330
0x858310 match_word
../../gcc/fortran/parse.cc:67
0x858310 decode_statement
../../gcc/fortran/parse.cc:363
0x859e0a next_free
../../gcc/fortran/parse.cc:1402
0x859e0a next_statement
../../gcc/fortran/parse.cc:1634
0x85b84b parse_spec
../../gcc/fortran/parse.cc:4190
0x85ea5c parse_progunit
../../gcc/fortran/parse.cc:6237

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

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

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

Bug ID: 107396
   Summary: [12 regression] new test case
gcc.dg/analyzer/pipe-glibc.c in
r13-3466-g792f039fc37faa fails with excess errors
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:792f039fc37faa3446725a643c8018f084e8ccab, r13-3466-g792f039fc37faa
make  -k check-gcc RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/pipe-glibc.c"
FAIL: gcc.dg/analyzer/pipe-glibc.c (test for excess errors)
# of unexpected failures1


I am only seeing this failure on power 9.  It works fine on power 8 and power
10.


commit 792f039fc37faa3446725a643c8018f084e8ccab (HEAD, refs/bisect/bad)
Author: David Malcolm 
Date:   Mon Oct 24 16:38:22 2022 -0400

analyzer: handle "pipe" and "pipe2" [PR106300]

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
-fdiagnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summaries -S -o pipe-glibc.s^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c: In
function 'write_to_pipe':^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3:
warning: use of possibly-NULL 'stream' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:27:12:
note: (1) this call could return NULL^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3:
note: (2) argument 4 ('stream') from (1) could be NULL where non-null
expected^M
: note: argument 4 of '__builtin_fwrite' must be non-null^M
FAIL: gcc.dg/analyzer/pipe-glibc.c (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3:
warning: use of possibly-NULL 'stream' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]

[Bug tree-optimization/107394] [13 Regression] ICE in verify_range, at value-range.cc:716

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Tomas Kalibera  ---
I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
mailing list in May:

https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html

The patches still apply to current 10,11,12 and trunk. Please see the email
linked above for more information.

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

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

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

--- Comment #12 from Alexander Monakov  ---
ICE on the emutls-3.c testcase isn't related to emutls. Rather, the frontend
invokes decl_default_tls_model before attributes are processed, so the first
time around we miss the 'common' attribute when deciding the TLS access model.

The following cut-down testcase fails on x86 as well with -m32 -fpie:

__attribute__((common))
__thread int i;

int *f()
{
return 
}

Before the offending commit GCC compiled 'f' as if the attribute was ignored.
(on ELF targets combining TLS and COMMON is problematic if not undefined)

[Bug tree-optimization/107395] New: Missed warning opportunity on bultin string optimization

[nrk at disroot dot org via Gcc-bugs]

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

Bug ID: 107395
   Summary: Missed warning opportunity on bultin string
optimization
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nrk at disroot dot org
  Target Milestone: ---

In the first case, it optimizes the strlen call with 0, with the assumption
that
for a single byte array to be a valid string, it has to be 0 len; while it can
clearly see that *s != '\0'

In the 2nd case, it optimizes the call out to 2, which is correct.
But in the 3rd case (with missing nul-byte) it figures something is wrong and
just goes ahead an let's the libc strlen deal with it.

In both cases (f and f3) it should be possible (I assume without too much
effort, given that f3 seems to be aware of something going wrong) to detect
that strlen is being called with a non-nul-terminated byte array and issue a
warning.

Perhaps a good candidate for -Wstringop-overread ?

#include 

size_t f(void) {
char s[1] = "h";
return strlen(s); /* "optimized out" to 0 */
}

size_t f2(void) {
char s[] = "hi";
return strlen(s); /* optimized out to 2 */
}

size_t f3(void) {
char s[2] = "hi";
return strlen(s); /* calls strlen */
}


Tested with gcc 12.2, compiled with -O2 (https://godbolt.org/z/1KW7qna1E)

[Bug c++/85944] Address of temporary bound to a function parameter at global scope not considered constexpr

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

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

--- Comment #7 from Jakub Jelinek  ---
I'm afraid the middle-end can't do here much.
maybe_nonzero_address handles file scope vars (vars in symbol table) and
automatic vars, but for the TARGET_EXPR temporaries created by
force_target_expr -> build_local_temp if they are built outside of the function
it doesn't know anything about them until they are gimplified.  They are
artificial VAR_DECLs with NULL DECL_CONTEXT, their DECL_CONTEXT will be set
only
during gimplification when the static ctors function is created.

So, either we'd need to mark such local temporaries some way that
maybe_nonzero_address could assume that while they don't look like automatic
vars yet, they will be ones later on (special attribute, or flag, etc.), or
constexpr.cc would need to handle folding those cases itself.

[Bug tree-optimization/107394] New: [13 Regression] ICE in verify_range, at value-range.cc:716

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107394
   Summary: [13 Regression] ICE in verify_range, at
value-range.cc:716
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20221023 snapshot (g:0e37fd4dc74c1db99cdc7d71ef378e1221253c6f) ICEs
when compiling the following testcase w/ -O2:

static double
quux (double x)
{
  return __builtin_fabs (x);
}

__attribute__ ((flatten, optimize ("-ffinite-math-only"))) static int
bar (int *p)
{
  *p = quux (0.0);

  return 0;
}

void
foo (int *p)
{
  (void) bar (p);
}

% gcc-13 -O2 -c owzufzxh.c
during IPA pass: inline
owzufzxh.c: In function 'bar.isra':
owzufzxh.c:10:8: internal compiler error: in verify_range, at
value-range.cc:716
   10 |   *p = quux (0.0);
  |^~
0x7bca0d frange::verify_range()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/value-range.cc:716
0x1160ad8 range_info_get_range(tree_node*, vrange&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-ssanames.cc:121
0x1160ad8 duplicate_ssa_name_range_info(tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-ssanames.cc:750
0xf85de3 remap_ssa_name
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:256
0xf8bf37 remap_gimple_op_r
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:1028
0x12179c3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree.cc:11270
0xbf1a92 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/gimple-walk.cc:221
0xf886bf remap_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:1986
0xf8cb87 copy_bb
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:2056
0xf8e87c copy_cfg_body
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:3090
0xf8e87c copy_body
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:3343
0xf93452 expand_call_inline
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:5128
0xf95411 gimple_expand_calls_inline
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:5323
0xf95411 optimize_inline_calls(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-inline.cc:5495
0xc9653b inline_transform(cgraph_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/ipa-inline-transform.cc:790
0xe0d116 execute_one_ipa_transform_pass
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/passes.cc:2336
0xe0d116 execute_all_ipa_transforms(bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/passes.cc:2399
0xa463dd cgraph_node::expand()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:1827
0xa463dd cgraph_node::expand()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:1787
0xa47a1e expand_all_functions
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:2008

[Bug c/102989] Implement C2x's n2763 (_BitInt)

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #11)
> The x86-64 psABI has been changed for this:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/
> 8ca45392570e96920f8a15d903d6122f6d263cd0
> but the state of the padding bits isn't mentioned there anywhere.

It was done on purpose.  Here are discussions about padding:

https://reviews.llvm.org/D108643

> Also, not sure I understand the
> \texttt{_BitInt(N)} types are byte-aligned to the next greatest power-of-2
> up to 64 bits.
> sentence because for N <= 64 there are different rules that apply (size and
> alignment
> same as smallest standard integral type that can contain them) and so IMHO
> it should just
> say that the N > 64 bit-precise types are 64-bit aligned.

It sounds reasonable.

[Bug c/107389] Alignment not inferred from type at -O0

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

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

--- Comment #3 from Richard Henderson  ---
If __builtin_assume_aligned were to work at -O0,
that would also work for me.  Better, probably,
than fiddling with __attribute__((aligned)).

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

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

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

--- Comment #11 from Alexander Monakov  ---
I've broken out the C++ issue from comment #10 as PR 107393, thanks for the
testcase. It's a separate issue from emutls and Fortran ICEs on other targets.

[Bug c++/107393] New: Wrong TLS model for specialized template

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

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

Bug ID: 107393
   Summary: Wrong TLS model for specialized template
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
bergner at gcc dot gnu.org, iains at gcc dot gnu.org,
law at gcc dot gnu.org, marxin at gcc dot gnu.org,
segher at gcc dot gnu.org, seurer at gcc dot gnu.org,
unassigned at gcc dot gnu.org
Blocks: 107353
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #107353 +++

template
struct S {
static __thread int i;
};

template
__thread int S::i;

extern template
__thread int S::i;

int ()
{
return S::i;
}

int ()
{
return S::i;
}

Current trunk ICEs due to a new verification in ipa-visibility, before that gcc
-O2 used to emit:


_Z2viv:
movq%fs:0, %rax
addq$_ZN1SIvE1iE@tpoff, %rax
ret
_Z2civ:
movq%fs:0, %rax
addq$_ZN1SIcE1iE@tpoff, %rax
ret
_ZN1SIcE1iE:
.zero   4

which incorrectly uses local-exec model to retrieve S::i, which is extern
(and thus could reside in a shared library at link time, not the executable
being linked).

Clang correctly uses initial-exec for S::i and local-exec for S::i.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
[Bug 107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

[Bug c/107389] Alignment not inferred from type at -O0

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

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

--- Comment #2 from Richard Biener  ---
Btw, with

typedef __uint128_t aligned_type __attribute__((aligned(16)));
_Static_assert(__alignof(aligned_type) == 16);
__uint128_t foo(aligned_type *p) { p = __builtin_assume_aligned (p, 16); return
__atomic_load_n(p, 0); }

I see

foo:
.LFB0:
.cfi_startproc
lpq %r4,0(%r3)
stmg%r4,%r5,0(%r2)
br  %r14

at -O2 but without the __builtin_assume_aligned optimization doesn't help much.
And without optimization but __builtin_assume_aligned in place we simply
leave that around - we probably should have elided it in
fold-all-builtins and set alignment on the destination SSA name also
when not optimizing (we do that there when optimizing), or do the same
during RTL expansion.

[Bug libstdc++/95048] [10/11/12/13 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[ulf.lorenz at ptvgroup dot com via Gcc-bugs]

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

--- Comment #17 from Ulf Lorenz  ---
Your point was an item during implementation. Besides the other cases being
rare and probably exotic, the killer argument was that it would be way more
complex. While I am confident now that I can move around the libstdc++ source
code reasonably well and do simple patches and working tests, understanding
iconv and the required acceptance_tests_with_special_compilation_flags requires
considerable more time budget than I have needed so far.

I agree that this is not the bullet-proof solution, though, but only an
incremental improvement.

[Bug c/107389] Alignment not inferred from type at -O0

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Yes, that's definitely a no-go since pointer types have no semantic meanings.

I don't understand s390 assembly much but I see calls to __atomic_load_16@PLT
for both -O0 and -O2 so I wonder if it is the testcase you are seeing a
difference for?

If __atomic_load_n (and others) imply certain alignment of the pointer
arguments then their expanders have to explicitely add that.  But I guess
there's no requirement that __builtin_atomic_load (p, 16) has p 16 byte
aligned?

There was talks to "rectify" specified type alignment for pointers in
function arguments but IIRC that has never materialized.  See duplicate
bugreports about memcpy involving properly align-typed function parameters.

That said, iff __atomic_* constraints are not exploited we should do that.

[Bug middle-end/50481] builtin to reverse the bit order

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

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

Carlo Wood  changed:

   What|Removed |Added

 CC||carlo at gcc dot gnu.org

--- Comment #8 from Carlo Wood  ---
Bump - I need this too ;)

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #11 from Jakub Jelinek  ---
The x86-64 psABI has been changed for this:
https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/8ca45392570e96920f8a15d903d6122f6d263cd0
but the state of the padding bits isn't mentioned there anywhere.
Also, not sure I understand the
\texttt{_BitInt(N)} types are byte-aligned to the next greatest power-of-2 up
to 64 bits.
sentence because for N <= 64 there are different rules that apply (size and
alignment
same as smallest standard integral type that can contain them) and so IMHO it
should just
say that the N > 64 bit-precise types are 64-bit aligned.

[Bug target/107316] [aarch64] Init big const value should be improved compare to llvm

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #3 from Wilco  ---
As Andrew says, it's a duplicate so fixed now.

[Bug target/107316] [aarch64] Init big const value should be improved compare to llvm

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

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

Bug 106583 Summary: Suboptimal immediate generation on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106583

   What|Removed |Added

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

[Bug target/106583] Suboptimal immediate generation on aarch64

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #3 from Wilco  ---
Fixed

[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Lance Fredrickson from comment #0)
> Thread 2 "ld.lld" received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 27688]
> 0x42deada0 in
> std::condition_variable::wait(std::unique_lock&)@GLIBCXX_3.4.11
> () from /mmc/usr/lib/libstdc++.so.6

If ld.lld was built against gcc-12 then why is it linking to the
@GLIBCXX_3.4.11 symbol?

Does this target support symbol renaming using .symver ?

[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled

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

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

--- Comment #2 from Jonathan Wakely  ---
We're missing a proper testcase.

Is the buggy lld binary linked by lld, or binutils? Maybe there's a bug in
handling of ELF symbol versioning.

[Bug libstdc++/95048] [10/11/12/13 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

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

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

--- Comment #16 from Jonathan Wakely  ---
Thanks. As per https://gcc.gnu.org/lists.html patches for libstdc++ need to be
CC'd to the libstdc++ list, but I'll find it in the gcc-patches archive and
review it ASAP.

I'm still concerned that this just moves the problem, so that different cases
fail instead. But maybe it's an improvement for the most common case, and it's
better to fail in the rare situations.

[Bug ada/107392] New: excessive compilation time for decimal_literal - that should be rejected as type-error

[johannes.waldmann--- via Gcc-bugs]

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

Bug ID: 107392
   Summary: excessive compilation time for decimal_literal - that
should be rejected as type-error
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johannes.waldm...@htwk-leipzig.de
  Target Milestone: ---

this compilation does not seem to finish:

$ echo "procedure main is x : integer := 1.1e1_11; begin null; end main;" >
main.adb
$ gcc -c main.adb

$ gcc --version
gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)


while the program should just be rejected - as does indeed happen for

$ echo "procedure main is x : integer := 1.1e1_1; begin null; end main;" >
main.adb
$ gcc -c main.adb
main.adb:1:34: error: expected type "Standard.Integer"
main.adb:1:34: error: found type universal real

[Bug tree-optimization/107176] [10/11/12 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression] Wrong
   |Wrong code at -Os on|code at -Os on
   |x86_64-pc-linux-gnu since   |x86_64-pc-linux-gnu since
   |r7-2012-g43aabfcfd4139e4c   |r7-2012-g43aabfcfd4139e4c
  Known to work||13.0

--- Comment #10 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

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

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

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

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

commit r13-3486-g4c5b1160776382772fc0a33130dfaf621699fdbf
Author: Richard Biener 
Date:   Mon Oct 24 08:52:12 2022 +0200

tree-optimization/107176 - SCEV analysis association issue

The following fixes a wrong-code issue caused by SCEV analysis
associating an addition due trying to use tail-recursion in
follow_ssa_edge_expr.  That causes us to apply a conversion at
the wrong point and thus miscompute the scalar evolution of
an induction variable.  This reverts the PR66375 fix and
revisits the PR42512 fix by keeping the evolution symbolic
up to the point we process the first linear function when
we then can check for the supported cases and substitute the
whole symbolic expression with the built chrec substituting
the proper initial value.

To simplify passing around things and to clarify scoping of
the involved functions this change wraps the SCEV DFS walking
code into a class.

PR tree-optimization/107176
PR tree-optimization/66375
PR tree-optimization/42512
* tree-scalar-evolution.cc (follow_ssa_edge_expr): Revert
the PR66375 fix, do not not associate PLUS_EXPR to be able
to use tail-recursion.
(follow_ssa_edge_binary): Likewise.
(interpret_loop_phi): Revert PR42512 fix, do not throw
away analyze_evolution_in_loop result after the fact.
(follow_ssa_edge_expr): When reaching halting_phi initalize
the evolution to the symbolic value of the PHI result.
(add_to_evolution_1): When adding the first evolution verify
we can handle the expression wrapping the symbolic evolution
and replace that in full using the initial condition.
(class scev_dfs): New, contains ...
(follow_ssa_edge_expr, follow_ssa_edge_binary,
follow_ssa_edge_in_condition_phi_branch,
follow_ssa_edge_in_condition_phi,
follow_ssa_edge_inner_loop_phi,
add_to_evolution, add_to_evolution_1): ... these with
loop and halting_phi arguments in class data.
(scev_dfs::get_ev): New toplevel DFS entry, start with
a chrec_dont_know evolution.
(analyze_evolution_in_loop): Use scev_dfs.

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

[Bug middle-end/66375] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

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

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

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

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

commit r13-3486-g4c5b1160776382772fc0a33130dfaf621699fdbf
Author: Richard Biener 
Date:   Mon Oct 24 08:52:12 2022 +0200

tree-optimization/107176 - SCEV analysis association issue

The following fixes a wrong-code issue caused by SCEV analysis
associating an addition due trying to use tail-recursion in
follow_ssa_edge_expr.  That causes us to apply a conversion at
the wrong point and thus miscompute the scalar evolution of
an induction variable.  This reverts the PR66375 fix and
revisits the PR42512 fix by keeping the evolution symbolic
up to the point we process the first linear function when
we then can check for the supported cases and substitute the
whole symbolic expression with the built chrec substituting
the proper initial value.

To simplify passing around things and to clarify scoping of
the involved functions this change wraps the SCEV DFS walking
code into a class.

PR tree-optimization/107176
PR tree-optimization/66375
PR tree-optimization/42512
* tree-scalar-evolution.cc (follow_ssa_edge_expr): Revert
the PR66375 fix, do not not associate PLUS_EXPR to be able
to use tail-recursion.
(follow_ssa_edge_binary): Likewise.
(interpret_loop_phi): Revert PR42512 fix, do not throw
away analyze_evolution_in_loop result after the fact.
(follow_ssa_edge_expr): When reaching halting_phi initalize
the evolution to the symbolic value of the PHI result.
(add_to_evolution_1): When adding the first evolution verify
we can handle the expression wrapping the symbolic evolution
and replace that in full using the initial condition.
(class scev_dfs): New, contains ...
(follow_ssa_edge_expr, follow_ssa_edge_binary,
follow_ssa_edge_in_condition_phi_branch,
follow_ssa_edge_in_condition_phi,
follow_ssa_edge_inner_loop_phi,
add_to_evolution, add_to_evolution_1): ... these with
loop and halting_phi arguments in class data.
(scev_dfs::get_ev): New toplevel DFS entry, start with
a chrec_dont_know evolution.
(analyze_evolution_in_loop): Use scev_dfs.

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

[Bug tree-optimization/107176] [10/11/12/13 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c

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

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

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

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

commit r13-3486-g4c5b1160776382772fc0a33130dfaf621699fdbf
Author: Richard Biener 
Date:   Mon Oct 24 08:52:12 2022 +0200

tree-optimization/107176 - SCEV analysis association issue

The following fixes a wrong-code issue caused by SCEV analysis
associating an addition due trying to use tail-recursion in
follow_ssa_edge_expr.  That causes us to apply a conversion at
the wrong point and thus miscompute the scalar evolution of
an induction variable.  This reverts the PR66375 fix and
revisits the PR42512 fix by keeping the evolution symbolic
up to the point we process the first linear function when
we then can check for the supported cases and substitute the
whole symbolic expression with the built chrec substituting
the proper initial value.

To simplify passing around things and to clarify scoping of
the involved functions this change wraps the SCEV DFS walking
code into a class.

PR tree-optimization/107176
PR tree-optimization/66375
PR tree-optimization/42512
* tree-scalar-evolution.cc (follow_ssa_edge_expr): Revert
the PR66375 fix, do not not associate PLUS_EXPR to be able
to use tail-recursion.
(follow_ssa_edge_binary): Likewise.
(interpret_loop_phi): Revert PR42512 fix, do not throw
away analyze_evolution_in_loop result after the fact.
(follow_ssa_edge_expr): When reaching halting_phi initalize
the evolution to the symbolic value of the PHI result.
(add_to_evolution_1): When adding the first evolution verify
we can handle the expression wrapping the symbolic evolution
and replace that in full using the initial condition.
(class scev_dfs): New, contains ...
(follow_ssa_edge_expr, follow_ssa_edge_binary,
follow_ssa_edge_in_condition_phi_branch,
follow_ssa_edge_in_condition_phi,
follow_ssa_edge_inner_loop_phi,
add_to_evolution, add_to_evolution_1): ... these with
loop and halting_phi arguments in class data.
(scev_dfs::get_ev): New toplevel DFS entry, start with
a chrec_dont_know evolution.
(analyze_evolution_in_loop): Use scev_dfs.

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

[Bug ada/107391] New: decimal_literal with long exponent: Constraint_Error uintp.adb:2287

[johannes.waldmann--- via Gcc-bugs]

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

Bug ID: 107391
   Summary: decimal_literal with long exponent: Constraint_Error
uintp.adb:2287
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johannes.waldm...@htwk-leipzig.de
  Target Milestone: ---

$ echo "procedure main is x : float := 1.1e; begin null;
end main;" > main.adb

$ gcc -c main.adb 
+===GNAT BUG DETECTED==+
| 12.2.1 20220819 (Red Hat 12.2.1-2) (x86_64-redhat-linux) Constraint_Error
uintp.adb:2287 explicit raise|
| Error detected at main.adb:1:32  |
| Compiling main.adb   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |

$ gcc --version
gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)


with up to ten digits in the exponent, I get the expected

$ echo "procedure main is x : float := 1.1e1_1; begin null; end main;"
> main.adb

$ gcc -c main.adb 
main.adb:1:32: error: value not in range of type "Standard.Float"
main.adb:1:32: error: static expression fails Constraint_Check

[Bug c++/106644] [C++23] P2468R2 - The Equality Operator You Are Looking For

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 53770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53770=edit
gcc13-pr106644-wip.patch

Untested WIP.
Compared to vanilla trunk, this rejects the f2 case which is a2 from the
example in the standard.  But doesn't handle anything else unfortunately.
In the g1 case (c1 from the example in the standard), it is accepted for a
wrong reason, decls_match rejects the comparison between B::operator== and
C::operator!= because they have different CP_DECL_CONTEXT and so we think that
the operator== is a rewrite target when it is not.  Shall we use
something different than decls_match (say a copy of it that ignores the context
and for non-static members the this type too)?
The reason it is then accepted is some non-standard handling of the
rewritten/reversed candidates in joust?
Then g2 case (c2 in the standard) is then incorrectly accepted because of that
code in joust or so.
Not really sure if we have a way to search just in a single namespace and not
all the containing ones, and not sure about the using decls if those are
something that should be ignored like in the patch or handled too.
The k case in the testcase is I think because of joust too.
The u3 case in the testcase is I think about whether using decls count or not.
Anyway, the remaining // ERR cases are where clang++ trunk rejects stuff but we
with the patch don't.

[Bug middle-end/106208] [12/13 Regression] ICE in branch_prob, at profile.cc:1459 since r12-5275-gbcebd05720540e25

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101598
 CC||ebotcazou at gcc dot gnu.org,
   ||edlinger at gcc dot gnu.org

--- Comment #5 from Thomas Schwinge  ---
This ICE (when compiling with '-ftest-coverage -fcoarray=lib') reported here
originally: 'gfortran.dg/coarray/registering_1.f90' as well as Martin's reduced
test case 'reg.f90' disappears via Eric's PR101598-related commit
r13-3485-gcb21297f9259ceedd5f5dd7c3973535f14124d6d "Relax assertion in
profiler".

Should we still add these Fortran test cases -- or is in fact 'gfortran' still
generating "undesirable" location information?  Stated by Eric: "This assertion
in branch_prob [...] had been correct until the fix for PR debug/101598 was
installed", but that clearly doesn't apply to the Fortran case discussed in
this PR, as Bernd's commit r12-2846-ga45918f8a7444a40eb397a037683ba5900a2db74
"Ada: Remove debug line number for DECL_IGNORED_P functions" was relevant for
Ada only; 'gcc/ada/gcc-interface/trans.c'.

[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Eric Botcazou
:

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

commit r12-8866-gda1f6e5260dbcce59372cb522e1af763f25eed6b
Author: Eric Botcazou 
Date:   Tue Oct 25 12:20:33 2022 +0200

Relax assertion in profiler

This assertion in branch_prob:

  if (bb == ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb)
{
  location_t loc = DECL_SOURCE_LOCATION (current_function_decl);
  gcc_checking_assert (!RESERVED_LOCATION_P (loc));

had been correct until the fix for PR debug/101598 was installed.

gcc/
* profile.cc (branch_prob): Be prepared for ignored functions with
DECL_SOURCE_LOCATION set to UNKNOWN_LOCATION.

gcc/testsuite:
* gnat.dg/specs/coverage1.ads: New test.
* gnat.dg/specs/variant_part.ads: Minor tweak.
* gnat.dg/specs/weak1.ads: Add dg directive.

[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r13-3485-gcb21297f9259ceedd5f5dd7c3973535f14124d6d
Author: Eric Botcazou 
Date:   Tue Oct 25 12:20:33 2022 +0200

Relax assertion in profiler

This assertion in branch_prob:

  if (bb == ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb)
{
  location_t loc = DECL_SOURCE_LOCATION (current_function_decl);
  gcc_checking_assert (!RESERVED_LOCATION_P (loc));

had been correct until the fix for PR debug/101598 was installed.

gcc/
* profile.cc (branch_prob): Be prepared for ignored functions with
DECL_SOURCE_LOCATION set to UNKNOWN_LOCATION.

gcc/testsuite:
* gnat.dg/specs/coverage1.ads: New test.
* gnat.dg/specs/variant_part.ads: Minor tweak.
* gnat.dg/specs/weak1.ads: Add dg directive.

[Bug libstdc++/107376] regex executor requires allocator to be default constructible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Thanks for the report. The patch is necessary, but not sufficient.

We should probably have used the same allocator for _M_rep_count but doing that
now would be an ABI break.

We should definitely have used the same allocator for _M_states, and for its
_ResultsVec members, which would also be an ABI break, but we can mitigate that
with:

--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -124,9 +124,10 @@ namespace __detail
break;
  std::fill_n(_M_states._M_visited_states, _M_nfa.size(), false);
  auto __old_queue = std::move(_M_states._M_match_queue);
+ auto __alloc = _M_cur_results.get_allocator();
  for (auto& __task : __old_queue)
{
- _M_cur_results = std::move(__task.second);
+ _M_cur_results = _ResultsVec(std::move(__task.second), __alloc);
  _M_dfs(__match_mode, __task.first);
}
  if (__match_mode == _Match_mode::_Prefix)

With this change and the original patch suggestion, _M_cur_results always has
the same allocator as _M_results and so _Executor::_M_handle_accept won't
replace the allocator in _M_results when assigning the new results to it.

We could also use the same allocator for the local vector here:

bool _Executor<_BiIter, _Alloc, _TraitsT, __dfs_mode>::
_M_lookahead(_StateIdT __next)
{
  // Backreferences may refer to captured content.
  // We may want to make this faster by not copying,
  // but let's not be clever prematurely.
  _ResultsVec __what(_M_cur_results);

Or we can rely on select_on_container_copy_construction() to do "the right
thing". Users of non-propagating allocators would probably prefer that, but it
means that matching with std::pmr::match_results will always use new/delete for
allocating intermediate results. But that's just one of the costs of the PMR
design.

[Bug c++/107390] template-nested lambda type uniqueness

[development at jordi dot vilar.cat via Gcc-bugs]

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

Jordi Vilar  changed:

   What|Removed |Added

 CC||development at jordi dot 
vilar.cat

--- Comment #1 from Jordi Vilar  ---
This same code compiles successflully with clang-14 and mscv-19.x. The
following link to compiler explorer demoes it.

https://godbolt.org/z/a9oqbd8bx

[Bug c++/107390] New: template-nested lambda type uniqueness

[development at jordi dot vilar.cat via Gcc-bugs]

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

Bug ID: 107390
   Summary: template-nested lambda type uniqueness
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: development at jordi dot vilar.cat
  Target Milestone: ---

type obtained from a lambda (with c++20 decltype()) nested into a template
(either class o function) is not resolved as a unique type, making this simple
code to fail (compiled with g++-12 -std=c++20):

#include 

template struct test1
{
using type0 = decltype([]{});
using type1 = std::type_identity_t;

static_assert(std::is_same_v);
};

template void test2()
{
using type0 = decltype([]{});
using type1 = std::type_identity_t;

static_assert(std::is_same_v);
}

int main(int, char**)
{
test1{};
test2();
}

both static_assert fail identically:

 error: static assertion failed
8 | static_assert(std::is_same_v);
  |   ~^~~
:8:24: note: 'std::is_same_v::,
test1:: >' evaluates to false
:16:24: error: static assertion failed
   16 | static_assert(std::is_same_v);
  |   ~^~~
:16:24: note: 'std::is_same_v()::,
test2():: >' evaluates to false

This compiles correctly if lambdas are not nested inside a template.

[Bug rtl-optimization/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
I'm testing

modified   gcc/lra-constraints.cc
@@ -4382,7 +4382,14 @@ curr_insn_transform (bool check_only_p)
 (op, (enum reg_class) goal_alt[i]) == NO_REGS)
|| no_input_reloads_p))
  {
-   rtx tem = force_const_mem (mode, op);
+   rtx tem;
+
+   /* PR 107057, for same constant pool, don't bother
+  force_const_mem again, just reuse the matched op.  */
+   if (goal_alt_matches[i] >= 0)
+ tem = *curr_id->operand_loc[goal_alt_matches[i]];
+   else
+ tem = force_const_mem (mode, op);

change_p = true;
if (subreg != NULL_RTX)

[Bug tree-optimization/107387] [13 Regression] gcc trunk -O2 crashes when enable UBSan since r13-2288-g61c4c989034548

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Mine.