[Bug libgcc/31180] #if __cplusplus should be #ifdef in libgcc/unwind-pe.h

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-02
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Andrew Pinski  ---
I will handle this for GCC 15. It is an obvious patch but I don't want to do it
this close to the release of GCC 14.

[Bug tree-optimization/114555] New: ICE: definition in block 14 does not dominate use in block 15 at -O and above with _BitInt() bitfield

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114555
   Summary: ICE: definition in block 14 does not dominate use in
block 15 at -O and above with _BitInt() bitfield
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
testcase.c: In function 'foo':
testcase.c:10:1: error: definition in block 14 does not dominate use in block
15
   10 | foo (void)
  | ^~~
for SSA_NAME: _15 in statement:
_14 = PHI <_13(2), _15(15)>
PHI argument
_15
for PHI node
_14 = PHI <_13(2), _15(15)>
during GIMPLE pass: bitintlower
testcase.c:10:1: internal compiler error: verify_ssa failed
0x17913a0 verify_ssa(bool, bool)
/repo/gcc-trunk/gcc/tree-ssa.cc:1203
0x13d19e5 execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2095
0x13d1e4e execute_todo
/repo/gcc-trunk/gcc/passes.cc:2142
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9731-20240331183750-gb313baba57f-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9731-20240331183750-gb313baba57f-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240331 (experimental) (GCC)

[Bug middle-end/114509] [11/12/13/14 Regression] an infinite loop or ICE with openmp after errors in some cases

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug tree-optimization/114511] [11/12/13/14 Regression] Missed optimization: x = -y; x = c + x + y; ==> x=c;

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.5

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P2  |P1
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-02
 Status|UNCONFIRMED |NEW

--- Comment #6 from Richard Biener  ---
Note I think given the offending rev fixed a very old bug we should eventually
revert the fix and rework it during next stage1.  This was at least
unexpectedly big fallout AFAIU.

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

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

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

--- Comment #10 from Kewen Lin  ---
Created attachment 57844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57844&action=edit
patch changing the current implementation

Considering the current implementation is not useful at all for both kernel and
userspace uses, I'm inclined to change the current implementation instead of
introducing another option, but updating the documentation to emphasize the
NOPs may not be consecutive for this case.

[Bug testsuite/114518] [14 regression] gcc.target/powerpc/combine-2-2.c fails after r14-9692-g839bc42772ba7a

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Priority|P3  |P1

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

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

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

