[Bug target/117278] [12/13/14/15 regression] Code at -Os is larger on trunk than GCC 11.4.0 since r12-6149-gdc1969dab39266

[dccitaliano at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Davide Italiano  ---
(In reply to Davide Italiano from comment #3)
> Another example that I found while looking at this:
> 
> int f(int* a) {
>   int sum = *a;
>   for (int i = 0; i < 10; i++) {
> if (i % 2 == 0 && (i > 3 || *a < 5)) {
>   for (int j = 0; j < 5; j++) {
> if (j > 2 && sum > 0) {
>   sum += i + j;
> }
> for (int k = 0; k < 3; k++) {
>   if ((k * j) % 2 != 0 && i > 5) {
> sum -= k;
>   }
>   if (k > 1 && j < 4 && (sum % (i + 1)) == 0) {
> sum += k * j;
>   }
> }
>   }
> }
>   }
>   return sum;
> }

Sorry, wrong comment, ignore this one

[Bug fortran/117473] New: Issue with OpenMP workshare and -fsanitize=thread

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

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

Bug ID: 117473
   Summary: Issue with OpenMP workshare and -fsanitize=thread
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59547&action=edit
Reproducer

This may be a dup of pr66553 or not, but I am reporting this anyway.

The attached code runs fine when compiled with

gfc-15 -fopenmp -O2 -g gfc-omp-workshare.f90 -fsanitize=thread

when executing with OMP_NUM_THREADS=1:

 Max.threads:   1
 -0.165948499762316132.8431552110569240E-002

However, with more threads I get a sanitizer warning:

OMP_NUM_THREADS=2 ./a.out  Max.threads:   2
==
WARNING: ThreadSanitizer: data race (pid=6436)
  Read of size 8 at 0x72cc00044610 by main thread (mutexes: write M0):
#0 test /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:19 (a.out+0x4040b1)
#1 main /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:2 (a.out+0x402d95)

  Previous write of size 8 at 0x72cc00044610 by thread T1:
#0 spline_init_vec.0._omp_fn.0
/home/anlauf/gcc-bugs/gfc-omp-workshare.f90:45 (a.out+0x40381a)
#1 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:129
(libgomp.so.1+0x22c97)

  Location is heap block of size 101400 at 0x72cc00038000 allocated by main
thread:
#0 malloc
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors_posix.cpp:665
(libtsan.so.2+0x56917)
#1 test /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:9 (a.out+0x403a3a)
#2 main /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:2 (a.out+0x402d95)

  Mutex M0 (0x725803e0) created at:
#0 pthread_mutex_lock
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors_posix.cpp:1341
(libtsan.so.2+0x5af6e)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:795 (a.out+0x40c72b)
#2 insert_unit ../../../gcc-trunk/libgfortran/io/unit.c:250
(a.out+0x40c72b)

  Thread T1 (tid=6438, running) created by main thread at:
#0 pthread_create
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors_posix.cpp:1022
(libtsan.so.2+0x5c0f5)
#1 gomp_team_start ../../../gcc-trunk/libgomp/team.c:859
(libgomp.so.1+0x2329f)
#2 main /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:2 (a.out+0x402d95)

SUMMARY: ThreadSanitizer: data race
/home/anlauf/gcc-bugs/gfc-omp-workshare.f90:19 in test
==
 -0.165948499762316132.8431552110569240E-002


So is this a bug in the program source code, or a false positive in the
thread sanitizer?

[Bug fortran/117473] Issue with OpenMP workshare and -fsanitize=thread

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 59548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59548&action=edit
Fix missing initialization outside of the parallel region

[Bug c++/117472] New: pack of function parameters without a name

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

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

Bug ID: 117472
   Summary: pack of function parameters without a name
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

A test from  should compile in
C++23:

```
template 
void f(T... [1]);
template 
void g(T... ptr[1]);
int main() {
  f(nullptr, nullptr); // ill-formed, previously void f(int [1], double [1])
  g(nullptr, nullptr); // ok
}
```

but we emit

pack-indexing11.C:7:13: error: expected ‘,’ or ‘...’ before ‘[’ token
7 | void f(T... [1]);
  | ^
pack-indexing11.C: In function ‘int main()’:
pack-indexing11.C:11:18: error: cannot convert ‘std::nullptr_t’ to ‘int’
   11 |   f(nullptr, nullptr); // { dg-error "no matching
function" }
  |  ^~~
  |  |
  |  std::nullptr_t
pack-indexing11.C:7:8: note:   initializing argument 1 of ‘void f(T ...) [with
T = {int, double}]’
7 | void f(T... [1]);
  |^~~~

[Bug c++/117470] new expression invalid size handling

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

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

--- Comment #1 from Jonathan Wakely  ---
I think this is PR 99934

[Bug c++/61105] [constexpr] accepts-invalid with new-expression in constant expression

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

[Bug target/116371] The SME2 svpext intrinsics are missing a _lane suffix

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Tamar Christina
:

https://gcc.gnu.org/g:97640e9632697b9f0ab31e4022d24d360d1ea2c9

commit r14-10893-g97640e9632697b9f0ab31e4022d24d360d1ea2c9
Author: Tamar Christina 
Date:   Mon Oct 14 13:58:09 2024 +0100

AArch64: rename the SVE2 psel intrinsics to psel_lane [PR116371]

The psel intrinsics. similar to the pext, should be name psel_lane.  This
corrects the naming.

gcc/ChangeLog:

PR target/116371
* config/aarch64/aarch64-sve-builtins-sve2.cc (class svpsel_impl):
Renamed to ...
(class svpsel_lane_impl): ... This and adjust initialization.
* config/aarch64/aarch64-sve-builtins-sve2.def (svpsel): Renamed to
...
(svpsel_lane): ... This.
* config/aarch64/aarch64-sve-builtins-sve2.h (svpsel): Renamed to
svpsel_lane.

gcc/testsuite/ChangeLog:

PR target/116371
* gcc.target/aarch64/sme2/acle-asm/psel_b16.c,
gcc.target/aarch64/sme2/acle-asm/psel_b32.c,
gcc.target/aarch64/sme2/acle-asm/psel_b64.c,
gcc.target/aarch64/sme2/acle-asm/psel_b8.c,
gcc.target/aarch64/sme2/acle-asm/psel_c16.c,
gcc.target/aarch64/sme2/acle-asm/psel_c32.c,
gcc.target/aarch64/sme2/acle-asm/psel_c64.c,
gcc.target/aarch64/sme2/acle-asm/psel_c8.c: Renamed to
* gcc.target/aarch64/sme2/acle-asm/psel_lane_b16.c,
gcc.target/aarch64/sme2/acle-asm/psel_lane_b32.c,
gcc.target/aarch64/sme2/acle-asm/psel_lane_b64.c,
gcc.target/aarch64/sme2/acle-asm/psel_lane_b8.c,
gcc.target/aarch64/sme2/acle-asm/psel_lane_c16.c,
gcc.target/aarch64/sme2/acle-asm/psel_lane_c32.c,
gcc.target/aarch64/sme2/acle-asm/psel_lane_c64.c,
gcc.target/aarch64/sme2/acle-asm/psel_lane_c8.c: ... These.

(cherry picked from commit 306834b7f74ab61160f205e04f5bf35b71f9ec52)

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #424 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #423)
> 
> If I may ask one last question, could you give advise on this glibc bug that
> affects SH?
> 
> > https://sourceware.org/bugzilla/show_bug.cgi?id=27543
> 
> There is a suggested patch to fix it. Maybe you could briefly comment on it?
> 

This is absolutely unrelated to this PR.  I have commented it there.

[Bug c++/117475] New: C++20: Union object with atomic integer cannot be statically initialized

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 117475
   Summary: C++20: Union object with atomic integer cannot be
statically initialized
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

The following test program fails to compile with GCC and -std=c++20:

#include 

typedef std::atomic_int Atomic_Int;

struct S {
  Atomic_Int v;
};

union U {
  S s;
};

U obj;

For example:

aarch64-rtems6-gcc -Wall -Wextra -std=c++20 -pedantic -S test.cc
test.cc:13:3: error: use of deleted function 'U::U()'
   13 | U obj;
  |   ^~~
test.cc:9:7: note: 'U::U()' is implicitly deleted because the default
definition would be ill-formed:
9 | union U {
  |   ^
test.cc:10:5: error: union member 'U::s' with non-trivial 'constexpr S::S()'
   10 |   S s;
  | ^

It works with clang 17.0.6:

clang -Wall -Wextra -std=c++20 -pedantic -S test.cc -o -
.text
.file   "test.cc"
.type   obj,@object # @obj
.bss
.globl  obj
.p2align2, 0x0
obj:
.zero   4
.size   obj, 4

.section".linker-options","e",@llvm_linker_options
.ident  "clang version 17.0.6"
.section".note.GNU-stack","",@progbits
.addrsig

[Bug middle-end/115805] 436.cactusADM and 507.cactuBSSN_r miscompilation with -O2 generic -flto and some hardening options

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

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

--- Comment #3 from Filip Kastl  ---
I've just tried this on some older commits but still didn't find a commit
without this behavior so I don't have evidence that this is a regression. The
oldest commit I know where this behavior is present is
r14-5791-g24592abd68e6ef.

I'm not sure how I would reduce this.  I don't know Fortran so I don't think I
could reduce this manually and I also don't know how I would use automated
tools to reduce this.

[Bug rtl-optimization/117464] Pointers mismatch after some pointer arithmetic (+ and - from base address)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Yes you writing to a location as `char*` and then reading it as `int*`.


Note this is not about writing via a char either.

[Bug ipa/117440] [12/13/14/15 regression] ICE: in merge, at ipa-modref.cc:2138 at -Os

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-06
 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Confirmed by Andrew.

[Bug fortran/117455] ld warning about executable stack, follows from PR 117434

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||fxcoudert at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-06

--- Comment #5 from Iain Sandoe  ---
(In reply to Sam James from comment #4)
> https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-
> segments

thanks Sam, that's an excellent write-up and saves us trying to replicate the
content here.

So .. to recap : the bottom line is that this is not specifically a technical
fault, it is more one of perceived (or actual) risk of executable stack w.r.t
malicious intent and the policy of dealing with that risk.

Having said this, there are ways in which we can avoid having to make (or abide
by) policy on executable stack.

1. On x86_64/aarch64 Linux (and on x86_64/arm64 Darwin) there's an alternate
trampoline implementation that uses the heap (-ftrampoline-impl=heap).

2. ISTR that Richi suggested that gfortran's code-gen could be restructured to
avoid the use of nested functions.

I'm of the opinion that it's not exactly a "bug" to fix here - more that
gfortran platform maintainers need to decide if they:

 a) want to suppress this warning (either generally by adding the appropriate
flags to the gfortran specs, or specifically in individual test cases).

 b) want to shift their platform to use heap-based trampolines (which might
involve implementing the support for it for any cases not listed in 1 above)

 c) want to consider re-architecting the gfortran code-gen to avoid the use of
nested functions for their current purposes.

I'd say that (c) is well out of reach for GCC-15 and (b) is probably out of
reach for platforms without an implementation already, unless they start work
today ;).  However, the call needs to be made by the individual platform
maintainer(s).

>From the PoV of Darwin the decision was made for us because Apple's new OSs no
longer allow executable stack - so we currently use heap trampolines.  I would
be interested in the re-architecting idea but (i) have no idea how complex it
would be and (ii) in any event have no spare cycles to work on it.

[Bug target/116725] operand size mismatch for vfpclasssd and vfpclassss when using -masm=intel for AVX512 builtins

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

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

--- Comment #10 from Sam James  ---
(In reply to Antoni from comment #9)
> Sam, since I use -masm=intel in rustc_codegen_gcc, I fixed a few bugs and I
> also test a lot of x86-specific intrinsics (since they're used in stdarch:
> https://github.com/rust-lang/stdarch), so it might not be as bad as you
> think.

Ah, interesting. Maybe I will do a run with it soon then. Thanks!

[Bug rtl-optimization/117464] Pointers mismatch after some pointer arithmetic (+ and - from base address)

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

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

--- Comment #1 from Andrew Pinski  ---
I am not 100% sure but I am suspecting there is some aliasing issues with the
code.

Does -fno-strict-aliasing fix the issue?

I suspect you are writing and then reading via two different types to the same
memory location which is causing issues.

[Bug rtl-optimization/117464] Pointers mismatch after some pointer arithmetic (+ and - from base address)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug rtl-optimization/117464] Pointers mismatch after some pointer arithmetic (+ and - from base address)

[prazdnovserg at gmail dot com via Gcc-bugs]

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

Серёжа Празднов  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

[Bug rtl-optimization/117464] Pointers mismatch after some pointer arithmetic (+ and - from base address)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Andrew Pinski  ---
>From gcc point of view the code is undefined so the bug report should be closed
as invalid.

[Bug middle-end/115162] ICE in OpenMP target data map directive

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Tobias Burnus  ---
Should be the same as PR113724

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

[Bug libstdc++/115285] [12/13/14 Regression] std::unordered_set can have duplicate value

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

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to frs.dumont from comment #15)
> It's surprising that we need to handle this use case. The user wants K 
> is to be explicitly built from int but then insert ints, weird.

How else would you insert a range of values constructed from the ints into the
container?

The user can insert them one-by-one like this:

for (auto i : int_range)
  m.emplace(i);

So there's no reason to prevent them from doing it using insert(first, last).

> Are other Standard library handling this ?

Yes, because the standard requires it.

The requirement on insert(i, j) is "value_type is Cpp17EmplaceConstructible
into X from *i", which means that allocator_traits::construct(m, p, *i) must
be valid.

allocator_traits::construct always does explicit construction of a new object,
there is no implicit conversion.

This means that insert(i, j) must be equivalent to emplace(*i) in a loop. Which
is what my patch does.

[Bug tree-optimization/117467] New: [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

Bug ID: 117467
   Summary: [15 Regression] 521.wrf_r again explodes
memory/compile-time wise
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

It tops 25GB memory usage when building with -Ofast -march=znver5 -fno-checking
-fopt-info-vec

One of the big offending TUs is start_em.fppized.f90, but the worst seems to
be module_first_rk_step_part1.fppized.f90 for which -ftime-report (checking
bootstrapped build, but -fno-checking) shows

 df reaching defs   :  35.27 (  7%) 0  (  0%)
 tree VRP   :  81.03 ( 16%)   125M (  4%)
 dominator optimization :  28.98 (  6%)84M (  3%)
 LRA non-specific   :  23.21 (  5%)63M (  2%)
 rest of compilation: 167.62 ( 33%)23M (  1%)
 TOTAL  : 506.00 3218M

[Bug tree-optimization/117467] [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||compile-time-hog,
   ||memory-hog

[Bug ipa/117440] [12/13/14/15 regression] ICE: in merge, at ipa-modref.cc:2138 at -Os

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

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

--- Comment #3 from Jan Hubicka  ---
When processing covariant return thunk to g::f() const which is expanded to
gimple we get stuck on:

# .MEM_6 = VDEF <.MEM_4(D)>
g::*.LTHUNK0 (this_5(D));

It fails on sanity check of EAF flags:
  /* Check that flags seems sane: if function does not read the parameter
 it can not access it indirectly.  */
  gcc_checking_assert (!(f & EAF_NO_DIRECT_READ)
   || ((f & EAF_NO_INDIRECT_READ)
   && (f & EAF_NO_INDIRECT_CLOBBER)
   && (f & EAF_NO_INDIRECT_ESCAPE)
   && (f & EAF_NOT_RETURNED_INDIRECTLY)));

The f & EAF_NO_DIRECT_READ is true but f & EAF_NO_INDIRECT_CLOBBER is false. 
So I need to figure out where NO_INDIRECT_CLOBBER got cleaned.

[Bug c++/117466] New: brk #1000 rsp. ud2

[hans.buchmann.wantuch at gmail dot com via Gcc-bugs]

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

Bug ID: 117466
   Summary: brk #1000 rsp. ud2
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hans.buchmann.wantuch at gmail dot com
  Target Milestone: ---

Created attachment 59546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59546&action=edit
The code, the assembler outputs and the compiler versions

The code 'brk-1000.cc'

--8<--8<--8<--8<--
struct R
{
 static const unsigned N=1;
 unsigned v[N];
 R(const unsigned in[])
 {
  for(unsigned i=0;auto& d:v)d=in[i++];
 }
};

struct Card
{
 R rca={0};
};

Card card;
--8<--8<--8<--8<--

compiled with:

CC=aarch64-linux-gnu-g++
${CC} -O2 -freport-bug -std=c++2a -Wall -Wextra \
-S -o brk-1000.s brk-1000.cc

results in the assembler output:

_GLOBAL__sub_I_card:
.LFB7:
.cfi_startproc
mov x0, 0
ldr w0, [x0]
brk #1000   //< why
.cfi_endproc

compiling the same code with g++ 

_GLOBAL__sub_I_card:
.LFB7:
.cfi_startproc
movl0, %eax
ud2   //< why
.cfi_endproc


Sincerely

Hans Buchmann

[Bug c++/63388] cout of enum class value - segmentation fault

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:85736ba8e1fc4a5003f958dd268a155e379e059f

commit r15-4983-g85736ba8e1fc4a5003f958dd268a155e379e059f
Author: David Malcolm 
Date:   Wed Nov 6 08:45:29 2024 -0500

testsuite: add infinite recursion test case [PR63388]

gcc/testsuite/ChangeLog:
PR c++/63388
* g++.dg/analyzer/infinite-recursion-pr63388.C: New test.

Signed-off-by: David Malcolm 

[Bug rtl-optimization/117464] Pointers mismatch after some pointer arithmetic (+ and - from base address)

[prazdnovserg at gmail dot com via Gcc-bugs]

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

Серёжа Празднов  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|INVALID |FIXED

--- Comment #4 from Серёжа Празднов  ---
(In reply to Andrew Pinski from comment #3)
> You can place an compiler barrier after the update of the pointer though
> like so:
> ```
> AllocatedMemBlocks[1].MemBlockPtr -= 10;
> asm("":::"memory");
> ```
> 
> Which will "Fix" the issue but that is just workaround the overall aliasing
> violation you have.

Thanks, i'll try to rewrite code. Is it possible to avoid memory fragmentation
moving data and pointers to it?

[Bug c/117469] New: returns_twice on defined functions

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

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

Bug ID: 117469
   Summary: returns_twice on defined functions
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

It is not really possible to define (not just declare) a returns_twice function
in C. The only possibilities I see are:

1) a "naked" function, on targets where that's supported;

2) a weak function, where the dummy definition returns normally, but the
link-time replacement (not written in C) really returns twice;

and there's a third alternative, which users could plausibly expect to work,
but we can not guarantee that:

3) the C code attempts to tail-call another function (which does return twice).

This third alternative is broken:

a) at -O0,
b) if sibcall transform fails for any reason,
c) if another function is not annotated with returns_twice (and our function is
inlined, for example).

