[Bug c/117021] [C2y] Implement N3370, Case range expressions

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
 Contrary to what's claimed in that paper, range endpoints that change
value as a result of converting to the promoted type of the controlling
expression are a warning, not a hard error or pedwarn, and that would need
changing as part of implementing the feature.

[Bug c/117020] [C2y] Implement N3366, Restartable Functions for Efficient Character Conversions

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

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

--- Comment #2 from Joseph S. Myers  ---
There is very little language content in this paper (only some predefined
macros).

[Bug c/117022] [C2y] Implement N3355, Named loops

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

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

--- Comment #1 from Marek Polacek  ---
There is a request for a do-while example to be added editorially.

[Bug c/117022] New: [C2y] Implement N3355, Named loops

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

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

Bug ID: 117022
   Summary: [C2y] Implement N3355, Named loops
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c/117028] [C2y] Implement N3353, Obsolete implicitly octal literals and add delimited escape sequences

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
0o123 or 0O123 aren't supported for C++, just \u{123}, \x{123}, \o{123} are.

[Bug tree-optimization/117032] New: missing vectorization of V4HI to V4DF

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

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

Bug ID: 117032
   Summary: missing vectorization of V4HI to V4DF
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

GCC can vectorize V4HI to V4DF on aarch64 if going indirectly via V4SI.
That is take:
```
static inline 
void g(unsigned short *a, int *b)
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
}
static inline 
void g2(int *a, double *b)
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
}

void indirect(unsigned short *a, double *b)
{
  int t[4];
  g(a, t);
  g2(t, b);
}

void direct(unsigned short *a, double *b)
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
}

```

[Bug tree-optimization/117031] increasing VF during SLP vectorization permutes unnecessarily

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

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

--- Comment #1 from Andrew Pinski  ---
So on the V4HI to V4DF missed vectorization, I filed PR 117032 since GCC does
understand if there is an indirection via V4SI.

[Bug tree-optimization/101956] Miss vectorization from v4hi to v4df

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug tree-optimization/117033] GCC trunk emits larger code at -Os compared to -O2

