[Bug tree-optimization/117439] [12/13/14 Regression] ICE in encode_tree_to_bitpos

[lixinyang411 at gmail dot com via Gcc-bugs]

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

--- Comment #9 from 李心杨  ---
Thanks for your quick response! I've tested the patch on gcc-13.3.0 and it
works well.

[Bug middle-end/117525] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
[apinski@xeond2 gcc]$ ./cc1plus  t.ii -quiet -I. -w -O3 -ffast-math
during RTL pass: ce1
../libs/canvas/canvas.cc: In member function ‘virtual void
ArdourCanvas::GtkCanvasViewport::on_size_request(Gtk::Requisition*)’:
../libs/canvas/canvas.cc:1675:1: internal compiler error: in expand_fix, at
optabs.cc:5952

[Bug middle-end/117525] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952

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

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

--- Comment #1 from Andrew Pinski  ---
  convert_optab tab = unsignedp ? ufix_optab : sfix_optab;
  libfunc = convert_optab_libfunc (tab, GET_MODE (to), GET_MODE (from));
  gcc_assert (libfunc);


I suspect this is a regression; maybe starting with r15-2890 .

[Bug c++/117530] [14/15 Regression] Mismatch of lambda type with itself in recursive alias declaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c++/117530] [14/15 Regression] Mismatch of lambda type with itself in recursive alias declaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to fail||14.1.0
   Target Milestone|--- |14.3
  Known to work||13.3.0
Summary|Mismatch of lambda type |[14/15 Regression] Mismatch
   |with itself in recursive|of lambda type with itself
   |alias declaration   |in recursive alias
   ||declaration

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug middle-end/117525] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952

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

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

--- Comment #3 from Andrew Pinski  ---
Reducing ...

[Bug c/117528] New: Miscompile with -O1 and -O0/2/3

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

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

Bug ID: 117528
   Summary: Miscompile with -O1 and -O0/2/3
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunboni at smail dot nju.edu.cn
  Target Milestone: ---

When I compiled this code with -O1, its output is -167. However, with -O0/2/3,
its output is 89:

```c
int printf(const char *, ...);
int a;
long b;
char c, d = 166;
long *e = &b;
int main() {
  int f;
  for (; c <= 3; c++) {
f = c & a ? 0 : d - a;
*e = 255 ^ (f & 255U);
  }
  printf("%d\n", (int)b);
}
```

Details can be found here: https://godbolt.org/z/vT5rfqvYG

[Bug c/117528] Miscompile with -O1 and -O0/2/3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

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

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

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

[Bug tree-optimization/117529] New: Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)

[Explorer09 at gmail dot com via Gcc-bugs]

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

Bug ID: 117529
   Summary: Missed optimization: (y != 0 && x > (unsigned)(-1) /
y) (multiplication overflow check)
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Explorer09 at gmail dot com
  Target Milestone: ---

```c
#include 
#include 

bool func1(unsigned long long x, unsigned long long y)
{
return x > (ULLONG_MAX / y);
}

bool func2(unsigned long long x, unsigned long long y)
{
return y != 0 && x > (ULLONG_MAX / y);
}

bool func3(unsigned long long x, unsigned long long y)
{
unsigned long long res;
return __builtin_umulll_overflow(x, y, &res);
}
```

Expected result: All three functions produce the same code.

Actual result: func1() and func3() optimize to same code, but func2() had a
redundant (y != 0) check that is not optimized out.

x86-64 gcc with "-Os" option (tested in Compiler Explorer, a.k.a. godbolt.org)

```x86asm
func1:
movq%rdi, %rax
mulq%rsi
seto%al
ret
func2:
xorl%eax, %eax
testq   %rsi, %rsi
je  .L5
movq%rsi, %rax
mulq%rdi
seto%al
movzbl  %al, %eax
.L5:
andl$1, %eax
ret
```