I guess diagnostics for any of this is too much work, but extending our
documentation to reflect this could be reasonable.

[Bug target/117468] New: arm thumb1 high reg restoration trashes register reserved with -ffixed-reg

[matt.parks--- via Gcc-bugs]

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

Bug ID: 117468
   Summary: arm thumb1 high reg restoration trashes register
reserved with -ffixed-reg
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt.pa...@go-aps.com
  Target Milestone: ---

ARM thumb1 compilation using -ffixed-reg with r4-r7, without -Os (which
prohibits use of high registers), produces bad high register restoration code
that clobbers the fixed register.

Bug is in gcc/config/arm/arm.cc (or arm.c in older versions) and was introduced
in gcc 10, when functions thumb1_prologue_unused_call_clobbered_lo_regs and
thumb1_epilogue_unused_call_clobbered_lo_regs were added. I believe it affects
all gcc versions greater than 10.

Example source test_hireg.c which excites the problem:
---
void ext_func(int e1, int e2, int e3, int e4);

int bad_func(int p1, int p2, int p3, int p4) {
ext_func(p4, p3, p2, p1);
return p1 + p2 + p3 + p4;
}
---

Compile example:
arm-none-eabi-gcc -ffixed-r7 -march=armv5te -mthumb -mabi=apcs-gnu -O2 -S -o
test_hireg.s test_hireg.c