--- Comment #11 from Kewen Lin  ---
(In reply to Giuliano Belinassi from comment #9)
> Yes, this is for userspace livepatching.
> 
> Assume the following example:
> https://godbolt.org/z/b9M8nMbo1
> 
> As one can see, the sequence of 14 nops are generated after the global
> function entry point. In such way we can't use the this space to place a
> trampoline to the new function. We need this sequence of nops to be placed
> *before* the global function entry point.
> 

Hi Giuliano, thanks for the inputs!

[Bug rtl-optimization/114522] [14 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm
   Priority|P2  |P1

[Bug rtl-optimization/114556] New: weird loop unrolling when there's attribute aligned in side the loop

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

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

Bug ID: 114556
   Summary: weird loop unrolling when there's attribute aligned in
side the loop
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liuhongt at gcc dot gnu.org
  Target Milestone: ---

v32qi
z (void* pa, void* pb, void* pc)
{
v32qi __attribute__((aligned(64))) a;
v32qi __attribute__((aligned(64))) b;
v32qi __attribute__((aligned(64))) c;
__builtin_memcpy (&a, pa, sizeof (a));
__builtin_memcpy (&b, pb, sizeof (a));
__builtin_memcpy (&c, pc, sizeof (a));
#pragma GCC unroll 8
for (int i = 0; i != 2048; i++)
  a += b;
  return a;
}

-O2 -mavx2, we have 

z:
vmovdqu (%rsi), %ymm1
vpaddb  (%rdi), %ymm1, %ymm0
movl$2041, %eax
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
jmp .L2
.L3:
vpaddb  %ymm0, %ymm1, %ymm0
subl$8, %eax
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
vpaddb  %ymm0, %ymm1, %ymm0
.L2:
vpaddb  %ymm0, %ymm1, %ymm0
cmpl$1, %eax
jne .L3
ret

But shouldn't it better with

z:
vmovdqu (%rsi), %ymm1
vmovdqu (%rdi), %ymm0
movl$2048, %eax
.L2:
vpaddb  %ymm1, %ymm0, %ymm0
vpaddb  %ymm1, %ymm0, %ymm0
vpaddb  %ymm1, %ymm0, %ymm0
vpaddb  %ymm1, %ymm0, %ymm0
vpaddb  %ymm1, %ymm0, %ymm0
vpaddb  %ymm1, %ymm0, %ymm0
vpaddb  %ymm1, %ymm0, %ymm0
vpaddb  %ymm1, %ymm0, %ymm0
subl$8, %eax
jne .L2
ret

[Bug c++/114525] [11/12/13/14 Regression] Incorrect code generated when setting a value through a pointer-to-member on a ternary returning an object reference

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #4 from Kewen Lin  ---
(In reply to Andrew Pinski from comment #3)
> Found it:
>   /* In GIMPLE the type of the MEM_REF specifies the alignment.  The
> required alignment (power) is 4 bytes regardless of data type.  */
>   tree align_ltype = build_aligned_type (lhs_type, 4);
> 
> That should be 4*8 instead of just 4.
> 
> There are 2 build_aligned_type in rs6000-builtins.cc which uses the wrong
> alignment; thinking it was the alignment argument was bytes rather than bits.
> 
> Introduced by r9-2375-g3f7a77cd20d07c which means this is a regression.

Hi Andrew, thanks for digging into this!  William has not worked on GCC project
any more, will you make a patch for this?

[Bug tree-optimization/114527] [meta-bug] missed sccp (final value) optimizations

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

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

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

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

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

--- Comment #21 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Thomas Neumann
:

https://gcc.gnu.org/g:11f37868bb5812c4f0ac023909f5421595f68a43

commit r13-8555-g11f37868bb5812c4f0ac023909f5421595f68a43
Author: Thomas Neumann 
Date:   Mon Mar 11 14:35:20 2024 +0100

handle unwind tables that are embedded within unwinding code [PR111731]

Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731

The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup structure. That data structure
assumes that is consists of non-overlappping intervals. This
becomes a problem if the unwinding table is embedded within the
code itself, as now the intervals do overlap.

To fix this problem we now keep the unwind tables in a separate
b-tree, which prevents the overlap.

libgcc/ChangeLog:
PR libgcc/111731
* unwind-dw2-fde.c: Split unwind ranges if they contain the
unwind table.

[Bug ipa/113907] [11/12/13/14 regression] ICU miscompiled on x86 since r14-5109-ga291237b628f41

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #70 from Jan Hubicka  ---
Hello,
over easter I did some analysis of the cases where ICF is now disabled
due to jump function miscompare.  Most common case (seen also on GCC) is
the situation where function is originally static inline and in some
units its callee is known which enables us to propagate return value
range.  It happens on wide int implementaiton but it is not that
importnat.

Other case is when function has address taken of local label and
ICF two functions taking address of local label and passing it to a
calle (maybe we should not but C standard says nothing).

I tought there is also case where jump function has other function local
stuff, but that does not happen since we avoid putting them to
jumptables (to avoid need to stream function blocal BLOCKS).

Last case is that the function takes as parameter an address of static
symbol that can be merged.  We currently don't do that since we miss any
logic tracking whether value address is eventually used to compare.  So

I think for release branchs and trunk Martin's patch is fine. For next
stage1 we will need to work on using icf's compare_op in the ipa-prop
code and also add merging of value ranges.

Honza

[Bug modula2/114529] profiledbootstrap fails to build and m2 causes odr violations during build

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

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

--- Comment #2 from Arsen Arsenović  ---
full build.log also:
https://dev.gentoo.org/~arsen/gcc-14.0.1_pre20240331-Werror-odr-build.log.gz

[Bug tree-optimization/114557] New: ehcleanup cleanup_empty_eh_merge_phis eats a lot of memory

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

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

Bug ID: 114557
   Summary: ehcleanup cleanup_empty_eh_merge_phis eats a lot of
memory
   Product: gcc
   Version: 14.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: ---

For the testcase in PR114480 we end up redirecting a lot of edges into
very high in-degree blocks.

(gdb) p new_bb->preds.m_vecpfx
$3 = {m_alloc = 4095, m_using_auto_storage = 0, m_num = 3911}

the way the edge redirection works it will resize the target PHI nodes
a lot of time, leaving the old PHIs as garbage until the next GC collection.

For the testcase this piles up to 16GB of garbage.

[Bug c/114558] New: GCC 13.2.1 encountered a segmentation fault error when compiling PyTorch.

[wencan at live dot cn via Gcc-bugs]

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

Bug ID: 114558
   Summary: GCC 13.2.1 encountered a segmentation fault error when
compiling PyTorch.
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wencan at live dot cn
  Target Milestone: ---

I encountered a compilation error when compiling PyTorch.
GCC version: (GCC) 13.2.1 20240316 (Red Hat 13.2.1-7)
pytorch version: commit dd8a24b

code: 
extern "C" status_t DNNL_API dnnl_memory_desc_set_data_type(
memory_desc_t *memory_desc, data_type_t data_type) {
if (any_null(memory_desc)) return invalid_arguments;
memory_desc->data_type = data_type;
return success;
} // this line!

I downgraded gcc to 13.2.1 2023091 (Red Hat 13.2.1-3), and the issue no longer
occurred.
more info: https://github.com/pytorch/pytorch/issues/123091

[Bug middle-end/114559] New: After function inlining some optimizations missing

[antoshkka at gmail dot com via Gcc-bugs]

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

Bug ID: 114559
   Summary: After function inlining some optimizations missing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

template 
int AtomicUpdate(int& atomic, Func updater) {
  int old_value = atomic;
  while (true) {
const int new_value = updater(int{old_value});
if (old_value == new_value) return old_value;
if (__atomic_compare_exchange_n(&atomic, &old_value, new_value, 1, 5, 5))
return new_value;
  }
}

int AtomicMin(int& atomic, int value) {
  return AtomicUpdate(atomic, [value](int old_value) {
return value < old_value ? value : old_value;
  });
}


With -O2 GCC produces the assembly:


AtomicMin(int&, int):
mov eax, DWORD PTR [rdi]
.L3:
cmp esi, eax
mov edx, eax
cmovle  edx, esi
jge .L4
lock cmpxchgDWORD PTR [rdi], edx
jne .L3
.L1:
mov eax, edx
ret
.L4:
mov edx, eax
jmp .L1


However, a more optimal assembly is possible:


AtomicMin(int&, int):# @AtomicMin(int&, int)
mov eax, dword ptr [rdi]
.LBB0_1:# =>This Inner Loop Header: Depth=1
cmp eax, esi
jle .LBB0_4
lockcmpxchg dword ptr [rdi], esi
jne .LBB0_1
mov eax, esi
.LBB0_4:
ret


Note that manual inlining of the lambda improves the codegen:

int AtomicMin(int& atomic, int value) {
  int old_value = atomic;
  while (true) {
const int new_value = (value < old_value ? value : old_value);
if (old_value == new_value) return old_value;
if (__atomic_compare_exchange_n(&atomic, &old_value, new_value, 1, 5, 5))
return new_value;
  }
}

Results in

AtomicMin(int&, int):
mov eax, DWORD PTR [rdi]
.L3:
cmp esi, eax
mov edx, eax
cmovle  edx, esi
jge .L1
lock cmpxchgDWORD PTR [rdi], edx
jne .L3
.L1:
mov eax, edx
ret


Godbolt playground: https://godbolt.org/z/G6YEGb15q

[Bug c++/114560] New: Compilation error when using _mm512_maskz_expandloadu_epi16 with only -mavx512vbmi2

[meirav.grimberg at redis dot com via Gcc-bugs]

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

Bug ID: 114560
   Summary: Compilation error when using
_mm512_maskz_expandloadu_epi16 with only -mavx512vbmi2
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meirav.grimberg at redis dot com
  Target Milestone: ---

Hello,
I'm using gcc 11.4. The problem also exits in gcc13.

The following code fails to compile:

#include 

int main(void) {
unsigned short vec[16];
for (size_t i =0; i < 16; i++) {
vec[i] = 2;
}
__mmask32 mask = 0x;
__m512i bf16_to_fp32 = _mm512_maskz_expandloadu_epi16(mask, vec);
return 0;
}
```

g++ test.cpp -o test -mavx512vbmi2; 

In file included from /usr/lib/gcc/x86_64-linux-gnu/11/include/immintrin.h:81,
 from test.cpp:1:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx512vbmi2intrin.h: In function ‘int
main()’:
/usr/lib/gcc/x86_64-linux-gnu/11/include/avx512vbmi2intrin.h:451:1: error:
inlining failed in call to ‘always_inline’ ‘__m512i
_mm512_maskz_expandloadu_epi16(__mmask32, const void*)’: target specific option
mismatch
  451 | _mm512_maskz_expandloadu_epi16 (__mmask32 __A, const void * __B)
  | ^~
test.cpp:9:58: note: called from here
9 | __m512i bf16_to_fp32 = _mm512_maskz_expandloadu_epi16(mask, vec);

According to Intel® Intrinsics Guide, only avx512vbmi2 flag is required to use
_mm512_maskz_expandloadu_epi16. 

However, when I add -mavx512bw flag to the compilation command, it works as
expected with no errors.
i notice that indeed, in avx512vbmi2intrin.h this function is located within
the section that requires both flags:

#if !defined(__AVX512VBMI2__) || !defined(__AVX512BW__)
#pragma GCC push_options
#pragma GCC target("avx512vbmi2,avx512bw")
#define __DISABLE_AVX512VBMI2BW__
#endif /* __AVX512VBMI2BW__ */

...

extern __inline __m512i
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
_mm512_maskz_expand_epi16 (__mmask32 __A, __m512i __B)
{
  return (__m512i) __builtin_ia32_expandhi512_maskz ((__v32hi) __B,
(__v32hi) _mm512_setzero_si512 (), (__mmask32) __A);
}

...
#ifdef __DISABLE_AVX512VBMI2BW__
#undef __DISABLE_AVX512VBMI2BW__

#pragma GCC pop_options
#endif /* __DISABLE_AVX512VBMI2BW__ */


In addition, i tried to compile this code with clang14 and intel c++ compiler,
using only the -mavx512vbmi2 flag, and both succeeded.

Thank you.

[Bug tree-optimization/114557] ehcleanup cleanup_empty_eh_merge_phis eats a lot of memory

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
The main reason is that the "large" PHI nodes are never re-used for large
allocations and that the GTY ((deletable (""))) for the free_phinodes
array doesn't seem to be effective for this testcase.

diff --git a/gcc/tree-phinodes.cc b/gcc/tree-phinodes.cc
index ddd731323e1..44dc345a3b7 100644
--- a/gcc/tree-phinodes.cc
+++ b/gcc/tree-phinodes.cc
@@ -223,6 +223,12 @@ release_phi_node (gimple *phi)
   delink_imm_use (imm);
 }

+  if (len - 2 >= NUM_BUCKETS - 2)
+{
+  ggc_free (phi);
+  return;
+}
+
   bucket = len > NUM_BUCKETS - 1 ? NUM_BUCKETS - 1 : len;
   bucket -= 2;
   vec_safe_push (free_phinodes[bucket], phi);

cuts memory usage to 10GB.  The free_phinodes buckets are also badly
designed - we always allocate power-of-two overall PHI node memory
through ideal_phi_node_len but have buckets for [2, ..., 10] actual
PHI nodes which likely makes us have exactly a single (maybe two)
free PHI node buckets ...

After ehcleanup (and with the above patch) we have

(gdb) p/r free_phinodes
$5 = {0x0, 0x0, 0x7668e000, 0x0, 0x0, 0x0, 0x0, 0x7ffe8b3df000}

so as I said.  Two slots are used only.

(gdb) p/r (free_phinodes)[2].m_vecpfx
$7 = {m_alloc = 524287, m_using_auto_storage = 0, m_num = 265598}
(gdb) p/r (free_phinodes)[7].m_vecpfx
$8 = {m_alloc = 65535, m_using_auto_storage = 0, m_num = 59610}

After the next collection the array is actually empty:

(gdb) p/r free_phinodes
$9 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}

but memory usage doesn't shrink, likely either due to fragmentation or
due to stale references.  Maybe the 'deleteable' only gets effective
upon next collection but we do not collect anymore after hitting 10GB,
likely because we no longer expand the heap (hitting this peak is the
bug anyway).  We do re-collect in final(), but that doesn't reduce the
memory.  We do have a lot of blocks and edges and thus PHIs.

[Bug c/114558] GCC 13.2.1 encountered a segmentation fault error when compiling PyTorch.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Please see https://gcc.gnu.org/bugs/ on what we need, in particular we need
full preprocessed source of the compilation unit (unless -flto is involved, in
that case even more than that) + g++ command line used to compile that.

[Bug c++/114561] New: Comma operator with forwarding reference to pointer raises invalid lvalue required error

[Liam.Jackson--- via Gcc-bugs]

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

Bug ID: 114561
   Summary: Comma operator with forwarding reference to pointer
raises invalid lvalue required error
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liam.jack...@qa-systems.com
  Target Milestone: ---

Created attachment 57845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57845&action=edit
Source to reproduce bug

Compiling the attached source (cut down example) with `g++ -c fail.cpp` raises
the following error:

fail.cpp: In instantiation of ‘static T Create::create(U&&) [with U = void*
const&; T = MyClass]’:
fail.cpp:38:28:   required from here
fail.cpp:31:12: error: lvalue required as unary ‘&’ operand
   31 | return T( ( (beforeParam()), (forward(u)) ) );
  |^


This code is expected to compile correctly. There is no unary '&' operator in
use.

This seems to be caused by a combination of using the comma operator and
calling `create` with a pointer variable (using nullptr directly compiles, as
shown in the code comment).

[Bug c++/114562] New: ICE when trying to bind rvalue reference to lvalue with comma operator and forwarding reference to pointer

[Liam.Jackson--- via Gcc-bugs]

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

Bug ID: 114562
   Summary: ICE when trying to bind rvalue reference to lvalue
with comma operator and forwarding reference to
pointer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liam.jack...@qa-systems.com
  Target Milestone: ---

Created attachment 57846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57846&action=edit
Source to reproduce ice

Compiling the attached source would expect to raise an error such as 

error: cannot bind rvalue reference of type 'const void*&&' to lvalue of type
'void* const'

Instead the following ICE occurs:

: In instantiation of 'static T Create::create(U&&) [with U = void*
const&; T = MyClass]':
:34:28:   required from here
   34 | Create::create(MyClass::NONE);
  | ~~~^~~
:28:13: internal compiler error: in convert_like_internal, at
cp/call.cc:8879
   28 |  return T( ( (beforeParam()), (u) ) );
  | ^
0x266d8bc internal_error(char const*, ...)
???:0
0xa572eb fancy_abort(char const*, int, char const*)
???:0
0xa81334 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xa8265b build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xa8ff69 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
???:0
0xd33f73 build_functional_cast(unsigned int, tree_node*, tree_node*, int)
???:0
0xc92ed3 instantiate_decl(tree_node*, bool, bool)
???:0
0xcbc0ab instantiate_pending_templates(int)
???:0
0xb5a619 c_parse_final_cleanups()
???:0
0xdaf328 c_common_parse_file()
???:0


It may be possible to construct an example source which is expected to compile
successfully yet still triggers this ICE. This has not been explored.

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

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

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

--- Comment #9 from Chung-Ju Wu  ---
(In reply to Sam James from comment #1)
> One of the xz developers, Jia Tan, has kindly minimised it to not need
> BIND_NOW. I've adapted it a bit to cleanup flags and warnings.
> 

CVE-2024-3094

Jia Tan is the one who injected backdoor in xz-5.6.0 and xz-5.6.1, which may be
the cause of the segfaults. I'm wondering if we still need a workaround for
this issue...

[Bug middle-end/114563] New: ggc_internal_alloc is slow

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

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

Bug ID: 114563
   Summary: ggc_internal_alloc is slow
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We seem to have a single bucket of free objects we walk:

  /* Check the list of free pages for one we can use.  */
  for (pp = &G.free_pages, p = *pp; p; pp = &p->next, p = *pp) 
if (p->bytes == entry_size)
  break;

and if that list becomes large this is a very bad bottleneck.

[Bug middle-end/114563] ggc_internal_alloc is slow

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114480

--- Comment #1 from Richard Biener  ---
See PR114480 for a testcase which shows

Samples: 299K of event 'cycles', Event count (approx.): 338413178083
Overhead   Samples  Command  Shared Object   Symbol 
  23.16% 67756  cc1plus  cc1plus [.] ggc_internal_alloc

[Bug tree-optimization/114557] ehcleanup cleanup_empty_eh_merge_phis eats a lot of memory

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

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

--- Comment #2 from Richard Biener  ---
The free_phinodes buckets itself could better use the ->next chain of the
gimple stmts rather than a (re-allocated) GC vector.  Given the current
bucket structure a single chain for the 4-argument case might be good
enough.  Otherwise hooking into the GC special sizes array might be
worthwhile.

Note that ggc_free()ing all PHIs (and thus using the GC allocator freelist
which has its own issues) is a tiny bit faster than keeping the pool for at
least the testcase at hand.

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

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

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

--- Comment #10 from Sam James  ---
I'm aware, but there's a minimised test case attached here which shows this is
still somewhat of a problem by itself.

Either a better diagnostic is needed or to not instrument the resolver.

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

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

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

--- Comment #11 from Sam James  ---
(In reply to Sam James from comment #10)
> I'm aware, but there's a minimised test case attached here which shows this
> is still somewhat of a problem by itself.
> 
> Either a better diagnostic is needed or to not instrument the resolver.

s/better// (we don't emit any rn)

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 57847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57847&action=edit
gcc14-pr114462.patch

Untested fix.

[Bug c++/114564] New: Accessing template Base via template Derived fails

[benni.buch at gmail dot com via Gcc-bugs]

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

Bug ID: 114564
   Summary: Accessing template Base via template Derived fails
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

```cpp
template 
struct Base {};

template 
struct Derived: Base {
Derived(Derived::Base obj);
};
```

Accessing Base via Derived works with clang and MSVC, but not with GCC.

Live:

- https://godbolt.org/z/Wv3EK3e71

[Bug ipa/109817] internal error in ICF pass on Ada interfaces

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
That check was added to verify that we do not lose the thunk annotations.  Now
when datastructure is stable, i think we can simply drop it, if that makes Ada
to work.

[Bug ipa/109817] internal error in ICF pass on Ada interfaces

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

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

--- Comment #6 from Eric Botcazou  ---
It's not visible in release builds and testing shows that it's a very rare
situation in practice, so no real need IMO.

[Bug c++/114561] Comma operator with forwarding reference to pointer raises invalid lvalue required error

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-02
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70822
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Clang and EDG accept the code.

[Bug c++/57573] [C++1y] bogus "taking address of temporary" error

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=60409
  Known to work|4.10.0  |5.0

--- Comment #6 from Jonathan Wakely  ---
For the record, it started to fail with:

commit 10c6dc8e3932d33c8e47e6706885d2412b29c069 [r0-122521-g10c6dc8e3932d3]
Author: Jason Merrill
Date:   Fri Mar 29 19:51:36 2013

cp-tree.h (AUTO_IS_DECLTYPE): New.

N3582
* cp-tree.h (AUTO_IS_DECLTYPE): New.
* parser.c (cp_parser_decltype): Handle decltype(auto).
(cp_parser_type_id_1): Allow auto without a late-specified
return in C++1y.
(cp_parser_primary_expression): Use the return value of
finish_parenthesized_expr.
(cp_parser_transaction_expression): Likewise.
* semantics.c (force_paren_expr): New.
(finish_parenthesized_expr): Use it.
* call.c (build_conditional_expr_1): Likewise.
* pt.c (do_auto_deduction): Handle decltype(auto).
(tsubst_copy): Handle PAREN_EXPR.
(tsubst_copy_and_build): Likewise.
* error.c (dump_expr): Handle PAREN_EXPR.
* cxx-pretty-print.c (pp_cxx_expression): Likewise.
* mangle.c (write_expression): Ignore PAREN_EXPR.

* parser.c (cp_parser_decltype_expr): Split out...
(cp_parser_decltype): ...from here.

From-SVN: r197248

That commit also caused an ICE, and then this bug and the ICE were both fixed
by:

commit f9b381b8eb56252e302b88ea4fe89beffc33cf80 [r0-128726-gf9b381b8eb5625]
Author: Jason Merrill
Date:   Wed Mar 5 19:25:37 2014

re PR c++/60409 ([c++1y] ICE on valid with template function)

PR c++/60409
* semantics.c (force_paren_expr): Only add a PAREN_EXPR to a
dependent expression.

From-SVN: r208352

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.2.1
  Known to fail||13.2.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

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

[Bug target/114036] Test failure of gcov-14.c on darwin

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r14-9747-gad8e34eaa870608e2b07b4e7147e6ef2944bb8b5
Author: Iain Sandoe 
Date:   Sun Mar 31 11:27:53 2024 +0100

testsuite, Darwin: Allow for an undefined symbol [PR114036].

Darwin's linker defaults to requiring all symbols to be defined at
static link time (unless specifically noted or dynamic lookuo is
enabled).

For this test, we just need to note that the symbol is expected to
be undefined.

PR testsuite/114036

gcc/testsuite/ChangeLog:

* gcc.misc-tests/gcov-14.c: Allow for 'Foo' to be undefined
on Darwin link lines.

Signed-off-by: Iain Sandoe 

[Bug c++/114561] Comma operator with forwarding reference to pointer raises invalid lvalue required error

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

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

--- Comment #2 from Jonathan Wakely  ---
Reduced:

void* const NONE = nullptr; //Compiles

void beforeParam();

template
void create(U && u) noexcept {
const void* const& r = ( (void) beforeParam(), u );
}

void test_func() {
create(NONE);
}


comma.cc: In instantiation of ‘void create(U&&) [with U = void* const&]’:
comma.cc:11:11:   required from here
comma.cc:7:24: error: lvalue required as unary ‘&’ operand
7 | const void* const& r = ( (void) beforeParam(), u );
  |^


GCC has recurring problems with parentheses causing lvalue expressions to be
incorrectly treated as rvalues.

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ABI
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
The question is whether the caller misbehaves according to the ABI here? 
There's likely a known alignment present we could re-instantiate with a
__builtin_assume_aligned?

[Bug fortran/114535] [13/14 regression] ICE with elemental finalizer

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
   Priority|P3  |P4

[Bug testsuite/114034] Failure of tests gcov-dump-{1,2}.C

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:799a056cf804f433ce0050a5a6bf900f7a01ecb1

commit r14-9748-g799a056cf804f433ce0050a5a6bf900f7a01ecb1
Author: Iain Sandoe 
Date:   Sun Mar 31 11:22:58 2024 +0100

testsuite: Remove duplicate -lgcov [PR114034]

Duplicate library entries now cause linker warnings with newer linker
versions on Darwin which leads to these tests regressing.  The library
is already added by the test flags so there is no need to put an extra
one in the options.

PR testsuite/114034

gcc/testsuite/ChangeLog:

* g++.dg/gcov/gcov-dump-1.C: Remove extra -lgcov.
* g++.dg/gcov/gcov-dump-2.C: Likewise.

Signed-off-by: Iain Sandoe 

[Bug c++/114549] [11/12/13 Regression] GCC >= 10.1 selects the wrong overload of C++20 reversed operator== function

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|unknown |14.0
  Known to work||13.2.0

[Bug c++/114561] Comma operator with forwarding reference to pointer raises invalid lvalue required error

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

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

--- Comment #3 from Jonathan Wakely  ---
Further reduced:

void create(void* u) {
const void* const& r = ( (void)0, u );
}

void test_func() {
create(0);
}


The result of (0, u) is an lvalue of type void* which should then be converted
to a const void* prvalue, which is then bound to the reference.

[Bug middle-end/114552] [13/14 Regression] wrong code at -O1 and above on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |14.0
   Priority|P3  |P2

[Bug c++/114561] Comma operator with forwarding reference to pointer raises invalid lvalue required error

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> Further reduced:

Actually now that it's no longer a function template we don't even need to
instantiate it to trigger the error, so this is the minimal reproducer:

void create(void* u) {
const void* const& r = ( (void)0, u );
}

[Bug c++/114558] GCC 13.2.1 encountered a segmentation fault error when compiling PyTorch.

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-02

[Bug libstdc++/114553] Undefined symbol in directory_iterator move assignment operator with -Os

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/114553] Undefined symbol in directory_iterator move assignment operator with -Os

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Toni Lammi from comment #0)
> The issue does not seem to be present in trunk.

It seems to be a change in inlining decisions on trunk, because the swap symbol
still isn't exported from the shared lib. So the problem is probably latent on
trunk.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

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

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

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

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

commit r14-9751-g9a5e4aade2b847c5262577a1490ce6f3df9a9841
Author: Jakub Jelinek 
Date:   Tue Apr 2 13:40:27 2024 +0200

Fix up postboot dependencies [PR106472]

On Wed, Mar 13, 2024 at 10:13:37AM +0100, Jakub Jelinek wrote:
> While the first Makefile.tpl hunk looks obviously ok, the others look
> completely wrong to me.
> There is nothing special about libgo vs. libbacktrace/libatomic
> compared to any other target library which is not bootstrapped vs. any
> of its dependencies which are in the bootstrapped set.
> So, Makefile.tpl shouldn't hardcode such dependencies.

Here is my version of the fix.
The dependencies in the toplevel Makefile simply didn't take into account
that some target modules could be in a bootstrapped build built in some
configurations as bootstrap modules (typically as dependencies of other
target bootstrap modules), while in other configurations just as
dependencies of non-bootstrap target modules and so not built during the
bootstrap, but after it.
Makefile.tpl arranges for those postboot target module -> target module
dependencies to be emitted only inside of an @unless gcc-bootstrap block,
while for @if gcc-bootstrap it just emits
configure-target-whatever: stage_last
dependencies which ensure those postbootstrap target modules are only built
after everything that is bootstrapped has been.

Now, the libbacktrace/libatomic target modules have bootstrap=true
target_modules = { module= libbacktrace; bootstrap=true; };
target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };
because those modules are dependencies of libphobos target module, so
when d is included among bootstrapped languages, those are all bootstrapped
and everything works correctly.
While if d is not included, libphobos target module is disabled,
libbacktrace/libatomic target modules aren't bootstrapped, nothing during
bootstrap needs them, but post bootstrap libgo target module depends on
the libatomic and libbacktrace target modules, libgfortran target module
depends on the libbacktrace target module and libgm2 target module depends
on the libatomic target module, but those dependencies were emitted only
@unless gcc-bootstrap.  There is a similar theoretical problem for zlib
target module if GCJ would be ressurected, libphobos as bootstrap target
module depends on the zlib target module, but if d is not configured,
fastjar also depends on it.

The following patch arranges for the @if gcc-bootstrap case to emit also
target module -> target module dependencies, but conditionally on the
on dependency not being bootstrapped.

In the generated Makefile.in you can see what the Makefile.tpl change
produces and that it just adds extra dependencies which weren't there
before in the @if gcc-bootstrap case.

I've bootstrapped without this patch with
../configure --enable-languages=c,c++,go; make
on x86_64-linux (note, make -j2 or higher usually worked) which failed
as described in the PR, then with this patch with the same command which
built fine and the Makefile difference between the two builds being
diff -up obj40{a,b}/Makefile
--- obj40a/Makefile 2024-03-31 00:35:22.243791499 +0100
+++ obj40b/Makefile 2024-03-31 22:40:38.143299144 +0200
@@ -29376,6 +29376,14 @@ configure-bison: stage_last
 configure-flex: stage_last
 configure-m4: stage_last

+configure-target-fastjar: maybe-configure-target-zlib
+all-target-fastjar: maybe-all-target-zlib
+all-target-libgo: maybe-all-target-libbacktrace
+all-target-libgo: maybe-all-target-libatomic
+all-target-libgm2: maybe-all-target-libatomic
+configure-target-libgfortran: maybe-all-target-libbacktrace
+configure-target-libgo: maybe-all-target-libbacktrace
+

 # Dependencies for target modules on other target modules are
 # described by lang_env_dependencies; the defaults apply to anything

which I believe are exactly the extra dependencies we want.
Plus I've done normal x86_64-linux and i686-linux bootstraps/regtests
which in my case include
--enable-languages=default,ada,obj-c++,lto,go,d,rust,m2
for x86_64 and the same except ada for i686; those with my usual make -j32.
The Makefile difference in those builds vs. unpatched case
is just an extra empty line.

2024-04-02  Jakub Jelinek  

PR bootstrap/106472
* Makefile.tpl (make-postboot-target-dep): New lambda.
Use it to add --enable-bootstrap dependencies of target modules
on other target modules if the latter aren't bootstrapped.
* Makefile.in: Regenerate.

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

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

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

--- Comment #2 from Jakub Jelinek  ---
>From what I can see, glibc uses there the same thing as libquadmath does, so
why is it ok on the glibc side and not on the libquadmath side?

I mean
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf_fp.c;h=e75706f089bba3baabbcfb6bcf41514bad0a9dcb;hb=HEAD#l222
and
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf_fp.c;h=e75706f089bba3baabbcfb6bcf41514bad0a9dcb;hb=HEAD#l191

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

[schwab--- via Gcc-bugs]

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

--- Comment #3 from Andreas Schwab  ---
Is the stack properly aligned at this point?

[Bug target/114036] Test failure of gcov-14.c on darwin

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

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

--- Comment #5 from Iain Sandoe  ---
fixed on trunk, needed on open branches.

[Bug testsuite/114034] Failure of tests gcov-dump-{1,2}.C

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

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

--- Comment #4 from Iain Sandoe  ---
fixed on trunk, needed on open branches.

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

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

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

--- Comment #4 from Florian Weimer  ---
This looks like a glibc bug to me.

[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Mikael Morin
:

https://gcc.gnu.org/g:38dd703d368c9e60159e6f19cfc8303ad639b557

commit r12-10305-g38dd703d368c9e60159e6f19cfc8303ad639b557
Author: Mikael Morin 
Date:   Thu Mar 21 17:27:54 2024 +0100

fortran: Ignore use statements on error [PR107426]

This fixes an access to freed memory on the testcase from the PR.
The problem comes from an invalid subroutine statement in an interface,
which is ignored and causes the following statements forming the procedure
body to be rejected.  One of them use-associates the intrinsic
ISO_C_BINDING
module, which imports new symbols in a namespace that is freed at the time
the statement is rejected.  However, this creates dangling pointers as
ISO_C_BINDING is special and its import creates a reference to the imported
C_PTR symbol in the return type of the global intrinsic symbol for C_LOC
(see the function create_intrinsic_function).

This change saves and restores the list of use statements, so that rejected
use statements are removed before they have a chance to be applied to the
current namespace and create dangling pointers.

PR fortran/107426

gcc/fortran/ChangeLog:

* gfortran.h (gfc_save_module_list, gfc_restore_old_module_list):
New declarations.
* module.cc (old_module_list_tail): New global variable.
(gfc_save_module_list, gfc_restore_old_module_list): New functions.
(gfc_use_modules): Set module_list and old_module_list_tail.
* parse.cc (next_statement): Save module_list before doing any
work.
(reject_statement): Restore module_list to its saved value.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr89943_3.f90: Update error pattern.
* gfortran.dg/pr89943_4.f90: Likewise.
* gfortran.dg/use_31.f90: New test.

(cherry picked from commit a44d7e8a52007c2d45217709ca02947c6600de87)

[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Mikael Morin
:

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

commit r11-11305-g3d05b9ac1c6ad950339f9487702c3165c189fe9e
Author: Mikael Morin 
Date:   Thu Mar 21 17:27:54 2024 +0100

fortran: Ignore use statements on error [PR107426]

This fixes an access to freed memory on the testcase from the PR.
The problem comes from an invalid subroutine statement in an interface,
which is ignored and causes the following statements forming the procedure
body to be rejected.  One of them use-associates the intrinsic
ISO_C_BINDING
module, which imports new symbols in a namespace that is freed at the time
the statement is rejected.  However, this creates dangling pointers as
ISO_C_BINDING is special and its import creates a reference to the imported
C_PTR symbol in the return type of the global intrinsic symbol for C_LOC
(see the function create_intrinsic_function).

This change saves and restores the list of use statements, so that rejected
use statements are removed before they have a chance to be applied to the
current namespace and create dangling pointers.

PR fortran/107426

gcc/fortran/ChangeLog:

* gfortran.h (gfc_save_module_list, gfc_restore_old_module_list):
New declarations.
* module.c (old_module_list_tail): New global variable.
(gfc_save_module_list, gfc_restore_old_module_list): New functions.
(gfc_use_modules): Set module_list and old_module_list_tail.
* parse.c (next_statement): Save module_list before doing any work.
(reject_statement): Restore module_list to its saved value.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr89943_3.f90: Update error pattern.
* gfortran.dg/pr89943_4.f90: Likewise.
* gfortran.dg/use_31.f90: New test.

(cherry picked from commit a44d7e8a52007c2d45217709ca02947c6600de87)

[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #14 from Mikael Morin  ---
Fixed for gfortran versions 14.1, 13.3, 12.4 and 11.5.
Closing.

[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #5 from Mikael Morin  ---
Fixed.

[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #12 from Mikael Morin  ---
Fixed for gfortran 14.1.
Closing.

[Bug go/106813] getSiginfo() libgo/runtime/go-signal.c missing Solaris specific code to get ret.sigpc

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #1 from Rainer Orth  ---
FWIW I had a similar patch in my local tree for years, but neglected to submit
it (among others because it lacked dumpregs support.

While going over the remaining go.test failures recently, I noted some that
might be related, so I completed the patch (attached).  A few notes:

* I've used the customary __sun__ && __svr4__ guard for Solaris-specific code,
  not __sun && __SVR4 which is only used in runtime/go-libmain.c.

* I've reused the Linux/x86_64 code in dumpregs for Solaris.  Only a few
  adjustments were necessary, but this still seemed better than replicating
  the whole section.

* I've added SPARC support, too.  Since gregs[] is almost identical between
  32 and 64-bit, I've just used different formats for printing 32 and 64-bit
  registers, again to avoid massive duplication.

* When testing on Debian/sparc64, the 64-bit version there reguired an ugly
  variation: the general-purpose member of mcontext_t is called mc_gregs
  instead of gregs, and the indices are named MC_* instead of REG_* (although
  the names are identical with one exception).  I have no idea what rid them
  to do this, but at least my code does compile and run there.

The patch has been tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-pc-linux-gnu, and sparc64-unknown-linux-gnu (32 and 64-bit each).

There were no regressions, but compared to a vanilla tree there where no new
PASSes either.

[Bug fortran/112407] [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:35408b3669fac104cd380582b32e32c64a603d8b

commit r14-9752-g35408b3669fac104cd380582b32e32c64a603d8b
Author: Paul Thomas 
Date:   Tue Apr 2 14:19:09 2024 +0100

Fortran: Fix wrong recursive errors and class initialization [PR112407]

2024-04-02  Paul Thomas  

gcc/fortran
PR fortran/112407
* resolve.cc (resolve_procedure_expression): Change the test for
for recursion in the case of hidden procedures from modules.
(resolve_typebound_static): Add warning for possible recursive
calls to typebound procedures.
* trans-expr.cc (gfc_trans_class_init_assign): Do not apply
default initializer to class dummy where component initializers
are all null.

gcc/testsuite/
PR fortran/112407
* gfortran.dg/pr112407a.f90: New test.
* gfortran.dg/pr112407b.f90: New test.

[Bug go/106813] getSiginfo() libgo/runtime/go-signal.c missing Solaris specific code to get ret.sigpc

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

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

--- Comment #2 from Rainer Orth  ---
Created attachment 57848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57848&action=edit
Alternative patch.

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-04-02
 Ever confirmed|0   |1

--- Comment #5 from Andreas Schwab  ---
Without a test case it is hard to tell.

[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #2 from Jakub Jelinek  ---
Started with r14-2944-g3d48c11ad082def8ee237e5778d8a5d569bff96d
a is -1, so the testcase shouldn't do much except almost empty loops with a few
iterations.
The continue in there seems to be important, but dunno why, it is effectively
just a goto to the immediately next statement; perhaps the continue predictor
affects it?

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-04-02
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #19 from Tamar Christina  ---
Thanks! back from holidays and looking into it now.

mine.

[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

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

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

--- Comment #16 from Richard Biener  ---
Created attachment 57849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57849&action=edit
patch for expand

Interestingly this patch for RTL expansion, more specifically
add_scope_conflicts, only slows down things even though it should improve
cache locality.  In particular doing the 2nd stage inbetween makes things
worse.

Maybe this is due to the high in-degree of some blocks in the CFG.

I'll note there's no "change" in the 2nd iteration for SCCs, so optimizing
to only IOR in from (changed) backedges might "work" to reduce work.

Still it's odd the apparent locality improvement doesn't actually help
(as said it might be skewed by a high indegree of an SCC).

[Bug middle-end/114552] [13/14 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[13/14 Regression] wrong|[13/14 Regression] wrong
   |code at -O1 and above on|code at -O1 and above on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r13-990
 CC||jakub at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #3 from Jakub Jelinek  ---
Further cleaned up testcase:

struct __attribute__((packed)) S { short b; int c; };
struct T { struct S b; int e; };
static const struct T k = { { 1, 0 }, 0 };

__attribute__((noinline)) void
foo (void)
{
  asm ("" : : : "memory");
}

__attribute__((noinline)) void
bar (struct S n)
{
  foo ();
}

int
main ()
{
  bar (k.b);
  return 0;
}

Started with r13-990-ged6fd2aed58f2cca99f15331bf68999c0e6df370

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[paul.richard.thomas at gmail dot com via Gcc-bugs]

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

--- Comment #7 from paul.richard.thomas at gmail dot com  ---
Hi Harald,

I will have a stab at backporting r14-1629 later this afternoon and will
let you know what happens. I am just rebuilding after applying the fix for
pr112407 (yes, I did add -std=f2008 :-) ).

I don't think that there is any point in going back to 12-branch at this
point in the release cycle.

Cheers

Paul




On Mon, 1 Apr 2024 at 21:42, anlauf at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> 
>  Status|NEW |ASSIGNED
>
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> (In reply to Paul Thomas from comment #5)
> > Hi Harald,
> >
> > I am pinning this one on you since it needs backporting to 13-branch, at
> > least. It also keeps the audit trail clean.
>
> Hi Paul,
>
> this one is at the top of my backport list.
>
> It depends on backporting r14-8902 (mine), and has weak conflict if
> r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90
> was introduced in that commit.
>
> I could amend backporting the fix for the current PR as well as r14-8902
> to 13-branch by removing the changes to pr99350.f90 from the backport.
> That is likely the most simple solution, as backporting r14-1629 might
> introduce regressions.
>
> Nevertheless, the current fixes can only be backported to 13-branch,
> as some of the infrastructure changes for better error recovery after
> arithmetic errors and when array ctors are involved are to risky to
> backport to 12-branch.
>
> What do you think?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #6 from Andreas Schwab  ---
Looks like the issue is that args_pa_user is not kept aligned.  On the other
hand, flt128_va already uses memcpy, so it does not expect the memory to be
aligned.

[Bug middle-end/114552] [13/14 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990

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

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

--- Comment #4 from Jakub Jelinek  ---
The r13-989 to r13-990 difference is
-   movlk(%rip), %eax
-   movl%eax, (%rsp)
-   movzwl  k+4(%rip), %eax
-   movw%ax, 4(%rsp)
+   movw$1, (%rsp)
+   movl$0, 2(%rsp)
+   movl$0, 8(%rsp)
which clearly shows that previously it was copying just 6 bytes from k to
%rsp+0,
while now it directly sets those 6 bytes at %rsp+0 + another 4 bytes at %rsp+8.
The last insn is incorrect, shouldn't be there.

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

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

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

--- Comment #12 from Andrew Pinski  ---
For anyone reading this, -fprofile-generate with ifunc attributes should be
fixed and is not related to the xz backdoor. The issue will show up in valid
usage of ifuncs even ones which don't call  external/non-inlined functions like
the example code. There is another bug already about the diagnosising the
calling of external functions so please don't file a new one. Also we don't
need any extra comments about the backdoor in the gcc bugzilla.

[Bug target/114492] Invalid use of gcc_assert (notably in gcc/config/aarch64/aarch64-ldp-fusion.cc)

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #4 from Alex Coplan  ---
I think these should be OK. In the case of:

  for (unsigned i = 0; i < changes.length (); i++)
gcc_assert (rtl_ssa::restrict_movement_ignoring (*changes[i],
is_changing));

I think this is OK because the pass guarantees to have chosen a singleton move
range for the pair, so we don't rely on the call to restrict_movement_ignoring
updating the move range for any of the changes.  Other changes in the set are
either deletions or no-ops in terms of movement.  So we call this purely for
checking purposes to make sure we're not attempting something invalid.

Similarly in the case of:

  gcc_assert (crtl->ssa->verify_insn_changes (changes));

this is OK because the function doesn't have side effects (other than possibly
dumping).

Discussing this offline with Richard S he suggested asserting that we have
singleton move ranges before calling restrict_movement_ignoring to make that
case more obviously correct, so mine for that improvement (but either way I
think this should be OK).

[Bug middle-end/114552] [13/14 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 57850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57850&action=edit
gcc14-pr114552.patch

Untested fix.
Note, perhaps for GCC 15 we could support even non-matching sizes, as long as
we'd create a CONSTRUCTOR for just the needed bytes.  But, in that case we
wouldn't have to require that it is loaded from the beginning of a .rodata MEM.

[Bug c++/107945] static constexpr incomplete (depedent) data member of a class template and in-member initialized incorrectly accepted

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Jason Liam  ---
Here is another invalid snippet that gcc accepts but both clang and msvc
rejects correctly. https://godbolt.org/z/sz4rczEaG

```
#include 

template
requires std::is_arithmetic_v && (N >= 1)
class Vector
{
static constexpr std::size_t Dimension = N;
std::array Elements;

public:
constexpr Vector() noexcept : Elements{} {}
constexpr ~Vector() = default;
static constexpr Vector ZeroVector{};
};

int main()
{
Vector boo = Vector::ZeroVector;
}
```

Related thread
https://stackoverflow.com/questions/78248691/static-data-member-of-template-class-type-constexpr-vs-const-constinit

[Bug c++/114562] [11/12/13/14 Regression] ICE when trying to bind rvalue reference to lvalue with comma operator and forwarding reference to pointer since r10-7410

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
   Priority|P3  |P2
Summary|ICE when trying to bind |[11/12/13/14 Regression]
   |rvalue reference to lvalue  |ICE when trying to bind
   |with comma operator and |rvalue reference to lvalue
   |forwarding reference to |with comma operator and
   |pointer |forwarding reference to
   ||pointer since r10-7410
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2024-04-02
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started to ICE with r10-7410-g72809d6fe8e085440403ce125c51d01d6e7512b0

[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Kewen Lin from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > Found it:
> > /* In GIMPLE the type of the MEM_REF specifies the alignment.  The
> >   required alignment (power) is 4 bytes regardless of data type.  */
> > tree align_ltype = build_aligned_type (lhs_type, 4);
> > 
> > That should be 4*8 instead of just 4.
> > 
> > There are 2 build_aligned_type in rs6000-builtins.cc which uses the wrong
> > alignment; thinking it was the alignment argument was bytes rather than 
> > bits.
> > 
> > Introduced by r9-2375-g3f7a77cd20d07c which means this is a regression.
> 
> Hi Andrew, thanks for digging into this!  William has not worked on GCC
> project any more, will you make a patch for this?

I don't have time to test it really.

[Bug c++/114561] [11/12/13/14 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|Comma operator with |[11/12/13/14 Regression]
   |forwarding reference to |Comma operator with
   |pointer raises invalid  |forwarding reference to
   |lvalue required error   |pointer raises invalid
   ||lvalue required error since
   ||r10-7410
 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Started with r10-7410-g72809d6fe8e085440403ce125c51d01d6e7512b0 too.

[Bug c++/114561] [11/12/13/14 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
   Priority|P3  |P2

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[paul.richard.thomas at gmail dot com via Gcc-bugs]

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

--- Comment #8 from paul.richard.thomas at gmail dot com  ---
Hi Harald,

After a lot of messing around, I managed to backport the patch; essentially
by hand. However, two of the  testcases ICEd in trans-array.cc and so there
were obviously dependences that I had missed.

I will not be backporting r14-1629, if for no other reason than it is not a
regression but also because the amount of work that would be involved
doesn't warrant it. It's a pity that I didn't keep 13-branch up to speed
with mainline on the associate fixes but we will just have to live with it
now.

Regards

Paul


On Tue, 2 Apr 2024 at 14:32, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Hi Harald,
>
> I will have a stab at backporting r14-1629 later this afternoon and will
> let you know what happens. I am just rebuilding after applying the fix for
> pr112407 (yes, I did add -std=f2008 :-) ).
>
> I don't think that there is any point in going back to 12-branch at this
> point in the release cycle.
>
> Cheers
>
> Paul
>
>
>
>
> On Mon, 1 Apr 2024 at 21:42, anlauf at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
>>
>> anlauf at gcc dot gnu.org changed:
>>
>>What|Removed |Added
>>
>> 
>>  Status|NEW |ASSIGNED
>>
>> --- Comment #6 from anlauf at gcc dot gnu.org ---
>> (In reply to Paul Thomas from comment #5)
>> > Hi Harald,
>> >
>> > I am pinning this one on you since it needs backporting to 13-branch, at
>> > least. It also keeps the audit trail clean.
>>
>> Hi Paul,
>>
>> this one is at the top of my backport list.
>>
>> It depends on backporting r14-8902 (mine), and has weak conflict if
>> r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90
>> was introduced in that commit.
>>
>> I could amend backporting the fix for the current PR as well as r14-8902
>> to 13-branch by removing the changes to pr99350.f90 from the backport.
>> That is likely the most simple solution, as backporting r14-1629 might
>> introduce regressions.
>>
>> Nevertheless, the current fixes can only be backported to 13-branch,
>> as some of the infrastructure changes for better error recovery after
>> arithmetic errors and when array ctors are involved are to risky to
>> backport to 12-branch.
>>
>> What do you think?
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>
>

[Bug c++/114561] [11/12/13/14 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/114552] [13/14 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #6 from Roger Sayle  ---
Many thanks Jakub, and my apologies for the breakage/inconvenience.  It looks
like sizeof(k) is 10 bytes, and sizeof(k.b) is 6 bytes, and somehow this code
is getting the constructor for "k" and not for just "k.b".  This is, of course,
fine for memcpy as it can move the just the pieces it wants.  I completely
agree that the safe fix is to check that the sizes match; I don't think I ever
considered that they might not be identical when I wrote this code, or assumed
that partial would be non-zero for this case].

[Bug tree-optimization/111407] [11/12/13 Regression] ICE: SSA corruption due to widening_mul opt on conflict across an abnormal edge

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Qing Zhao :

https://gcc.gnu.org/g:2d9a9488e26233eb9497722fa9ccb88258f7402c

commit r13-8556-g2d9a9488e26233eb9497722fa9ccb88258f7402c
Author: Qing Zhao 
Date:   Thu Feb 29 15:07:49 2024 +

Fix SSA corruption due to widening_mul opt on conflict across an abnormal
edge [PR111407]

This is a bug in tree-ssa-math-opts.cc, when applying the widening mul
optimization, the compiler needs to check whether the operand is in a
ABNORMAL PHI, if YES, we should avoid the transformation.

PR tree-optimization/111407

gcc/ChangeLog:

* tree-ssa-math-opts.cc (convert_mult_to_widen): Avoid the
transform
when one of the operands is subject to abnormal coalescing.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit 4aca1cfd6235090e48a53dab734437740671bbf3)

[Bug c++/114564] Accessing template Base via template Derived fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
  Known to fail||4.1.2
   Last reconfirmed||2024-04-02

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Simple workaround if needed is to place `typename` before `Derived::Base` . 
GCC is thinking `Derived::Base` is not a type for some reason ...

[Bug c++/114562] [11/12/13/14 Regression] ICE when trying to bind rvalue reference to lvalue with comma operator and forwarding reference to pointer since r10-7410

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/106999] [11/12/13/14 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-9753-ga7aa9455a8b9cb080649a7357b7360f2d99bcbf1
Author: Paul Thomas 
Date:   Tue Apr 2 15:53:29 2024 +0100

Fortran: Add error for subroutine passed to a variable dummy [PR106999]

2024-04-02  Paul Thomas  

gcc/fortran
PR fortran/106999
* interface.cc (gfc_compare_interfaces): Add error for a
subroutine proc pointer passed to a variable formal.
(compare_parameter): If a procedure pointer is being passed to
a non-procedure formal arg, and there is an an interface, use
gfc_compare_interfaces to check and provide a more useful error
message.

gcc/testsuite/
PR fortran/106999
* gfortran.dg/pr106999.f90: New test.

[Bug modula2/114565] New: progress trace would be useful to isolate ICE for users

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

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

Bug ID: 114565
   Summary: progress trace would be useful to isolate ICE for
users
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

As suggested on the gm2 mailing list, it would be helpful if gm2 had an option
to dump progress to help users isolate source code which triggers an ICE.

[Bug modula2/114565] progress trace would be useful to isolate ICE for users

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-02
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug target/114560] Compilation error when using _mm512_maskz_expandloadu_epi16 with only -mavx512vbmi2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
AVX512BW is needed to be able to use __mmask32/__mmask64, those aren't
supported in AVX512F, which only supports __mmask16.  __mmask8 needs AVX512DQ
(though, guess for that one one can just use KMOV with 16-bit mask).
In GCC 13 and later, -mavx512bw has been added as the implicit requirement of
-mavx512vbmi2
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615906.html
and -mavx512bitalg
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615905.html

[Bug modula2/114565] progress trace would be useful to isolate ICE for users

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 57851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57851&action=edit
Proposed patch

Here is a proposed patch which introduces the option -fm2-debug-trace=
and allows a comma separated list containing: quad,token,line,all.
It currently dumps progress to stdout and this would be expected to change once
PR113836 is complete.  In short the progress data should also be dumped to file
and flushed on every newline.

[Bug tree-optimization/111407] [11/12/13 Regression] ICE: SSA corruption due to widening_mul opt on conflict across an abnormal edge

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Qing Zhao :

https://gcc.gnu.org/g:5f23f9f141c4b52e8f4a9aadc88b8155cf1959a3

commit r12-10306-g5f23f9f141c4b52e8f4a9aadc88b8155cf1959a3
Author: Qing Zhao 
Date:   Thu Feb 29 15:07:49 2024 +

Fix SSA corruption due to widening_mul opt on conflict across an abnormal
edge [PR111407]

This is a bug in tree-ssa-math-opts.cc, when applying the widening mul
optimization, the compiler needs to check whether the operand is in a
ABNORMAL PHI, if YES, we should avoid the transformation.

PR tree-optimization/111407

gcc/ChangeLog:

* tree-ssa-math-opts.cc (convert_mult_to_widen): Avoid the
transform
when one of the operands is subject to abnormal coalescing.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit 4aca1cfd6235090e48a53dab734437740671bbf3)

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

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

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

--- Comment #8 from Joseph S. Myers  ---
"rejects", in the ISO C sense, only applies to errors and pedwarns in GCC; not
to warnings conditional on -pedantic (of which there are also some, but which
don't turn into errors with -pedantic).

If you have cases where something that is only *undefined as a property of a
particular execution of the program* (as opposed to undefined as a property of
a translation unit or of the collection of translation units making up a
program, or violating a Constraint or syntax rule) but that are errors or
pedwarns, those should be reported as separate bugs. There are various cases
where we make sure to only warn at compilation time and generate code that
aborts at precisely the point in execution where undefined behavior would
occur, precisely because the undefined behavior in those cases is a property of
a program execution.

I believe conversions between function and object pointers are undefined as a
property of the translation unit - not of a particular execution. Whereas e.g.
calling a function pointer converted to an incompatible type is undefined as a
property of a particular execution (the undefinedness only occurring when the
call itself is executed, after all side effects from the function designator
and arguments have taken place).

[Bug target/114560] Compilation error when using _mm512_maskz_expandloadu_epi16 with only -mavx512vbmi2

[meirav.grimberg at redis dot com via Gcc-bugs]

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

--- Comment #2 from Meirav Grimberg  ---
(In reply to Jakub Jelinek from comment #1)
> AVX512BW is needed to be able to use __mmask32/__mmask64, those aren't
> supported in AVX512F, which only supports __mmask16.  __mmask8 needs
> AVX512DQ (though, guess for that one one can just use KMOV with 16-bit mask).
> In GCC 13 and later, -mavx512bw has been added as the implicit requirement of
> -mavx512vbmi2
> https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615906.html
> and -mavx512bitalg
> https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615905.html

Hi,
thank you for the quick reply.

As i mentioned Intel Intrinsics Guide specifically specifies only the
AVX512_VBMI2 flag without referencing AVX512BW. Could you shed some light on
this?

Moreover, I noticed that both Clang and Intel's compiler allow compilation
without additional flags, suggesting an implementation that aligns with the
hardware requirements. Could you provide insights into why GCC necessitates an
additional flag?


Regarding the term "implicit requirement," could you please clarify its
meaning? I didn't observe any apparent differences when attempting compilation
with GCC 13.

Thank you for your assistance.

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #9 from Harald van Dijk  ---
(In reply to Joseph S. Myers from comment #8)
> "rejects", in the ISO C sense, only applies to errors and pedwarns in GCC;
> not to warnings conditional on -pedantic (of which there are also some, but
> which don't turn into errors with -pedantic).
> 
> If you have cases where something that is only *undefined as a property of a
> particular execution of the program* (as opposed to undefined as a property
> of a translation unit or of the collection of translation units making up a
> program, or violating a Constraint or syntax rule) but that are errors or
> pedwarns, those should be reported as separate bugs.

Bug 83584, which like this one is closed as a duplicate of 11234, is about
exactly that.

  void *f(void) { return (void *)f; }
  int main(void) { return 0; }

This is a strictly conforming program. It violates no syntax rule or
constraint, and exhibits no translation-time undefined behaviour, yet it
triggers a pedwarn, turning into an error with -pedantic-errors. It would have
undefined behaviour i f f were ever called, but it is not called.

[Bug c/114526] ISO C does not prohibit extensions: fix misconception.

[harald at gigawatt dot nl via Gcc-bugs]

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

--- Comment #10 from Harald van Dijk  ---
Sorry, sent my earlier comment too soon.

(In reply to Joseph S. Myers from comment #8)
> I believe conversions between function and object pointers are undefined as
> a property of the translation unit - not of a particular execution.

But there is nothing in the standard to support this. The standard fully
defines the behaviour of the program I posted, which is just to return 0.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

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

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

--- Comment #20 from Tamar Christina  ---
This is a bad interaction with early break and peeling for gaps.

when peeling for gaps we set bias_for_lowest to 0, which then negates the ceil
for the upper bound calculation when the div is exact.

We end up doing on a loop that does:

Analyzing # of iterations of loop 1
  exit condition [8, + , 18446744073709551615] != 0
  bounds on difference of bases: -8 ... -8
  result:
# of iterations 8, bounded by 8

and a VF=4 calculating:

Loop 1 iterates at most 1 times.
Loop 1 likely iterates at most 1 times.
Analyzing # of iterations of loop 1
  exit condition [1, + , 1](no_overflow) < bnd.5505_39
  bounds on difference of bases: 0 ... 4611686018427387902
Matching expression match.pd:2011, generic-match-8.cc:27
Applying pattern match.pd:2067, generic-match-1.cc:4813
  result:
# of iterations bnd.5505_39 + 18446744073709551615, bounded by
4611686018427387902
Estimating sizes for loop 1
...
   Induction variable computation will be folded away.
  size:   2 if (ivtmp_312 < bnd.5505_39)
   Exit condition will be eliminated in last copy.
size: 24-3, last_iteration: 24-5
  Loop size: 24
  Estimated size after unrolling: 26
;; Guessed iterations of loop 1 is 0.858446. New upper bound 1.

upper bound should be 2 not 1. I have a working patch, trying to create a
standalone testcase for it.

[Bug modula2/114565] progress trace would be useful to isolate ICE for users

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

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

Gaius Mulley  changed:

   What|Removed |Added

  Attachment #57851|0   |1
is obsolete||

--- Comment #3 from Gaius Mulley  ---
Created attachment 57852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57852&action=edit
Proposed patch v3

Here is an improved patch which has been generated against the current tip of
the repository and also contains performance fixes for the token trace.

[Bug target/114560] Compilation error when using _mm512_maskz_expandloadu_epi16 with only -mavx512vbmi2

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

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Meirav Grimberg from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > AVX512BW is needed to be able to use __mmask32/__mmask64, those aren't
> > supported in AVX512F, which only supports __mmask16.  __mmask8 needs
> > AVX512DQ (though, guess for that one one can just use KMOV with 16-bit 
> > mask).
> > In GCC 13 and later, -mavx512bw has been added as the implicit requirement 
> > of
> > -mavx512vbmi2
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615906.html
> > and -mavx512bitalg
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615905.html
> 
> Hi,
> thank you for the quick reply.
> 
> As i mentioned Intel Intrinsics Guide specifically specifies only the
> AVX512_VBMI2 flag without referencing AVX512BW. Could you shed some light on
> this?

That is just a bug in the Intrinsic Guide IMNSHO.

> Moreover, I noticed that both Clang and Intel's compiler allow compilation
> without additional flags, suggesting an implementation that aligns with the
> hardware requirements. Could you provide insights into why GCC necessitates
> an additional flag?

The intrinsic needs to load the 32-bit mask into one of the %k{0,1,2,3,4,5,6,7}
registers.  And without AVX512BW there is just not an instruction for that.
If you'll compile your testcase with clang with -O0 -mavx512vbmi2, you can see
kmovd   %ecx, %k1
instruction, which requires AVX512BW CPUID.  So, supposedly it does what GCC14
and later does, enabling -mavx512bw implicitly when -mavx512vbmi2 is requested.
While the vpexpandw instruction indeed maybe only needs AVX512VBMI2, you can't
implement the intrinsic without AVX512BW.
When I check clang -E -dD -mavx512vbmi2 output on godbolt, I see
#define __AVX512BW__ 1
#define __AVX512VBMI2__ 1
defined there.

> Regarding the term "implicit requirement," could you please clarify its
> meaning? I didn't observe any apparent differences when attempting
> compilation with GCC 13.

Ah, sorry, it is indeed in GCC 14 only.  I was misled by the commit date of
January 2023, but it has been actually pushed into GCC trunk only in April
after GCC 13 branched.
In GCC 11-13 you need to use both -mavx512vbmi2 -mavx512bw to use these
intrinsics.