[dccitaliano at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Davide Italiano  ---
I noticed you linked the LLVM bug I found. 
As part of my search/analysis, I found out there are cases that sometimes clang
gets but GCC doesn't (unsurprisingly, FWIW).

Here's a simple one.
https://godbolt.org/z/fjjzf9xds

[Bug c++/117034] ICE on abbreviated function template with type constraint containing a lambda argument

[eczbek.void at gmail dot com via Gcc-bugs]

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

--- Comment #2 from eczbek.void at gmail dot com ---
Is this error related?

```
template
concept A = true;

template T>
void foo(T) {}
```

Compiler Explorer link: https://godbolt.org/z/dfKaW8dxa

[Bug tree-optimization/117033] GCC trunk emits larger code at -Os compared to -O2

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Davide Italiano from comment #6)
> I noticed you linked the LLVM bug I found. 
> As part of my search/analysis, I found out there are cases that sometimes
> clang gets but GCC doesn't (unsurprisingly, FWIW).
> 
> Here's a simple one.
> https://godbolt.org/z/fjjzf9xds

here is a slightly modified example which shows the opposite way, GCC figures
it at -Os but LLVM does not:
```
long patatino() {
long x = 0;
for (int i = 0; i < 5; ++i) {
if (x < 10)
while (x < 10) {
x += 1;
}
}
return x;
}
```

[Bug c++/117034] ICE on abbreviated function template with type constraint containing a lambda argument

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to eczbek.void from comment #2)
> Is this error related?

Yes but you filed PR 116952 which is that issue.

[Bug c++/117034] ICE on abbreviated function template with type constraint containing a lambda argument

[eczbek.void at gmail dot com via Gcc-bugs]

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

--- Comment #4 from eczbek.void at gmail dot com ---
Whoops.

[Bug tree-optimization/117033] GCC trunk emits larger code at -Os compared to -O2

[dccitaliano at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Davide Italiano  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Davide Italiano from comment #6)
> > I noticed you linked the LLVM bug I found. 
> > As part of my search/analysis, I found out there are cases that sometimes
> > clang gets but GCC doesn't (unsurprisingly, FWIW).
> > 
> > Here's a simple one.
> > https://godbolt.org/z/fjjzf9xds
> 
> here is a slightly modified example which shows the opposite way, GCC
> figures it at -Os but LLVM does not:
> ```
> long patatino() {
> long x = 0;
> for (int i = 0; i < 5; ++i) {
> if (x < 10)
> while (x < 10) {
> x += 1;
> }
> }
> return x;
> }
> ```

Yes, indeed. I found example that go both way. From what I see, FWIW, but I'm
still very early in my investigation, GCC's -Oz outperforms LLVM's -Oz on many
cases.

[Bug target/80881] Implement Windows native TLS

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

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

--- Comment #32 from Eric Botcazou  ---
> It's a bit of a shame I couldn't figure out how to make the zero extend
> approach work correctly. That aside, I'm concerned that this patch still
> isn't correct, because it doesn't seem to be using the parallel rtx
> correctly.

No worries, it's the standard way of requesting a scratch register, and nothing
will try to use the result of a CLOBBER on it.  That being said, we could
indeed try and split the instructions for better scheduling, although the TLS
pattern for the Sun linker is multi-insn too, see tls_initial_exec_64_sun.

I'm attaching a minor update which uses named insns to simplify the code.

[Bug tree-optimization/117031] New: increasing VF during SLP vectorization permutes unnecessarily

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

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

Bug ID: 117031
   Summary: increasing VF during SLP vectorization permutes
unnecessarily
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---

The following testcase:

---
void
test1 (unsigned short *x, double *y, int n)
{
for (int i = 0; i < n; i++)
{
unsigned short a = x[i * 4 + 0];
unsigned short b = x[i * 4 + 1];
unsigned short c = x[i * 4 + 2];
unsigned short d = x[i * 4 + 3];
y[i] = (double)a + (double)b + (double)c + (double)d;
}
}
---

at -O3 vectorizes using LOAD_LANES on aarch64:

  vect_array.11 = .LOAD_LANES (MEM  [(short unsigned
int *)vectp_x.9_123]);
  vect_a_29.12_125 = vect_array.11[0];
  vect__14.17_129 = [vec_unpack_lo_expr] vect_a_29.12_125;
  vect__14.17_130 = [vec_unpack_hi_expr] vect_a_29.12_125;
  vect__14.16_131 = [vec_unpack_lo_expr] vect__14.17_129;
  vect__14.16_132 = [vec_unpack_hi_expr] vect__14.17_129;
  vect__14.16_133 = [vec_unpack_lo_expr] vect__14.17_130;
  vect__14.16_134 = [vec_unpack_hi_expr] vect__14.17_130;
  vect__14.18_135 = (vector(2) double) vect__14.16_131;
  vect__14.18_136 = (vector(2) double) vect__14.16_132;
  vect__14.18_137 = (vector(2) double) vect__14.16_133;
  vect__14.18_138 = (vector(2) double) vect__14.16_134;
...


because input type is 4 shorts, so V4HI is the natural size. V4HI fails to
vectorize because
we don't support direct conversion from V4HI to V4SI.

We then pick a higher VF (V8HI) and the loads are detected as interleaving.
LLVM however avoids
the permute here by detecting that the unrolling doesn't result in a permuted
access as it's
equivalent to:

void
test3 (unsigned short *x, double *y, int n)
{
for (int i = 0; i < n; i+=2)
{
unsigned short a1 = x[i * 4 + 0];
unsigned short b1 = x[i * 4 + 1];
unsigned short c1 = x[i * 4 + 2];
unsigned short d1 = x[i * 4 + 3];
y[i+0] = (double)a1 + (double)b1 + (double)c1 + (double)d1;
unsigned short a2 = x[i * 4 + 4];
unsigned short b2 = x[i * 4 + 5];
unsigned short c2 = x[i * 4 + 6];
unsigned short d2 = x[i * 4 + 7];
y[i+1] = (double)a2 + (double)b2 + (double)c2 + (double)d2;
}
}

GCC seems to miss that there is no gap between the group accesses and that
stride == 1.
test3 is vectorized linearly by GCC, so it seems this is missed optimization in
data ref analysis?

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

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

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

Bug 116024 Summary: [14/15 Regression] unnecessary integer comparison(s) for a 
simple loop since r14-5628-g53ba8d669550d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116024

   What|Removed |Added

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

[Bug ipa/96265] offloading to nvptx-none from aarch64-linux-gnu (and riscv*-linux-gnu) does not work

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

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

--- Comment #18 from GCC Commits  ---
The master branch has been updated by Prathamesh Kulkarni
:

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

commit r15-4133-gae88da5e070659d37b3c3daa4b880531769183bf
Author: Prathamesh Kulkarni 
Date:   Tue Oct 8 12:38:31 2024 +0530

Recompute TYPE_MODE and DECL_MODE for vector_type for accelerator.

gcc/ChangeLog:
PR ipa/96265
* lto-streamer-in.cc (lto_read_tree_1): Set TYPE_MODE and DECL_MODE
for vector_type if offloading is enabled.
(lto_input_mode_table): Remove handling of vector modes.
* tree-streamer-out.cc (pack_ts_decl_common_value_fields): Stream
out
VOIDmode for vector_type if offloading is enabled.
(pack_ts_decl_common_value_fields): Likewise.

Signed-off-by: Prathamesh Kulkarni 

[Bug target/117008] -march=native pessimization of 25% with bitset []

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
Btw, GCC 14.2 doesn't vectorize for me anymore, likely because the use of
gather has been nerfed (for Intel).

With AVX2 we see

   [local count: 139586405]:
  # vect_total_21.15_24 = PHI 
  # vect_vec_iv_.16_20 = PHI <_18(3), { 0, 1, 2, 3, 4, 5, 6, 7 }(2)>
  # ivtmp.27_27 = PHI 
  _18 = vect_vec_iv_.16_20 + { 8, 8, 8, 8, 8, 8, 8, 8 };
  vect__17.17_5 = vect_vec_iv_.16_20 >> 5;
  vect__19.18_3 = vect_vec_iv_.16_20 & { 31, 31, 31, 31, 31, 31, 31, 31 };
  vect_30 = VIEW_CONVERT_EXPR(vect__17.17_5);
  vect_31 = __builtin_ia32_gathersiv8si ({ 0, 0, 0, 0, 0, 0, 0, 0 }, &values,
vect_30, { -1, -1, -1, -1, -1, -1, -1, -1 }, 4);
  vect__13.19_32 = VIEW_CONVERT_EXPR(vect_31);
  vect__14.20_34 = { 1, 1, 1, 1, 1, 1, 1, 1 } << vect__19.18_3;
  vect__15.21_35 = vect__13.19_32 & vect__14.20_34;
  mask__16.22_37 = vect__15.21_35 != { 0, 0, 0, 0, 0, 0, 0, 0 };
  _51 = VIEW_CONVERT_EXPR(mask__16.22_37);
  vect_total_11.24_41 = vect_total_21.15_24 - _51;
  ivtmp.27_23 = ivtmp.27_27 + 1;
  if (ivtmp.27_23 != 160)

so the first point is we are not able to analyze the memory access pattern
in a very good way and then of course cost modeling breaks down here as well.

The scalar IL is

   [local count: 1063004409]:
  # total_21 = PHI 
  # index_23 = PHI 
  # ivtmp_27 = PHI 
  _17 = index_23 >> 5;
  _19 = index_23 & 31;
  _13 = MEM  [(_WordT *)&values]._M_w[_17];
  _14 = 1 << _19;
  _15 = _13 & _14;
  _16 = _15 != 0;
  _1 = (unsigned int) _16;
  total_11 = _1 + total_21;
  index_12 = index_23 + 1;
  ivtmp_26 = ivtmp_27 - 1;
  if (ivtmp_26 != 0)

I think for this kind of access pattern it might be nice to unroll the
loop as many times as the same memory location is accessed (1 << 5, aka
32 times).

But as Andrew says - it's just a very bad testcase ;)

[Bug rtl-optimization/117012] New: [15 Regression] incorrect RTL simplification around vector AND and shifts

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

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

Bug ID: 117012
   Summary: [15 Regression] incorrect RTL simplification around
vector AND and shifts
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

The following example:

#include 
#include 

uint8x16_t f (uint8x16_t x)
{
  uint8x16_t mask = vreinterpretq_u8_u64(vdupq_n_u64 (0x101));
  return vandq_u8(vcltq_s8(vreinterpretq_s8_u8(x), vdupq_n_s8(0)), mask);
}

compiled at -O3 gives the following:

f:
ushrv0.16b, v0.16b, 7
ret

This is incorrect as it assumes that the value in every lane for the AND was
0x1 where in fact only the bottom lane is.

combine is matching this incorrect pattern:

Trying 7, 6 -> 8:
7: r108:V16QI=const_vector
6: r107:V16QI=r109:V16QI>>const_vector
  REG_DEAD r109:V16QI
8: r106:V16QI=r107:V16QI&r108:V16QI
  REG_DEAD r108:V16QI
  REG_DEAD r107:V16QI
  REG_EQUAL r107:V16QI&const_vector
Successfully matched this instruction:
(set (reg:V16QI 106 [ _5 ])
(lshiftrt:V16QI (reg:V16QI 109 [ xD.22802 ])
(const_vector:V16QI [
(const_int 7 [0x7]) repeated x16
])))

The optimization seems to only look at the bottom lane of the vector:

#include 
#include 

uint8x16_t f (uint8x16_t x)
{
  uint8x16_t mask = vreinterpretq_u8_u64(vdupq_n_u64 (0x301));
  return vandq_u8(vcltq_s8(vreinterpretq_s8_u8(x), vdupq_n_s8(0)), mask);
}

also generates incorrect code but changing the bottom lane

#include 
#include 

uint8x16_t f (uint8x16_t x)
{
  uint8x16_t mask = vreinterpretq_u8_u64(vdupq_n_u64 (0x102));
  return vandq_u8(vcltq_s8(vreinterpretq_s8_u8(x), vdupq_n_s8(0)), mask);
}

gives the right result.

[Bug target/96835] Constructor in offload template class

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Depends on||105018
 CC||tschwinge at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2020-08-28 00:00:00 |2024-10-08

--- Comment #8 from Thomas Schwinge  ---
With current GCC, for nvptx offloading, '-O0', we get for the "Reproducer"
(attached, also #c2):

reproducer.cpp:18:1: error: alias definitions not supported in this
configuration
   18 | vector::vector(int const& init_val) {
  | ^
nvptx mkoffload: fatal error:
build-gcc/gcc/x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status
[...]

With either optimizations enabled, or '-O0' with additional
'-foffload-options=nvptx-none="-mptx=6.3 -malias"', compilation succeeds, and
we get the expected:

$ ./a.out 
8

Therefore, this issue should (soon...) get resolved via PR105018 "[nvptx] Need
better alias support", and I'll make sure to include your test case, thanks!


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105018
[Bug 105018] [nvptx] Need better alias support

[Bug target/117011] New: RISC-V: Logic overlap in IF_THEN_ELSE case for instruction cost calculation

[Jovan.Vukic--- via Gcc-bugs]

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

Bug ID: 117011
   Summary: RISC-V: Logic overlap in IF_THEN_ELSE case for
instruction cost calculation
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jovan.vu...@rt-rk.com
  Target Milestone: ---
Target: riscv

In the file riscv.cc, in the function riscv_rtx_costs, we have the  
following code for the IF_THEN_ELSE case:

if ((TARGET_SFB_ALU || TARGET_XTHEADCONDMOV) 
&& reg_or_0_operand(XEXP(x, 1), mode) 
&& sfb_alu_operand(XEXP(x, 2), mode) 
&& comparison_operator(XEXP(x, 0), VOIDmode)) 
{
/* For predicated conditional-move operations, we assume the cost 
   of a single instruction, even though there are actually two. */ 
*total = COSTS_N_INSNS(1); 
return true; 
} 
else if (TARGET_ZICOND_LIKE 
 && outer_code == SET 
 && ...) 
{
*total = COSTS_N_INSNS(1); 
return true; 
}


However, what will happen if both TARGET_SFB_ALU and 
TARGET_ZICOND_LIKE are set to 1 at the same time 
(-mtune=sifive-7-series -march=rv64gc_zicond)? In this case, we won't be 
able to distinguish between the movcc and czero instructions, and for 
czero, we will enter the "if" branch instead of (as we expect) the 
"else if" branch.

Since both branches currently set *total to 1 instruction, there is 
essentially no difference. However, if someone changes the way the 
calculation is performed in the future, it could lead to issues.

[Bug target/117007] Poor optimization for small vector constants needed for vector shift/rotate/mask generation

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc
   Keywords||missed-optimization

--- Comment #2 from Richard Biener  ---
It's likely those constants are now exposed to GIMPLE somehow so we expand
a constant vector CTOR for which the backend should implement a vec_init
optab, recognizing constants it can create efficiently (I think we try
to expand uniform vector constants with splats already).

So you need to analyze why RTL expansion ends up with a constant pool load
initially.

[Bug middle-end/117002] [13/14/15 Regression] lifetime.d: In function ‘_d_newclassT’: error: size of array element is not a multiple of its alignment with -Warray-bounds and -O2

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |13.3.1
Summary|[13/14 regression]  |[13/14/15 Regression]
   |lifetime.d: In function |lifetime.d: In function
   |‘_d_newclassT’: error: size |‘_d_newclassT’: error: size
   |of array element is not a   |of array element is not a
   |multiple of its alignment   |multiple of its alignment
   |with -Warray-bounds and -O2 |with -Warray-bounds and -O2
   Target Milestone|--- |13.4
   Keywords||diagnostic

[Bug target/117006] [15 regression] GCC trunk generates larger code than GCC 14 at -Os

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |15.0
   Target Milestone|--- |15.0

[Bug target/117008] -march=native pessimization of 25% with bitset []

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Matt Bentley from comment #4)
> I haven't tested whether vector/array
> indexing triggers the same bad vectorisation.

I'm certain it won't be, because (apart from vector) they access memory
locations that are at least one byte, not repeating very similar bitwise ops
for every bit in a word.

[Bug target/117008] -march=native pessimization of 25% with bitset []

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Matt Bentley from comment #5)
> (In reply to Andrew Pinski from comment #1)
> > Can you provide the output of invoking g++ with -march=native and when
> > compiling?
> 
> The .ii files were identical, so did you you mean .o files?

I'm guessing Andrew meant the output when you add -v to the compilation
command, with and without march=native

That would show exactly the instruction sets being enabled by march=native.

[Bug middle-end/117002] [13/14/15 Regression] lifetime.d: In function ‘_d_newclassT’: error: size of array element is not a multiple of its alignment with -Warray-bounds and -O2

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuclaw at gdcproject dot org

--- Comment #2 from Iain Buclaw  ---
Initial reduction, though @Andrew may have given the needed hint to remove the
class declaration (all D classes have a void** vptr pointing at a vtable array)

---
module object;

extern(C++) class Foo {
ubyte[4] not_multiple_of_8;
}

int pr117002(void *p)
{
auto init = __traits(initSymbol, Foo);
if (init.ptr + init.length <= p)
return 1;

return 0;
}

[Bug target/117010] [nvptx] Incorrect ptx code-gen for C++ code with templates

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-08

--- Comment #3 from Thomas Schwinge  ---
(In reply to Andrew Pinski from comment #2)
> I think this is a dup of bug 96835.

One would assume so, but it's not; there's something else (additional) going on
here.  As Prathamesh noted, the current GCC/nvptx '-malias' is not sufficient
to make this one work:

(In reply to prathamesh3492 from comment #0)
> Compiling with -O0 -fopenmp -foffload=nvptx-none -foffload=-malias 
> -foffload=-mptx=6.3, results in following error:
> 
> ptxas ./a.xnvptx-none.mkoffload.o, line 45; error   : Call to 
> '_ZN1VILi0EEC1Ev' requires call prototype
> ptxas ./a.xnvptx-none.mkoffload.o, line 45; error   : Unknown symbol 
> '_ZN1VILi0EEC1Ev'
> ptxas fatal   : Ptx assembly aborted due to errors
> nvptx-as: ptxas returned 255 exit status

[Bug target/116883] Compile cpp code with rv32imafc_zve32f failed

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #3 from Li Pan  ---
I think xuli is working on this issue. As you know, the first week of Oct is
the National Holiday.

[Bug target/116883] Compile cpp code with rv32imafc_zve32f failed

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #4 from Huaqi  ---
(In reply to Li Pan from comment #3)
> I think xuli is working on this issue. As you know, the first week of Oct is
> the National Holiday.

Ok, thanks, just confirm this issue is acked.

[Bug c++/117034] New: ICE on abbreviated function template with type constraint containing a lambda argument

[eczbek.void at gmail dot com via Gcc-bugs]

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

Bug ID: 117034
   Summary: ICE on abbreviated function template with type
constraint containing a lambda argument
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eczbek.void at gmail dot com
  Target Milestone: ---

This causes an ICE:



```
template
concept A = true;

void f(A<[] {}> auto) {}
```



Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20241008/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2 --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc-14870c1f8636feaa45eac1133ce5b9228225d8bd-binutils-2.42
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241008 (experimental)
(Compiler-Explorer-Build-gcc-14870c1f8636feaa45eac1133ce5b9228225d8bd-binutils-2.42)
 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-fno-verbose-asm' '-S' '-std=c++20' '-v' '-freport-bug'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'

/opt/compiler-explorer/gcc-trunk-20241008/bin/../libexec/gcc/x86_64-linux-gnu/15.0.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/
-D_GNU_SOURCE  -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -std=c++20 -version
-fdiagnostics-color=always -fno-verbose-asm -freport-bug -o /app/output.s
GNU C++20
(Compiler-Explorer-Build-gcc-14870c1f8636feaa45eac1133ce5b9228225d8bd-binutils-2.42)
version 15.0.0 20241008 (experimental) (x86_64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/backward"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/include-fixed/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0

/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/x86_64-linux-gnu

/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/../../../../include/c++/15.0.0/backward

/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/include

/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/include-fixed/x86_64-linux-gnu

/opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/x86_64-linux-gnu/15.0.0/include-fixed
 /usr/local/include
 /opt/compiler-explorer/gcc-trunk-20241008/bin/../lib/gcc/../../include
 /usr/include/x86_64-linux-gnu
 /usr/include
En

[Bug ada/115376] ICE with if expression in value setting of a constant declaration

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

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

--- Comment #6 from Eric Botcazou  ---
Great, thanks for checking!

[Bug tree-optimization/117032] missing vectorization of V4HI to V4DF

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-08

--- Comment #1 from Tamar Christina  ---
Confirmed.

Note that we miss the general case (e.g. without the FLOAT_EXPR) for both
direct and indirect.

static inline 
void g(unsigned short *a, int *b)
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
}
static inline 
void g2(int *a, long long *b)
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
}

void indirect(unsigned short *a, long long *b)
{
  int t[4];
  g(a, t);
  g2(t, b);
}

void direct(unsigned short *a, long long *b)
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
}

This is due to the way vec_unpack is implemented in the backend.
We rewrite it the mode to VHALF to model the intermediate vec_select, however
that means that V4HI is unmodel-able as that requires a V2HI.

I have a patch that adds direct conversion support, but this fails atm due
to the aarch64 backend not supporting 64-bit to 128-bit vector permutes yet
until another series of mine gets in.

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

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

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

Bug 89808 Summary: An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808

   What|Removed |Added

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

[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"

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

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

Ken Matsui  changed:

   What|Removed |Added

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

--- Comment #17 from Ken Matsui  ---
Thank you for your report, sduguay.  This issue has been resolved in
https://gcc.gnu.org/g:821d56100e1110ab6a166f50819522254eb30923.

[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/117035] New: ICE in unify, at cp/pt.cc:25410, when specifying lambda expression template argument in partial specialization

[guyutongxue at 163 dot com via Gcc-bugs]

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

Bug ID: 117035
   Summary: ICE in unify, at cp/pt.cc:25410, when specifying
lambda expression template argument in partial
specialization
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guyutongxue at 163 dot com
  Target Milestone: ---

```
template 
struct Foo {};

template 
struct Foo {};

constexpr auto oops = Foo<0>{};
```

causes GCC ICE in all versions from 9.1 to current trunk (15.0). 
Clang and MSVC compiles, while EDG rejects this code. Godbolt: 
https://godbolt.org/z/xWToxf39b


GCC 14.2.0 output:

:7:30: internal compiler error: in unify, at cp/pt.cc:25410
7 | constexpr auto oops = Foo<0>{};
  |  ^
0x2031cbc internal_error(char const*, ...)
???:0
0x77895f fancy_abort(char const*, int, char const*)
???:0
0x928a6d most_specialized_partial_spec(tree_node*, int, bool)
???:0
0x94c21e instantiate_class_template(tree_node*)
???:0
0x98936b complete_type(tree_node*)
???:0
0x95f4d9 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x90ee14 c_parse_file()
???:0
0xa0d1b9 c_common_parse_file()
???:0

[Bug middle-end/117037] gcc14.2.1 riscv64-unknown-linux-gnu-g++ build opencv 5.x error

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |middle-end
 Target||riscv
   Last reconfirmed||2024-10-09
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source as requested by
https://gcc.gnu.org/bugs/ ?

[Bug c++/117037] New: gcc14.2.1 riscv64-unknown-linux-gnu-g++ build opencv 5.x error

[bigmagicreadsun at gmail dot com via Gcc-bugs]

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

Bug ID: 117037
   Summary: gcc14.2.1 riscv64-unknown-linux-gnu-g++ build opencv
5.x error
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bigmagicreadsun at gmail dot com
  Target Milestone: ---

When compiling OpenCV 5.x with riscv64-unknown-linux-gnu-g++, the following
error occurs.

set(CMAKE_C_FLAGS_INIT "-march=rv64imafdcv -mabi=lp64d -O3 -static")
set(CMAKE_CXX_FLAGS_INIT "-march=rv64imafdcv -mabi=lp64d -O3 -static")

opencv/modules/dnn/src/layers/reduce_layer.cpp: In member function 'void
cv::dnn::ReduceLayerImpl::ReduceAllInvoker::operator()(const cv::Range&)
const [with Op = cv::dnn::ReduceLayerImpl::ReduceProd]':
/Local/home/zhaofujin/opencv/opencv/modules/dnn/src/layers/reduce_layer.cpp:290:14:
internal compiler error: in vect_create_partial_epilog, at
tree-vect-loop.cc:5866
  290 | void operator()(const Range& r) const CV_OVERRIDE {
  |  ^~~~
0x7f5a1f485082 __libc_start_main
../csu/libc-start.c:308
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.
make[2]: *** [modules/dnn/CMakeFiles/opencv_dnn.dir/build.make:1181:
modules/dnn/CMakeFiles/opencv_dnn.dir/src/layers/reduce_layer.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs



The code where the error occurs in reduce_layer.cpp is as follows:



ReduceAllInvoker(const Mat& src_, Mat& dst_) : src(src_), dst(dst_) {
auto shape_src = shape(src);

n_reduce = std::accumulate(shape_src.begin(), shape_src.end(), 1,
std::multiplies());
loop_size = n_reduce;

total = 1;
cost_per_thread = 1;
}

void operator()(const Range& r) const CV_OVERRIDE {
int start = r.start;
int end = r.end;

const dtype* p_src = src.ptr();
dtype* p_dst = dst.ptr();

for (int i = start; i < end; ++i) {
Op accumulator(n_reduce, *p_src);
for (int l = 0; l < loop_size; ++l) {
accumulator.update(p_src[l]);
}
p_dst[i] = accumulator.get_value();
}
}

This error seems to be related to g++'s generation logic for RVV.

[Bug tree-optimization/117041] New: ICE on valid code at -O3 on x86_64-linux-gnu: in vectorizable_load, at tree-vect-stmts.cc:10327

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

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

Bug ID: 117041
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in
vectorizable_load, at tree-vect-stmts.cc:10327
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression as it doesn't reproduce with 14.2 and
earlier.

Compiler Explorer: https://godbolt.org/z/oaM8cWM96

[533] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241009 (experimental) (GCC)
[534] %
[534] % gcctk -O3 small.c
during GIMPLE pass: vect
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in vectorizable_load, at
tree-vect-stmts.cc:10327
3 | int main() {
  | ^~~~
0x2611df5 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0xa7faf0 fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1617
0x8ee2da vectorizable_load
../../gcc-trunk/gcc/tree-vect-stmts.cc:10327
0x14ae36a vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
../../gcc-trunk/gcc/tree-vect-stmts.cc:13428
0x1511806 vect_slp_analyze_node_operations_1
../../gcc-trunk/gcc/tree-vect-slp.cc:7402
0x1511806 vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.cc:7606
0x151171c vect_slp_analyze_node_operations
../../gcc-trunk/gcc/tree-vect-slp.cc:7583
0x151373f vect_slp_analyze_operations(vec_info*)
../../gcc-trunk/gcc/tree-vect-slp.cc:8001
0x14d9887 vect_analyze_loop_2
../../gcc-trunk/gcc/tree-vect-loop.cc:2977
0x14db603 vect_analyze_loop_1
../../gcc-trunk/gcc/tree-vect-loop.cc:3452
0x14dbdde vect_analyze_loop(loop*, gimple*, vec_info_shared*)
../../gcc-trunk/gcc/tree-vect-loop.cc:3612
0x1529926 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.cc:1071
0x1529926 try_vectorize_loop
../../gcc-trunk/gcc/tree-vectorizer.cc:1187
0x152a1fc execute
../../gcc-trunk/gcc/tree-vectorizer.cc:1303
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.
[535] %
[535] % cat small.c
unsigned short a;
int b, c[7][6];
int main() {
  for (a = 0; a < 6; a++)
for (b = 5; b; b--)
  c[a][b] = c[a+1][b];
  return 0;
}

[Bug ada/117018] internal error on nested iterated component associations

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
Summary|Compiler error with |internal error on nested
   |iterated array aggregate|iterated component
   ||associations

[Bug c++/117040] New: g++ crashed for __alignof and got internal compiler error: in poplevel, at cp/decl.cc:643

[yihan4845 at gmail dot com via Gcc-bugs]

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

Bug ID: 117040
   Summary: g++ crashed for __alignof and got internal compiler
error: in poplevel, at cp/decl.cc:643
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yihan4845 at gmail dot com
  Target Milestone: ---

The following illformed code crashes current gcc trunk. This code was generated
by a fuzzer.

Compiler Explorer: https://godbolt.org/z/E8hYfzraz

Code:

_Alignof(auto);
struct S {
int t;
};

Stack dump:

:3:9: internal compiler error: in poplevel, at cp/decl.cc:643
0x283dbf5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x28515d5 internal_error(char const*, ...)
???:0
0xa87f78 fancy_abort(char const*, int, char const*)
???:0
0xc9e5f0 end_template_decl()
???:0
0xc954ca c_parse_file()
???:0
0xded089 c_common_parse_file()
???:0
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.
Compiler returned: 1

[Bug middle-end/116997] [13/14/15 Regression] Wrong bitfield accesses since r13-3219-g25413fdb2ac249

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

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
I gave it a try on s390 and I also end up with

MEM  [(void *)Ptr.0_1] = { 7, 6291456 };

Thanks for the very fast fix :)

[Bug libstdc++/117016] Alignment requirements of std::simd too large

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

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

--- Comment #5 from Matthias Kretz (Vir)  ---
Wrt. working on a larger data set you might be interested in:
https://github.com/mattkretz/vir-simd?tab=readme-ov-file#simd-execution-policy-p0350

For the problem you seem to describe, I like to have a native_simd-aligned
array of scalars and then iterate over it using native_simd. If your algorithm
allows, the simplest epilogue is allocation of some extra values (this
allocation is free, because of alignment and how allocators work) and then
simply process a few more inputs and ignore the outputs from the padding.

[Bug ada/117018] Compiler error with iterated array aggregate

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-09
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
Yes, removing the call has exactly the same effect internally as "constant".

[Bug ada/113036] crash on default value with nested iterated component associations

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

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

Eric Botcazou  changed:

   What|Removed |Added

Version|14.0|14.2.1
Summary|assertion failure on|crash on default value with
   |default value that is a |nested iterated component
   |nested iterated aggregate   |associations

--- Comment #2 from Eric Botcazou  ---
This crashes with released compilers:

+===GNAT BUG DETECTED==+
| 14.2.1 20241004 [gcc-14 r14-10744-g7363d73e263] (x86_64-suse-linux)  |
| Storage_Error stack overflow or erroneous memory access  |
| Error detected at p2.adb:7:4 |

[Bug ada/113036] crash on default value with nested iterated component associations

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug ada/89786] ice in add_expr, at tree.c:7767

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug c++/117042] New: internal compiler error: Segmentation fault in tsubst(tree_node*, tree_node*, int, tree_node*)

[yihan4845 at gmail dot com via Gcc-bugs]

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

Bug ID: 117042
   Summary: internal compiler error: Segmentation fault in
tsubst(tree_node*, tree_node*, int, tree_node*)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yihan4845 at gmail dot com
  Target Milestone: ---

The following illformed code crashes current gcc trunk. This code was generated
by a fuzzer.

Compiler Explorer: https://godbolt.org/z/bvzxP455G

Code:

template 
struct Future {
  explicit Future(T v);
  template 
  auto call(F&& fn) -> decltype(v(T())) {}
  template 
  auto then(F&& fn) -> decltype(call(fn)) {}
};
Future f;

Stack dump:

0x283dbf5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x28515d5 internal_error(char const*, ...)
???:0
0xcd3068 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xcd276d tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xcf5edc instantiate_class_template(tree_node*)
???:0
0xb4b9a9 start_decl_1(tree_node*, bool)
???:0
0xb6e5cf start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0xc954ca c_parse_file()
???:0
0xded089 c_common_parse_file()
???:0
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.
Compiler returned: 1

[Bug target/116883] Compile cpp code with rv32imafc_zve32f failed

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #2 from Huaqi  ---
Hi there, I tested with godbolt.org with latest gcc15(trunk), this issue still
exists, and gcc14.2 still fail.

/opt/compiler-explorer/riscv32/gcc-trunk-20241008/riscv32-unknown-linux-gnu/lib/gcc/riscv32-unknown-linux-gnu/15.0.0/include/riscv_vector.h:40:25:
error: ambiguating new declaration of 'vint64m4_t __riscv_vle64(vbool16_t,
const long long int*, unsigned int)'
   40 | #pragma riscv intrinsic "vector"
  | ^~~~


https://godbolt.org/z/Wfjvefnex

Can anybody take a look at it

[Bug target/117036] New: [SH] add __builtin_sh_fsca, __builtin_sh_fsrra

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

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

Bug ID: 117036
   Summary: [SH] add __builtin_sh_fsca, __builtin_sh_fsrra
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---

Currently the compiler will convert std::sin, std::cos, 1/std::sqrt into fsca
and fsrra instruction when e.g. --fast-math is enabled.

However, there are cases where users want to emit those instructions directly,
regardless of optimization settings.  E.g. to implement platform specific
fast-math functions/libraries.

[Bug bootstrap/117039] New: [15 Regression] Build failure: libcpp/directives.cc:2078:34: error: unknown conversion type character '>' in format [-Werror=format=]

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

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

Bug ID: 117039
   Summary: [15 Regression] Build failure:
libcpp/directives.cc:2078:34: error: unknown
conversion type character '>' in format
[-Werror=format=]
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed build failure on today's gcc-master from r15-4191-g821d56100e1110:

I suspect r15-4191-g821d56100e1110 to be a culprit.

/tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 
-I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/slyfox/dev/git/gcc/libcpp -I.
-I/home/slyfox/dev/git/gcc/libcpp/../include
-I/home/slyfox/dev/git/gcc/libcpp/include  -g -O2 -fno-checking -gtoggle -W
-Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic
-Wno-long-long -Werror -fno-exceptions -fno-rtti
-I/home/slyfox/dev/git/gcc/libcpp -I.
-I/home/slyfox/dev/git/gcc/libcpp/../include
-I/home/slyfox/dev/git/gcc/libcpp/include-c -o directives.o -MT
directives.o -MMD -MP -MF .deps/directives.Tpo
/home/slyfox/dev/git/gcc/libcpp/directives.cc
/home/slyfox/dev/git/gcc/libcpp/directives.cc: In function 'void
do_pragma_once(cpp_reader*)':
/home/slyfox/dev/git/gcc/libcpp/directives.cc:2078:20: error: unknown
conversion type character '<' in format [-Werror=format=]
 2078 |  "%<#pragma once%> in main file");
  |^
/home/slyfox/dev/git/gcc/libcpp/directives.cc:2078:34: error: unknown
conversion type character '>' in format [-Werror=format=]
 2078 |  "%<#pragma once%> in main file");
  |  ^

$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v
Reading specs from /tmp/gb/./prev-gcc/specs
COLLECT_GCC=/tmp/gb/./prev-gcc/xg++
COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241009 (experimental) (GCC)

[Bug target/80881] Implement Windows native TLS

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

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #59295|0   |1
is obsolete||

--- Comment #33 from Eric Botcazou  ---
Created attachment 59298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59298&action=edit
WIP patch

[Bug tree-optimization/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3

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

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

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

https://gcc.gnu.org/g:0883c88664d48463dfc79335dccaf15a69230952

commit r15-4186-g0883c88664d48463dfc79335dccaf15a69230952
Author: Artemiy Volkov 
Date:   Tue Oct 8 17:51:08 2024 -0600

tree-optimization/116024 - simplify C1-X cmp C2 for UB-on-overflow types

Implement a match.pd pattern for C1 - X cmp C2, where C1 and C2 are
integer constants and X is of a UB-on-overflow type.  The pattern is
simplified to X rcmp C1 - C2 by moving X and C2 to the other side of the
comparison (with opposite signs).  If C1 - C2 happens to overflow,
replace the whole expression with either a constant 0 or a constant 1
node, depending on the comparison operator and the sign of the overflow.

This transformation allows to occasionally save load-immediate /
subtraction instructions, e.g. the following statement:

10 - (int) x <= 9;

now compiles to

sgt a0,a0,zero

instead of

li  a5,10
sub a0,a5,a0
sltia0,a0,10

on 32-bit RISC-V.

Additional examples can be found in the newly added test file. This
patch has been bootstrapped and regtested on aarch64, x86_64, and
i386, and additionally regtested on riscv32.  Existing tests were
adjusted where necessary.

gcc/ChangeLog:

PR tree-optimization/116024
* match.pd: New transformation around integer comparison.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr116024.c: New test.
* gcc.dg/pr67089-6.c: Adjust.

[Bug tree-optimization/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3

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

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

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

https://gcc.gnu.org/g:65b33d43d29b148e127b1ba997f1bbc2c7028b94

commit r15-4187-g65b33d43d29b148e127b1ba997f1bbc2c7028b94
Author: Artemiy Volkov 
Date:   Tue Oct 8 17:54:55 2024 -0600

tree-optimization/116024 - simplify C1-X cmp C2 for unsigned types

Implement a match.pd transformation inverting the sign of X in
C1 - X cmp C2, where C1 and C2 are integer constants and X is
of an unsigned type, by observing that:

(a) If cmp is == or !=, simply move X and C2 to opposite sides of the
comparison to arrive at X cmp C1 - C2.

(b) If cmp is <:
- C1 - X < C2 means that C1 - X spans the range of 0, 1, ..., C2 -
1;
- This means that X spans the range of C1 - (C2 - 1),
  C1 - (C2 - 2), ..., C1;
- Subtracting C1 - (C2 - 1), X - (C1 - (C2 - 1)) is one of 0, 1,
  ..., C1 - (C1 - (C2 - 1));
- Simplifying the above, X - (C1 - C2 + 1) is one of 0, 1, ...,
 C2 - 1;
- Summarizing, the expression C1 - X < C2 can be transformed
  into X - (C1 - C2 + 1) < C2.

(c) Similarly, if cmp is <=:
- C1 - X <= C2 means that C1 - X is one of 0, 1, ..., C2;
- It follows that X is one of C1 - C2, C1 - (C2 - 1), ..., C1;
- Subtracting C1 - C2, X - (C1 - C2) has range 0, 1, ..., C2;
- Thus, the expression C1 - X <= C2 can be transformed into
  X - (C1 - C2) <= C2.

(d) The >= and > cases are negations of (b) and (c), respectively.

This transformation allows to occasionally save load-immediate /
subtraction instructions, e.g. the following statement:

300 - (unsigned int)f() < 100;

now compiles to

addia0,a0,-201
sltiu   a0,a0,100

instead of

li  a5,300
sub a0,a5,a0
sltiu   a0,a0,100

on 32-bit RISC-V.

Additional examples can be found in the newly added test file.  This
patch has been bootstrapped and regtested on aarch64, x86_64, and i386,
and additionally regtested on riscv32.

gcc/ChangeLog:

PR tree-optimization/116024
* match.pd: New transformation around integer comparison.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr116024-1.c: New test.

[Bug tree-optimization/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3

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

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

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

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

commit r15-4188-ge5f5cffb8c8243896a9d3bd0e2b8f14c70f8df1e
Author: Artemiy Volkov 
Date:   Tue Oct 8 18:04:13 2024 -0600

tree-optimization/116024 - simplify C1-X cmp C2 for wrapping signed types

Implement a match.pd transformation inverting the sign of X in
C1 - X cmp C2, where C1 and C2 are integer constants and X is
of a wrapping signed type, by observing that:

(a) If cmp is == or !=, simply move X and C2 to opposite sides of
the comparison to arrive at X cmp C1 - C2.

(b) If cmp is <:
- C1 - X < C2 means that C1 - X spans the values of -INF,
  -INF + 1, ..., C2 - 1;
- Therefore, X is one of C1 - -INF, C1 - (-INF + 1), ...,
  C1 - C2 + 1;
- Subtracting (C1 + 1), X - (C1 + 1) is one of - (-INF) - 1,
  - (-INF) - 2, ..., -C2;
- Using the fact that - (-INF) - 1 is +INF, derive that
  X - (C1 + 1) spans the values +INF, +INF - 1, ..., -C2;
- Thus, the original expression can be simplified to
  X - (C1 + 1) > -C2 - 1.

(c) Similarly, C1 - X <= C2 is equivalent to X - (C1 + 1) >= -C2 - 1.

(d) The >= and > cases are negations of (b) and (c), respectively.

(e) In all cases, the expression -C2 - 1 can be shortened to
bit_not (C2).

This transformation allows to occasionally save load-immediate /
subtraction instructions, e.g. the following statement:

10 - (int)f() >= 20;

now compiles to

addia0,a0,-11
sltia0,a0,-20

instead of

li  a5,10
sub a0,a5,a0
sltit0,a0,20
xoria0,t0,1

on 32-bit RISC-V when compiled with -fwrapv.

Additional examples can be found in the newly added test file.  This
patch has been bootstrapped and regtested on aarch64, x86_64, and i386,
and additionally regtested on riscv32.

gcc/ChangeLog:

PR tree-optimization/116024
* match.pd: New transformation around integer comparison.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr116024-1-fwrapv.c: New test.

[Bug tree-optimization/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3

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

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

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

https://gcc.gnu.org/g:52fdf1e7eb89a148a9cdd1daade524f4540ab5fa

commit r15-4189-g52fdf1e7eb89a148a9cdd1daade524f4540ab5fa
Author: Artemiy Volkov 
Date:   Tue Oct 8 18:06:23 2024 -0600

tree-optimization/116024 - simplify some cases of X +- C1 cmp C2

Whenever C1 and C2 are integer constants, X is of a wrapping type, and
cmp is a relational operator, the expression X +- C1 cmp C2 can be
simplified in the following cases:

(a) If cmp is <= and C2 -+ C1 == +INF(1), we can transform the initial
comparison in the following way:
   X +- C1 <= C2
   -INF <= X +- C1 <= C2 (add left hand side which holds for any X, C1)
   -INF -+ C1 <= X <= C2 -+ C1 (add -+C1 to all 3 expressions)
   -INF -+ C1 <= X <= +INF (due to (1))
   -INF -+ C1 <= X (eliminate the right hand side since it holds for any X)

(b) By analogy, if cmp if >= and C2 -+ C1 == -INF(1), use the following
sequence of transformations:

   X +- C1 >= C2
   +INF >= X +- C1 >= C2 (add left hand side which holds for any X, C1)
   +INF -+ C1 >= X >= C2 -+ C1 (add -+C1 to all 3 expressions)
   +INF -+ C1 >= X >= -INF (due to (1))
   +INF -+ C1 >= X (eliminate the right hand side since it holds for any X)

(c) The > and < cases are negations of (a) and (b), respectively.

This transformation allows to occasionally save add / sub instructions,
for instance the expression

3 + (uint32_t)f() < 2

compiles to

cmn w0, #4
csetw0, ls

instead of

add w0, w0, 3
cmp w0, 2
csetw0, ls

on aarch64.

Testcases that go together with this patch have been split into two
separate files, one containing testcases for unsigned variables and the
other for wrapping signed ones (and thus compiled with -fwrapv).
Additionally, one aarch64 test has been adjusted since the patch has
caused the generated code to change from

cmn w0, #2
csinc   w0, w1, wzr, cc   (x < -2)

to

cmn w0, #3
csinc   w0, w1, wzr, cs   (x <= -3)

This patch has been bootstrapped and regtested on aarch64, x86_64, and
i386, and additionally regtested on riscv32.

gcc/ChangeLog:

PR tree-optimization/116024
* match.pd: New transformation around integer comparison.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr116024-2.c: New test.
* gcc.dg/tree-ssa/pr116024-2-fwrapv.c: Ditto.
* gcc.target/aarch64/gtu_to_ltu_cmp_1.c: Adjust.

[Bug tree-optimization/116024] [14/15 Regression] unnecessary integer comparison(s) for a simple loop since r14-5628-g53ba8d669550d3

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #13 from Jeffrey A. Law  ---
Should be fixed on the trunk now.

[Bug ada/117038] New: [15 regression] Ada bootstrap fails with LTO errors (fe.h:361:23: error: type of ‘sinput__c_source_buffer’ does not match original declaration [-Werror=lto-type-mismatch])

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

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

Bug ID: 117038
   Summary: [15 regression] Ada bootstrap fails with LTO errors
(fe.h:361:23: error: type of ‘sinput__c_source_buffer’
does not match original declaration
[-Werror=lto-type-mismatch])
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Bootstrapping with Ada fails when using -Werror=lto-type-mismatch -Werror=odr:
```
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/ada/fe.h:361:23:
error: type of ‘sinput__c_source_buffer’ does not match original declaration
[-Werror=lto-type-mismatch]
  361 | extern struct c_array C_Source_Buffer (Source_File_Index);
  |   ^
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/ada/sinput.adb:283:4:
note: return value type mismatch
  283 |function C_Source_Buffer (S : SFI) return C_Array is
  |^
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/ada/sinput.adb:283:4:
note: type ‘struct sinput__c_array’ should match type ‘struct c_array’
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/ada/fe.h:350:8:
note: the incompatible type is defined here
  350 | struct c_array {
  |^
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/ada/sinput.adb:283:4:
note: ‘sinput__c_source_buffer’ was previously declared here
  283 |function C_Source_Buffer (S : SFI) return C_Array is
  |^
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/ada/sinput.adb:283:4:
note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
lto1: some warnings being treated as errors
```

This seems to have regressed with yesterday's Ada patches.

[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array

[dl.soluz at gmx dot net via Gcc-bugs]

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

--- Comment #18 from dennis luehring  ---
rechecked it with godbolt gcc-trunk and 14.2
gcc still does not optimize the std::vector case

clang is doing the optimization for at least 11 years

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #34 from Julian Waters  ---
(In reply to Eric Botcazou from comment #32)
> > It's a bit of a shame I couldn't figure out how to make the zero extend
> > approach work correctly. That aside, I'm concerned that this patch still
> > isn't correct, because it doesn't seem to be using the parallel rtx
> > correctly.
> 
> No worries, it's the standard way of requesting a scratch register, and
> nothing will try to use the result of a CLOBBER on it.  That being said, we
> could indeed try and split the instructions for better scheduling, although
> the TLS pattern for the Sun linker is multi-insn too, see
> tls_initial_exec_64_sun.
> 
> I'm attaching a minor update which uses named insns to simplify the code.

Perhaps splitting the 3 instructions that make up the thread pointer load into
the 2 instructions that can be done in parallel and the last one that depends
on the 2 is an enhancement that can be done, yes. Right now it seems like gcc
cannot compile libgomp again though, this time when done with bootstrap enabled

../../../gcc-14.2.0/libgomp/team.c: In function 'gomp_team_start':
../../../gcc-14.2.0/libgomp/team.c:940:1: error: unrecognizable insn:
  940 | }
  | ^
(insn 290 289 291 12 (set (reg:DI 406)
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("gomp_tls_data") [flags 0x2a] )
] UNSPEC_SECREL32)
(const_int 16 [0x10]
"../../../gcc-14.2.0/libgomp/team.c":354:17 -1
 (nil))
during RTL pass: vregs

The corresponding command line was

libtool: compile: 
/c/Users/vertig0/Downloads/eclipse-committers-2023-12-R-win32-x86_64/Workspace/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/./gcc/xgcc
-B/c/Users/vertig0/Downloads/eclipse-committers-2023-12-R-win32-x86_64/Workspace/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/./gcc/
-L/c/Users/vertig0/Downloads/eclipse-committers-2023-12-R-win32-x86_64/Workspace/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/./gcc
-isystem /ucrt64/x86_64-w64-mingw32/include -isystem /ucrt64/include
-B/ucrt64/x86_64-w64-mingw32/bin/ -B/ucrt64/x86_64-w64-mingw32/lib/ -isystem
/ucrt64/x86_64-w64-mingw32/include -isystem
/ucrt64/x86_64-w64-mingw32/sys-include -fno-checking -DHAVE_CONFIG_H -I.
-I../../../gcc-14.2.0/libgomp -I../../../gcc-14.2.0/libgomp/config/mingw32
-I../../../gcc-14.2.0/libgomp/config/posix -I../../../gcc-14.2.0/libgomp
-I../../../gcc-14.2.0/libgomp/../include -pthread -Wall -g -march=nocona -msahf
-mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong
-Wp,-D__USE_MINGW_ANSI_STDIO=1 -MT team.lo -MD -MP -MF .deps/team.Tpo -c
../../../gcc-14.2.0/libgomp/team.c  -DDLL_EXPORT -DPIC -o .libs/team.o

I will work on trying to fix this and creating a reproducer for the issue. The
patch used here is slightly different because I'm testing it on gcc 14

[Bug ada/117038] [15 regression] Ada bootstrap fails with LTO errors (fe.h:361:23: error: type of ‘sinput__c_source_buffer’ does not match original declaration [-Werror=lto-type-mismatch])

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

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

--- Comment #1 from Sam James  ---
r15-4141-g7e09f16ef98088

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #35 from Julian Waters  ---
Created attachment 59300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59300&action=edit
gcc 14 version, broken

[Bug ada/117038] [15 regression] Ada bootstrap fails with LTO errors (fe.h:361:23: error: type of ‘sinput__c_source_buffer’ does not match original declaration [-Werror=lto-type-mismatch]) since r15-4

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/96945] unused std::vector is not always optimized away

[dl.soluz at gmx dot net via Gcc-bugs]

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

dennis luehring  changed:

   What|Removed |Added

 CC||dl.soluz at gmx dot net

--- Comment #3 from dennis luehring  ---
still gets not optimized away by gcc-14.2, because gcc isn't allowed to remove
the new/delete

[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471

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

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

--- Comment #12 from John David Anglin  ---
See comment #3 in glibc bug.

[Bug c++/89088] Dllexport for explicit template instantiation missing inline methods

[dkk089 at gmail dot com via Gcc-bugs]

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

Daniel Kamil Kozar  changed:

   What|Removed |Added

 CC||dkk089 at gmail dot com

--- Comment #3 from Daniel Kamil Kozar  ---
Still present in 13.2.0.

[Bug libstdc++/117016] Alignment requirements of std::simd too large

[pieter.p.dev at outlook dot com via Gcc-bugs]

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

--- Comment #4 from Pieter P  ---
Thank you, I appreciate for the quick responses.

> The design goal of the fixed_size ABI was an ABI-stable "this is never going 
> to break on ABI boundaries" type.

You're right, ABI stability is not something I considered.

> Not really. Considering operator new gets passed the alignment since c++17.

Indeed, but allocation is not the issue I was struggling with: I wanted to be
able to have the simple requirement that "all array arguments should be aligned
to the native SIMD size" for the user-facing APIs, and then decide on the
optimal SIMD size in the underlying algorithm, as an implementation detail.

The algorithm may encounter remainders that are not multiples of the native
SIMD sizes, and I was using the fixed_size_simd type to handle those. As a
work-around, I'll just have to implement the remainders manually using multiple
smaller native SIMD types and/or masks, rather than using fixed_size_simd.

[Bug target/80881] Implement Windows native TLS

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #31 from Julian Waters  ---
(In reply to Eric Botcazou from comment #30)
> AFAICT the last missing piece is the configure check for the linker.

It's a bit of a shame I couldn't figure out how to make the zero extend
approach work correctly. That aside, I'm concerned that this patch still isn't
correct, because it doesn't seem to be using the parallel rtx correctly. From
what I can gather parallel is meant for multiple operations to run at the same
time, which crucially means results from one operation cannot be assumed to be
available for the next operation inside a parallel, which is exactly what this
patch is doing, since it's using the results from the first 2 instructions to
calculate the base thread pointer. I've tried to do this the "correct" way by
splitting the part of the thread pointer load that can be done in parallel into
one insn (In particular trying to use UNSPEC_PCREL) and the actual calculation
of the base pointer into another, but both insns are not recognized by gcc. I
don't know how to circumvent this issue at the moment

[Bug ada/115535] negative value returned by 'Image for array with nonnegative integer component

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Marc Poulhi?s :

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

commit r15-4161-gcfbee1856f5125bbabc28088f62a86f3dee5a159
Author: Eric Botcazou 
Date:   Wed Sep 11 19:37:08 2024 +0200

ada: Fix negative value returned by 'Image for array with nonnegative
component

The problem is that Exp_Put_Image.Build_Elementary_Put_Image_Call uses the
signedness of the base type but the size of the first subtype, hence the
discrepancy between them.

gcc/ada/ChangeLog:
PR ada/115535
* exp_put_image.adb (Build_Elementary_Put_Image_Call): Use the size
of the underlying type to find the support type.

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Marc Poulhi?s :

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

commit r15-4162-gd77ba2eec2a560514de162bf9499194250f291e2
Author: Eric Botcazou 
Date:   Wed Sep 11 19:42:03 2024 +0200

ada: Fix bogus error in instantiation with formal package

The compiler reports that an actual does not match the formal when there
is a defaulted formal discrete type because Check_Formal_Package_Instance
fails to skip the implicit base type generated by the compiler.

gcc/ada/ChangeLog:
PR ada/114636
* sem_ch12.adb (Check_Formal_Package_Instance): For a defaulted
formal discrete type, skip the generated implicit base type.

[Bug ada/115507] bogus Constraint_Error for 'Wide_Wide_Value on wide enumeration literal

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Marc Poulhi?s :

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

commit r15-4163-gc4d9a73e12b25a9f0ac152df2da5ceac80bd9d6a
Author: Eric Botcazou 
Date:   Thu Sep 12 12:45:27 2024 +0200

ada: Fix bogus Constraint_Error for 'Wide_Wide_Value on wide enumeration
literal

The problem is that 'Wide_Wide_Value is piggybacked on 'Value and the
latter
invokes System.Val_Util.Normalize_String, which incorrectly normalizes the
input string in the presence of enumeration literals with wide characters.

gcc/ada/ChangeLog:
PR ada/115507
* exp_imgv.adb (Expand_Valid_Value_Attribute): Add actual parameter
for Is_Wide formal in the call to Valid_Value_Enumeration_NN.
(Expand_Value_Attribute): Likewise.
* libgnat/s-vaen16.ads (Value_Enumeration_16): Add Is_Wide formal.
(Valid_Value_Enumeration_16): Likewise.
* libgnat/s-vaen32.ads (Value_Enumeration_32): Likewise.
(Valid_Value_Enumeration_32): Likewise.
* libgnat/s-vaenu8.ads (Value_Enumeration_8): Likewise.
(Valid_Value_Enumeration_8): Likewise.
* libgnat/s-valboo.adb (Value_Boolean): Pass True for To_Upper_Case
formal parameter in call to Normalize_String.
* libgnat/s-valcha.adb (Value_Character): Likewise.
* libgnat/s-valuen.ads (Value_Enumeration): Add Is_Wide formal.
(Valid_Value_Enumeration): Likewise.
* libgnat/s-valuen.adb (Value_Enumeration_Pos): Likewise and pass
its negation for To_Upper_Case formal in call to Normalize_String.
(Valid_Value_Enumeration): Add Is_Wide formal and forward it in
call to Value_Enumeration_Pos.
(Value_Enumeration): Likewise.
* libgnat/s-valuti.ads (Normalize_String): Add To_Upper_Case formal
parameter and adjust post-condition accordingly.
* libgnat/s-valuti.adb (Normalize_String): Add To_Upper_Case formal
parameter and adjust implementation accordingly.
* libgnat/s-valwch.adb (Value_Wide_Wide_Character): Pass False for
To_Upper_Case formal parameter in call to Normalize_String.

[Bug target/116979] [12/13/14/15 regression] fma not always used in complex product

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #7 from vincenzo Innocente  ---
hadcrafted x86 code would look like this
scalar code:

   vmovss  xmm0, dword ptr [rdi]
   vmovss  xmm1, dword ptr [rdi + 4]
   vmovss  xmm2, dword ptr [rsi]
   vmovss  xmm3, dword ptr [rsi + 4]
   vmulss  xmm4, xmm3, xmm1
   vmulss  xmm1, xmm2, xmm1
   vfmsub231ss xmm4, xmm0, xmm2
   vfmadd231ss xmm1, xmm3, xmm0
   vinsertps   xmm0, xmm4, xmm1, 16
   ret

and vector code:

   vmovsdxmm3, QWORD PTR [rdi]
   vmovshdup xmm1, QWORD PTR [rsi]   
   vmovsldup xmm0, QWORD PTR [rsi]
   vshufps   xmm2, xmm3, xmm3, 177  
   vmulpsxmm4, xmm1, xmm2  
   vfmaddsub213ps xmm0, xmm3, xmm4
   ret

scalar:  4 loads, 2 multiplies, 2 FMA
vector:  3 loads, 1 shuffle, 1 multiply, 1 FMA

Note that the hardware instructions vmovshdup and vmovsldup use only the load
ports.

so the vector code should be even faster with the use of fma

[Bug ada/114640] internal error on elsif part of if-statement containing if-expression

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Marc Poulhi?s :

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

commit r15-4160-gda2a85ac53cbb9a9162cfb9a6da1c2bd47fc0b1b
Author: Eric Botcazou 
Date:   Wed Sep 11 19:26:18 2024 +0200

ada: Fix internal error on elsif part of if-statement containing
if-expression

The problem occurs when the compiler is trying to find a context to which
it can hoist finalization actions coming from the if-expression, because
Find_Hook_Context incorrectly returns the N_Elsif_Part node.

gcc/ada/ChangeLog:
PR ada/114640
* exp_util.adb (Find_Hook_Context): For a node present within a
conditional expression, do not return an N_Elsif_Part node.

[Bug ada/116498] infinite loop on MSP430 with -mlarge flag

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Marc Poulhi?s :

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

commit r15-4166-g9fd38cc5d636124f0611aa5d26ac4258431f164a
Author: Eric Botcazou 
Date:   Wed Sep 11 20:15:32 2024 +0200

ada: Fix infinite loop on MSP430 with -mlarge flag

This removes the loop trying to find a pointer mode among the integer
modes,
which is obsolete and does not work on platforms where pointers have
unusual
size like MSP430 or special semantics like Morello.

gcc/ada/ChangeLog:
PR ada/116498
* gcc-interface/decl.cc (validate_size): Use the size of the
default
pointer mode as the minimum size for access types and fat pointers.

[Bug middle-end/116896] codegen for <=> compared to hand-written equivalent

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

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

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

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

commit r15-4167-gff889b35935d5e796cf308fb2368d4e319c60ece
Author: Jakub Jelinek 
Date:   Tue Oct 8 10:40:29 2024 +0200

ssa-math-opts, i386: Handle most unordered values rather than just 2
[PR116896]

On Mon, Oct 07, 2024 at 10:32:57AM +0200, Richard Biener wrote:
> > They are implementation defined, -1, 0, 1, 2 is defined by libstdc++:
> > using type = signed char;
> > enum class _Ord : type { equivalent = 0, less = -1, greater = 1 };
> > enum class _Ncmp : type { _Unordered = 2 };
> > https://eel.is/c++draft/cmp#categories.pre-1 documents them as
> > enum class ord { equal = 0, equivalent = equal, less = -1, greater = 1
}; // exposition only
> > enum class ncmp { unordered = -127 };  
  // exposition only
> > and now looking at it, LLVM's libc++ takes that literally and uses
> > -1, 0, 1, -127.  One can't use <=> operator without including 
> > which provides the enums, so I think if all we care about is libstdc++,
> > then just hardcoding -1, 0, 1, 2 is fine, if we want to also optimize
> > libc++ when used with gcc, we could support -1, 0, 1, -127 as another
> > option.
> > Supporting arbitrary 4 values doesn't make sense, at least on x86 the
> > only reason to do the conversion to int in an optab is a good sequence
> > to turn the flag comparisons to -1, 0, 1.  So, either we do nothing
> > more than the patch, or add handle both 2 and -127 for unordered,
> > or add support for arbitrary value for the unordered case except
> > -1, 0, 1 (then -1 could mean signed int, 1 unsigned int, 0 do the jumps
> > and any other value what should be returned for unordered.

Here is an incremental patch which adds support for (almost) arbitrary
unordered constant value.  It changes the .SPACESHIP and spaceship4
optab conventions, so 0 means use branches, floating point, -1, 0, 1, 2
results consumed by tree-ssa-math-opts.cc emitted comparisons, -1
means signed int comparisons, -1, 0, 1 results, 1 means unsigned int
comparisons, -1, 0, 1 results, and for constant other than -1, 0, 1
which fit into [-128, 127] converted to the PHI type are otherwise
specified as the last argument (then it is -1, 0, 1, C results).

2024-10-08  Jakub Jelinek  

PR middle-end/116896
* tree-ssa-math-opts.cc (optimize_spaceship): Handle unordered
values
other than 2, but they still need to be signed char range possibly
converted to the PHI result and can't be in [-1, 1] range.  Use
last .SPACESHIP argument of 1 for unsigned int comparisons, -1 for
signed int, 0 for floating point branches and any other for
floating
point with that value as unordered.
* config/i386/i386-expand.cc (ix86_expand_fp_spaceship): Use op2
rather
const2_rtx if op2 is not const0_rtx for unordered result.
(ix86_expand_int_spaceship): Change INTVAL (op2) == 1 tests to
INTVAL (op2) != -1.
* doc/md.texi (spaceship@var{m}4): Document the above changes.

* gcc.target/i386/pr116896.c: New test.

[Bug rtl-optimization/117012] [15 Regression] incorrect RTL simplification around vector AND and shifts

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

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

--- Comment #1 from Tamar Christina  ---
bisect landed on

g:aac00d09859cc5934bd0f7493d537b8430337773 is the first bad commit
commit aac00d09859cc5934bd0f7493d537b8430337773
Author: liuhongt 
Date:   Thu Jun 20 12:41:13 2024 +0800

Optimize a < 0 ? -1 : 0 to (signed)a >> 31.

Try to optimize x < 0 ? -1 : 0 into (signed) x >> 31
and x < 0 ? 1 : 0 into (unsigned) x >> 31.

Move the optimization did in ix86_expand_int_vcond to match.pd

gcc/ChangeLog:

PR target/114189
* match.pd: Simplify a < 0 ? -1 : 0 to (signed) >> 31 and a <
0 ? 1 : 0 to (unsigned) a >> 31 for vector integer type.

gcc/testsuite/ChangeLog:

* gcc.target/i386/avx2-pr115517.c: New test.
* gcc.target/i386/avx512-pr115517.c: New test.
* g++.target/i386/avx2-pr115517.C: New test.
* g++.target/i386/avx512-pr115517.C: New test.
* g++.dg/tree-ssa/pr88152-1.C: Adjust testcase.

 gcc/match.pd| 30 +++
 gcc/testsuite/g++.dg/tree-ssa/pr88152-1.C   |  2 +-
 gcc/testsuite/g++.target/i386/avx2-pr115517.C   | 60 +
 gcc/testsuite/g++.target/i386/avx512-pr115517.C | 70 +
 gcc/testsuite/gcc.target/i386/avx2-pr115517.c   | 33 
 gcc/testsuite/gcc.target/i386/avx512-pr115517.c | 70 +
 6 files changed, 264 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.target/i386/avx2-pr115517.C
 create mode 100644 gcc/testsuite/g++.target/i386/avx512-pr115517.C
 create mode 100644 gcc/testsuite/gcc.target/i386/avx2-pr115517.c
 create mode 100644 gcc/testsuite/gcc.target/i386/avx512-pr115517.c

but I guess that's just exposing the issue.

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:932d1c3adb5759a0f37779ed027e96647bdb8b60

commit r14-10754-g932d1c3adb5759a0f37779ed027e96647bdb8b60
Author: Eric Botcazou 
Date:   Tue Oct 8 15:08:15 2024 +0200

Add regression test

gcc/testsuite/
PR ada/114636
* gnat.dg/specs/generic_inst1.ads: New test.

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

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

https://gcc.gnu.org/g:89d2007d211947c0085c6852749a7d348cb458fd

commit r14-10753-g89d2007d211947c0085c6852749a7d348cb458fd
Author: Eric Botcazou 
Date:   Wed Sep 11 19:42:03 2024 +0200

ada: Fix bogus error in instantiation with formal package

The compiler reports that an actual does not match the formal when there
is a defaulted formal discrete type because Check_Formal_Package_Instance
fails to skip the implicit base type generated by the compiler.

gcc/ada/ChangeLog:
PR ada/114636
* sem_ch12.adb (Check_Formal_Package_Instance): For a defaulted
formal discrete type, skip the generated implicit base type.

[Bug ada/115535] negative value returned by 'Image for array with nonnegative integer component

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Eric Botcazou
:

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

commit r13-9095-geec5e10a79daa0a4fb41f7fb2e59db3318821e62
Author: Eric Botcazou 
Date:   Tue Oct 8 15:15:26 2024 +0200

Add regression test

gcc/testsuite/
PR ada/115535
* gnat.dg/put_image1.adb: New test

[Bug ada/115535] negative value returned by 'Image for array with nonnegative integer component

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Eric Botcazou
:

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

commit r13-9094-gd0abc47f940173863966c04d852fa75e76d07be9
Author: Eric Botcazou 
Date:   Wed Sep 11 19:37:08 2024 +0200

ada: Fix negative value returned by 'Image for array with nonnegative
component

The problem is that Exp_Put_Image.Build_Elementary_Put_Image_Call uses the
signedness of the base type but the size of the first subtype, hence the
discrepancy between them.

gcc/ada/ChangeLog:
PR ada/115535
* exp_put_image.adb (Build_Elementary_Put_Image_Call): Use the size
of the underlying type to find the support type.

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Eric Botcazou
:

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

commit r13-9092-gb3cf0bd981327077fc90fd89540d2fa051675636
Author: Eric Botcazou 
Date:   Tue Oct 8 15:08:15 2024 +0200

Add regression test

gcc/testsuite/
PR ada/114636
* gnat.dg/specs/generic_inst1.ads: New test.

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Botcazou  ---
Fixed on mainline, 14 and 13 branches.

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:8547dab3cb619b91112466bc0dc97379240b9011

commit r13-9091-g8547dab3cb619b91112466bc0dc97379240b9011
Author: Eric Botcazou 
Date:   Wed Sep 11 19:42:03 2024 +0200

ada: Fix bogus error in instantiation with formal package

The compiler reports that an actual does not match the formal when there
is a defaulted formal discrete type because Check_Formal_Package_Instance
fails to skip the implicit base type generated by the compiler.

gcc/ada/ChangeLog:
PR ada/114636
* sem_ch12.adb (Check_Formal_Package_Instance): For a defaulted
formal discrete type, skip the generated implicit base type.

[Bug ada/114640] internal error on elsif part of if-statement containing if-expression

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
Fixed on mainline, 14 and 13 branches.

[Bug ada/114640] internal error on elsif part of if-statement containing if-expression

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Eric Botcazou
:

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

commit r13-9093-gda4f4b27c8f8e29be2003dc3771f8eae3b90e2ff
Author: Eric Botcazou 
Date:   Wed Sep 11 19:26:18 2024 +0200

ada: Fix internal error on elsif part of if-statement containing
if-expression

The problem occurs when the compiler is trying to find a context to which
it can hoist finalization actions coming from the if-expression, because
Find_Hook_Context incorrectly returns the N_Elsif_Part node.

gcc/ada/ChangeLog:
PR ada/114640
* exp_util.adb (Find_Hook_Context): For a node present within a
conditional expression, do not return an N_Elsif_Part node.

[Bug ada/114640] internal error on elsif part of if-statement containing if-expression

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

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

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

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

commit r14-10755-gc9fe4eae41c0e05ef213b9a47c611d5fc704006a
Author: Eric Botcazou 
Date:   Wed Sep 11 19:26:18 2024 +0200

ada: Fix internal error on elsif part of if-statement containing
if-expression

The problem occurs when the compiler is trying to find a context to which
it can hoist finalization actions coming from the if-expression, because
Find_Hook_Context incorrectly returns the N_Elsif_Part node.

gcc/ada/ChangeLog:
PR ada/114640
* exp_util.adb (Find_Hook_Context): For a node present within a
conditional expression, do not return an N_Elsif_Part node.

[Bug ada/115535] negative value returned by 'Image for array with nonnegative integer component

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

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

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

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

commit r14-10756-gf45fc31bd618154c270fa5a7b354d2025800862b
Author: Eric Botcazou 
Date:   Wed Sep 11 19:37:08 2024 +0200

ada: Fix negative value returned by 'Image for array with nonnegative
component

The problem is that Exp_Put_Image.Build_Elementary_Put_Image_Call uses the
signedness of the base type but the size of the first subtype, hence the
discrepancy between them.

gcc/ada/ChangeLog:
PR ada/115535
* exp_put_image.adb (Build_Elementary_Put_Image_Call): Use the size
of the underlying type to find the support type.

[Bug ada/115535] negative value returned by 'Image for array with nonnegative integer component

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

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

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

https://gcc.gnu.org/g:4390e95fa5304110562777292c6d3e3dc97de8f6

commit r14-10757-g4390e95fa5304110562777292c6d3e3dc97de8f6
Author: Eric Botcazou 
Date:   Tue Oct 8 15:15:26 2024 +0200

Add regression test

gcc/testsuite/
PR ada/115535
* gnat.dg/put_image1.adb: New test

[Bug ada/115535] negative value returned by 'Image for array with nonnegative integer component

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
Fixed on mainline, 14 and 13 branches.

[Bug ada/114640] internal error on elsif part of if-statement containing if-expression

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |13.4

[Bug ada/116190] wrong finalization of anonymous array aggregate

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

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

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

https://gcc.gnu.org/g:70c46d8e455144cf5968d38b932692cbe0cfa2e1

commit r14-10759-g70c46d8e455144cf5968d38b932692cbe0cfa2e1
Author: Eric Botcazou 
Date:   Tue Oct 8 15:17:27 2024 +0200

Add regression test

gcc/testsuite/
PR ada/116190
* gnat.dg/aggr31.adb: New test.

[Bug ada/116190] wrong finalization of anonymous array aggregate

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Eric Botcazou
:

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

commit r13-9097-ga998902576db03a178fe21aa46ed38647f112a98
Author: Eric Botcazou 
Date:   Tue Oct 8 15:17:27 2024 +0200

Add regression test

gcc/testsuite/
PR ada/116190
* gnat.dg/aggr31.adb: New test.

[Bug ada/116190] wrong finalization of anonymous array aggregate

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
Fixed on mainline, 14 and 13 branches.

[Bug target/117008] -march=native pessimization of 25% with bitset []

[mattreecebentley at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Matt Bentley  ---
Created attachment 59294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59294&action=edit
-v build output for -o2 only in second "if" variant

 As requested

[Bug target/117008] -march=native pessimization of 25% with bitset []

[mattreecebentley at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Matt Bentley  ---
(In reply to Jonathan Wakely from comment #7)

> I'm certain it won't be, because (apart from vector) they access
> memory locations that are at least one byte, not repeating very similar
> bitwise ops for every bit in a word.

Have tested 4 additional scenarios: random access, sequential iteration with an
if statement, the vector equivalent, and sequential iteration with an if
statement and a more complicated action.

Can confirm that the issue only occurs in the second of those, ie.:
{
std::bitset<1280> values;

for (unsigned int counter = 0; counter != 500; ++counter)
{
for (unsigned int index = 0; index != 1280;
++index)
{
values.set(index, plf::rand() & 1);
}


for (unsigned int index = 0; index != 1280;
++index)
{
if (values[index])
{
total += values[index] * 2;
}
}
}
}


While this statement is closer to what you might see in real world code ie. if
1, do this,
I'm assuming it gets optimized into a conditional move or something, as the
same 25% slowdown occurs.
Once you add in a more complicated action ie.:

for (unsigned int index = 0; index != 1280;
++index)
{
if (values[index])
{
total += values[index] * 2;
total ^= values[index];
}
}


The problem goes away. So essentially Andrew's correct, unless the user's
chosen action can be trivially optimized.

Will generate the -v output for the second of the scenarios now.

[Bug ada/116190] wrong finalization of anonymous array aggregate

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

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

--- Comment #3 from Eric Botcazou  ---
https://gcc.gnu.org/g:45131b851522180c532bebb3521865e488025af0

commit r15-4143-g45131b851522180c532bebb3521865e488025af0
Author: Eric Botcazou 
Date:   Thu Sep 5 00:19:25 2024 +0200

ada: Fix wrong finalization of anonymous array aggregate

The issue arises when the aggregate consists only of iterated associations
because, in this case, its expansion uses a 2-pass mechanism which creates
a temporary that needs a fully-fledged initialization, thus running afoul
of the optimization that avoids building the initialization procedure in
the anonymous array case.

gcc/ada/ChangeLog:
* exp_aggr.ads (Is_Two_Pass_Aggregate): New function declaration.
* exp_aggr.adb (Is_Two_Pass_Aggregate): New function body.
(Expand_Array_Aggregate): Call Is_Two_Pass_Aggregate to detect the
aggregates that need the 2-pass expansion.
* exp_ch3.adb (Expand_Freeze_Array_Type): In the anonymous array
case, build the initialization procedure if the initial value in
the object declaration is a 2-pass aggregate.

[Bug middle-end/116896] codegen for <=> compared to hand-written equivalent

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #31 from Jakub Jelinek  ---
Fixed.

[Bug target/117013] New: aarch64 should define spaceship4 optab

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

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

Bug ID: 117013
   Summary: aarch64 should define spaceship4 optab
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Please look at code generation for
signed char f1 (float x, float y) { if (x == y) return 0; else if (x < y)
return -1; else if (x > y) return 1; else return 2; }
__attribute__((optimize ("fast-math"))) signed char f2 (float x, float y) { if
(x == y) return 0; else if (x < y) return -1; else if (x > y) return 1; else
return 2; }
signed char f3 (float x, float y) { if (x == y) return 0; else if (x < y)
return -1; else if (x > y) return 1; else return -127; }
void g1 (void); void g2 (void); void g3 (void); void g4 (void);
void f4 (float x, float y) { if (x == y) g1 (); else if (x < y) g2 (); else if
(x > y) g3 (); else g4 (); }
signed char f5 (int x, int y) { if (x == y) return 0; else if (x < y) return
-1; else return 1; }
signed char f6 (unsigned x, unsigned y) { if (x == y) return 0; else if (x < y)
return -1; else return 1; }
signed char f7 (int x, int y) { return (int) (x > y) - (int) (x < y); }
signed char f8 (unsigned x, unsigned y) { return (int) (x > y) - (int) (x < y);
}

The above is C version of various x <=> y C++ cases (and f7/f8 are one possible
way how to also emit what f5/f6 does differently).

This shows aarch64 suffers from similar issue why spaceship optab has been
introduced, at least the two comparisons
fcmps0, s1
mov w0, 0
beq .L2
fcmpe   s0, s1
bmi .L5
csetw0, gt
mov w1, 2
sub w0, w1, w0
.L2:
ret
.L5:
mov w0, -1
ret
look unnecessary and by defining at least spaceship{sf,df}4 one could do just
one comparison instead of two and just test the flags.
Whether it would be helpful to also define the patterns for integral modes is
something that needs to be carefully judged,
i.e. whether you get now for the comparisons into -1, 0, 1 values optimal code
or whether something different is needed.