[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
   [local count: 1073741824]:
  if (y_4(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  _1 = .MUL_OVERFLOW (y_4(D), x_5(D));
  _2 = IMAGPART_EXPR <_1>;
  _8 = (bool) _2;

   [local count: 1073741824]:
  # iftmp.0_3 = PHI <_8(3), 0(2)>
  return iftmp.0_3;

[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced down to just:
```
bool func4(unsigned long long x, unsigned long long y)
{
if (y == 0) return 0;
unsigned long long res;
return __builtin_umulll_overflow(x, y, &res);
}
```

[Bug c++/117530] New: Mismatch of lambda type with itself in recursive alias declaration

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

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

Bug ID: 117530
   Summary: Mismatch of lambda type with itself in recursive alias
declaration
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
  Target Milestone: ---

The following testcase based off the testcase in PR86171 fails starting with
GCC14 (it worked in GCC13):

  template  struct A;
  template  using B = decltype([]() -> A::X { return 0; });
  template  struct A {
typedef int X;
typedef B U;
  };
  B b;

$ g++ -std=c++20 test.cpp

test.cpp: In substitution of ‘template using B = decltype ()
[with T = short int]’:
test.cpp:7:8:   required from here
7 | B b;
  |^
test.cpp:2:26: error: conflicting declaration ‘using B = struct’
2 | template  using B = decltype([]() -> A::X { return 0; });
  |  ^
test.cpp:2:26: note: previous declaration as ‘using B = struct’

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #26 from John David Anglin  ---
(In reply to Segher Boessenkool from comment #25)
> (In reply to John David Anglin from comment #24)
> > There are a couple of issues.  The pa backend only supports memory
> > accesses that load to a register or store from a register.  LRA was
> > creating insns like the following:
> > 
> > (insn 387 386 35 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 28)
> > (subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 28))
> > "/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15
> > 42 {*pa.md:2195}
> >  (nil))
> 
> That is a simple 32-bit register-to-register move, which is quite expected
> here?  It should work fine if your OImode datums are stored in 8 consecutive
> GPR regs.

Yes.  Problem arises if reg/v:OI 452 is spilled to memory.  Without
reg_equiv_mem, I don't see how pa backend can handle spill.  What happens
is pa_emit_move_sequence is called repeatedly with same arguments.

While there are 31 general registers, they are split between caller saves and
callee saves. Some registers have fixed functionality.  We have three 8
register block in non pic code and two in pic code.

> > There doesn't seem to be any good reason to allow register modes that
> > aren't supported in pa.md.
> 
> Obviously.  And LRA tries to use such modes?  That can never work, no?  So
> we should do something about that?

Yes, LRA used OI and TI modes with  gcc.c-torture/compile/pr92618.c.  It
defines the following types:

typedef long long __m128i __attribute__((__may_alias__, __vector_size__(2 *
sizeof (long long;
typedef long long __m256i __attribute__((__may_alias__, __vector_size__(4 *
sizeof (long long;
typedef long long __m512i __attribute__((__may_alias__, __vector_size__(8 *
sizeof (long long;

Maybe PA has enough registers but I don't know how to handle subreg spills in
backend with LRA.

I did wonder about doing the following:

@@ -2011,6 +2027,17 @@ pa_emit_move_sequence (rtx *operands, machine_mode mode,
rtx scratch_reg)
  != XEXP (operand1, 0)))
 operand1 = replace_equiv_address (operand1, tem);

+  if (scratch_reg
+  && !(REG_P (operand0)
+  || REG_P (operand1)
+  || operand1 == CONST0_RTX (GET_MODE (operands[0]
+{
+  scratch_reg = force_mode (GET_MODE (operand0), scratch_reg);
+  emit_move_insn (scratch_reg, operand1);
+  emit_move_insn (operand0, scratch_reg);
+  return 1;
+}
+
   /* Handle secondary reloads for loads/stores of FP registers from
  REG+D addresses where D does not fit in 5 or 14 bits, including
  (subreg (mem (addr))) cases, and reloads for other unsupported

Maybe LRA could handle spills then?

> > I debated whether to allow complex 16-byte
> > modes in the general registers.  There's one test that fails if I disallow
> > 16-byte modes in the general registers.  It uses an asm to load a complex
> > long long value to a register.  It is xfailed on a number of targets
> > because they don't have enough registers.
> 
> But it's just four hardware registers for you, and you have plenty?

I tried allowing all 16-byte types in the general registers but pr92618.c still
failed with LRA.

> If your ABI doesn't require this (for parameter passing), I don't think
> there is much benefit though (and if it does require it, of course you
> have to, no choice then :-) )

Types larger than 64-bits are passed by reference in 32-bit ABI. This is not
the case in the 64-bit ABI where all types and aggregates are passed by value. 
Test doesn't fail on 64-bit.

[Bug tree-optimization/117527] New: [15 regression] 511.povary_r with march_native_ofast_lto build fail since r15-5021

[haochen.jiang at intel dot com via Gcc-bugs]

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

Bug ID: 117527
   Summary: [15 regression] 511.povary_r with
march_native_ofast_lto build fail since r15-5021
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haochen.jiang at intel dot com
  Target Milestone: ---

I have got a build fail on 511.povary_y with march_native_ofast_lto.

Known to fail: x86 since Cascade Lake and Zen3, aarch64 for Amphere (and
probably Graviton3).

The case will also happen w/o -flto.

After eliminating -flto, it seems that when building lighting.cpp, I got:

$
/export/users/haochenj/CI_Framework/task/2024102138/install/applications.compilers.source.gnu-toolchain.gcc/bin/g++
-m64 -c -o lighting.o -DSPEC -DNDEBUG -Ifrontend -Ibase -I. -Ispec_qsort
-DSPEC_AUTO_SUPPRESS_OPENMP  -Ofast -march=native -mfpmath=sse  
-fno-finite-math-only -DSPEC_LP64  lighting.cpp
lighting.cpp: In function ‘void pov::do_light_area_light(LIGHT_SOURCE*,
double*, RAY*, RAY*, double*)’:
lighting.cpp:1359:18: warning: ISO C++17 does not allow ‘register’ storage
class specifier [-Wregister]
 1359 | register int i;
  |  ^
lighting.cpp: In function ‘void pov::block_area_light(LIGHT_SOURCE*, double*,
RAY*, RAY*, double*, float*, int, int, int, int, int)’:
lighting.cpp:1596:22: warning: ISO C++17 does not allow ‘register’ storage
class specifier [-Wregister]
 1596 | register int i;
  |  ^
lighting.cpp:1723:26: warning: ISO C++17 does not allow ‘register’ storage
class specifier [-Wregister]
 1723 | register int i;
  |  ^
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

The strangest thing is that it doesn't show backtrace for the ICE.

I will try to reduce that first.

[Bug tree-optimization/117527] [15 regression] 511.povary_r with march_native_ofast_lto build fail since r15-5021

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117499
   Last reconfirmed||2024-11-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
This was already fixed by r15-5063 .

PR 117499 had a reduced testcase already and I made sure it was a dup of bug
117496 I tested the patch too.

[Bug tree-optimization/117527] [15 regression] 511.povary_r with march_native_ofast_lto build fail since r15-5021

[haochen.jiang at intel dot com via Gcc-bugs]

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

Haochen Jiang  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|WAITING |RESOLVED

--- Comment #2 from Haochen Jiang  ---
I see. I suppose that would be a dup since PR117499 got a similar problem.

I am trying with latest trunk and I suppose it should be ok.

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

[Bug middle-end/117496] [15 Regression] infinite recursion in insert_predicates_for_cond() on cdrkit-1.1.11

[haochen.jiang at intel dot com via Gcc-bugs]

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

Haochen Jiang  changed:

   What|Removed |Added

 CC||haochen.jiang at intel dot com

--- Comment #12 from Haochen Jiang  ---
*** Bug 117527 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/117529] Missed optimization: (y != 0 && x > (unsigned)(-1) / y) (multiplication overflow check)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug other/116948] bootstrap-ubsan should set UBSAN_OPTIONS to abort on error

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

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

Sam James  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED

--- Comment #9 from Sam James  ---
Doc changes done. I need to think about how we want to handle the remaining
bits.

[Bug other/116948] bootstrap-ubsan should set UBSAN_OPTIONS to abort on error

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Sam James :

https://gcc.gnu.org/g:00448f9b5a123b4b6b3e6f45d2fecf0a5dca66b3

commit r15-5076-g00448f9b5a123b4b6b3e6f45d2fecf0a5dca66b3
Author: Sam James 
Date:   Thu Oct 31 21:09:32 2024 +

doc: install: document UBSAN_OPTIONS

Explain that 'bootstrap-ubsan' won't abort on errors by default and how
to override that by setting UBSAN_OPTIONS.

gcc/ChangeLog:
PR other/116948

* doc/install.texi (Building a native compiler): Document
UBSAN_OPTIONS.

[Bug other/116948] bootstrap-ubsan should set UBSAN_OPTIONS to abort on error

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-5075-g8f791fac1419a5dc663abd5091cf4db409539b33
Author: Sam James 
Date:   Thu Oct 31 21:06:13 2024 +

doc: install: document bootstrap-ubsan

gcc/ChangeLog:
PR other/116948

* doc/install.texi (Building a native compiler): Mention
bootstrap-ubsan.

[Bug c++/117516] [12/13/14/15 Regression] compile time hog figuring out has flexarrays since r6-5791-g7e9a3ad30076ad

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
   |compile time hog figuring   |compile time hog figuring
   |out has flexarrays  |out has flexarrays since
   ||r6-5791-g7e9a3ad30076ad
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-10

--- Comment #1 from Sam James  ---
Confirmed.

[Bug ada/117517] Reduce attribute creates bug

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

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

Sam James  changed:

   What|Removed |Added

  Known to fail||15.0
   Last reconfirmed||2024-11-10

--- Comment #1 from Sam James  ---
Fails on trunk too.

[Bug c++/117519] LTO ICE when building gloox: lto1: internal compiler error: symtab_node::verify failed

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

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

--- Comment #2 from Sam James  ---
In GCC 10 (pre-modref), it fails in pure const instead.

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #22 from John David Anglin  ---
As of commit 440be01b07941506d1c8819448bd17c8717d55f5, we have the following
additional fails on hppa64-hp-hpux11.11 with LRA:

+FAIL: gcc.dg/graphite/interchange-15.c execution test
+FAIL: gcc.dg/graphite/pr29581-2.c execution test
+FAIL: gcc.dg/graphite/pr29581-3.c execution test
+FAIL: gcc.dg/graphite/pr29581-4.c execution test
+FAIL: gcc.dg/graphite/uns-interchange-15.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-14.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-15.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-3.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/for-6.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-14.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-15.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-3.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-5.c execution test
+FAIL: libgomp.c/../libgomp.c-c++-common/for-6.c execution test
+FAIL: libgomp.c/loop-23.c execution test

Excluding guality tests, we have the following additional fails on
hppa-unknown-linux-gnu with LRA:

+FAIL: g++.dg/torture/pr37922.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel
-loops -ftracer -finline-functions  execution test
+FAIL: libgomp.c/doacross-6.c execution test
+FAIL: libgomp.c/loop-1.c execution test
+FAIL: libgomp.c/loop-2.c execution test
+FAIL: libgomp.c/ordered-1.c execution test
+FAIL: libgomp.c/pr29947-2.c execution test
+FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for excess errors)
+UNRESOLVED: 20_util/variant/run.cc  -std=gnu++17 compilation failed to produce
executable
+FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc 
-std=gnu++17 (test for excess errors)
+UNRESOLVED:
23_containers/vector/requirements/exception/generation_prohibited.cc 
-std=gnu++17 compilation failed to produce executable
+FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++23 (test for excess errors)
+UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++23 compilation failed
to produce executable
+FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++26 (test for excess errors)
+UNRESOLVED: std/ranges/cartesian_product/1.cc  -std=gnu++26 compilation failed
to produce executable

[Bug middle-end/108036] [12/13/14/15 Regression] Spurious warning for zero-sized array parameters to a function

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

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

--- Comment #12 from uecker at gcc dot gnu.org ---

UBSan and Wstringop-overflow have completely separate implementations (I wish
there was a more sysematic approach...).

[Bug c++/69585] [C++ 11] parser errors mixing alignas, C++ 11 and GNU attributes on class declaration

[soap at gentoo dot org via Gcc-bugs]

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

David Seifert  changed:

   What|Removed |Added

 CC||soap at gentoo dot org

--- Comment #8 from David Seifert  ---
Marek Polacek, could we please get this backported to GCC 12 too?

DeepLearn 2025: early registration November 26

[IRDTA via Gcc-bugs]

*To be removed from our mailing list, please respond to this message with 
UNSUBSCRIBE in the subject line*

--

**

12th INTERNATIONAL SCHOOL ON DEEP LEARNING
(with a special focus on Large Language Models, Foundation Models and 
Generative AI)

DeepLearn 2025

Porto – Maia, Portugal

July 21-25, 2025

https://deeplearn.irdta.eu/2025/

**

Co-organized by:

University of Maia

Institute for Research Development, Training and Advice – IRDTA
Brussels/London

**

Early registration: November 26, 2024

**

SCOPE:

DeepLearn 2025 will be a research training event with a global scope aiming at 
updating participants on the most recent advances in the critical and fast 
developing area of deep learning. Previous events were held in Bilbao, Genova, 
Warsaw, Las Palmas de Gran Canaria, Guimarães, Las Palmas de Gran Canaria, 
Luleå, Bournemouth, Bari, Las Palmas de Gran Canaria and Porto.

Deep learning is a branch of artificial intelligence covering a spectrum of 
current frontier research and industrial innovation that provides more 
efficient algorithms to deal with large-scale data in a huge variety of 
environments: computer vision, neurosciences, speech recognition, language 
processing, human-computer interaction, drug discovery, biomedicine and health 
informatics, medical image analysis, recommender systems, advertising, fraud 
detection, robotics, games, business and finance, biotechnology, physics 
experiments, biometrics, communications, climate sciences, geographic 
information systems, signal processing, genomics, materials design, video 
technology, social systems, earth and sustainability, etc. etc.

The field is also raising a number of relevant questions about robustness of 
the algorithms, explainability, transparency, interpretability, as well as 
important ethical concerns at the frontier of current knowledge that deserve 
careful multidisciplinary discussion.

Most deep learning subareas will be displayed, and main challenges identified 
through 18 four-hour and a half courses, 2 keynote lectures, 1 round table and 
a hackathon competition among participants. Renowned academics and industry 
pioneers will lecture and share their views with the audience. The organizers 
are convinced that outstanding speakers will attract the brightest and most 
motivated students. Face to face interaction and networking will be main 
ingredients of the event. It will be also possible to fully participate in vivo 
remotely.

DeepLearn 2025 will place special emphasis on large language models, foundation 
models and generative artificial intelligence.

ADDRESSED TO:

Graduate students, postgraduate students and industry practitioners will be 
typical profiles of participants. However, there are no formal pre-requisites 
for attendance in terms of academic degrees, so people less or more advanced in 
their career will be welcome as well.

Since there will be a variety of levels, specific knowledge background may be 
assumed for some of the courses.

Overall, DeepLearn 2025 is addressed to students, researchers and practitioners 
who want to keep themselves updated about recent developments and future 
trends. All will surely find it fruitful to listen to and discuss with major 
researchers, industry leaders and innovators.

VENUE:

DeepLearn 2025 will take place in Porto, the second largest city in Portugal, 
recognized by UNESCO in 1996 as a World Heritage Site. The venue will be:

University of Maia
Avenida Carlos de Oliveira Campos - Castlo da Maia
4475-690 Maia
Porto, Portugal

https://www.umaia.pt/en

STRUCTURE:

3 courses will run in parallel during the whole event. Participants will be 
able to freely choose the courses they wish to attend as well as to move from 
one to another.

All lectures will be videorecorded. Participants will be able to watch them 
again for 45 days after the event.

An open session will give participants the opportunity to present their own 
work in progress in 5 minutes. Also companies will be able to present their 
technical developments for 10 minutes.

The school will include a hackathon, where participants will be able to work in 
teams to tackle several machine learning challenges.

Full live online participation will be possible. The organizers highlight, 
however, the importance of face to face interaction and networking in this kind 
of research training event.

KEYNOTE SPEAKERS:

Yonina Eldar (Weizmann institute of Science), Model Based AI and Applications

Manuela Veloso (JPMorganChase), AI, Humans, and Robots for Task Solving

PROFESSORS AND COURSES:

Pierre Baldi (University of California Irvine), [intermediate/advanced] From 
Deep Learning and Transformers to AI Risks and Safety

Sean Benson (Amsterdam University Medical Center), [intermediate] Digital T

[Bug debug/108843] [12 regression] timeout with -g -O3 since r9-2635-g78ea9abc2018243a since r9-2635-g78ea9abc2018243a

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

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

--- Comment #7 from Sam James  ---
(In reply to David Binderman from comment #5)
> Created attachment 57711 [details]
> C source code
> 
> Another test case.
> 

I think this is probably a different case.

[Bug libstdc++/117520] New: C++26 std::text_encoding: == should be =

[pkeir at outlook dot com via Gcc-bugs]

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

Bug ID: 117520
   Summary: C++26 std::text_encoding: == should be =
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkeir at outlook dot com
  Target Milestone: ---

I am seeing warnings about equality comparison results being unused
[-Wunused-comparison] in libstdc++-v3/include/std/text_encoding - which is
included through locale_classes.h.

The definition of operator+= on line 568 includes two instances of:

*this == _Iterator{};

...which I suspect should be:

*this = _Iterator{};

[Bug c++/117521] New: ICE with duplicate placeholder variables

[drepper.fsp+rhbz at gmail dot com via Gcc-bugs]

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

Bug ID: 117521
   Summary: ICE with duplicate placeholder variables
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

The following code causes an ICE with gcc 14.2 as well as the trunk version
from 2024-11-4:

#include 
#include 

#ifndef P
#define P _
#endif

void f(const std::vector>& v)
{
  for (auto& [_,P,c] : v)
asm("" : : "m"(v));
}


when compiled with
  g++ -c -std=gnu++2c e.cc

e.cc: In function ‘void f(const std::vector >&)’:
e.cc:10:22: internal compiler error: Segmentation fault
   10 |   for (auto& [_,P,c] : v)
  |  ^
0x7fbffec10dcf ???
   
/usr/src/debug/glibc-2.40-9.fc41.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7fbffebfa247 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fbffebfa30a __libc_start_main_impl
../csu/libc-start.c:360




when instead compiled with
  g++ -c -std=gnu++2c e.cc -DP=b
there is no problem.

[Bug debug/108843] [12 regression] timeout with -g -O3 since r9-2635-g78ea9abc2018243a since r9-2635-g78ea9abc2018243a

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

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

Sam James  changed:

   What|Removed |Added

Summary|timeout with -g -O3 since   |[12 regression] timeout
   |r9-2635-g78ea9abc2018243a   |with -g -O3 since
   ||r9-2635-g78ea9abc2018243a
   ||since
   ||r9-2635-g78ea9abc2018243a
   Target Milestone|--- |12.5

--- Comment #6 from Sam James  ---
13/14/15 all complete in reasonable time w/ -g -O3 with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108843#c4. 12 still has the issue.

[Bug c/117522] New: Miscompile with -O3 and -O0/1/2

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

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

Bug ID: 117522
   Summary: Miscompile with -O3 and -O0/1/2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunboni at smail dot nju.edu.cn
  Target Milestone: ---

When I compiled this code with -O3, it triggered SIGSEGV. With -O0/1/2, it
outputs 0:

```c
int printf(const char *, ...);
int a, b = 4095;
int c[6];
const short d = -2;
void e(char f) { b = c[(b ^ f) & 255]; }
int main() {
  e(d >> 8);
  printf("%X\n", a);
}
```

Details can be found here: https://godbolt.org/z/fr8s9j6a9

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

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

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

Sam James  changed:

   What|Removed |Added

 CC||yunboni at smail dot nju.edu.cn

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

[Bug rtl-optimization/117191] [avr][dse2][lra] wrong dead store elimination

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

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

--- Comment #7 from denisc at gcc dot gnu.org ---
I'm sorry for the strange previous comment.
The right one.

Probably I found a bug.

The bug appears after the dse2 pass.
The dse2 pass removes necessary insns. (ie insn 554)
They are removed because LRA doesn't remove CLOBBER insn. (insn 202)
The old "good" reload has a special "pass" for removing such CLOBBER insns.

Fragment from reload1.c:
---
  reload_completed = 1;

  /* Make a pass over all the insns and delete all USEs which we inserted
 only to tag a REG_EQUAL note on them.  Remove all REG_DEAD and REG_UNUSED
 notes.  Delete all CLOBBER insns, except those that refer to the return
 value and the special mem:BLK CLOBBERs added to prevent the scheduler
 from misarranging variable-array code, and simplify (subreg (reg))
 operands.  Strip and regenerate REG_INC notes that may have been moved
 around.  */

  for (insn = first; insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
  {
rtx *pnote;

if (CALL_P (insn))
  replace_pseudos_in (& CALL_INSN_FUNCTION_USAGE (insn),
  VOIDmode, CALL_INSN_FUNCTION_USAGE (insn));

if ((GET_CODE (PATTERN (insn)) == USE
 /* We mark with QImode USEs introduced by reload itself.  */
 && (GET_MODE (insn) == QImode
 || find_reg_note (insn, REG_EQUAL, NULL_RTX)))
|| (GET_CODE (PATTERN (insn)) == CLOBBER
&& (!MEM_P (XEXP (PATTERN (insn), 0))
|| GET_MODE (XEXP (PATTERN (insn), 0)) != BLKmode
|| (GET_CODE (XEXP (XEXP (PATTERN (insn), 0), 0)) !=
SCRATCH
&& XEXP (XEXP (PATTERN (insn), 0), 0)
!= stack_pointer_rtx))
&& (!REG_P (XEXP (PATTERN (insn), 0))
|| ! REG_FUNCTION_VALUE_P (XEXP (PATTERN (insn), 0)
  {
delete_insn (insn);
continue;
  }
---


The fix is simple:
diff --git a/gcc/lra-spills.cc b/gcc/lra-spills.cc
index c149c3388cd..db591e1d12c 100644
--- a/gcc/lra-spills.cc
+++ b/gcc/lra-spills.cc
@@ -741,10 +741,19 @@ lra_final_code_change (void)
  delete_insn (insn);
  continue;
}
- if (GET_CODE (pat) == CLOBBER && LRA_TEMP_CLOBBER_P (pat))
+ if (GET_CODE (pat) == CLOBBER
+ && (LRA_TEMP_CLOBBER_P (pat)
+ || (!MEM_P (XEXP (pat, 0))
+ || GET_MODE (XEXP (pat, 0)) != BLKmode
+ || (GET_CODE (XEXP (XEXP (pat, 0), 0)) != SCRATCH
+ && XEXP (XEXP (pat, 0), 0)
+ != stack_pointer_rtx
{
- /* Remove clobbers temporarily created in LRA.  We don't
-need them anymore and don't want to waste compiler
+ /* Remove clobbers temporarily created in LRA and clobbers with
+registers spilled to memory except those that refer to the
+return value and the special mem:BLK CLOBBERs added to prevent
+the scheduler from misarranging variable-array code.
+We don't need them anymore and don't want to waste compiler
 time processing them in a few subsequent passes.  */
  lra_invalidate_insn_data (insn);
  delete_insn (insn);

[Bug rtl-optimization/117191] [avr][dse2][lra] wrong dead store elimination

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

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

--- Comment #6 from denisc at gcc dot gnu.org ---
The patch:

(In reply to denisc from comment #4)
> (In reply to denisc from comment #0)
> > Created attachment 59370 [details]
> > dse2 pass dump file
> > 
> > Failed testcase:
> > $ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim
> > --tool_opts='-mlra' avr-torture.exp=lra-pr116550-2.c"
> > [...]
> > Running
> > /mnt/d/gcc-avr-lra/gcc/testsuite/gcc.target/avr/torture/avr-torture.exp ...
> > FAIL: gcc.target/avr/torture/lra-pr116550-2.c   -O1  execution test
> > 
> > === gcc Summary ===
> > 
> > # of expected passes21
> > # of unexpected failures1
> > /mnt/d/mk-avr-lra/gcc/xgcc  version 15.0.0 20241016 (experimental) (GCC) 
> > [...]
> > 
> > 
> > This test successfully passed without -mlra option, may be lra related:
> > $ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim
> > --tool_opts='-mno-lra' avr-torture.exp=lra-pr116550-2.c"
> > [...]
> > Running
> > /mnt/d/gcc-avr-lra/gcc/testsuite/gcc.target/avr/torture/avr-torture.exp ...
> > 
> > === gcc Summary ===
> > 
> > # of expected passes22
> > /mnt/d/mk-avr-lra/gcc/xgcc  version 15.0.0 20241016 (experimental) (GCC) 
> > [...]
> > 
> > Testcase 
> > 
> > $ avr-gcc -da -O1 -S -dp -fverbose-asm -mmcu=atmega128 lra-pr116550-2.c
> > 
> > 
> > dse2 pass made a wrong elimination of insn 554 (%sfp+13)
> > insn 456 have a use of *(%sfp+13):QI
> > probably scanning of it have to be like:
> > **scanning insn=505
> >   mem: (plus:HI (reg/f:HI 28 r28)
> > (const_int 5 [0x5]))
> > 
> >after canon_rtx address: (plus:HI (reg/f:HI 28 r28)
> > (const_int 5 [0x5]))
> >   gid=1 offset=5
> >  processing const load gid=1[5..6)
> > removing from active insn=459 has store
> > mems_found = 0, cannot_delete = true
> > 
> > but it's
> > **scanning insn=456
> >   mem: (plus:HI (reg/f:HI 28 r28)
> > (const_int 13 [0xd]))
> > 
> >after canon_rtx address: (plus:HI (reg/f:HI 28 r28)
> > (const_int 13 [0xd]))
> >   gid=1 offset=13
> >  processing const load gid=1[13..14)
> > mems_found = 0, cannot_delete = true
> > 
> > Scanning of insn 456 doesn't have 'removing from active insn=554 has store'
> > because of that insn 554 was removed but it have a store to *(%sfp+13)
> > It's wrong because insn 456 have a use of *(%sfp+13)
diff --git a/gcc/lra-spills.cc b/gcc/lra-spills.cc
index c149c3388cd..db591e1d12c 100644
--- a/gcc/lra-spills.cc
+++ b/gcc/lra-spills.cc
@@ -741,10 +741,19 @@ lra_final_code_change (void)
  delete_insn (insn);
  continue;
}
- if (GET_CODE (pat) == CLOBBER && LRA_TEMP_CLOBBER_P (pat))
+ if (GET_CODE (pat) == CLOBBER
+ && (LRA_TEMP_CLOBBER_P (pat)
+ || (!MEM_P (XEXP (pat, 0))
+ || GET_MODE (XEXP (pat, 0)) != BLKmode
+ || (GET_CODE (XEXP (XEXP (pat, 0), 0)) != SCRATCH
+ && XEXP (XEXP (pat, 0), 0)
+ != stack_pointer_rtx
{
- /* Remove clobbers temporarily created in LRA.  We don't
-need them anymore and don't want to waste compiler
+ /* Remove clobbers temporarily created in LRA and clobbers with
+registers spilled to memory except those that refer to the
+return value and the special mem:BLK CLOBBERs added to prevent
+the scheduler from misarranging variable-array code.
+We don't need them anymore and don't want to waste compiler
 time processing them in a few subsequent passes.  */
diff --git a/gcc/lra-spills.cc b/gcc/lra-spills.cc
index c149c3388cd..db591e1d12c 100644
--- a/gcc/lra-spills.cc
+++ b/gcc/lra-spills.cc
@@ -741,10 +741,19 @@ lra_final_code_change (void)
  delete_insn (insn);
  continue;
}
- if (GET_CODE (pat) == CLOBBER && LRA_TEMP_CLOBBER_P (pat))
+ if (GET_CODE (pat) == CLOBBER
+ && (LRA_TEMP_CLOBBER_P (pat)
+ || (!MEM_P (XEXP (pat, 0))
+ || GET_MODE (XEXP (pat, 0)) != BLKmode
+ || (GET_CODE (XEXP (XEXP (pat, 0), 0)) != SCRATCH
+ && XEXP (XEXP (pat, 0), 0)
+ != stack_pointer_rtx
{
- /* Remove clobbers temporarily created in LRA.  We don't
-need them anymore and don't want to waste compiler
+ /* Remove clobbers temporarily created in LRA and clobbers with
+registers spilled to memory except those that refer to the
+return value and the special mem:BLK CLOBBERs added to prevent
+the scheduler from misarranging variable-array code.
+We don't need them anymore and don't want to waste compiler
 time processing them in a few subsequent passes.  */
 

[Bug c/117522] Miscompile with -O3 and -O0/1/2

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #1 from Sam James  ---
I can't reproduce it with a revert for PR117476 and it looks very similar.

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

[Bug c++/115586] c++26: with 2 or more name-independent declarations (anonymous structure bindings) with for loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||drepper.fsp+rhbz at gmail dot 
com

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

[Bug c++/117521] ICE with duplicate placeholder variables

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug c++/115586] c++26: with 2 or more name-independent declarations (anonymous structure bindings) with for loop

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
I'll have a look, but only in stage3 (Nov 18th+).

[Bug rtl-optimization/117191] [avr][dse2][lra] wrong dead store elimination

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

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

--- Comment #8 from denisc at gcc dot gnu.org ---
I forgot to add condition for "except those that refer to the return value"

The patch:

diff --git a/gcc/lra-spills.cc b/gcc/lra-spills.cc
index c149c3388cd..2f86ec0026c 100644
--- a/gcc/lra-spills.cc
+++ b/gcc/lra-spills.cc
@@ -741,10 +741,20 @@ lra_final_code_change (void)
  delete_insn (insn);
  continue;
}
- if (GET_CODE (pat) == CLOBBER && LRA_TEMP_CLOBBER_P (pat))
+ if (GET_CODE (pat) == CLOBBER
+ && (LRA_TEMP_CLOBBER_P (pat)
+ || ((!MEM_P (XEXP (pat, 0))
+  || GET_MODE (XEXP (pat, 0)) != BLKmode
+  || (GET_CODE (XEXP (XEXP (pat, 0), 0)) != SCRATCH
+  && XEXP (XEXP (pat, 0), 0) != stack_pointer_rtx))
+ && (!REG_P (XEXP (pat, 0))
+ || !REG_FUNCTION_VALUE_P (XEXP (pat, 0))
{
- /* Remove clobbers temporarily created in LRA.  We don't
-need them anymore and don't want to waste compiler
+ /* Remove clobbers temporarily created in LRA and clobbers with
+registers spilled to memory except those that refer to the
+return value and the special mem:BLK CLOBBERs added to prevent
+the scheduler from misarranging variable-array code.
+We don't need them anymore and don't want to waste compiler
 time processing them in a few subsequent passes.  */
  lra_invalidate_insn_data (insn);
  delete_insn (insn);

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #23 from Segher Boessenkool  ---
(In reply to John David Anglin from comment #21)
> This bug was fixed by changing PA_HARD_REGNO_MODE_OK.  On the 32-bit
> target we no longer allow TI and OI mode in the hard registers.  I only
> allowed complex 16 byte modes in the general registers.  It's possible
> this is problematic but there isn't much testing.

So, hrm.  Is that more a fix, or more a workaround?

Is LRA doing something wrong so that bigger nodes / multireg modes do
not work?

Why is PA special in this?

[Bug fortran/117474] Excessive memory usage during parser stage in interface blocks with types having type-bound procedures

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-10

--- Comment #2 from anlauf at gcc dot gnu.org ---
Do you have a reproducer you can attach?

Ideally one that allows studying the increase of memory usage with complexity?

[Bug fortran/113928] Aliasing of pointer in expression

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-10

--- Comment #2 from anlauf at gcc dot gnu.org ---
Workaround: force an evaluation of the r.h.s. with an array ctor:

  wr = [ wr + wz(N:1:-1)%re ]

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

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

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

--- Comment #3 from Tobias Burnus  ---
I bet that the spec writers ment the following (i.e. with the text written in
brackets):

“If a procedure is determined to be a function variant through more than one
declare variant directive [for a given base function] then the construct
selector set of their context selectors must be the same."

The current wording is otherwise a bit odd.

BTW: Besides requiring that their context selector is the same, also
append_args and adjust_args must be effectively the same (ignoring different
parameter names for C/C++ as long as the result of adjust_args effectively the
same).

[Bug c++/117519] [12/13/14/15 regression] LTO ICE when building gloox: lto1: internal compiler error: symtab_node::verify failed since r9-5035-g4611c03d2b0ede

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

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

Sam James  changed:

   What|Removed |Added

Summary|LTO ICE when building   |[12/13/14/15 regression]
   |gloox: lto1: internal   |LTO ICE when building
   |compiler error: |gloox: lto1: internal
   |symtab_node::verify failed  |compiler error:
   ||symtab_node::verify failed
   ||since
   ||r9-5035-g4611c03d2b0ede

--- Comment #3 from Sam James  ---
r9-5035-g4611c03d2b0ede so a dupe?

[Bug c++/117523] ICE in dependent_alias_template_spec_p when call a alias template

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
> This code should compile with a too many arguments error or something because 
> variadic parameter passed to an alias that doesn't require one

Well techincally that is DR 1430 :
https://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1430

[Bug c++/117523] New: ICE in dependent_alias_template_spec_p when call a alias template

[jonathan.poelen at gmail dot com via Gcc-bugs]

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

Bug ID: 117523
   Summary: ICE in dependent_alias_template_spec_p when call a
alias template
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathan.poelen at gmail dot com
  Target Milestone: ---

This code should compile with a too many arguments error or something because
variadic parameter passed to an alias that doesn't require one, but for now it
gives an ICE.

It compiled (I think wrongly) in a previous version (13.2):
https://godbolt.org/z/ere5cYK6e

$ g++ test.cpp -freport-bug

// Target: x86_64-pc-linux-gnu
// Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 14.2.1 20240910 (GCC) 
// 
// test.cpp: In instantiation of ‘struct algo’:
// test.cpp:15:10:   required from here
//15 | algo::f();
//   |  ^~
// test.cpp:6:9: internal compiler error: in dependent_alias_template_spec_p,
at cp/pt.cc:6737
// 6 |   using f = typename Pred::template f;
//   | ^
// 0x21a922a internal_error(char const*, ...)
//  ???:0
// 0x704ec1 fancy_abort(char const*, int, char const*)
//  ???:0
// 0x8e4730 lookup_template_class(tree_node*, tree_node*, tree_node*,
tree_node*, int, int)
//  ???:0
// 0x8d90f7 tsubst(tree_node*, tree_node*, int, tree_node*)
//  ???:0
// 0x8e1abd instantiate_class_template(tree_node*)
//  ???:0
// 0x93ab0b complete_type(tree_node*)
//  ???:0
// 0x9cd270 c_common_parse_file()
//  ???:0
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See 
for instructions.

// /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/cc1plus -quiet -D_GNU_SOURCE
test.cpp -quiet -dumpdir a- -dumpbase test.cpp -dumpbase-ext .cpp
-mtune=generic -march=x86-64 -freport-bug -o - -frandom-seed=0 -fdump-noaddr

# 0 "test.cpp"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "test.cpp"

template
struct algo
{
  template
  using f = typename Pred::template f;
};

struct foo
{
  template
  using f = int;
};

algo::f();

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #24 from John David Anglin  ---
There are a couple of issues.  The pa backend only supports memory
accesses that load to a register or store from a register.  LRA was
creating insns like the following:

(insn 387 386 35 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 28)
(subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 28))
"/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42
{*pa.md:2195}
 (nil))

LRA can not handle spill for reg/v:OI 132.

The code in pa_emit_move_sequence to handle subreg spills doesn't
work with LRA.

  if (scratch_reg
  && reload_in_progress
  && GET_CODE (operand0) == REG
  && REGNO (operand0) >= FIRST_PSEUDO_REGISTER)
operand0 = reg_equiv_mem (REGNO (operand0));
  else if (scratch_reg
   && reload_in_progress
   && GET_CODE (operand0) == SUBREG
   && GET_CODE (SUBREG_REG (operand0)) == REG
   && REGNO (SUBREG_REG (operand0)) >= FIRST_PSEUDO_REGISTER)
{
 /* We must not alter SUBREG_BYTE (operand0) since that would confuse
the code which tracks sets/uses for delete_output_reload.  */
  rtx temp = gen_rtx_SUBREG (GET_MODE (operand0),
 reg_equiv_mem (REGNO (SUBREG_REG (operand0))),
 SUBREG_BYTE (operand0));
  operand0 = alter_subreg (&temp, true);
}

As far as I can tell, reg_equiv_mem always return NULL_RTX when LRA
is used.  Thus, LRA has to handle spills itself.

There doesn't seem to be any good reason to allow register modes that
aren't supported in pa.md.  I debated whether to allow complex 16-byte
modes in the general registers.  There's one test that fails if I disallow
16-byte modes in the general registers.  It uses an asm to load a complex
long long value to a register.  It is xfailed on a number of targets
because they don't have enough registers.

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

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

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

--- Comment #2 from sandra at gcc dot gnu.org ---
Isn't this explicitly prohibited by the spec?  Second bullet point at the top
of page 295 in TR13 says:

"If a procedure is determined to be a function variant through more than one
declare variant directive then the construct selector set of their context
selectors must be the same."

[Bug target/113933] Switch pa to LRA

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

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

--- Comment #25 from Segher Boessenkool  ---
(In reply to John David Anglin from comment #24)
> There are a couple of issues.  The pa backend only supports memory
> accesses that load to a register or store from a register.  LRA was
> creating insns like the following:
> 
> (insn 387 386 35 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 28)
> (subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 28))
> "/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15
> 42 {*pa.md:2195}
>  (nil))

That is a simple 32-bit register-to-register move, which is quite expected
here?  It should work fine if your OImode datums are stored in 8 consecutive
GPR regs.

> There doesn't seem to be any good reason to allow register modes that
> aren't supported in pa.md.

Obviously.  And LRA tries to use such modes?  That can never work, no?  So
we should do something about that?

> I debated whether to allow complex 16-byte
> modes in the general registers.  There's one test that fails if I disallow
> 16-byte modes in the general registers.  It uses an asm to load a complex
> long long value to a register.  It is xfailed on a number of targets
> because they don't have enough registers.

But it's just four hardware registers for you, and you have plenty?

If your ABI doesn't require this (for parameter passing), I don't think
there is much benefit though (and if it does require it, of course you
have to, no choice then :-) )

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

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

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

--- Comment #4 from sandra at gcc dot gnu.org ---
Hmmm.  Look also at item 2 at the bottom of page 283, that says that construct
selectors for a variant function are added to its enclosing OpenMP context.  I
thought this was the reason for the restriction; if you've got different
construct contexts, which one do you use to resolve metadirectives or calls to
other variant functions in its body?  I guess that if you want that to work
you'd have to clone the variant function for each base function it's used with.

This probably all ties in with PR 115076, the issue about the current "declare
variant" implementation using global state instead of following the usual
scoping rules.

[Bug c++/117519] New: LTO ICE when building gloox: lto1: internal compiler error: symtab_node::verify failed

[csfore at posteo dot net via Gcc-bugs]

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

Bug ID: 117519
   Summary: LTO ICE when building gloox: lto1: internal compiler
error: symtab_node::verify failed
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: csfore at posteo dot net
  Target Milestone: ---

Created attachment 59572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59572&action=edit
original preprocessed clientbase.ii and instantmucroom.ii

Notes: -ansi is required, -fno-inline seems to be what is causing the ICE.


```
$ g++ clientbase.ii instantmucroom.ii -O2 -flto -fno-inline -ansi
lto1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
_ZN5gloox7MUCRoom8handleIqERKNS_2IQE/4950 (handleIq)
  Type: function definition analyzed
  Visibility: externally_visible semantic_interposition undef public weak
comdat comdat_group:_ZN5gloox7MUCRoom8handleIqERKNS_2IQE one_only
section:.text._ZN5gloox7MUCRoom8handleIqERKNS_2IQE (implicit_section) virtual
  Address is taken.
  References: 
  Referring: *.LTHUNK0/571 (alias) _ZTVN5gloox14InstantMUCRoomE/5920 (addr) 
  Read from file: /tmp/ccEI4KT2.o
  Unit id: 2
  Function flags: count:1073741824 (estimated locally)
  Called by: 
  Calls: 
_ZThn16_N5gloox7MUCRoom8handleIqERKNS_2IQE/572
(_ZThn16_N5gloox7MUCRoom8handleIqERKNS_2IQE)
  Type: function definition analyzed
  Visibility: externally_visible semantic_interposition prevailing_def_ironly
public weak comdat comdat_group:_ZN5gloox7MUCRoom8handleIqERKNS_2IQE one_only
section:.text._ZN5gloox7MUCRoom8handleIqERKNS_2IQE (implicit_section) virtual
artificial
  Same comdat group as: *.LTHUNK0/571
  Address is taken.
  References: 
  Referring: _ZTVN5gloox14InstantMUCRoomE/5920 (addr) 
  Read from file: /tmp/cc6QyeIG.o
  Unit id: 1
  Function flags: calls_comdat_local merged_comdat indirect_call_target
  Thunk fixed offset -16 virtual value 0 indirect_offset 0 has virtual offset 0
  Called by: 
  Calls: *.LTHUNK0/571 (can throw external) 
during IPA pass: modref
lto1: internal compiler error: symtab_node::verify failed
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/15/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

--

```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0.0_pre20241103/work/gcc-15-20241103/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,go,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
15.0.0_pre20241103 p21' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --disable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --without-isl --enable-default-pie
--enable-host-pie --enable-host-bind-now --enable-default-ssp
--disable-fixincludes --with-build-config='bootstrap-O3 bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241103 (experimental) (Gentoo Hardened 15.0.0_pre20241103
p21)
```

[Bug c++/117519] LTO ICE when building gloox: lto1: internal compiler error: symtab_node::verify failed

[csfore at posteo dot net via Gcc-bugs]

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

--- Comment #1 from Christopher Fore  ---
Created attachment 59573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59573&action=edit
reduced preprocessed clientbase.ii and instantmucroom.ii

[Bug middle-end/108036] [12/13/14/15 Regression] Spurious warning for zero-sized array parameters to a function

[alx at kernel dot org via Gcc-bugs]

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

Alejandro Colomar  changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #11 from Alejandro Colomar  ---
I've tested with the recent changes from Martin Uecker, to see if this was
fixed.  It still triggers.  Martin, this might be related to the problems you
mentioned having with the UB sanitizers, right?  I guess the UB sanitizer
triggers for similar reasons that trigger this diagnostic.


$ cat end.c 
void h(char *start, char end[0]);

#define size 100
void j(void)
{
char dst[size];
h(dst, dst+size);
}


$ /opt/local/gnu/gcc/countof18/bin/gcc -Wall -Wextra end.c 
end.c: In function ‘j’:
end.c:7:9: warning: ‘h’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
7 | h(dst, dst+size);
  | ^~~~
end.c:7:9: note: referencing argument 2 of type ‘char[0]’
end.c:1:6: note: in a call to function ‘h’

[Bug middle-end/108036] [12/13/14/15 Regression] Spurious warning for zero-sized array parameters to a function

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

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

--- Comment #13 from Sam James  ---
They're not completely distinct (some of the middle-end overflow warnings do
use builtin_object_size and friends), fwiw, as does UBSAN.

[Bug middle-end/117526] gcc.dg/tree-ssa/pr108357.c fails without integer argument promotion

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup. As PR 108357 is still open and there are other targets which fail it still
for the same reason as mentioned here. (solaris for an example).

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

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

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #25 from H.J. Lu  ---
One difference of signed vs unsigned char comes from:

static ccp_prop_value_t
get_value_for_expr (tree expr, bool for_bits_p)
{
...
  if (val.lattice_val == VARYING
  && INTEGRAL_TYPE_P (TREE_TYPE (expr))
  && TYPE_UNSIGNED (TREE_TYPE (expr)))
val.mask = wi::zext (val.mask, TYPE_PRECISION (TREE_TYPE (expr)));

  return val;
}

[Bug middle-end/117525] New: canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952

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

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

Bug ID: 117525
   Summary: canvas.cc:1675:1: internal compiler error: in
expand_fix, at optabs.cc:5952
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

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

during RTL pass: ce1
../libs/canvas/canvas.cc: In member function ‘virtual void
ArdourCanvas::GtkCanvasViewport::on_size_request(Gtk::Requisition*)’:
../libs/canvas/canvas.cc:1675:1: internal compiler error: in expand_fix, at
optabs.cc:5952
 1675 | }
  | ^
0x19c6ab3 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:518
0x228b87 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1696
0x9f5027 expand_fix(rtx_def*, rtx_def*, int)
../../gcc/gcc/optabs.cc:5952
0x717093 force_operand(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:8723
0x716dcb force_operand(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:8710
0x6e8d4f copy_to_mode_reg(machine_mode, rtx_def*)
../../gcc/gcc/explow.cc:655
0x9e6777 maybe_legitimize_operand
../../gcc/gcc/optabs.cc:8045
0x9e6777 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../gcc/gcc/optabs.cc:8188
0x9e3e37 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../gcc/gcc/optabs.cc:8207
0x9e5b87 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/gcc/optabs.cc:8262
0x9e5b87 emit_conditional_move_1
../../gcc/gcc/optabs.cc:5233
0x9e6017 emit_conditional_move(rtx_def*, rtx_comparison, rtx_def*, rtx_def*,
machine_mode, int)
../../gcc/gcc/optabs.cc:5146
0x17ffb17 noce_emit_cmove
../../gcc/gcc/ifcvt.cc:1773
0x180719f try_emit_cmove_seq
../../gcc/gcc/ifcvt.cc:3406
0x180719f noce_convert_multiple_sets_1
../../gcc/gcc/ifcvt.cc:3701
0x18076cf noce_convert_multiple_sets
../../gcc/gcc/ifcvt.cc:3492
0x180ad2f noce_process_if_block
../../gcc/gcc/ifcvt.cc:4041
0x180ad2f noce_find_if_block
../../gcc/gcc/ifcvt.cc:4722
0x180ad2f find_if_header
../../gcc/gcc/ifcvt.cc:4927
0x180ad2f if_convert
../../gcc/gcc/ifcvt.cc:6074
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
['/home/dave/opt/gnu/gcc/gcc-15/bin/g++',
'-I/home/dave/debian/ardour/ardour-8.10.0+ds', '-g', '-O2',
'-ffile-prefix-map=/home/dave/debian/ardour/ardour-8.10.0+ds=.', '-Wformat',
'-Werror=format-security', '--param', 'ggc-min-expand=10',
'-I/usr/include/qm-dsp', '-DHAVE_RF64_RIFF', '-DWAF_BUILD', '-DNDEBUG',
'-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math',
'-fstrength-reduce', '-pipe', '-DLXVST_32BIT', '-Wall', '-Wpointer-arith',
'-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter',
'-DBOOST_SYSTEM_NO_DEPRECATED', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS',
'-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64',
'-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="8"', '-std=c++11',
'-DBOOST_NO_AUTO_PTR', '-DBOOST_BIND_GLOBAL_PLACEHOLDERS',
'-Woverloaded-virtual', '-Wno-unused-local-typedefs', '-Wno-deprecated-copy',
'-D__STDC_LIMIT_MACROS', '-D__STDC_FORMAT_MACROS', '-DCANVAS_DEBUG',
'-DBOOST_ERROR_CODE_HEADER_ONLY', '-fPIC', '-fPIC', '-pthread', '-pthread',
'-pthread', '-Ilibs/canvas', '-I../libs/canvas', '-Ilibs/gtkmm2ext',
'-I../libs/gtkmm2ext', '-Ilibs/pbd', '-I../libs/pbd', '-Ilibs/tk/ytkmm/ytkmm',
'-I../libs/tk/ytkmm/ytkmm', '-Ilibs/tk/ydkmm/ydkmm',
'-I../libs/tk/ydkmm/ydkmm', '-Ilibs/tk/ytk/ytk', '-I../libs/tk/ytk/ytk',
'-Ilibs/tk/ydk/ydk', '-I../libs/tk/ydk/ydk', '-Ilibs/tk/ydk/ydk/gdk',
'-I../libs/tk/ydk/ydk/gdk', '-Ilibs/tk/ydk/ydk/x11',
'-I../libs/tk/ydk/ydk/x11', '-Ilibs/tk/ztkmm/ztkmm',
'-I../libs/tk/ztkmm/ztkmm', '-Ilibs/tk/ztk/ztk', '-I../libs/tk/ztk/ztk',
'-Ilibs/tk/ydk-pixbuf/ydk-pixbuf', '-I../libs/tk/ydk-pixbuf/ydk-pixbuf',
'-I/usr/include/sigc++-2.0', '-I/usr/lib/hppa-linux-gnu/sigc++-2.0/include',
'-I/usr/include/cairomm-1.0', '-I/usr/lib/hppa-linux-gnu/cairomm-1.0/include',
'-I/usr/include/cairo', '-I/usr/include/libpng16', '-I/usr/include/freetype2',
'-I/usr/include/pixman-1', '-I/usr/include/pangomm-1.4',
'-I/usr/lib/hppa-linux-gnu/pangomm-1.4/include', '-I/usr/include/glibmm-2.4',
'-I/usr/lib/hppa-linux-gnu/glibmm-2.4/include', '-I/usr/include/glib-2.0',
'-I/usr/lib/hppa-linux-gnu/glib-2.0/include', '-I/usr/include/sysprof-6',
'-I/usr/include/pango-1.0', '-I/usr/include/harfbuzz',
'-I/usr/include/libmount', '-I/usr/include/blkid', '-I/usr/include/fribidi',
'-I/usr/include/libxml2', '-I/usr/include/giomm-2.4',
'-I/

[Bug middle-end/117526] New: gcc.dg/tree-ssa/pr108357.c fails without integer argument promotion

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

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

Bug ID: 117526
   Summary: gcc.dg/tree-ssa/pr108357.c fails without integer
argument promotion
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

If TARGET_PROMOTE_PROTOTYPES returns false or the C frontend doesn't promote
integer argument as implemented in

https://patchwork.sourceware.org/project/gcc/list/?series=40497

gcc.dg/tree-ssa/pr108357.c fails if char is signed.  The difference starts
at the ccp1 pass:

1.  With signed char:

;; Function main (main, funcdef_no=2, decl_uid=2806, cgraph_uid=3,
symbol_order=
4)

Adding destination of edge (0 -> 2) to worklist

Simulating block 2

Visiting statement:
b.2_1 = b;
which is likely CONSTANT
Lattice value changed to VARYING.  Adding SSA edges to worklist.

Visiting statement:
_2 = (short int) b.2_1;
which is likely CONSTANT
Lattice value changed to VARYING.  Adding SSA edges to worklist.

2. With unsigned char:

;; Function main (main, funcdef_no=2, decl_uid=4429, cgraph_uid=3,
symbol_order=
4)

Adding destination of edge (0 -> 2) to worklist

Simulating block 2

Visiting statement:
b.2_1 = b;
which is likely CONSTANT
Lattice value changed to VARYING.  Adding SSA edges to worklist.

Visiting statement:
_2 = (short int) b.2_1;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0xff).  Adding SSA edges to worklist.
marking stmt to be not simulated again

It is due to

static ccp_prop_value_t
get_value_for_expr (tree expr, bool for_bits_p)
{
...
  if (val.lattice_val == VARYING
  && INTEGRAL_TYPE_P (TREE_TYPE (expr))
  && TYPE_UNSIGNED (TREE_TYPE (expr)))
val.mask = wi::zext (val.mask, TYPE_PRECISION (TREE_TYPE (expr)));

  return val;
}

[Bug c/117524] New: Segmentation fault with -fipa-cp-clone

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 117524
   Summary: Segmentation fault with -fipa-cp-clone
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For the attached C code with -O2 -fipa-cp-clone

foundBugs $ /home/dcb40b/gcc/results.20241105.asan.ubsan/bin/gcc -O2 -w
-fipa-cp-clone -Werror=uninitialized -Werror=aggressive-loop-optimizations
-Werror=sequence-point bug1064.c && ./a.out
checksum = 62CA1B9B
foundBugs $ /home/dcb40b/gcc/results.20241107.asan.ubsan/bin/gcc -O2 -w
-fipa-cp-clone -Werror=uninitialized -Werror=aggressive-loop-optimizations
-Werror=sequence-point bug1064.c && ./a.out
Segmentation fault (core dumped)
foundBugs $ /home/dcb40b/gcc/results.20241105.asan.ubsan/bin/gcc -v 2>&1 | grep
exp
gcc version 15.0.0 20241105 (experimental) (e152a734337a06ed) 
foundBugs $ /home/dcb40b/gcc/results.20241107.asan.ubsan/bin/gcc -v 2>&1 | grep
exp
gcc version 15.0.0 20241107 (experimental) (4473cf8409f4db19) 

I have a reduction running.

[Bug rtl-optimization/117524] Segmentation fault with -fipa-cp-clone

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

static void
crc32_byte (uint8_t b) {
 crc32_context =
  ((crc32_context >> 8) & 0x00FF) ^
  crc32_tab[(crc32_context ^ b) & 0xFF];
}

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

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

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

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

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

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117526
 CC||hjl.tools at gmail dot com

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