[Bug target/111354] [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #3 from d_vampile  ---
(In reply to Andrew Pinski from comment #1)
> First off the performance is difference is die to micro-arch issues with
> unaligned stores of 256 bits. 
> 
> Also iirc rte_mov128blocks is tuned at copying blocks which are aligned at
> least to 32 bytes wide. But you are better asking the dpdk forum why they
> don't just use memcpy here.

The instruction 'movdqu' do not require the memory address to be aligned on a
natural vector-length byte boundary. Why does rte_mov128blocks need to be
aligened at 32 bytes wide? 

The test platform is Xeon.

[Bug c++/111352] Inconsistent constructor behavior associated with auto lambda

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

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

--- Comment #4 from Andrew Pinski  ---
also see https://en.wikipedia.org/wiki/Most_vexing_parse for more explanation
on why this mistake in GCC happened.

[Bug c++/111352] Inconsistent constructor behavior associated with auto lambda

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid

--- Comment #3 from Andrew Pinski  ---
You can also use this as a workaround:
```
AA aa{Constructor([](auto& p) { p.x = 1; })};
```

Confirmed.
The problem is GCC starts parsing as a function declaration for aa that takes a
type of arrays of function pointers that has a function argument named
Constructor and then noticed the `{` and decides whoops we need to back up. But
it is too late as GCC already error'd for the auto too early on.

Basically GCC errors out on auto too soon (during the parsing) rather
afterwards ...

[Bug target/111354] [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases.

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

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

--- Comment #2 from Andrew Pinski  ---
It might be the case DPDK is tuned towards xeon's rather than the i series
also.

[Bug target/111354] [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases.

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

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

--- Comment #1 from Andrew Pinski  ---
First off the performance is difference is die to micro-arch issues with
unaligned stores of 256 bits. 

Also iirc rte_mov128blocks is tuned at copying blocks which are aligned at
least to 32 bytes wide. But you are better asking the dpdk forum why they don't
just use memcpy here.

[Bug libstdc++/111347] Memory leak loading a shared library built with --static-libsdtc++ when version script is used

[gyunaev at ulduzsoft dot com via Gcc-bugs]

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

--- Comment #3 from George Yunaev  ---
Indeed making a unique symbol local results in a leak.

[Bug target/111354] New: [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases.

[d_vampile at 163 dot com via Gcc-bugs]

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

Bug ID: 111354
   Summary: [7/10/12 regression] The instructions of the DPDK demo
program are different and run time increases.
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d_vampile at 163 dot com
  Target Milestone: ---

Created attachment 55863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55863&action=edit
test case

Test platform: x86_64
The test platform supports avx2 and sse4.2
Default mtune=generic
Compiler Options:  
gcc main.c -g -o main -O2 -msse4.2 -mavx2 -fno-inline

GCC 7.3.0 produces:
.L3:
vmovdqu (%rsi), %xmm3
subq$-128, %rdi
subq$-128, %rsi
vmovdqu -96(%rsi), %xmm2
vinserti128 $0x1, -112(%rsi), %ymm3, %ymm3
vmovdqu -64(%rsi), %xmm1
vinserti128 $0x1, -80(%rsi), %ymm2, %ymm2
vmovdqu -32(%rsi), %xmm0
vinserti128 $0x1, -48(%rsi), %ymm1, %ymm1
vinserti128 $0x1, -16(%rsi), %ymm0, %ymm0
vmovups %xmm3, -128(%rdi)
vextracti128$0x1, %ymm3, -112(%rdi)
vmovups %xmm2, -96(%rdi)
vextracti128$0x1, %ymm2, -80(%rdi)
vmovups %xmm1, -64(%rdi)
vextracti128$0x1, %ymm1, -48(%rdi)
vmovups %xmm0, -32(%rdi)
vextracti128$0x1, %ymm0, -16(%rdi)
cmpq%rax, %rdi
jne .L3
vzeroupper

Runtime with gcc7.3.0:
$ time ./main_gcc7.3 2000
start to run 2000.
end to run 2000.

real6m30.461s
user6m26.587s
sys 0m0.814s

GCC 10.3.0 produces:
.L3:
vmovdqu (%rsi), %xmm4
vmovdqu 32(%rsi), %xmm5
subq$-128, %rdi
subq$-128, %rsi
vmovdqu -64(%rsi), %xmm6
vmovdqu -32(%rsi), %xmm7
vinserti128 $0x1, -112(%rsi), %ymm4, %ymm3
vinserti128 $0x1, -80(%rsi), %ymm5, %ymm2
vinserti128 $0x1, -48(%rsi), %ymm6, %ymm1
vinserti128 $0x1, -16(%rsi), %ymm7, %ymm0
vmovdqu %xmm3, -128(%rdi)
vextracti128$0x1, %ymm3, -112(%rdi)
vextracti128$0x1, %ymm2, -80(%rdi)
vmovdqu %xmm2, -96(%rdi)
vextracti128$0x1, %ymm1, -48(%rdi)
vextracti128$0x1, %ymm0, -16(%rdi)
vmovdqu %xmm1, -64(%rdi)
vmovdqu %xmm0, -32(%rdi)
cmpq%rax, %rdi
jne .L3
vzeroupper

Runtime with gcc10.3.0:
$ time ./main_gcc10.3 2000
start to run 2000.
end to run 2000.

real7m18.696s
user7m13.912s
sys 0m1.098s


GCC 12.3.0 produces:
.L3:
vmovdqu (%rsi), %ymm2
vmovdqu 32(%rsi), %ymm1
subq$-128, %rdi
subq$-128, %rsi
vmovdqu -64(%rsi), %ymm0
vmovdqu -32(%rsi), %ymm3
vmovdqu %ymm2, -128(%rdi)
vmovdqu %ymm3, -32(%rdi)
vmovdqu %ymm1, -96(%rdi)
vmovdqu %ymm0, -64(%rdi)
cmpq%rax, %rdi
jne .L3
vzeroupper

Runtime with gcc12.3.0:
$ time ./main_gcc12.3 2000
start to run 2000.
end to run 2000.

real10m1.303s
user9m52.527s
sys 0m2.253s

Why does it seem that the instructions of gcc12 are simpler but run time is
significantly increased in the same test environment and compilation options?

What is the reason for the different instructions generated by these three
versions of gcc？

[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu

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

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

Eric Gallager  changed:

   What|Removed |Added

   Host||i?86-*-*

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> (In reply to Ian Lance Taylor from comment #1)
> > What kind of system are you running on?
> > 
> > What is the output of
> > ../gcc-9.1.0/config.guess
> > ?
> 
> I just got a similar error on gcc13 on the compile farm; config.guess there
> reports:
> 
> $ ../config.guess
> x86_64-pc-linux-gnu
> 
> So, confirmed.

Oops wait make that gcc14, not gcc13 (since there isn't even any machine called
gcc13 on the compile farm in the first place)

[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu

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

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-09

--- Comment #2 from Eric Gallager  ---
(In reply to Ian Lance Taylor from comment #1)
> What kind of system are you running on?
> 
> What is the output of
> ../gcc-9.1.0/config.guess
> ?

I just got a similar error on gcc13 on the compile farm; config.guess there
reports:

$ ../config.guess
x86_64-pc-linux-gnu

So, confirmed.

[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Arthur O'Dwyer  ---
(Author of the blog post here.)
In contrast to James' view, I think the libstdc++/MSVC behavior is relatively
easy to explain; I think libc++'s `if consteval` approach is baroque and
confusing. [That is, _both_ behaviors are confusing to the newbie and need
expert explanation, but libc++'s choice is confusing even for the experts, who
have to maintain its split-brain SSO logic forever because Hyrum's Law. If you
have to maintain something forever, you should at least choose to make it
_simple_! As I say in the blog post, in hindsight I think libc++ screwed up
here.]

IMHO it is a feature, not a bug, that I can write these lines:

constinit std::string s1;
constinit std::vector v1;

libstdc++ would be within its rights, paper-Standard-wise, to reject both of
these lines; but I don't think libstdc++ _should_ reject either of them.
They're both fine code as far as I'm concerned. I think libc++ is the
user-hostile/broken implementation here, not libstdc++.

Anyone who thinks libstdc++ ought to reject `s1` above should at least be
forced to explain what libstdc++ ought to do about `v1`. From the
user-programmer's POV, there's no difference between a default-initialized
string and a default-initialized vector. Users don't care about these SSO
details; they just want the code to work. That's what libstdc++ currently does.
Good, IMO.

[Bug libstdc++/111353] New: bits/new_allocator.h: No such file or directory in freestanding C++ toolchain

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 111353
   Summary: bits/new_allocator.h: No such file or directory in
freestanding C++ toolchain
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-elf/x86_64-elf/include/c++/14.0.0/x86_64-elf/bits/c++allocator.h:33:10:
fatal error: bits/new_allocator.h: No such file or directory
   33 | #include 
  |  ^~


As I reported to wg21 before, there is no way to allocate memory in constexpr
context for freestanding. clang provides __builtin_operator_new and
__builtin_operator_delete. Maybe gcc needs that too?

[Bug libstdc++/111347] Memory leak loading a shared library built with --static-libsdtc++ when version script is used

[gyunaev at ulduzsoft dot com via Gcc-bugs]

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

--- Comment #2 from George Yunaev  ---
Adding -fno-gnu-unique to the makefile for libleak.so doesn't remove the leak.

[Bug c++/111352] Inconsistent constructor behavior associated with auto lambda

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

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

--- Comment #2 from Andrew Pinski  ---
99% sure this is because we start parsing as a function declaration and then
see it is not but we errored out already.

[Bug c++/111352] Inconsistent constructor behavior associated with auto lambda

[peter.fletcher at bandicootimaging dot com.au via Gcc-bugs]

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

Peter Fletcher  changed:

   What|Removed |Added

 CC||peter.fletcher@bandicootima
   ||ging.com.au

--- Comment #1 from Peter Fletcher  ---
Created attachment 55862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55862&action=edit
Source file

Source code

[Bug c++/111352] New: Inconsistent constructor behavior associated with auto lambda

[peter.fletcher at bandicootimaging dot com.au via Gcc-bugs]

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

Bug ID: 111352
   Summary: Inconsistent constructor behavior associated with auto
lambda
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.fletcher at bandicootimaging dot com.au
  Target Milestone: ---

Created attachment 55861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55861&action=edit
Output of gcc -v -save_temps

When a constructor involving an auto lambda is called in two different
contexts, one triggers a compilation error, one does not.

g++ test_bug3.cpp -o test_bug3 -Wall -Wextra
test_bug3.cpp: In function ‘int main(int, char**)’:
test_bug3.cpp:41:27: error: ‘auto’ parameter not permitted in this context
   41 | AA aa(Constructor([&](auto& p) { p.x = 1; }));
  |   ^~~~
Compilation exited abnormally with code 1 at Sat Sep  9 08:50:05

template  struct Constructor
{
const L& lambda;

Constructor(const L& lambda) :
lambda(lambda)
{
}

template  operator T () const
{
T out;

lambda(out);

return out;
}
};

struct A
{
int x;
};

struct AA
{
int x{0};

AA()
{
}

AA(A op) :
x(op.x)
{
}
};

int main(int argc, char* argv[])
{
AA aa(Constructor([&](auto& p) { p.x = 1; }));
AA bb = AA(Constructor([&](auto& p) { p.x = 1; }));

return aa.x+bb.x+argc+argv[0][0];
}

[Bug libstdc++/111351] New: constexpr std::string objects permitted to escape constant evaluation when SSO

[foom at fuhm dot net via Gcc-bugs]

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

Bug ID: 111351
   Summary: constexpr std::string objects permitted to escape
constant evaluation when SSO
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foom at fuhm dot net
  Target Milestone: ---

In C++20, libstdc++ currently allows an std::string instance to escape from
constant evaluation to runtime, as long as the string fit within the SSO
length.

E.g., as a global variable, compiled with -std=c++20:
constexpr std::string s1; // OK
constexpr std::string s1 = ""; // OK
constexpr std::string s1 = "0123456789abcde"; // OK
constexpr std::string s2 = "0123456789abcdef"; // FAIL

I believe all of the above ought to fail to compile.

This will result in user code which can be built or not based on whether their
string happens to fit within the SSO string length. I find that quite
unfortunate, since it is supposed to be an internal implementation
detail/optimization, and this makes it effectively part of the API that code
will grow to depend on.

As comparison, libc++ rejects all the above examples, by forcing the SSO-size
to zero in constant evaluation context, so that a pointer to an external
allocation is always used.

This was brought to my attention from 
https://quuxplusone.github.io/blog/2023/09/08/constexpr-string-firewall/

[Bug tree-optimization/109878] missed simplifications of MAX and MIN

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-09-08

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

[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21

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

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Francois-Xavier Coudert from comment #3)
> > Clang: 14.0.0 build 1400
> > CLT: 14.2.0.0.1.1668646533
> 
> ah, it seems the vfcmulcph insn, at least, is not supported before XC14, and
> it gives the error at 14.0b3 and 14.3.  It seems fixed at XC 15b7.

perhaps we can add something to the "avx512fp16" target test that requires
assembly of one of those insns so that the tests will be automatically
unsupported for broken assemblers.

[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21

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

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Francois-Xavier Coudert from comment #3)
> Clang: 14.0.0 build 1400
> CLT: 14.2.0.0.1.1668646533

ah, it seems the vfcmulcph insn, at least, is not supported before XC14, and it
gives the error at 14.0b3 and 14.3.  It seems fixed at XC 15b7.

[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21

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

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

--- Comment #3 from Francois-Xavier Coudert  ---
Clang: 14.0.0 build 1400
CLT: 14.2.0.0.1.1668646533

[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21

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

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

--- Comment #2 from Iain Sandoe  ---
(In reply to Andrew Pinski from comment #1)
> This seems like a bug in darwin's assembler as all of those registers are
> distinct  ...

indeed, it does look that way - what version of Xcode?

[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21

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

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

--- Comment #1 from Andrew Pinski  ---
This seems like a bug in darwin's assembler as all of those registers are
distinct  ...

[Bug target/111350] New: gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21

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

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

Bug ID: 111350
   Summary: gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends
fail on x86_64-apple-darwin21
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

We're seeing these failures on x86_64-apple-darwin21:

FAIL: gcc.target/i386/avx512fp16-vfcmulcph-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfcmulcsh-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfmulcph-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfmulcsh-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16vl-vfcmulcph-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16vl-vfmulcph-1b.c (test for excess errors)


The errors are all similar-looking:

FAIL: gcc.target/i386/avx512fp16-vfmulcsh-1b.c (test for excess errors)
Excess errors:
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cclz0cVD.s:379:2: warning:
Destination register should be distinct from source registers
vfmulcsh{rn-sae}, %xmm1, %xmm3, %xmm0{%k1}
^


FAIL: gcc.target/i386/avx512fp16-vfcmulcph-1b.c (test for excess errors)
Excess errors:
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccB0dfAf.s:475:2: warning:
Destination register should be distinct from source registers
vfcmulcph   _src2(%rip), %zmm2, %zmm0{%k1}
^
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccB0dfAf.s:540:2: warning:
Destination register should be distinct from source registers
vfcmulcph   {rn-sae}, %zmm7, %zmm6, %zmm0{%k1}
^



I tried to reduce one, and got:

$ cat avx512fp16vl-vfcmulcph-1b.i
typedef _Float16 __m256h __attribute__ ((__vector_size__ (32), __may_alias__));
typedef _Float16 __v16hf __attribute__ ((__vector_size__ (32)));

typedef union {
  __m256h ymmh[2];
  unsigned short u16[32];
} V512;

V512 src1, src2;
int n_errs = 0;

extern __inline __m256h __attribute__ ((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_mask_fcmul_pch (__m256h __A, unsigned char __B, __m256h __C, __m256h
__D)
{ return (__m256h) __builtin_ia32_vfcmulcph256_mask ((__v16hf) __C, (__v16hf)
__D, (__v16hf) __A, __B); }


void check_results(void *got, void *exp, int n_elems, char *banner) {
int i;
V512 *v1 = (V512*)got;
V512 *v2 = (V512*)exp;

for (i = 0; i < n_elems; i++) {
if (v1->u16[i] != v2->u16[i] &&
((v1->u16[i] > (v2->u16[i] + 1)) ||
 (v1->u16[i] < (v2->u16[i] - 1 {
n_errs++;
break;
}
}
}

int main () {
  V512 res;
  V512 exp;
  res.ymmh[0] = _mm256_mask_fcmul_pch (res.ymmh[0], 0xcc, src1.ymmh[0],
src2.ymmh[0]);
  check_results ((void*)&res, (void*)&exp, (256 / 16),
"_mm256_mask_fcmul_pch");
}


which yields the warning:

$ /Users/fx/ibin/gcc/xgcc -B/Users/fx/ibin/gcc/ avx512fp16vl-vfcmulcph-1b.i -O2
-mavx512fp16 -mavx512vl -mavx512dq -c
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccruiM7F.s:57:2: warning:
Destination register should be distinct from source registers
vfcmulcph   _src2(%rip), %ymm1, %ymm0{%k1}
^

[Bug tree-optimization/111349] `Optimize (a CMP CST1) ? max : a` pattern's cmp is missing :c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-08
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug tree-optimization/111349] New: `Optimize (a CMP CST1) ? max : a` pattern's cmp is missing :c

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

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

Bug ID: 111349
   Summary: `Optimize (a CMP CST1) ? max : a` pattern's
cmp is missing :c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

```
/* Optimize (a CMP CST1) ? max : a */
(for cmp(gt  ge  lt  le)
 minmax (min min max max)
 (simplify
  (cond (cmp @0 @1) (minmax:c@2 @0 @3) @4)
```
Just like PR 111348 really.

[Bug tree-optimization/111348] `(a CMP b) ? minmax : minmax` pattern missing :c on CMP

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-09-08

[Bug libstdc++/111347] Memory leak loading a shared library built with --static-libsdtc++ when version script is used

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

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

--- Comment #1 from Andrew Pinski  ---
I am pretty sure _ZNSt8messagesIwE2idE is marked as GNU unique 

[Bug tree-optimization/111348] `(a CMP b) ? minmax : minmax` pattern missing :c on CMP

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

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

--- Comment #1 from Andrew Pinski  ---
Need a testcase for this though.

[Bug tree-optimization/111348] New: `(a CMP b) ? minmax : minmax` pattern missing :c on CMP

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

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

Bug ID: 111348
   Summary: `(a CMP b) ? minmax : minmax` pattern
missing :c on CMP
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: internal-improvement, missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

```
(for minmax (min max)
 (for cmp (lt le gt ge ne)
  (simplify
   (cond (cmp @1 @3) (minmax:c @1 @4) (minmax:c @2 @4))
```

Is missing :c on cmp
because we could have
(@3 < @1) ? min(@1, @4) : min(@2, @4)

Which should match for and provide the same as `@1 > @3 ? min(@1, @4) : min(@2,
@4)`

[Bug libstdc++/111347] New: Memory leak loading a shared library built with --static-libsdtc++ when version script is used

[gyunaev at ulduzsoft dot com via Gcc-bugs]

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

Bug ID: 111347
   Summary: Memory leak loading a shared library built with
--static-libsdtc++ when version script is used
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gyunaev at ulduzsoft dot com
  Target Milestone: ---

Created attachment 55860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55860&action=edit
The source code of the library, tester and Makefile

Gcc 13.2 built from the source. Linux x86_64, OpenSuSe Leap 15.5.

Our team has found that when building a C++ DSO using --static-libgcc and
--static-libstdc++ and using a version script to hide the visibility of
symbols, loading and unloading the resulting shared library leaks memory each
time such dlopen/dlclose happens. 

If a version script is not used, there is no leak.

Smallest shared library source which reproduces the issue:

-- libtest.cpp --
#include 

int test()
{
std::string a;
return a.length();
}
---

The version script:
-- libtest.ver --
{
global:
test;

local:
*;
};
---

Built with:

g++ -fPIC -shared -static-libgcc -static-libstdc++
-Wl,--version-script=libtest.ver libtest.cpp -o libtest.so

load-unload of this library leaks memory each time it unloads.
Loading-unloading is all that is needed - you don't need to call test or even
dlsym it. Easiest to see it when running dlclose( dlopen( "./libtest.so",
RTLD_NOW)) in a loop.

If you remove --version-script and rebuild the library, load-unload will not
leak.

Experimentally we found out that adding the symbol "_ZNSt8messagesIwE2idE;"
into global: section of version script would stop the leak, but this isn't
obvious to me why. This symbol demangles into std::messages::id;

Attaching the tester, makefile and the loader.

[Bug tree-optimization/111346] `X <= MINMAX` pattern is missing :c on the cmp

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-09-08
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Have to find a testcase or 2 that fails because of the missing :c though.

[Bug tree-optimization/111346] New: `X <= MINMAX` pattern is missing :c on the cmp

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

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

Bug ID: 111346
   Summary: `X <= MINMAX` pattern is missing :c on the cmp
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: internal-improvement, missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

The pattern:
```
/* X <= MAX(X, Y) -> true
   X > MAX(X, Y) -> false 
   X >= MIN(X, Y) -> true
   X < MIN(X, Y) -> false */
(for minmax (min min max max )
 cmp(ge  lt  le  gt  )
 (simplify
  (cmp @0 (minmax:c @0 @1))
  { constant_boolean_node (cmp == GE_EXPR || cmp == LE_EXPR, type); } ))
```
Is missing :c on the cmp which causes us to miss:
MAX(X, Y) >= X -> true
etc.

[Bug tree-optimization/111345] `X % Y is smaller than Y.` pattern could be simpified

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-09-08

[Bug tree-optimization/111345] New: `X % Y is smaller than Y.` pattern could be simpified

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

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

Bug ID: 111345
   Summary: `X % Y is smaller than Y.` pattern could be simpified
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Right now it is defined as:
```
(for cmp (lt ge)
 (simplify
  (cmp (trunc_mod @0 @1) @1)
  (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
   { constant_boolean_node (cmp == LT_EXPR, type); })))
(for cmp (gt le)
 (simplify
  (cmp @1 (trunc_mod @0 @1))
  (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
   { constant_boolean_node (cmp == GT_EXPR, type); })))
```

But it could be simplified to:
```
(for cmp (lt ge)
 (simplify
  (cmp:c (trunc_mod @0 @1) @1)
  (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
   { constant_boolean_node (cmp == LT_EXPR, type); })))
```

This simplifies the written code but the produced code is the same ...

[Bug c/29280] misleading warning for assignment used as truth construct

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||markgaleck at gmail dot com

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

[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
Dup of bug 29280.
The warning needs some fine tuning on the wording but the parentheses is not
there. The syntax for, while and if requires parentheses for the truth value. 
That is it is not:
```
if a = b
{
}
```

But:
```
if (a = b)
{
}
```
the assignment in this case is used where a truth value would be used, there is
no parentheses around the assignment.

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

[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"

[markgaleck at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Mark Galeck  ---
(In reply to Andrew Pinski from comment #5)
> Reduced:
> ```
> int *f(const char*);
> int *g(int*);
> int main()
> {
>  int* pdir;
>  int* pentry;
> 
>  pdir = f("d");
> 
>  while (pentry = g(pdir)) ;
> }
> ```
> 
> No this warning is not bogus and is telling you exactly what it says.


Andrew I respect your opinion and certainly you are more experienced at gcc
than me.  But, with all due respect, I disagree with "is telling you exactly
what it says"

No it doesn't... it says "suggest parentheses around " and the parentheses is
there.   


Maybe it should say something like "suggest double parentheses, to confirm that
you meant = and not ==  , although, I fail to see how double parent should
confirm such a thing.

[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Reduced:
```
int *f(const char*);
int *g(int*);
int main()
{
 int* pdir;
 int* pentry;

 pdir = f("d");

 while (pentry = g(pdir)) ;
}
```

No this warning is not bogus and is telling you exactly what it says.

The reason for the warning is because GCC is telling the user that sometimes
they might have meant for == rather than = here.
If you add an extra parentheses around `pentry = g(pdir)`, then the warning
goes away because you are explictly saying you meant that assignment rather
than an equality comparison.

[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"

[markgaleck at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mark Galeck  ---
I am getting seemingly bogus "warning: suggest parentheses around assignment
used as truth value [-Wparentheses]".  I see long time ago there were such
reports, fixed at the time, but this is happening now for me with gcc 13.1.0

The preprocessed file foobar.i is attached. 

The warning is triggered by:

$gcc-13   -Wall  -lc -c foobar.i
foobar.c: In function ‘main’:
foobar.c:11:16: warning: suggest parentheses around assignment used as truth
value [-Wparentheses]
   11 | while (pentry = readdir(pdir)) ;
  |^~



If I add ANOTHER parentheses as the warning seems to suggest:

while ((pentry = readdir(pdir)))

the warning disappears.  


foobar.i is attached



$ gcc-13 -v
Using built-in specs.
COLLECT_GCC=gcc-13
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
13.1.0-8ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-13-IvzKaI/gcc-13-13.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-IvzKaI/gcc-13-13.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~22.04)

[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"

[markgaleck at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mark Galeck  ---
Created attachment 55859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55859&action=edit
preprocessed SSCCE foobar.i

[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"

[markgaleck at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mark Galeck  ---
Created attachment 55858
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55858&action=edit
preprocessed SSCCE foobar.i

[Bug target/111343] [SH] Including in C++23 causes an ICE with -m4-single-only

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

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

--- Comment #1 from Andrew Pinski  ---
Most likely introduced by  r13-2887-gb04208895fed34171eac6 which implements
C++23 extended floating point types ...

And the use of _Float32 but now sizeof(double) == sizeof(float) ==
sizeof(_Float32)

[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-08

--- Comment #1 from Andrew Pinski  ---
Can you provide a testcase?

[Bug c/111344] New: bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"

[markgaleck at gmail dot com via Gcc-bugs]

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

Bug ID: 111344
   Summary: bogus "warning: suggest parentheses around assignment
used as truth value [-Wparentheses]"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markgaleck at gmail dot com
  Target Milestone: ---

[Bug c++/111343] New: [SH] Including in C++23 causes an ICE with -m4-single-only

[gyrovorbis at gmail dot com via Gcc-bugs]

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

Bug ID: 111343
   Summary: [SH] Including  in C++23 causes an ICE with
-m4-single-only
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gyrovorbis at gmail dot com
  Target Milestone: ---

We recently updated from GCC12 to GCC13 in the Sega Dreamcast indie SDK,
KallistiOS, and while pretty much everything has worked fantastically, we are
encountering a pretty serious ICE when attempting to include the  header
with the -m4-single-only SH-specific flag (which treats doubles as floats),
when compiling as C++23.

The minimal program to reproduce the issue is here:

#include 

int main(int argc, char* argv[]) { 
return 0;
}

We are building with: -std=c++23 -m4-single-only


Note that without the -m4-single-only flag, the ICE disappears. Note also that
without including , with this flag, the following static assertion
fails:

static_assert(sizeof(__STDCPP_FLOAT64_T__) == 8,
 "Oh god, Dreamcast broke!");


Here is a link to a repro in Compiler Explorer: https://godbolt.org/z/MrE8a47oq

I'm assuming the addition of the new C++23  types is clashing with
the `-m4-single-only` flag, as it doesn't seem as though when these types are
created, there is any checking for sizeof(double) or anything target-specific:
https://github.com/gcc-mirror/gcc/blob/a7d052b3200c7928d903a0242b8cfd75d131e374/gcc/c-family/c-cppbuiltin.cc#L1265

[Bug c++/111075] ICE on g++.dg/torture/tail-padding1.C on darwin

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

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

--- Comment #1 from Francois-Xavier Coudert  ---
Preprocessed source:

% cat a-tail-padding1.ii
# 0 "/Users/fx/gcc-upstream/gcc/testsuite/g++.dg/torture/tail-padding1.C"
# 0 ""
# 0 ""
# 1 "/Users/fx/gcc-upstream/gcc/testsuite/g++.dg/torture/tail-padding1.C"





struct X { ~X() {} int n; char d; };
struct Y { Y(); char c[3]; };
struct Z : X, virtual Y { Z(); };

X f() { X nrvo; __builtin_memset(&nrvo, 0, sizeof(X)); return nrvo; }
Z::Z() : Y(), X(f()) {}
Y::Y() { c[0] = 1; }

int main() {
  Z z;
  if (z.c[0] != 1)
__builtin_abort ();
}


Backtrace of the ICE:

  * frame #0: 0x000101b76378 cc1plus`internal_error(char const*, ...)
[inlined] auto_diagnostic_group::auto_diagnostic_group(this=) at
diagnostic.cc:2320:14
frame #1: 0x000101b76378 cc1plus`internal_error(gmsgid="in %s, at
%s:%d")
frame #2: 0x000101f92296
cc1plus`fancy_abort(file="/Users/fx/gcc-upstream/gcc/cp/constexpr.cc",
line=2918, function="cxx_eval_call_expression") at diagnostic.cc:2311:18
frame #3: 0x000101c8254e
cc1plus`::__second_sect_of_cxx_eval_call_expression() at constexpr.cc:2918:3
frame #4: 0x000100054f3b
cc1plus`::cxx_eval_constant_expression(ctx=0x7ff7bfefe500, t=,
lval=vc_prvalue, non_constant_p=0x7ff7bfefe4ee,
overflow_p=0x7ff7bfefe4ef, jump_target=0x) at
constexpr.cc:7257:36
frame #5: 0x000100060156
cc1plus`::cxx_eval_outermost_constant_expr(t=0x0001045b9880,
allow_non_constant=true, strict=, manifestly_const_eval=mce_false,
constexpr_dtor=false, object=0x) at constexpr.cc:8500:36
frame #6: 0x00010006601c cc1plus`maybe_constant_value(t=,
decl=0x, manifestly_const_eval=mce_false) at
constexpr.cc:8788:45
frame #7: 0x000100091cf1 cc1plus`::cp_fold(x=,
flags=) at cp-gimplify.cc:3052:31
frame #8: 0x000100091f46 cc1plus`::cp_fold_r(stmt_p=0x0001045a3ca0,
walk_subtrees=0x7ff7bfefe8dc, data_=0x7ff7bfefe9a0) at
cp-gimplify.cc:1077:28
frame #9: 0x000101952268 cc1plus`walk_tree_1(tp=,
func=, data=0x7ff7bfefe9a0, pset=,
lh=(cc1plus`cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*) at tree.cc:5453:1))(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*)) at
tree.cc:11398:25
frame #10: 0x000101952f0a cc1plus`walk_tree_1(tp=,
func=, data=0x7ff7bfefe9a0, pset=,
lh=(cc1plus`cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*) at tree.cc:5453:1))(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*)) at
tree.cc:11514:4
frame #11: 0x000100087c18
cc1plus`cp_fold_function(fndecl=0x0001045be000) at cp-gimplify.cc:1199:3
frame #12: 0x0001000dc0b9
cc1plus`finish_function(inline_p=) at decl.cc:18345:22
frame #13: 0x0001001938bf
cc1plus`::maybe_thunk_body(fn=0x0001045b4e00, force=) at
optimize.cc:445:26
frame #14: 0x00010019443a
cc1plus`maybe_clone_body(fn=0x0001045b4e00) at optimize.cc:557:38
frame #15: 0x000100278978
cc1plus`expand_or_defer_fn_1(fn=0x0001045b4e00) at semantics.cc:4901:24
frame #16: 0x000100278c5e
cc1plus`expand_or_defer_fn(fn=0x0001045b4e00) at semantics.cc:4932:28
frame #17: 0x00010013c6d8
cc1plus`synthesize_method(fndecl=) at method.cc:1842:24
frame #18: 0x0001000ee7c2 cc1plus`mark_used(decl=0x0001045be000,
complain=) at decl2.cc:5855:25
frame #19: 0x00010002016b cc1plus`::build_over_call(cand=,
flags=, complain=3) at call.cc:10403:21
frame #20: 0x00010001d900
cc1plus`build_new_method_call(instance=0x0001044305d0,
fns=0x000104591f20, args=, conversion_path=,
flags=1, fn_p=0x, complain=3) at call.cc:11710:31
frame #21: 0x00010001eac0
cc1plus`build_special_member_call(instance=,
name=0x000104422100, args=0x7ff7bfeff110, binfo=, flags=1,
complain=3) at call.cc:11190:31
frame #22: 0x00010010fc1d cc1plus`::expand_aggr_init_1(tree, tree,
tree, tree, int, tsubst_flags_t) at init.cc:2203:40
frame #23: 0x00010010fb34
cc1plus`::expand_aggr_init_1(binfo=0x0001045b02a0,
true_exp=0x, exp=0x0001044305d0, init=,
flags=1, complain=3)
frame #24: 0x000100117964
cc1plus`emit_mem_initializers(mem_inits=) at init.cc:1562:23
frame #25: 0x0001001ebec0
cc1plus`::cp_parser_ctor_initializer_opt_and_function_body(parser=0x0001045ac150,
in_function_try_block=false) at parser.cc:17188:29
frame #26: 0x0001001ed6e0
cc1plus`::cp_parser_function_definition_after_declarator(parser=0x0001045ac150,
inline_p=false) at parser.cc:32243:7
frame #27: 0x0001001eecbe
cc1plus`::cp_parser_init_declarator(parser=0x000

[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo

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

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

--- Comment #4 from Jakub Jelinek  ---
Seems
sed -i -e 's/ -fcase / -fcase -Wno-all /' libgm2/*/Makefile.am
sed -i -e 's/ -fcase / -fcase -Wno-all /' libgm2/*/Makefile.in
can work as a work-around for this bug, but it would still be nice to
understand what's going on and get it fixed.

[Bug c++/106310] [12/13 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #15 from Marek Polacek  ---
I tried to backport the patch to gcc11 but cp_parser_lookup_name has changed
too much.

[Bug target/111342] New: ICE for g++.target/i386/pr105980.C on x86_64-apple-darwin21

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

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

Bug ID: 111342
   Summary: ICE for g++.target/i386/pr105980.C on
x86_64-apple-darwin21
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

There is an ICE for g++.target/i386/pr105980.C on x86_64-apple-darwin21. It is
linked to the -mforce-indirect-call option passed by the testcase: without that
option, the test can compile fine.



$ cat pr105980.ii 
# 0 "/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C"
# 0 ""
# 0 ""
# 1 "/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C"



struct A {
  virtual ~A();
};
struct B : virtual A {};
void bar() { B(); }

$ /Users/fx/ibin/gcc/testsuite/g++/../../cc1plus -fpreprocessed pr105980.ii
-fPIC -quiet -mforce-indirect-call -std=gnu++20 
/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C: In member
function ‘virtual void B::_ZTv0_n24_N1BD1Ev()’:
/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C:8:19: error:
unrecognizable insn:
8 | void bar() { B(); }
  |   ^
(call_insn/j 4 3 5 (call (mem:QI (symbol_ref/i:DI ("_ZN1BD1Ev") [flags 0x8001]
) [0  S1 A8])
(const_int 0 [0]))
"/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C":7:8 -1
 (nil)
(nil))


The backtrace, obtained under lldb, is:

  * frame #0: 0x000101b76378 cc1plus`internal_error(char const*, ...)
[inlined] auto_diagnostic_group::auto_diagnostic_group(this=) at
diagnostic.cc:2320:14
frame #1: 0x000101b76378 cc1plus`internal_error(gmsgid="in %s, at
%s:%d")
frame #2: 0x000101f92296
cc1plus`fancy_abort(file="/Users/fx/gcc-upstream/gcc/config/i386/i386.md",
line=22310, function="insn_default_length") at diagnostic.cc:2311:18
frame #3: 0x000101ebe875 cc1plus`_fatal_insn(msgid=,
insn=0x0001046cfd80, file="/Users/fx/gcc-upstream/gcc/config/i386/i386.md",
line=22310, function="insn_default_length") at rtl-error.cc:108:15
frame #4: 0x000101ebe893
cc1plus`_fatal_insn_not_found(insn=, file=,
line=, function=) at rtl-error.cc:116:17
frame #5: 0x000101dd06fb cc1plus`insn_default_length(rtx_insn*) at
i386.md:22310:9
frame #6: 0x00010101883d cc1plus`shorten_branches(first=)
at final.cc:1088:35
frame #7: 0x0001019f32bc
cc1plus`::x86_output_mi_thunk(file=0x7ff84841be00,
thunk_fndecl=0x0001046b5300, delta=,
vcall_offset=, function=) at i386.cc:22087:20
frame #8: 0x000100ead83a cc1plus`expand_thunk(node=0x0001046cb000,
output_asm_thunks=, force_gimple_thunk=) at
symtab-thunks.cc:388:39
frame #9: 0x000100ebf673
cc1plus`cgraph_node::assemble_thunks_and_aliases(this=0x00010451bdd0) at
cgraphunit.cc:1763:15
frame #10: 0x000100ebf9a4 cc1plus`cgraph_node::expand() at
cgraphunit.cc:1914:31
frame #11: 0x000100ebf7b0
cc1plus`cgraph_node::expand(this=0x00010451bdd0)
frame #12: 0x000100ec10c0
cc1plus`symbol_table::compile(this=0x000104506000) at cgraphunit.cc:2191:19
frame #13: 0x000100ec4656
cc1plus`symbol_table::finalize_compilation_unit() [inlined]
symbol_table::compile(this=0x000104506000) at cgraphunit.cc:2311:3
frame #14: 0x000100ec4645
cc1plus`symbol_table::finalize_compilation_unit(this=0x000104506000)
frame #15: 0x0001015b5efe cc1plus`::compile_file() at toplev.cc:471:41
frame #16: 0x000101f96942 cc1plus`toplev::main(this=0x7ff7bfeff8fe,
argc=, argv=) at toplev.cc:2126:24
frame #17: 0x000101f9712e cc1plus`main(argc=8, argv=0x7ff7bfeffa48)
at main.cc:39:23

[Bug c++/105512] compilation with -fmodules-ts and std=c++20 leads to segfault

[mail--- via Gcc-bugs]

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

Gerrit Albrecht  changed:

   What|Removed |Added

 CC||m...@gerrit-albrecht.de

--- Comment #2 from Gerrit Albrecht  ---
Hi. I can confirm both reports. Tried it with "g++.exe (Rev2, Built by MSYS2
project) 13.2.0" MinGW64 compiler; both -std=c++23 and -std=c++20 segfault
together with -fmodules-ts. It works without -std option and with
D_GLIBCXX_USE_CXX11_ABI=0. Thanks.

[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo

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

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

--- Comment #3 from Jakub Jelinek  ---
So, narrowed it down to Fedora build doing essentially (stripped down from all
languages etc.):
CC=gcc \
CXX=g++ \
CFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection' \
CXXFLAGS=' -O2 -g -grecord-gcc-switches -Wformat -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection ' \
XCFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection' \
TCFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection' \
../configure --disable-bootstrap --enable-languages=c,c++,m2,lto
--enable-checking=release --enable-multilib --disable-libsanitizer
--with-gcc-major-version-only --enable-plugin --enable-gnu-indirect-function
--enable-cet --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
make -j32 'BOOT_CFLAGS=-O2 -fexceptions -g -grecord-gcc-switches -Wall
-Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now

And what matters is using -Wall during the build in *FLAGS.
/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/./gcc/gm2
-B/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/./gcc/ -c
-O2 -Wall -fm2-pathname=m2iso -I. -Ilibm2iso
-I/builddir/build/BUILD/gcc-13.2.1-20230728/gcc/m2/gm2-libs-iso
-fm2-pathname=m2pim -I/builddir/build/BUILD/gcc-13.2.1-20230728/gcc/m2/gm2-libs
-fiso -fextended-opaque -fm2-g -g -Wreturn-type -fcase -fm2-prefix=m2iso
../../../../libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/SeqFile.mod  -fPIC -DPIC
-o .libs/SeqFile.o; echo $?
../../gcc/m2/gm2-compiler/M2SymInit.def:1:case statement has no matching
selection
1
while
/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/./gcc/gm2
-B/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/./gcc/ -c
-O2 -fm2-pathname=m2iso -I. -Ilibm2iso
-I/builddir/build/BUILD/gcc-13.2.1-20230728/gcc/m2/gm2-libs-iso
-fm2-pathname=m2pim -I/builddir/build/BUILD/gcc-13.2.1-20230728/gcc/m2/gm2-libs
-fiso -fextended-opaque -fm2-g -g -Wreturn-type -fcase -fm2-prefix=m2iso
../../../../libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/SeqFile.mod  -fPIC -DPIC
-o .libs/SeqFile.o; echo $?
0

Shouldn't -Wall affect just warnings (without -Werror) and not whether
compilation succeeds or fails?

[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo

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

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

--- Comment #2 from Jakub Jelinek  ---
Though, bisection points to r13-7651-g824a37d0bfa9f5c232 as first commit which
fails to build.

[Bug fortran/111339] bounds-check does not detect nonconforming functions

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-09-08

--- Comment #1 from anlauf at gcc dot gnu.org ---
The use of the intrinsic TRANSFER produces the equivalent of a function
but with non-constant size, derived from pr34740, also not detected:

program p
  real, allocatable :: ivec(:)
  real  :: jvec(3) = [1,2,3]
  ivec= [1.,2.]
  ivec(:) = transfer (jvec, [1.])
end

Detected by NAG, but not by Intel.

[Bug fortran/111341] New: Elemental operator on zero-sized array seg-faults

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Bug ID: 111341
   Summary: Elemental operator on zero-sized array seg-faults
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: everythingfunctional at protonmail dot com
  Target Milestone: ---

There were some scenarios in the real code for this that it doesn't segfault,
but the following reproducer was able to do it reliably for me.

fpm.toml

name = "empty_elemental"
version = "0.1.0"
license = "license"
author = "Brad Richardson"
maintainer = "everythingfunctio...@protonmail.com"
copyright = "Copyright 2023, Brad Richardson"

[dependencies]
strff = { git = "https://gitlab.com/everythingfunctional/strff.git";, tag =
"v4.0.0" }
iso_varying_string = { git =
"https://gitlab.com/everythingfunctional/iso_varying_string.git";, tag =
"v3.0.3" }

app/main.f90

program main
  use iso_varying_string, only: varying_string, operator(//), put_line
  use strff, only: join

  implicit none

  call put_line(join("'" // empty() // "'", ","))
contains
  pure function empty()
type(varying_string), allocatable :: empty(:)
allocate(empty(0))
  end function
end program main

For context, varying_string just has an allocatable deferred length character
component, operator(//) is elemental, join concatenates an array of strings
with the given separator between each, and put_line is basically just print for
varying_string. So the above program should just print a single, zero length
character.

[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |13.3

[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo

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

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

--- Comment #1 from Jakub Jelinek  ---
So far bisected to between r13-7647 (builds fine) and r13-7660 (fails to
build), and can reproduce even without bootstrap.  I suspect r13-7650 but will
confirm it or not soon.

[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > Note -fwrapv or -fno-ivopts causes the issue to disappear.
> 
> Does your patch for PR111331 work for this one too?

No because it is unrelated, there was no min or max in the IR either.

[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:294d11837367455499786578377c530a0238b6ca

commit r13-7782-g294d11837367455499786578377c530a0238b6ca
Author: Jonathan Wakely 
Date:   Thu Aug 31 18:31:32 2023 +0100

libstdc++: Avoid useless dependency on read_symlink from tzdb

chrono::tzdb::current_zone uses filesystem::read_symlink, which creates
a dependency on the fs_ops.o object in libstdc++.a, which then creates
dependencies on several OS functions if --gc-sections isn't used. For
more details see PR libstdc++/104167 comment 8 and comment 11.

In the cases where that causes linker failures, we probably don't have
readlink anyway, so the filesystem::read_symlink call will always fail.
Repeat the preprocessor conditions for filesystem::read_symlink in the
body of chrono::tzdb::current_zone so that we don't create a
dependency on fs_ops.o for a function that will always fail.

libstdc++-v3/ChangeLog:

* src/c++20/tzdb.cc (tzdb::current_zone): Check configure macros
for POSIX readlink before using filesystem::read_symlink.

(cherry picked from commit f2eb6132c6951edf7960a82828c571a1b98a1a09)

[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #3)
> Note -fwrapv or -fno-ivopts causes the issue to disappear.

Does your patch for PR111331 work for this one too?

[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad

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

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

--- Comment #3 from Andrew Pinski  ---
Note -fwrapv or -fno-ivopts causes the issue to disappear.

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

[rs2740 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from TC  ---
Confirmed with my reporter that this fixes their actual code too.

[Bug c++/99599] [11/12/13/14 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

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

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

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

https://gcc.gnu.org/g:2154bcd6d43cfd821ca70e1583880c4ed955355d

commit r14-3809-g2154bcd6d43cfd821ca70e1583880c4ed955355d
Author: Patrick Palka 
Date:   Fri Sep 8 12:02:20 2023 -0400

c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

As described in detail in the PR, the CWG 2369 resolution has the
surprising consequence of introducing constraint recursion in seemingly
valid and innocent code.

This patch attempts to fix this surpising behavior for the majority of
problematic cases.  Rather than checking satisfaction before _all_
non-dependent conversions, as specified by the CWG resolution, this patch
makes us first check "safe" non-dependent conversions, then satisfaction,
then followed by other non-dependent conversions.  A conversion is
considered "safe" if computing it is guaranteed to not induce template
instantiation, and we conservatively determine this by checking for
user-declared constructors (resp. conversion functions) in the parm
(resp. arg) class type, roughly.

PR c++/99599

gcc/cp/ChangeLog:

* pt.cc (check_non_deducible_conversions): Add bool parameter
passed down to check_non_deducible_conversion.
(fn_type_unification): Call check_non_deducible_conversions
an extra time before satisfaction with noninst_only_p=true.
(conversion_may_instantiate_p): Define.
(check_non_deducible_conversion): Add bool parameter controlling
whether to compute only conversions that are guaranteed to
not induce template instantiation.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-recursive-sat4.C: Make 'Int' non-aggregate
in order to preserve intent of the testcase.
* g++.dg/cpp2a/concepts-nondep4.C: New test.

[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Of course, what exactly falls under the "g" constraint is target specific.
Though, because that constraint also allows the constant to be reload into a
register,
if such constant isn't valid, then RA should have reloaded it into register or
memory.

Seems the failure is that i386.cc (output_pic_addr_const) doesn't have the
CONST_WIDE_INT case unlike output_addr_const.

[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Mathieu Malaterre from comment #7)
> @rguenth You added `needs-bisection` keyword, but the example is quite
> small: 154 lines of code.

needs-bisection means to figure out which commit caused the regression.
That is different from needs-reduction keyword which says we need a reduction
still ...

[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE

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

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

--- Comment #3 from Jakub Jelinek  ---
Seems to be a pre-existing problem.

void
bar (void)
{
  __asm ("# %0" : : "g" unsigned __int128) 0x123456789abcdef0ULL) << 64) |
0x0fedcba987654321ULL));
}

fails the same way.

void
baz (void)
{
  __asm ("# %0" : : "g" (0x0fedcba987654321ULL));
}

works with both -fpic and -fno-pic.
If it is solely about the testsuite FAIL, I can certainly add -fno-pic to
dg-options
in there.
But this is instead whether 128-bit integer constants work with "g" in
-fpic/-fpie modes (on 64-bit arches), 65..128 bit _BitInt on 32-bit arches
would expand like the 575 bit one into memory rather than CONST_WIDE_INT.

[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin

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

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

--- Comment #2 from Francois-Xavier Coudert  ---
Created attachment 55857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55857&action=edit
Output of -fdump-rtl-final

[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target|x86_64-apple-darwin |x86_64-*-*
 Status|UNCONFIRMED |NEW
  Build|x86_64-apple-darwin |
   Last reconfirmed||2023-09-08
   Host|x86_64-apple-darwin |

--- Comment #1 from Andrew Pinski  ---
The testcase also fails on x86_64-linux-gnu with -fPIE too with the same error
message.

[Bug c/111340] New: gcc.dg/bitint-12.c fails on x86_64-apple-darwin

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

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

Bug ID: 111340
   Summary: gcc.dg/bitint-12.c fails on x86_64-apple-darwin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

gcc.dg/bitint-12.c fails on x86_64-apple-darwin, with excess error:

/Users/fx/gcc-upstream/gcc/testsuite/gcc.dg/bitint-12.c:18:3: error: invalid
'asm': invalid expression as operand

I am not sure what the cause is, I don't know x86_64 assembler :(

[Bug c/111337] ICE in gimple-isel.cc for RISC-V port

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

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

Robin Dapp  changed:

   What|Removed |Added

 CC||rdapp at gcc dot gnu.org

--- Comment #1 from Robin Dapp  ---
This is gcc.dg/pr70252.c BTW.

What happens is that, starting with
  maskdest = (vec_cond mask1 1 0) >= (vec_cond mask2 1 0)
we fold to
  maskdest = mask1 >= (vec_cond (mask2 1 0))
and then sink the ">=" into the vec_cond so we end up with
  maskdest = vec_cond (mask2 ? mask1 : 0),
i.e. a vec_cond with a mask "data mode".

In gimple-isel, when the target does not provide a vcond_mask
implementation for that (which none does) we assert that the mask mode
be MODE_VECTOR_INT.

IMHO this should not happen and we should not sink comparisons (that could be
folded to masks) into vec_cond.

I'm preparing a patch that prevents the sinking of comparisons for mask types.

[Bug middle-end/111296] RISC-V vector: ICE in lra_split_hard_reg_for during reload pass

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Jeremy Bennett  changed:

   What|Removed |Added

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

--- Comment #4 from Jeremy Bennett  ---
I can confirm this patch resolves the issue.

[Bug target/111295] RISC-V vector ICE in vsetvl pass

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Jeremy Bennett  changed:

   What|Removed |Added

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

--- Comment #7 from Jeremy Bennett  ---
I can confirm this patch resolves the issue.

[Bug c/109393] Very trivial address calculation does not fold

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

--- Comment #9 from Manolis Tsamis  ---
Created attachment 55856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55856&action=edit
Address calculation pattern v1

[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Septemb
   ||er/629701.html
   Keywords||patch

--- Comment #12 from Andrew Pinski  ---
Trunk patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629701.html


Patches for the other branches will almost the same except the match.pd part is
removed since it is not there.

[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Shaohua Li  changed:

   What|Removed |Added

 CC||yinyuefengyi at gmail dot com

--- Comment #2 from Shaohua Li  ---
I have another similar test case that even affects GCC-12 (bisected to
r12-6087-g51a24e4a984)

Compiler explorer: https://godbolt.org/z/d6hjfGqzj

I reported another bug111331, which also looks similar but has different
bisection point.

$ cat a.c
int printf(const char *, ...);
int a, b;
long c = 3521733542;
int d[2];
int e(int f, int g) {
  if (f == 0)
return 0;
  if (f > 200)
return 0;
  if (g)
return 5000 * f;
  return 0;
}
int main() {
  int h = 0;
  for (;e((int)c + 773233762, c + 773233760) + (int)c + 773228714 + h < 2; h++)
d[h] = b;
  printf("%d\n", a);
}
$

[Bug middle-end/111338] [14 Regression] ice in vn_walk_cb_data

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2023-09-08

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

Untested fix.

[Bug middle-end/111338] [14 Regression] ice in vn_walk_cb_data

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|ice in vn_walk_cb_data  |[14 Regression] ice in
   ||vn_walk_cb_data
  Component|c   |middle-end
Version|unknown |14.0

[Bug c/111338] ice in vn_walk_cb_data

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Slightly cleaned up, still -O1:

_BitInt(575) e;

int
main ()
{
  __atomic_fetch_and (&e, 1, __ATOMIC_RELAXED);
}

(otherwise you'd want the wb suffix on the large constant to avoid warning).

Or even
_BitInt(575) e;

_BitInt(575)
foo (void)
{
  return e & 1;
}

The problem is that push_partial_def uses a fixed size 512-bit buffer, for
larger stuff it fails and my PR93582 patch assumed it doesn't fail.

[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

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

--- Comment #7 from Sergei Trofimovich  ---
Sounds reasonable. Closing as FIXED.

[Bug c/111338] ice in vn_walk_cb_data

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #3 from David Binderman  ---
Jakub seems to have implemented a lot of the _BitInt support.

[Bug c/111338] ice in vn_walk_cb_data

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
The code first seems to go wrong sometime between g:c1597e7fb9f9ecb9
and g:10d59b802a7db9ae, which is 36 commits.

[Bug c/111338] ice in vn_walk_cb_data

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced code is:

_BitInt(575) e;
main() {
  __atomic_fetch_and(
  &e,
 
40418462630594385361724744395454079240140931656245750192534103967695265126850678980088699287669565365078793986191778469857714756111026776864987769580622009237241167211461,
  __ATOMIC_RELAXED);
}

[Bug fortran/111339] New: bounds-check does not detect nonconforming functions

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

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

Bug ID: 111339
   Summary: bounds-check does not detect nonconforming functions
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
CC: anlauf at gcc dot gnu.org, dfranke at gcc dot gnu.org,
gcc-bugs at gcc dot gnu.org,
P.Schaffnit at access dot rwth-aachen.de,
tkoenig at gcc dot gnu.org, urbanjost at comcast dot net,
vivekrao4 at yahoo dot com
Depends on: 31059
Blocks: 27766, 37802
  Target Milestone: ---

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

Gfortran does not report an error if an allocatable array is set to a function
of larger size, for example in the code below.

program p
  integer, allocatable :: ivec(:)
  ivec = [1, 2]
  ! ivec(:) = func() ! case 1 (already diagnosed)
  ! ivec(:) = ivec + func()  ! case 2
  ! ivec(:) = func() + ivec  ! case 3
contains
  function func()
integer :: func(3)
func = [7, 8, 9]
  end function func
end

Uncomment either case 1, case 2 or case 3, and see if the program leads to a
runtime error with -fcheck=bounds.
Case 1 is diagnosed, but not case 2 and neither case 3.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug 27766] [meta-bug] -fbounds-check related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059
[Bug 31059] bounds-check does not detect nonconforming assignment arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802
[Bug 37802] Improve wording for matmul bound checking

[Bug middle-end/111329] [14 regression] gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails after r14-3745-g4f4fa2501186e4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-09-08
 Ever confirmed|0   |1

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

So far only very lightly tested patch (tested that the test FAILs in
bootstrapped build, applied patch, make -j32 in the stage3 directory, make
check for the test again, which now PASSes).
Had to put the out of line function into wide-int-print.cc rather than
pretty-print.cc, because otherwise e.g. modula2 doesn't link.

[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option

[malat at debian dot org via Gcc-bugs]

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

--- Comment #7 from Mathieu Malaterre  ---
@rguenth You added `needs-bisection` keyword, but the example is quite small:
154 lines of code.

[Bug c++/106310] [12/13 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #14 from Florian Weimer  ---
(In reply to Martin Liška from comment #4)
> Started with r12-6754-g30f2c22def739211.

And this was backported as r11-9991-g8d2f59c8e26960df, so this issue currently
exists on the gcc-11 branch.

[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__

[malat at debian dot org via Gcc-bugs]

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

Mathieu Malaterre  changed:

   What|Removed |Added

 CC||malat at debian dot org

--- Comment #6 from Mathieu Malaterre  ---
looks like this one should be marked fixed.

[Bug c/111338] New: ice in vn_walk_cb_data

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111338
   Summary: ice in vn_walk_cb_data
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

>From the gcc testsuite:

$ ~/gcc/results/bin/gcc -c -w ./gcc.dg/bitint-18.c
$
$ ~/gcc/results/bin/gcc -c -w -O1 ./gcc.dg/bitint-18.c
during GIMPLE pass: fre
./gcc.dg/bitint-18.c: In function ‘main’:
./gcc.dg/bitint-18.c:44:1: internal compiler error: in vn_walk_cb_data, at
tree-ssa-sccvn.cc:1866
   44 | }
  | ^
0x10897ff vn_walk_cb_data::vn_walk_cb_data(vn_reference_s*, tree_node*,
tree_node**, vn_lookup_kind, bool, tree_node*, bool)
../../trunk.year/gcc/tree-ssa-sccvn.cc:1866
0x10784e7 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
../../trunk.year/gcc/tree-ssa-sccvn.cc:4017
0x10860ec visit_nary_op(tree_node*, gassign*)
../../trunk.year/gcc/tree-ssa-sccvn.cc:5427

$ ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb38/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb38/gcc/results.20230908.asan.ubsan/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.year/configure
--prefix=/home/dcb38/gcc/results.20230908.asan.ubsan --disable-multilib
--disable-bootstrap --with-build-config=bootstrap-asan
--with-build-config=bootstrap-ubsan --with-pkgversion=daaed758517c81fc
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230907 (experimental) (daaed758517c81fc)

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #4 from JuzheZhong  ---
Update status:

All C++ FAILs are fixed.

There are only 38 FAILs in total:

FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl,  -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  compariso   n
FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl,  -O3 -g  comparison
FAIL: gcc.dg/Wstringop-overflow-70.c  (test for warnings, line 22)
FAIL: gcc.dg/pr104992.c scan-tree-dump-times optimized " % " 9
FAIL: gcc.dg/pr70252.c (internal compiler error: in
gimple_expand_vec_cond_expr, at gimple-isel.cc:284)
FAIL: gcc.dg/pr70252.c (test for excess errors)
FAIL: gcc.dg/pr92301.c execution test
FAIL: gcc.dg/signbit-2.c scan-tree-dump-not optimized "\\s+>>\\s+31"
FAIL: gcc.dg/signbit-5.c execution test
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"
FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: loop with
[0-9]+ iterations completely unrolled"
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo"
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized
"BIT_INSERT_EXPR" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized
"BIT_INSERT_EXPR" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect "vectorized 0
loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect "vectorized 0
loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded by 254"
FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254"
FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom "Unrolling 2
times." 2
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Combination" 1
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3
times." 1
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Combination" 2
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3
times." 1
FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing predictive
commoning without unrolling"
FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized
"(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+
(?:vect_)?sum_[\\d._]+|(?:v   ect_)?sum_[\\d._]+ \\+ (?:vect_)?_[\\d._]+)" 1
FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts " 
Type:\\tREFERENCE ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts " 
Type:\\tREFERENCE ADDRESS\n" 2
FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness wrto loop
niter:\tNo-overflow"
FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts "  Type:\\tREFERENCE
ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths "join
point for if-convertable half-diamond" 1
FAIL: gcc.target/riscv/rvv/base/vector-abi-9.c  (test for warnings, line 9)

Most of them are Dump FAIL which are because of missing VLS modes patterns.

Will address them soon

[Bug c/111337] New: ICE in gimple-isel.cc for RISC-V port

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 111337
   Summary: ICE in gimple-isel.cc for RISC-V port
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

This following case cause ICE:

extern unsigned char a [150];
extern unsigned char b [150];
extern unsigned char c [150];
extern unsigned char d [150];
extern unsigned char e [150];

void foo () {
  for (int i = 92; i <= 141; i += 2) {
int tmp = (d [i] && b [i]) <= (a [i] > c [i]);
e [i] = tmp >> b [i];
  }
}

auto.c:7:6: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:284
7 | void foo () {
  |  ^~~
0x1a9e309 gimple_expand_vec_cond_expr
../../../../gcc/gcc/gimple-isel.cc:283
0x1a9ea56 execute
../../../../gcc/gcc/gimple-isel.cc:390


Bause of this piece of code:
  gcc_assert (GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (op0)))
  == MODE_VECTOR_INT);

The statement cause such assertion FAIL was produced by "vrp2":

Before auto.c.202t.vrp2:

  mask__5.33_165 = vect__3.26_157 > vect__4.31_163;
  vect_patt_67.34_168 = VEC_COND_EXPR ;
  vect_patt_68.35_169 = (vector([4,4]) int) vect_patt_67.34_168;
  mask__7.36_170 = vect_patt_68.35_169 >= vect_patt_66.22_152;
  vect_patt_69.37_173 = VEC_COND_EXPR ;
  vect_patt_70.38_174 = (vector([4,4]) unsigned char) vect_patt_69.37_173;
  vect_patt_71.39_176 = MIN_EXPR ;
  vect_patt_72.40_177 = vect_patt_70.38_174 >> vect_patt_71.39_176;
  .MASK_LEN_SCATTER_STORE (vectp_e.42_181, { 0, 2, 4, ... }, 1,
vect_patt_72.40_177, { -1, ... }, _186, 0);

auto.c.202t.vrp2:

  mask__5.33_165 = vect__3.26_157 > vect__4.31_163;
  vect_patt_67.34_168 = VEC_COND_EXPR ;
  vect_patt_68.35_169 = VEC_COND_EXPR ;
  mask__7.36_170 = VEC_COND_EXPR ;
  vect_patt_69.37_173 = VEC_COND_EXPR ;
  vect_patt_70.38_174 = VEC_COND_EXPR ;
  vect_patt_71.39_176 = MIN_EXPR ;
  vect_patt_72.40_177 = vect_patt_70.38_174 >> vect_patt_71.39_176;
  .MASK_LEN_SCATTER_STORE (vectp_e.42_181, { 0, 2, 4, ... }, 1,
vect_patt_72.40_177, { -1, ... }, _186, 0);

There is a odd STMT here:

mask__7.36_170 = VEC_COND_EXPR ;

It seems that it should be logical operations of MASK?

[Bug fortran/108957] Fortran FE memleak with interfaces

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

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

Mikael Morin  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-08
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Mikael Morin  ---
(In reply to anlauf from comment #4)
> Mikael,
> 
> are you still onto it?

Thanks for the reminder.
This PR had disappeared from my radar.
Taking it.

[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad

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

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

Xi Ruoyao  changed:

   What|Removed |Added

Summary|Wrong code at -O2/3 since   |[14 Regression] Wrong code
   |r14-2472-g14b10ff30ad   |at -O2/3 since
   ||r14-2472-g14b10ff30ad
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-09-08
 Ever confirmed|0   |1
  Component|c   |tree-optimization

--- Comment #1 from Xi Ruoyao  ---
Confirmed.

[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization

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

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

--- Comment #15 from Xi Ruoyao  ---
(In reply to chenglulu from comment #13)
> (In reply to Xi Ruoyao from comment #12)
> > (In reply to chenglulu from comment #11)
> > > (In reply to Xi Ruoyao from comment #10)
> > > > (In reply to Xi Ruoyao from comment #9)
> > > > 
> > > > >  (define_insn "di3_fake"
> > > > >[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > > > > - (sign_extend:DI
> > > > > -   (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > -   (match_operand:DI 2 "register_operand" 
> > > > > "r,r,r"]
> > > > > -  ""
> > > > > + (if_then_else
> > > > > +   (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > +(sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > > +(eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > > +(sign_extend:DI (subreg:SI (match_dup 2) 0
> > > > > +   (sign_extend:DI
> > > > > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > > + (subreg:SI (match_dup 2) 0)))
> > > > > +   (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > > > 
> > > > With this the compiler will still believe all bad {div,mod}.w{,u}
> > > 
> > > I think this is already defined as UNSPEC. Isn’t the simpler the logic, 
> > > the
> > > better?
> > 
> > Yes, I think we should just use 4 different UNSPEC_ values and the simple
> > version.  But I've not find a way to use 4 different UNSPEC_ values in the
> > RTL template except duplicating everything 4 times...
> 
> I still have a question that I don't quite understand, that is, why that the
> four generated strings are equivalent when using an UNSPEC name? My template
> names are different, and they will not be automatically matched during
> optimization.???

Oh I get it, you mean

 (define_insn "di3_fake"
   [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
+ (unspec:DI [(any_div:DI
+   (match_operand:DI 1 "register_operand" "r,r,0")
+   (match_operand:DI 2 "register_operand" "r,r,r"))]
+UNSPEC_ANY_DIV)))]
   ""
 {
   return loongarch_output_division (".w\t%0,%1,%2", operands);

Good idea! I think it's better than my stupid hacks :).

I'd been thinking about:

 (define_insn "di3_fake"
   [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
+ (unspec:DI [(match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r")]
+UNSPEC_ANY_DIV)))]
   ""
 {
   return loongarch_output_division (".w\t%0,%1,%2", operands);

and this is just wrong.

[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization

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

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

--- Comment #14 from Xi Ruoyao  ---
I'm trying

diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..44d9b99b2f5 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -64,6 +64,12 @@ (define_c_enum "unspec" [
   UNSPEC_CRC
   UNSPEC_CRCC

+  ;; 32-bit divisions can produce unspecified value if TARGET_64BIT
+  UNSPEC_DIV_W
+  UNSPEC_UDIV_W
+  UNSPEC_MOD_W
+  UNSPEC_UMOD_W
+
   UNSPEC_LOAD_FROM_GOT
   UNSPEC_PCALAU12I
   UNSPEC_ORI_L_LO12
@@ -461,6 +467,8 @@ (define_code_iterator neg_bitwise [and ior])
 ;; This code iterator allows unsigned and signed division to be generated
 ;; from the same template.
 (define_code_iterator any_div [div udiv mod umod])
+(define_code_attr ANY_DIV [(div "DIV") (udiv "UDIV")
+  (mod "MOD") (umod "UMOD")])

 ;; This code iterator allows addition and subtraction to be generated
 ;; from the same template.
@@ -918,8 +926,9 @@ (define_insn "*3"
 (define_insn "di3_fake"
   [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
+ (unspec:SI [(match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r")]
+UNSPEC_)))]
   ""
 {
   return loongarch_output_division (".w\t%0,%1,%2", operands);

But:

../../gcc/gcc/config/loongarch/loongarch.md:931:23: error: invalid decimal
constant "UNSPEC_"

[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #13 from chenglulu  ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to chenglulu from comment #11)
> > (In reply to Xi Ruoyao from comment #10)
> > > (In reply to Xi Ruoyao from comment #9)
> > > 
> > > >  (define_insn "di3_fake"
> > > >[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > > > -   (sign_extend:DI
> > > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > - (match_operand:DI 2 "register_operand" 
> > > > "r,r,r"]
> > > > -  ""
> > > > +   (if_then_else
> > > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > +  (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > +  (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > +  (sign_extend:DI (subreg:SI (match_dup 2) 0
> > > > + (sign_extend:DI
> > > > +   (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > +   (subreg:SI (match_dup 2) 0)))
> > > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > > 
> > > With this the compiler will still believe all bad {div,mod}.w{,u}
> > 
> > I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
> > better?
> 
> Yes, I think we should just use 4 different UNSPEC_ values and the simple
> version.  But I've not find a way to use 4 different UNSPEC_ values in the
> RTL template except duplicating everything 4 times...

I still have a question that I don't quite understand, that is, why that the
four generated strings are equivalent when using an UNSPEC name? My template
names are different, and they will not be automatically matched during
optimization.???

[Bug c/111336] New: Wrong code at -O2/3 since r14-2472-g14b10ff30ad

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 111336
   Summary: Wrong code at -O2/3 since r14-2472-g14b10ff30ad
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

gcc at -O2/3 produced the wrong code on the following testcase.

Bisected to r14-2472-g14b10ff30ad

Compiler explorer: https://godbolt.org/z/njdcv5aK8

$ cat a.c
int printf(const char *, ...);
int a, b;
long c = 3521733542;
int d[2];
int e(int f, int g) {
  if (f == 0)
return 0;
  if (f > 200)
return 0;
  if (g)
return 5 * f;
  return 0;
}
int main() {
  int h = 0;
  for (; e((int)c + 773233762, c + 60) + 773163185 + h < 2; h++)
d[h] = b;
  printf("%X\n", a);
}
$
$ gcc -O0 a.c && ./a.out
0
$ gcc -O2 a.c && ./a.out
Segmentation fault
$