Bad results in test_hireg.s:
Prologue:
push {r4, r5, r6, lr}
mov lr, r8
mov r6, r2
mov r5, r3
push {lr}
mov r8, r0
...
Epilogue:
...
pop {r7} <-- violates -ffixed-r7 by clobbering register
mov r8, r7
pop {r4, r5, r6, pc}

Problem: thumb1_prologue_unused_call_clobbered_lo_regs and
thumb1_epilogue_unused_call_clobbered_lo_regs create a bitmask of unused
registers that may be used for scratch work. The search omits
callee_saved_reg_p(reg), but does not take into account fixed registers which
are not reported because callee_saved_reg_p returns !call_used_or_fixed_reg_p.

Bugfix:
Modify both thumb1_prologue_unused_call_clobbered_lo_regs and
thumb1_epilogue_unused_call_clobbered_lo_regs. In the if () statement in each
function, add condition "&& !fixed_regs[reg]".

Epilogue after bugfix:
...
pop {r6} <-- avoids fixed r7 and uses r6 instead
mov r8, r6
pop {r4, r5, r6, pc}

[Bug c++/117466] brk #1000 rsp. ud2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Because the testcase invokes UB (dereferences a NULL pointer) - d = in[0]; in
particular where in is nullptr and path isolation just adds __builtin_trap
after it because everything after invoking the UB is not needed.

[Bug libstdc++/111861] ranges::min/max should not use `auto __result = *__first;`

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2024-11-06
 Ever confirmed|0   |1

[Bug target/117366] arm thumb1 epilogue size optimizer violates -ffixed

[matt.parks--- via Gcc-bugs]

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

--- Comment #1 from Matt Parks  ---
Side note - just to eliminate an undocumented magic number, I'd also suggest
the following diff in thumb1_extra_regs_pushed:
- while(reg_base + n_free < 8 && ...
+ while(reg_base + n_free <= LAST_LO_REGNUM && ...

[Bug rtl-optimization/117464] New: Pointers mismatch after some pointer arithmetic (+ and - from base address)

[prazdnovserg at gmail dot com via Gcc-bugs]

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

Bug ID: 117464
   Summary: Pointers mismatch after some pointer arithmetic (+ and
- from base address)
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prazdnovserg at gmail dot com
  Target Milestone: ---

Created attachment 59545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59545&action=edit
Preprocessed file with -O2 flag

With any -O2+ flag **pointers starts to act weird 
Flags: -std=c23 -O2 -s -Werror -Wextra -Wall -Wduplicated-branches
-Wduplicated-cond -Wfloat-equal -Wcast-qual -Wconversion -Wsign-conversion
-Wlogical-op

[Bug gcov-profile/103652] Producing profile with -O2 -flto and trying to consume it with -O3 -flto leads to ICEs on indirect call profiling

[petr.hruska at nokia dot com via Gcc-bugs]

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

Petr Hruska (Nokia)  changed:

   What|Removed |Added

 CC||petr.hruska at nokia dot com

--- Comment #6 from Petr Hruska (Nokia)  ---
I would like to share, that we are observing identical ICE with gcc14.2
release. After applying proposed change, problem is rectified.

Would it be possible to consider to include change to release code?

[Bug c++/117463] [12/13/14/15 Regression] internal compiler error: Segmentation fault at is_nondependent_constant_expression(tree_node*)

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #3 from Simon Martin  ---
It's very close to PR c++/117101 for which I pushed a fix yesterday.

Will check whether it's still valid, and if so, look into this.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Uroš Bizjak  ---
Some more discussion at [1].

[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667718.html

[Bug fortran/117442] [15 Regression] Cannot build libgfortran with enable-gather-detailed-mem-stats after r15-4760-g0b73e9382ab51c

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

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

--- Comment #4 from Martin Jambor  ---
(In reply to David Malcolm from comment #3)
> Sorry about the regression.  Should be fixed by the above patch.

No worries, thanks for a quick fix!

[Bug middle-end/113724] [14/15 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1 since r14-6515

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||Bert.Wesarg at googlemail dot 
com

--- Comment #13 from Tobias Burnus  ---
*** Bug 115162 has been marked as a duplicate of this bug. ***

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

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

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

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

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

commit r15-4975-gaab572240a0752da74029ed9f8918e0b1628e8ba
Author: Jakub Jelinek 
Date:   Wed Nov 6 10:21:09 2024 +0100

store-merging: Don't use sub_byte_op_p mode for empty_ctor_p unless
necessary [PR117439]

encode_tree_to_bitpos uses the more expensive sub_byte_op_p mode in which
it has to allocate a buffer and do various extra work like shifting the
bits
etc. if bitlen or bitpos aren't multiples of BITS_PER_UNIT, or if bitlen
doesn't have corresponding integer mode.
The last case is explained later in the comments:
  /* The native_encode_expr machinery uses TYPE_MODE to determine how many
 bytes to write.  This means it can write more than
 ROUND_UP (bitlen, BITS_PER_UNIT) / BITS_PER_UNIT bytes (for example
 write 8 bytes for a bitlen of 40).  Skip the bytes that are not within
 bitlen and zero out the bits that are not relevant as well (that may
 contain a sign bit due to sign-extension).  */
Now, we've later added empty_ctor_p support, either {} CONSTRUCTOR
or {CLOBBER}, which doesn't use native_encode_expr at all, just memset,
so that case doesn't need those fancy games unless bitlen or bitpos
aren't multiples of BITS_PER_UNIT (unlikely, but let's pretend it is
possible).

The following patch makes us use the fast path even for empty_ctor_p
which occupy full bytes, we can just memset that in the provided buffer and
don't need to XALLOCAVEC another buffer.

This patch in itself fixes the testcase from the PR (which was about using
huge XALLLOCAVEC), but I want to do some other changes, to be posted in a
next patch.

2024-11-06  Jakub Jelinek  

PR tree-optimization/117439
* gimple-ssa-store-merging.cc (encode_tree_to_bitpos): For
empty_ctor_p use !sub_byte_op_p even if bitlen doesn't have an
integral mode.

[Bug c/117456] ICE: in expand_expr_real_2, at expr.cc:10567 with __builtin_stdc_rotate_left() on bitfield or _BitInt() of non-mode size

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
I'll handle this, but preferrably during stage3.

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

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

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

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

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

commit r15-4976-g6d8764cc1f938b3edee4ac26dc5d4d8dca74dc54
Author: Jakub Jelinek 
Date:   Wed Nov 6 10:22:13 2024 +0100

store-merging: Apply --param=store-merging-max-size= in more spots
[PR117439]

Store merging assumes a merged region won't be too large.  The assumption
is
e.g. in using inappropriate types in various spots (e.g. int for bit sizes
and bit positions in a few spots, or unsigned for the total size in bytes
of
the merged region), in doing XNEWVEC for the whole total size of the merged
region and preparing everything in there and even that XALLOCAVEC in two
spots.  The last case is what was breaking the test below in the patch,
64MB XALLOCAVEC is just too large, but even with that fixed I think we just
shouldn't be merging gigabyte large merge groups.

We already have --param=store-merging-max-size= parameter, right now with
65536 bytes maximum (if needed, we could raise that limit a little bit).
That parameter is currently used when merging two adjacent stores, if the
size of the already merged bitregion together with the new store's
bitregion
is above that limit, we don't merge those.
I guess initially that was sufficient, at that time a store was always
limited to MAX_BITSIZE_MODE_ANY_INT bits.
But later on we've added support for empty ctors ({} and even later
{CLOBBER}) and also added another spot where we merge further stores into
the merge group, if there is some overlap, we can merge various other
stores
in one coalesce_immediate_stores iteration.
And, we weren't applying the --param=store-merging-max-size= parameter
in either of those cases.  So a single store can be gigabytes long, and
if there is some overlap, we can extend the region again to gigabytes in
size.

The following patch attempts to apply that parameter even in those cases.
So, if testing if it should merge the merged group with info (we've already
punted if those together are above the parameter) and some other stores,
the first two hunks just punt if that would make the merge group too large.
And the third hunk doesn't even add stores which are over the limit.

2024-11-06  Jakub Jelinek  

PR tree-optimization/117439
* gimple-ssa-store-merging.cc
(imm_store_chain_info::coalesce_immediate_stores): Punt if merging
of
any of the additional overlapping stores would result in growing
the
bitregion size over param_store_merging_max_size.
(pass_store_merging::process_store): Terminate all aliasing chains
for stores with bitregion larger than param_store_merging_max_size.

* g++.dg/opt/pr117439.C: New test.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE
   |ICE in  |in encode_tree_to_bitpos
   |encode_tree_to_bitpos   |

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

[Bug middle-end/117459] ICE: in lower_stmt, at gimple-lower-bitint.cc:5714 with __builtin_assoc_barrier() on _BitInt(255)

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

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

--- Comment #2 from Richard Biener  ---
Possibly.  Maybe we should even diagnose such use?

[Bug c++/117463] [12/13/14/15 Regression] internal compiler error: Segmentation fault at is_nondependent_constant_expression(tree_node*)

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |15.0
   Priority|P3  |P4

[Bug c++/117465] New: Disable -Wnonnull-compare in macros

[david.bolvansky at gmail dot com via Gcc-bugs]

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

Bug ID: 117465
   Summary: Disable -Wnonnull-compare in macros
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

#include 

#define DEBUG(ptr) if (ptr) printf("%p", (void *)ptr);

class Clz {
int data;
public:
Clz(void) {
DEBUG(this);
}
};

int main(void) {

int i;
DEBUG(&i);
Clz a;

return 0;
}

g++ -Wall -Wextra code.cpp

warning: 'nonnull' argument 'this' compared to NULL [-Wnonnull-compare]
3 | #define DEBUG(ptr) if (ptr) printf("%p", (void *)ptr);



This is quite annoying in macros. Derived from real code, where null check is
needed, as macro is universal.

[Bug c++/63388] cout of enum class value - segmentation fault

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #6 from David Malcolm  ---
$ ./xg++ -B. -S
../../src/gcc/testsuite/g++.dg/analyzer/infinite-recursion-pr63388.C -fanalyzer
../../src/gcc/testsuite/g++.dg/analyzer/infinite-recursion-pr63388.C: In
function ‘std::ostream& operator<<(std::ostream&, Month)’:
../../src/gcc/testsuite/g++.dg/analyzer/infinite-recursion-pr63388.C:13:16:
warning: infinite recursion [CWE-674] [-Wanalyzer-infinite-recursion]
   13 |   return os << m; // { dg-warning "infinite recursion" }
  |^
  ‘std::ostream& operator<<(std::ostream&, Month)’: events 1-2
│
│   11 | std::ostream& operator<<(std::ostream& os, Month m)
│  |   ^~~~
│  |   |
│  |   (1) initial entry to ‘operator<<’
│   12 | {
│   13 |   return os << m; // { dg-warning "infinite recursion" }
│  |~
│  ||
│  |(2) calling ‘operator<<’ from ‘operator<<’
│
└──> ‘std::ostream& operator<<(std::ostream&, Month)’: events 3-4
   │
   │   11 | std::ostream& operator<<(std::ostream& os, Month m)
   │  |   ^~~~
   │  |   |
   │  |   (3) recursive entry to ‘operator<<’;
previously entered at (1)
   │  |   (4) ⚠️  apparently infinite recursion
   │

[Bug rtl-optimization/117464] Pointers mismatch after some pointer arithmetic (+ and - from base address)

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

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

--- Comment #3 from Andrew Pinski  ---
You can place an compiler barrier after the update of the pointer though like
so:
```
AllocatedMemBlocks[1].MemBlockPtr -= 10;
asm("":::"memory");
```

Which will "Fix" the issue but that is just workaround the overall aliasing
violation you have.

[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #6 from Jonathan Wakely  ---
This rewrite seems to have garbled the docs.

The attribute says:

  @var{level}=0 is the least strict level, all trailing arrays of structures
  are treated as flexible array members. @var{level}=3 is the strictest level,
  only when the trailing array is declared as a flexible array member per C99
  standard onwards (@samp{[]}), it is treated as a flexible array member.

The -fstrict-flex-arrays option used to agree, but now it says:

  @option{-fstrict-flex-arrays=3}, which is the strictest; all
  trailing arrays of structures are treated as flexible array members.

  The negative form @option{-fno-strict-flex-arrays} is equivalent to
  @option{-fstrict-flex-arrays=0}, which is the least strict.  In this
  case a trailing array is treated as a flexible array member only when
  it is declared as a flexible array member per C99 standard onwards.

So they disagree on what "strictest" means. This is very confusing now.

[Bug ipa/117440] [12/13/14/15 regression] ICE: in merge, at ipa-modref.cc:2138 at -Os

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

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

--- Comment #4 from Jan Hubicka  ---
OK, so the problem is that we analyze function body of g::f which is declared
with pure attribute:

modref analyzing 'virtual g* g::f() const/1' (ipa=0) (pure)
Analyzing flags of ssa name: this_4(D)
  Analyzing stmt: _1 = &this_4(D)->D.2861;
Analyzing flags of ssa name: _1
  Analyzing stmt: if (_1 != e.4_2)
  current flags of _1 no_direct_clobber no_indirect_clobber
no_direct_escape no_indirect_escape not_returned_directly
not_returned_indirectly no_direct_read no_indirect_read
flags of ssa name _1 no_direct_clobber no_indirect_clobber no_direct_escape
no_indirect_escape not_returned_directly not_returned_indirectly no_direct_read
no_indirect_read
  current flags of this_4(D) no_direct_clobber no_indirect_clobber
no_direct_escape no_indirect_escape not_returned_directly
not_returned_indirectly no_direct_read no_indirect_read
flags of ssa name this_4(D) no_direct_clobber no_indirect_clobber
no_direct_escape no_indirect_escape not_returned_directly
not_returned_indirectly no_direct_read no_indirect_read

...

  parm 0 flags: not_returned_directly not_returned_indirectly no_direct_read
no_indirect_read
__attribute__((pure))

here parm 0 is originally detected with many attributes including no_*_clobber
but they are taken away because we know they are implied by pure attribute. 
Now however function is called through thunk and ECF_FLAGS use thunk alias
while modref flags looks through the alias to actual definition, which means
that we end up with the insane combination.

So the bug is that we create aliases without the pure attribute on it or
altenratively ecf_flags may look through non-interposable aliases and merge in
the flags.

(gdb) p debug_tree (gimple_call_fndecl (call))
 
sizes-gimplified public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777ced20>
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777cee70 method basetype 
arg-types 
chain >>
pointer_to_this >
addressable used autoinline decl_5 QI m.C:7:28 align:8 warn_if_not_align:0
context  initial 
full-name "g* g::*.LTHUNK0() const">

(gdb) p cgraph_node::get (gimple_call_fndecl (call))->debug ()
*.LTHUNK0/2 (g* g::*.LTHUNK0() const)
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: semantic_interposition comdat_group:_ZNK1g1fEv
section:.text._ZNK1g1fEv (implicit_section) artificial
  Same comdat group as: _ZNK1g1fEv/1
  References: _ZNK1g1fEv/1 (alias) 
  Referring: 
  Availability: available
  Function flags: optimize_size
  Called by:

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #7 from Sebastian Huber  ---
This is not really great for C/C++ compatibility. Is there a way to get
statically initialized atomic integers using the standard C++20 ?

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Sebastian Huber from comment #7)
> This is not really great for C/C++ compatibility. Is there a way to get
> statically initialized atomic integers using the standard C++20 ?

Also please read the C++ library paper I pointed you to. Since it talks about
compatibility with C and C++ there.

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Note there was a bug in pre GCC 13 dealing with unions with C++20 and
non-trivial constructors and non-initialized fields; see PR 98423 for that.
That deals with the testcase like:
```
union U {
  int t = 0;
  S s;
};
```

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

--- Comment #11 from Andrew Pinski  ---
Note again the only reason clang 17 from opensuse works is because it is using
GCC's libstdc++ from GCC 7 which is pre the fix for PR 58605 (which was done in
GCC 10). And GCC 9.5.0 accepted the original testcase in comment #0 (with
-std=c++2a) but that is because std::atomic didn't have the change for PR 58605
.

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

[sebastian.huber--- via Gcc-bugs]

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

Sebastian Huber  changed:

   What|Removed |Added

Version|12.4.0  |13.0

--- Comment #5 from Sebastian Huber  ---
(In reply to Andrew Pinski from comment #1)
> >It works with clang 17.0.6:
> 
> It is rejected for me with both libstdc++ and libc++ with clang with
> -std=c++20:
> 
> :14:3: error: call to implicitly-deleted default constructor of 'U'
>14 | U obj;
>   |   ^
> :11:5: note: default constructor of 'U' is implicitly deleted
> because variant field 's' has a non-trivial default constructor
>11 |   S s;
>   | ^
> 
> https://godbolt.org/z/o7fnP8cjM
> 
> Are you sure you are testing the correct thing with clang?

I used the clang 17.0.6 from openSUSE Leap 15.6. With the clang from
godbolt.org I get also failures.

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #6 from Sebastian Huber  ---
(In reply to Andrew Pinski from comment #1)
> >It works with clang 17.0.6:
> 
> It is rejected for me with both libstdc++ and libc++ with clang with
> -std=c++20:
> 
> :14:3: error: call to implicitly-deleted default constructor of 'U'
>14 | U obj;
>   |   ^
> :11:5: note: default constructor of 'U' is implicitly deleted
> because variant field 's' has a non-trivial default constructor
>11 |   S s;
>   | ^
> 
> https://godbolt.org/z/o7fnP8cjM
> 
> Are you sure you are testing the correct thing with clang?

I used the clang 17.0.6 from openSUSE Leap 15.6. With the clang from
godbolt.org I get also failures.

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|13.0|12.4.0

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> testcase which works with clang but fails with GCC:

But that was fixed in GCC 13. Let me see if I can find the bug report ...

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Sebastian Huber from comment #6)
> 
> I used the clang 17.0.6 from openSUSE Leap 15.6. With the clang from
> godbolt.org I get also failures.

Because that uses libstdc++ from GCC 7 which does NOT have C++20 compatibility
at all.
(In reply to Sebastian Huber from comment #7)
> This is not really great for C/C++ compatibility. Is there a way to get
> statically initialized atomic integers using the standard C++20 ?

As I mentioned you can do:
```
union U {
  S s{};
};
```

To fix the issue by initializing the field s by default.


Other than that this is not a question for GCC since there is how standard C++
works.

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #12 from Sebastian Huber  ---
(In reply to Andrew Pinski from comment #11)
> Note again the only reason clang 17 from opensuse works is because it is
> using GCC's libstdc++ from GCC 7 which is pre the fix for PR 58605 (which
> was done in GCC 10). And GCC 9.5.0 accepted the original testcase in comment
> #0 (with -std=c++2a) but that is because std::atomic didn't have the change
> for PR 58605 .

Thanks for your detailed analysis.

[Bug target/117304] ICE: in emit_move_insn, at expr.cc:4633 with -mavx10.1 and __builtin_ia32_cvtudq2ps512_mask()

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Hu :

https://gcc.gnu.org/g:05fd99e3d5e9f00e4e23596ed15a3cec2aaba128

commit r14-10895-g05fd99e3d5e9f00e4e23596ed15a3cec2aaba128
Author: Hu, Lin1 
Date:   Tue Nov 5 15:49:57 2024 +0800

i386: Add OPTION_MASK_ISA2_EVEX512 for some AVX512 instructions.

gcc/ChangeLog:

PR target/117304
* config/i386/i386-builtin.def: Add OPTION_MASK_ISA2_EVEX512 for
some
AVX512 512-bits instructions.

gcc/testsuite/ChangeLog:

PR target/117304
* gcc.target/i386/pr117304-1.c: New test.

(cherry picked from commit 8ac694ae67e24a798dce368587bed4c40b90fbc0)

[Bug c/117469] returns_twice on defined functions

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

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

--- Comment #2 from Alexander Monakov  ---
(In reply to Xi Ruoyao from comment #1)
> So if the tail-call uses [[musttail]] the alternative 3 should be "fine"?

Yes, plus annotating the callees that return twice with the attribute is still
required.

And with that we are currently refusing to emit a sibcall:

__attribute__((returns_twice))
void foo(void);

__attribute__((returns_twice))
void bar()
{
[[gnu::musttail]] return foo();
}

t.c: In function 'bar':
t.c:7:30: error: cannot tail-call: caller uses setjmp

[Bug c/105863] RFE: C23 #embed

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

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

--- Comment #20 from Jakub Jelinek  ---
What still isn't committed is the C++ optimization support of #embed.
And, we need to decide what to do with the macro expansion for #embed, the
current implementation isn't conformant (but maybe WG14 will change it as a
DR), neither is the clang implementation conformant.

[Bug target/117278] [12/13/14/15 regression] Code at -Os is larger on trunk than GCC 11.4.0 since r12-6149-gdc1969dab39266

[dccitaliano at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Davide Italiano  ---
Another example that I found while looking at this:

int f(int* a) {
  int sum = *a;
  for (int i = 0; i < 10; i++) {
if (i % 2 == 0 && (i > 3 || *a < 5)) {
  for (int j = 0; j < 5; j++) {
if (j > 2 && sum > 0) {
  sum += i + j;
}
for (int k = 0; k < 3; k++) {
  if ((k * j) % 2 != 0 && i > 5) {
sum -= k;
  }
  if (k > 1 && j < 4 && (sum % (i + 1)) == 0) {
sum += k * j;
  }
}
  }
}
  }
  return sum;
}

[Bug rtl-optimization/117128] [15 regression] GCC trunk generates larger code than GCC 14 at -Os/Oz since r14-2161-g237e83e2158a3d

[dccitaliano at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Davide Italiano  ---
Yet another example:

int f(int* a) {
  int sum = *a;
  for (int i = 0; i < 10; i++) {
if (i % 2 == 0 && (i > 3 || *a < 5)) {
  for (int j = 0; j < 5; j++) {
if (j > 2 && sum > 0) {
  sum += i + j;
}
for (int k = 0; k < 3; k++) {
  if ((k * j) % 2 != 0 && i > 5) {
sum -= k;
  }
  if (k > 1 && j < 4 && (sum % (i + 1)) == 0) {
sum += k * j;
  }
}
  }
}
  }
  return sum;
}

[Bug c/105863] RFE: C23 #embed

[eschwartz93 at gmail dot com via Gcc-bugs]

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

Eli Schwartz  changed:

   What|Removed |Added

 CC||eschwartz93 at gmail dot com

--- Comment #19 from Eli Schwartz  ---
This has since been updated by various commits such as

r15-4375-g1844a4aa6615c2


Author: Jakub Jelinek 
Wed, 16 Oct 2024 08:09:49 + (10:09 +0200)

libcpp, c, middle-end: Optimize initializers using #embed in C

This patch actually optimizes #embed, so far in C.


ce0aecc7df1ff0be24c278dff5575ec28042ee58:  libcpp, v2: Add support for
gnu::base64 #embed parameter

44058b847145166715f15e49fa8854f30e852f24:  libcpp: Add support for gnu::offset
#embed/__has_embed parameter


...

Sam said he thinks most improvements have been landed and this is basically
feature complete except I guess for the gcc-15 Changes page?

[Bug c++/117470] New: new expression invalid size handling

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

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

Bug ID: 117470
   Summary: new expression invalid size handling
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

https://eel.is/c++draft/expr.new#8.6 says that for invalid sizes ::operator
new{,[]}
shouldn't be called (at least when not constant evaluating it), but either
throw or result in nullptr.
Now, for -fexceptions and new int[s] for VARYING size_t s we call
__cxa_throw_bad_array_new_length which supposedly throws the right exception
(haven't tested) if there is overflow or size too large, which looks good, but
for
new (std::nothrow) int[s]; my reading is that for -fexceptions it shouldn't
throw, but result in nullptr, but we still call
__cxa_throw_bad_array_new_length.
For -fno-exceptions, we call ::operator new{,[]} always, but for the
overflows/too large sizes with ~size_t(0) argument which supposedly should
throw or return NULL;
is that correct?  I mean, when the standard says ::operator new{,[]} shouldn't
be called...
Also from the POV of the allocation DCE, calling ::operator new* when the
standard says it shouldn't be called looks problematic, because then the
optimization can happily remove the ::operator new*/::operator delete* pair.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #425 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #422)
> Created attachment 59550 [details]
> a trial patch for c#419
> 
> Looks a similar issue with c#404 but for the constant float load.  Tested
> devel/sh-lra branch with c/c++ testsuite.

I can confirm that this patch fixes the ICE reported in comment #419.

[Bug c/117469] returns_twice on defined functions

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
So if the tail-call uses [[musttail]] the alternative 3 should be "fine"?

[Bug fortran/109345] [12/13/14/15 Regression] class(*) variable that is a string array is not handled correctly

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Created attachment 59551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59551&action=edit
"Fix" for this PR

This patch shows where the problem is. Scalarised array references use the
string length directly, whereas for some reason explicit array references use
the span and this not being set correctly.

.__tmp_CHARACTER_0_1 = var->_len; // Sets it to KIND
D.5013 = ubound.22;
parm.32.span = var->_vptr->_size;
parm.32.dtype = {.elem_len=8, .version=0, .rank=1, .type=10};
D.5020 = stride.23;
parm.32.dim[0].lbound = 1;
parm.32.dim[0].ubound = D.5013;
parm.32.dim[0].stride = NON_LVALUE_EXPR ;
parm.32.data = (void *) &(*var.0)[0];
parm.32.offset = -NON_LVALUE_EXPR ;
__tmp_CHARACTER_0_1 = parm.32;
__tmp_CHARACTER_0_1.dtype = {.elem_len=(unsigned long)
.__tmp_CHARACTER_0_1, .version=0, .rank=1, .type=6};
__tmp_CHARACTER_0_1.span = .__tmp_CHARACTER_0_1; // Effect of the
fix
{
  struct __st_parameter_dt dt_parm.27;

This will not be correct if the KIND of the unlimited polymorphic payload is 4.
Easily fixed. I will attend to it tonight.

Paul

[Bug target/117447] ICE in BPF GCC-trunk segmentation fault

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
(In reply to Yuchang Su from comment #0)

Did you hit this organically or are you fuzzing? If you're fuzzing either BPF
or just the CTF/BTF formats in general, please focus on C with `-gctf` or
`-gbtf` for now, as that'll have more interesting results.

[Bug fortran/117455] ld warning about executable stack, follows from PR 117434

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

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

--- Comment #6 from Jerry DeLisle  ---
Info:

-ftrampoline-impl=[stack|heap]

By default, trampolines are generated on stack. However, certain platforms
(such as the Apple M1) do not permit an executable stack. Compiling with
-ftrampoline-impl=heap generate calls to __gcc_nested_func_ptr_created and
__gcc_nested_func_ptr_deleted in order to allocate and deallocate trampoline
space on the executable heap. These functions are implemented in libgcc, and
will only be provided on specific targets: x86_64 Darwin, x86_64 and aarch64
Linux. PLEASE NOTE: Heap trampolines are not guaranteed to be correctly
deallocated if you setjmp, instantiate nested functions, and then longjmp back
to a state prior to having allocated those nested functions.

Is there a security issue? Above my pay range to answer.

Should this just be the gfortran default where applicable?

$ gfc test1.f90 
/usr/bin/ld: warning: /tmp/ccOTgxKq.o: requires executable stack (because the
.note.GNU-stack section is executable)
$ gfc -ftrampoline-impl=heap test1.f90 
$

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #421 from Kazumoto Kojima  ---
Created attachment 59549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59549&action=edit
a reduced test case for c#419

with "-m4 -mlra -O2 -std=c17 -fPIC  -fno-math-errno -fno-signed-zeros
-fno-tree-vectorize"

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #422 from Kazumoto Kojima  ---
Created attachment 59550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59550&action=edit
a trial patch for c#419

Looks a similar issue with c#404 but for the constant float load.  Tested
devel/sh-lra branch with c/c++ testsuite.

For personal reasons, I am no longer able to help as much as I used to. 
Fortunately, with the efforts made by Oleg and the help by the experts, I think
SH is now in a not so bad shape with LRA, even many problems remain.  Thanks
for your helps.

[Bug tree-optimization/112376] [14/15 Regression] gcc.dg/tree-ssa/ssa-dom-thread-7.c missed threading in aarch64 case

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667586.html

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

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Bug ID: 117474
   Summary: Excessive memory usage during parser stage in
interface blocks with types having type-bound
procedures
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

After addition of init() methods it was noticed that certain scientific model
sources started to require lots of memory to compile.

Derived type by itself is relatively small.
type phys_base_state_type
  real, pointer :: p1  (:,:,:) => null ()
  ! 
contains
  procedure :: init => phys_base_state_type_init
end type

However with addition of type-bound procedures (that take really big type
arguments) blows up both produced module size and memory requirements during
parsing of interface blocks that make use of this type.

$ cat phys_base_state_type_mod.mod | wc -c
2951559
$ zcat phys_base_state_type_mod.mod | wc -c
92422176


Simplified stripped case with 60 interface blocks and no executable code (any
bigger module will do):
$ cat test.f90
subroutine foo
  interface; subroutine foo_part01
use phys_base_state_type_mod, only : phys_base_state_type
  end subroutine; end interface
! 
  interface; subroutine foo_part60
use phys_base_state_type_mod, only : phys_base_state_type
  end subroutine; end interface
end subroutine foo

$ /usr/bin/time -v gfortran -I. -c test.f90 -ftime-report 2>&1 | grep -E
"(Maximum|wall|global)"
Time variable   usr   sys  wall
  GGC
 parser (global): 144.04 ( 99%)  17.05 (100%) 161.21 ( 99%)
   87M (100%)
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:44.02
Maximum resident set size (kbytes): 41411832

Parsing only a single interface block requires just:
Maximum resident set size (kbytes): 824424

Memory requirements grow linearly with every additional interface block present
in the source code.
It is hard to come up with reasonably small reproducer, since types passed to
INIT() methods have huge nesting of other types with their own type-bound
procedures.

It seems that the phys_base_state_type sym tree is created and populated for
every interface block separately without caching, thus increasing memory
requirements during the parsing stage.
Moreover it should be possible to skip populating type-bound procedure tree
nodes inside the interface blocks, other that they exist.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #423 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #422)
> Created attachment 59550 [details]
> a trial patch for c#419
> 
> Looks a similar issue with c#404 but for the constant float load.  Tested
> devel/sh-lra branch with c/c++ testsuite.

Thanks so much for your help and expertise!

> For personal reasons, I am no longer able to help as much as I used to. 
> Fortunately, with the efforts made by Oleg and the help by the experts, I
> think SH is now in a not so bad shape with LRA, even many problems remain. 
> Thanks for your helps.

If I may ask one last question, could you give advise on this glibc bug that
affects SH?

> https://sourceware.org/bugzilla/show_bug.cgi?id=27543

There is a suggested patch to fix it. Maybe you could briefly comment on it?

Again, thanks a lot for all your help!

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

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Rimvydas (RJ)  ---
It seams there are no major memory leaks.

$ valgrind --leak-check=full /usr/lib64/gcc/x86_64-suse-linux/14/f951 -I.
test.f90
...
==118405== 1,234,200 bytes in 4,675 blocks are definitely lost in loss record
7,382 of 7,384
==118405==at 0x484EA2F: calloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==118405==by 0x1B90FFE: UnknownInlinedFun (xmalloc.c:164)
==118405==by 0x1B90FFE: gfc_copy_array_spec(gfc_array_spec*) (array.cc:955)
==118405==by 0x1C8F2F4: resolve_component(gfc_component*, gfc_symbol*)
(resolve.cc:15439)
==118405==by 0x1C9036A: resolve_fl_derived0(gfc_symbol*) (resolve.cc:15849)
==118405==by 0x1C912D6: resolve_fl_derived(gfc_symbol*) (resolve.cc:15981)
==118405==by 0x1C8BA77: resolve_symbol(gfc_symbol*) (resolve.cc:16379)
==118405==by 0x1CA91F2: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) [clone .lto_priv.0] (symbol.cc:4338)
==118405==by 0x1C8A531: UnknownInlinedFun (symbol.cc:4363)
==118405==by 0x1C8A531: resolve_types(gfc_namespace*) (resolve.cc:18341)
==118405==by 0x1C8B1C9: gfc_resolve(gfc_namespace*) [clone .part.0]
(resolve.cc:18461)
==118405==by 0x1C8E541: resolve_symbol(gfc_symbol*) (resolve.cc:17016)
==118405==by 0x1CA91F2: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) [clone .lto_priv.0] (symbol.cc:4338)
==118405==by 0x1C8A531: UnknownInlinedFun (symbol.cc:4363)
==118405==by 0x1C8A531: resolve_types(gfc_namespace*) (resolve.cc:18341)
==118405==
==118405== 6,209,952 bytes in 27,723 blocks are definitely lost in loss record
7,383 of 7,384
==118405==at 0x484EA2F: calloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==118405==by 0x1BB5E8F: UnknownInlinedFun (xmalloc.c:164)
==118405==by 0x1BB5E8F: UnknownInlinedFun (expr.cc:49)
==118405==by 0x1BB5E8F: gfc_lval_expr_from_sym(gfc_symbol*) (expr.cc:5301)
==118405==by 0x1BA9767: generate_finalization_wrapper(gfc_symbol*,
gfc_namespace*, char const*, gfc_component*) (class.cc:2343)
==118405==by 0x1BA29B1: gfc_find_derived_vtab(gfc_symbol*) (class.cc:2672)
==118405==by 0x1C79137: gfc_resolve_finalizers(gfc_symbol*, bool*)
(resolve.cc:14523)
==118405==by 0x1C912B8: resolve_fl_derived(gfc_symbol*) (resolve.cc:15956)
==118405==by 0x1C8BA77: resolve_symbol(gfc_symbol*) (resolve.cc:16379)
==118405==by 0x1CA91F2: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) [clone .lto_priv.0] (symbol.cc:4338)
==118405==by 0x1C8A531: UnknownInlinedFun (symbol.cc:4363)
==118405==by 0x1C8A531: resolve_types(gfc_namespace*) (resolve.cc:18341)
==118405==by 0x1C8B1C9: gfc_resolve(gfc_namespace*) [clone .part.0]
(resolve.cc:18461)
==118405==by 0x1C8E541: resolve_symbol(gfc_symbol*) (resolve.cc:17016)
==118405==by 0x1CA91F2: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) [clone .lto_priv.0] (symbol.cc:4338)
==118405==
==118405== LEAK SUMMARY:
==118405==definitely lost: 171,216,496 bytes in 188,808 blocks
==118405==indirectly lost: 376,294,672 bytes in 1,159,513 blocks
==118405==  possibly lost: 24,832 bytes in 59 blocks
==118405==still reachable: 38,215,755 bytes in 22,899 blocks
==118405== suppressed: 0 bytes in 0 blocks

[Bug c++/61105] [constexpr] poor diagnostic for new-expression in constant expression

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

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|[constexpr] accepts-invalid |[constexpr] poor diagnostic
   |with new-expression in  |for new-expression in
   |constant expression |constant expression
 CC||jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill  ---
so yes, the accepts-invalid for comment #6 was fixed in GCC 12, but the
diagnostic isn't very helpful; the conversion from void* is implicit, not
written by the user.  It would be more useful to point out the placement new.

[Bug bootstrap/117471] New: bootstrap error after r15-4985-g5c9de3df854768

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

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

Bug ID: 117471
   Summary: bootstrap error after r15-4985-g5c9de3df854768
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:5c9de3df8547682bfb3d484d7d28a27776bf979c, r15-4985-g5c9de3df854768 

make[3]: Entering directory
'/home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc'
/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/xg++
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/bin/
-nostdinc++
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++
-L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fno-checking -gtoggle -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror  -DHAVE_CONFIG_H -fno-PIE
-I. -I. -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/.
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../include 
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcpp/include
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcody
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gmp
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gmp
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./mpfr/src
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpfr/src
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpc/src 
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libbacktrace
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./isl/include
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/isl/include  -o omp-general.o -MT
omp-general.o -MMD -MP -MF ./.deps/omp-general.TPo
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/omp-general.cc
In file included from
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/coretypes.h:497,
 from
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/omp-general.cc:25:
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/poly-int.h: In instantiation of
'typename if_nonpoly::type maybe_lt(const poly_int&, const Cb&)
[with unsigned int N = 1; Ca = long unsigned int; Cb = int; typename
if_nonpoly::type = bool]':
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/poly-int.h:1440:7:   required from
'poly_int::type, Cb>::type>
ordered_max(const Ca&, const poly_int&) [with unsigned int N = 1; Ca =
int; Cb = long unsigned int; typename poly_result::type, Cb>::type = long unsigned int; typename
if_nonpoly::type = int]'
 1342 | #define maybe_gt(A, B) maybe_lt (B, A)
  |~^~
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/omp-general.cc:1008:25:   required
from here
 1008 | return ordered_max (64, omp_max_vf (false));
  |^~~~
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/poly-int.h:1317:22: error:
comparison of integer expressions of different signedness: 'const long unsigned
int' and 'const int' [-Werror=sign-compare]
 1317 |   return a.coeffs[0] < b;
  |  ^~~
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/poly-int.h: In instantiation of
'typename if_nonpoly::type maybe_lt(const Ca&, const poly_int&) [with unsigned int N = 1; Ca = int; Cb = long unsigned int; typename
if_nonpoly::type = bool]':
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/poly-int.h:1445:2:   required from
'poly_int::type, Cb>::type>
ordered_max(const Ca&, const poly_int&) [with unsigned int N = 1; Ca =
int; Cb = long unsigned int; typename poly_result::type, Cb>::type = long unsigned int; typename
if_nonpoly::type = int]'
 1342 | #define maybe_gt(A, B) maybe_lt (B, A)
  |~^~
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/omp-general.cc:1008:25:   required
from here
 1008 | return ordered_max (64, omp_max_vf (false));
  |   

[Bug bootstrap/117471] bootstrap error after r15-4985-g5c9de3df854768

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-06
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |15.0

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667829.html

[Bug bootstrap/117471] bootstrap error after r15-4985-g5c9de3df854768

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Fixed:
https://gcc.gnu.org/pipermail/gcc-cvs/2024-November/412010.html

[Bug rtl-optimization/112398] Suboptimal code generation for xor pattern on subreg

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:69bd93c167fefbdff0cb88614275358b7a2b2941

commit r15-4991-g69bd93c167fefbdff0cb88614275358b7a2b2941
Author: Alexey Merzlyakov 
Date:   Wed Nov 6 14:39:30 2024 -0700

[PATCH v2] RISC-V: zero_extend(not) -> xor optimization [PR112398]

This patch adds optimization of the following patterns:

  (zero_extend:M (subreg:N (not:O==M (X:Q==M ->
  (xor:M (zero_extend:M (subreg:N (X:M)), mask))
... where the mask is GET_MODE_MASK (N).

For the cases when X:M doesn't have any non-zero bits outside of mode N,
(zero_extend:M (subreg:N (X:M)) could be simplified to just (X:M)
and whole optimization will be:

  (zero_extend:M (subreg:N (not:M (X:M ->
  (xor:M (X:M, mask))

Patch targets to handle code patterns like:
  not   a0,a0
  andi  a0,a0,0xff
to be optimized to:
  xori  a0,a0,255

Change was locally tested for x86_64 and AArch64 (as most common)
and for RV-64 and MIPS-32 targets (as having an effect from this
optimization):
no regressions for all cases.

PR rtl-optimization/112398
gcc/ChangeLog:

* simplify-rtx.cc (simplify_context::simplify_unary_operation_1):
Simplify ZERO_EXTEND (SUBREG (NOT X)) to XOR (X,
GET_MODE_MASK(SUBREG))
when X doesn't have any non-zero bits outside of SUBREG mode.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr112398.c: New test.

Signed-off-by: Alexey Merzlyakov 

[Bug target/117304] ICE: in emit_move_insn, at expr.cc:4633 with -mavx10.1 and __builtin_ia32_cvtudq2ps512_mask()

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #7 from Hongtao Liu  ---
Fixed everywhere.

[Bug ipa/117432] [12/13/14/15 Regression] IPA ICF disregards types of variadic arguments since r10-4643-ga37f58f506e436

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

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

--- Comment #7 from Jan Hubicka  ---
Hash needs to be stable for LTO streaming which affects types.  But at least we
ought to compare types when we are comparing bodies in
func_checker::compare_gimple_call.  I guess for non-varadic calls this happens
since both calls must have same signature. 

This untested patch may fix it
diff --git a/gcc/ipa-icf-gimple.cc b/gcc/ipa-icf-gimple.cc
index 31f6cdbda06..ef9e3ea3164 100644
--- a/gcc/ipa-icf-gimple.cc
+++ b/gcc/ipa-icf-gimple.cc
@@ -746,6 +746,8 @@ func_checker::compare_gimple_call (gcall *s1, gcall *s2)

   if (!compare_operand (t1, t2, get_operand_access_type (&map, t1)))
return return_false_with_msg ("GIMPLE call operands are different");
+  if (!types_compatible_p (TREE_TYPE (t1), TREE_TYPE (t2))
+   return return_false_with_msg ("GIMPLE call operand types are
different");
 }

   /* Return value checking.  */

I wonder if it won't cause us to give up too often, perhaps we could do that
only for variadic calls and calls with no prototype or so.

[Bug c++/117472] pack of function parameters without a name

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Interesting clang 19+ gives a warning:

:2:8: warning: pack indexing is a C++2c extension [-Wc++26-extensions]
2 | void f(T...[1]);
  |^

Which is wrong in a way but that is because it is just incompatible between
C++26 and C++23-.

[Bug c++/117472] pack of function parameters without a name

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/115222

--- Comment #2 from Andrew Pinski  ---
Submitted to clang since they now interrupt it incorrectly for -std=c++11 (to
-std=c++23) too.

[Bug rtl-optimization/112398] Suboptimal code generation for xor pattern on subreg

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

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

--- Comment #8 from Jeffrey A. Law  ---
So Alexey's patch helps the first case, generating the more efficient lbu+xori
sequence.

I suspect it's not helping the 2nd case because the constant is going to be out
of range.  Given the 2nd case also suffers from a lack of HI->DI zero
extension, there is some budget to improve that code.  If someone wanted to
tackle that, be my guest.  But be aware that with Zbb enabled the code as it
stands is probably optimal.

Hints for anyone wanting to tackle the second testcase.  You'll need a
define_insn_and_split for this construct:

(set (reg:DI 141)
(xor:DI (reg:DI 140)
(const_int 65535 [0x])))

It has to be a define_insn_and_split because it would be a 2->2 split which
isn't generally profitable.  It would need to be conditional on !Zbb and only
apply before register allocation.


The 3rd case can't be optimized in this way because the result of the NOT is
used as a source operand in multiple instructions.

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>It works with clang 17.0.6:

It is rejected for me with both libstdc++ and libc++ with clang with
-std=c++20:

:14:3: error: call to implicitly-deleted default constructor of 'U'
   14 | U obj;
  |   ^
:11:5: note: default constructor of 'U' is implicitly deleted because
variant field 's' has a non-trivial default constructor
   11 |   S s;
  | ^

https://godbolt.org/z/o7fnP8cjM

Are you sure you are testing the correct thing with clang?

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This was p0883r2 :
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0883r2.pdf

Which was the change in C++20.

GCC is correct here.

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---
 Ever confirmed|1   |0

--- Comment #3 from Andrew Pinski  ---
Doing this:
union U {
  S s{};
};

Works.


So the problem is the testcase provided is invalid code but here is a testcase
which works with clang but fails with GCC:
```
#include 

typedef std::atomic_int Atomic_Int;

struct S {
  Atomic_Int v;
};

union U {
  int t = 0;
  S s;
};

U obj;
```