[Bug tree-optimization/28794] missed optimization with non-COND_EXPR and vrp and comparisions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #5 from Andrew Pinski  ---
I am going to finally optimize this.

My plan is to change simplify_cond_using_ranges_1 to take 3 reference arguments
and return true if a change to them.

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
(In reply to Alexander Monakov from comment #7)
> Thanks for identifying the problem. Please don't rename the argument to
> 'op_mask' though: the parameter itself is not a mask, it's an eight-bit
> control word of the vpternlog instruction (holding the logic table of a
> three-operand Boolean function). The function derives a three-bit mask from
> it.

I'll rename it as ternlog_imm8 to avoid confusion.

[Bug tree-optimization/103281] [12/13/14 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||110293

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> We should be able to optimize:

This second testcase in comment #1 is now optimized since
r14-2501-g285c9d042e90a7425b376 .

Likewise the testcase in comment #8.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293
[Bug 110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #7 from Alexander Monakov  ---
Thanks for identifying the problem. Please don't rename the argument to
'op_mask' though: the parameter itself is not a mask, it's an eight-bit control
word of the vpternlog instruction (holding the logic table of a three-operand
Boolean function). The function derives a three-bit mask from it.

[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-August/
   ||626435.html

--- Comment #11 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626435.html

[Bug c++/110619] Dangling pointer returned from constexpr function converts in nullptr

[peter at cordes dot ca via Gcc-bugs]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #7 from Peter Cordes  ---
(In reply to Andrew Pinski from comment #2)
> >but it is not nullptr.
> 
> Or is it just undefined so it could be considered a nullptr ...


Implementation-defined behaviour, according to answers on
https://stackoverflow.com/questions/76843246/why-does-the-address-of-an-out-of-scope-variable-equal-zero-with-constexpr


https://eel.is/c++draft/basic.compound#def:value,invalid_pointer

https://eel.is/c++draft/basic.stc.general#4

>  Indirection through an invalid pointer value and passing an invalid pointer 
> value to a deallocation function have undefined behavior.
> **Any other use of an invalid pointer value has implementation-defined 
> behavior.**

So this wasn't a bug, but the new behaviour is also allowed.

This commit could be reverted or kept, depending on maintainability and/or
quality-of-life for users of GCC.  Having it pick the other
implementation-defined behaviour from clang (GCC's previous behaviour) is maybe
a *good* thing, to help programmers catch dependence on an invalid pointer
being either null or non-null if they try their code with both compilers.

[Bug analyzer/110928] New: ICE with -fanalyzer on -Wanalyzer-out-of-bounds checker

[geoffreydgr at icloud dot com via Gcc-bugs]

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

Bug ID: 110928
   Summary: ICE with -fanalyzer on -Wanalyzer-out-of-bounds
checker
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: geoffreydgr at icloud dot com
  Target Milestone: ---

ICE bug when analyzing the folowing program. And there also is a FP report of
out-of-bounds. 

cmd: gcc -O0 -fanalyzer
gcc version: x86-64 gcc (trunk)
compiler explore: https://godbolt.org/z/Gsx5WTqKj

```c
#include "stdio.h"
#include "stdint.h"


uint64_t d(int32_t h) {
  uint64_t j[2][6];
  int32_t k;
  for (k = 1;;) {
printf("FLAG\n");
if (h < 106 || j[k][h])
  return 0;
  }
}
int16_t e() {
  int32_t f[5];
  for (f[2] = 3; f[2]; --f[2])
d(0);
}

int main() { e(); }

```

output:
```
: In function 'd':
:10:24: warning: stack-based buffer over-read [CWE-121]
[-Wanalyzer-out-of-bounds]
   10 | if (h < 106 || j[k][h])
  |^~~
  'd': events 1-4
|
|6 |   uint64_t j[2][6];
|  |^
|  ||
|  |(1) capacity: 96 bytes
|..
|   10 | if (h < 106 || j[k][h])
|  |~   ~~~
|  ||   |
|  ||   (3) ...to here
|  ||   (4) read of 8 bytes at offset 'h * 8 + 48'
exceeds 'j'
|  |(2) following 'false' branch (when 'h > 105')...
|
:10:24: note: valid subscripts for 'j' are '[0]' to '[1]'
   10 | if (h < 106 || j[k][h])
  |^~~
during IPA pass: analyzer
:10:8: internal compiler error: in fold_binary_loc, at
fold-const.cc:11320
   10 | if (h < 106 || j[k][h])
  |^
0x216b2ae internal_error(char const*, ...)
???:0
0x9d1202 fancy_abort(char const*, int, char const*)
???:0
0xcdba8d fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0x172fc13 generic_simplify_MULT_EXPR(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*)
???:0
0xcd40c5 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0xcdba8d fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0x14beb7f ana::region_offset::calc_symbolic_bit_offset(ana::region_model
const&) const
???:0
0x213be3b ana::access_range::get_size(ana::region_model const&,
ana::bit_size_expr*) const
???:0
0x2148663 ana::access_diagram_impl::access_diagram_impl(ana::access_operation
const&, diagnostic_event_id_t, text_art::style_manager&, text_art::theme
const&, ana::logger*)
???:0
0x213ce0b ana::access_diagram::access_diagram(ana::access_operation const&,
diagnostic_event_id_t, text_art::style_manager&, text_art::theme const&,
ana::logger*)
???:0
0x1fbf5d3 ana::symbolic_buffer_over_read::emit(rich_location*, ana::logger*)
???:0
0x1fe653e ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
???:0
0x1fe6d40 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
???:0
0x149e891 ana::impl_run_checkers(ana::logger*)
???:0
0x149f83f ana::run_checkers()
???: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/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #5)
> I'm working on a patch.

 int
-vpternlog_redundant_operand_mask (rtx *operands)
+vpternlog_redundant_operand_mask (rtx op_mask)
 {
   int mask = 0;
-  int imm8 = XINT (operands[4], 0);
+  int imm8 = INTVAL (op_mask);


We should use INTVAL instead of XINT.

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
I'm working on a patch.

[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Depends on||109181
   Last reconfirmed||2023-08-07

--- Comment #1 from Andrew Pinski  ---
Confirmed, I suspect PR 109181 is the same (or rather reduced example).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
[Bug 109181] requires expression type requirement rejects valid type when it is
a nested member template

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---
(In reply to 罗勇刚(Yonggang Luo) from comment #6)
> MSVC also added, clang seems have optimization issue, but MSVC doesn't have
> that
No, I think what clang does is correct,

f(int, int): # @f(int, int)
testedi, edi   --- when source operand is zero.
je  .LBB0_2
rep   bsf eax, edi
ret
.LBB0_2:
mov eax, 32
ret


 The key difference between TZCNT and BSF instruction is that TZCNT provides
operand size as output when source operand is zero while in the case of BSF
instruction, if source operand is zero, the content of destination operand are
undefined.

https://godbolt.org/z/s74dfdWP4

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

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

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

--- Comment #4 from Sam James  ---
Created attachment 55699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55699=edit
reduced.i

[Bug c++/110927] New: GCC fails to parse dependent type in concept through partial specialization

[danakj at orodu dot net via Gcc-bugs]

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

Bug ID: 110927
   Summary: GCC fails to parse dependent type in concept through
partial specialization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danakj at orodu dot net
  Target Milestone: ---

Repro: https://godbolt.org/z/rWbbGzWdb

```
#include 
#include 

template 
struct Foo;

template <>
struct Foo {
template 
using Type = U;
};

struct S {
template 
using Type = U;
};

template 
concept C1 = requires { typename Foo::template Type; };

template 
concept C2 = requires { typename T::template Type; };

int main() {
static_assert(C1);  // Fails with `the required type 'typename
Foo::Type' is invalid`
static_assert(C2);  // Passes.
}
```

This is accepted by Clang and MSVC.

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

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

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

--- Comment #3 from Sam James  ---
Created attachment 55698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55698=edit
reduced.i

Reduced version attached, not cleaned it up yet.

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[luoyonggang at gmail dot com via Gcc-bugs]

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

--- Comment #6 from 罗勇刚(Yonggang Luo)  ---
MSVC also added, clang seems have optimization issue, but MSVC doesn't have
that


https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIMwDMpK4AMngMmAByPgBGmMQg0gAOqAqETgwe3r7%2BQSlpjgJhEdEscQnSdpgOGUIETMQEWT5%2BgbaY9oUMdQ0ExVGx8Ym29Y3NOW0Ko33hA2VDkgCUtqhexMjsHOYBeFRYVADUAPoAskJuRwBq2ABKJhoAgtvhyN5YByYBbuEExOEAdAhPth7k9Ah0lKDngxXl53p83KoABwANh%2BfwYgOBUPBDHwVChjx%2BByoEGJTFIB2JMUWUIA7FZHgdmSzmcRMAQ1gxjgQAF7IQRHLwBMwsiBMWkBRlPOkAEQ4y1onAArLw/BwtKRUJw3NZrAcFKt1pgPoEeKQCJoFcsANYSFH/DQBZUogJ0lEATkkkjpHpRkiCSo4kjVVq1nF4ChAGgtVuWcFgSDQLCSdHi5EoydT9ASADdkEkkkdc1wPUcDARMFMjqp/aQsLm8BtLnhMAB3ADySUYnHNNFoleIUYgMTDMXCDQAnr3eOPmMRJx2YtpqpbuLxk2xBB2GLRpxreFgYl5gG4xLQo%2Bv65gWIZgOID/W8Oyarmq2HMKpql5KzPyIIOjDWg8BiYgpw8LAw1%2BPAWBnZYqAMYAFBbdsux7K9%2BEEEQxHYKQZEERQVHUR9dDMfQ7xQPVLH0ECo0gZZUCSLpLwAWg7MxeFQN9iD%2BLA6IgZYqhqZwIFccY/C4YI8X6Upyj0fJ0gEcT5NSRSGBkwYEkkoSuh6MZPBaPQdNqaYNPmLSRl6ZTtNM2ZZKGLhBKNDYJEVFVQ0fbUOAOWtJAOFgFHzA4Sw9f4KyrAgDggXBCBIU0Akc3g1y0RZbQkSR/mVDQzC9JENC4FENDyuknX0TgQ1IdVNS8yNo1jA94xgRAUFQFM0zICgICzdqUAMIwjl%2BLwGBta9G2bVtO27dU%2BzoQdh1HR85ynP8loXJcVwcP9N0YAgdz3MMjxPM9aAvP8sFvIwH01fAX0cN9L01T9v1/K8fkAx9gNA8CME2TVoNg9d4MQ5CJrQ6beEw4RRHEPDIcItQw10SS%2BuMKibE%2B/iGKYjJWI7AJOO43j33o9pOgyFw8WsqT0DMuTJIUroqYZjJaYc0nVxMqyDJybSOg5gQ9JmEpNKM6YqamXpWa0py1hcxyyo4VVKrDLyfNRFj/QOV47yiwbhsWKKYqIYh4sS%2BqUrSswHTMLgNDpJEzEkKRlQK91pCDCqqs4iNbDq5KFVIBNmu6nMMy61rsyGJtkDMbLSxjBsm0wFDJvQmaB3ieaxwnBcVpzxdl1XLbWq3Xbd33a7MGPU9z0vc1zrvK7D2fDn7o/L9kB/TZzTeoNNU%2BsCFwg36kr%2BAGeCBpgkJTsG/0h7CYekOGlARkiQEDCjTEsawaJiTGtWxgRcY4rVCbwPj4EEvnhL8UTKe5iTqallSCgyJnVK6Z/ebJgWxYfozr66VssLcyosubZEfhLRoX8ZbGlcgrJWXtwzeWRCiDWflo4HFjjbf4oUNCG3wMbU2iwkpxjSlwJE/xUTKh9MqP0eUzD2yRArT2KsfZRhjP7Rq8AIBIFWAQJIP4w4h3iJEVgmxUHoIOMAZAyBdbECGjaEhwRCEkHPnoee0NcJL1kPDYimpSKkDbGBJIcEEEeWqpwDsP5BGRVQIcXy/lApyJCmFJglYphRQ8G1HM8UzDKK4WlOk/w6QUMkEiD0jtspmCRG6MiHsLHew4LVThcZA5NV4S1Hx6ZOoiISMALgIpRpJxnlNOes1M6UAWpqVa%2B5zS1PWkXK821tzlwOlXI6tczo3kbiPJ8t08Bt0fE9TuL0e4AT7rwAe31IKPn%2BmYhCU8QaoTKRhWQC9tH4XkCvfROhhgo0otvaiGNL4H2YpwNiooWJlBYHgAm8Qib72MiJMS/9JKhDsiLemH835vNIMzIonzQHf35t0P%2BECAE/zBZLIFdNLL6QhTZGFIC6awLlm5RWiTkFqzQZrGRcjCn/FFNFVRJtthm0CaQO0BV/gojpfShlDL3blSxTVX2qSGoYpPkgtllLuJpGcJIIAA%3D

The demo code is:

#ifdef _MSC_VER
#include 
#else
#include 
#endif

int f(int a, int b)
{
return _tzcnt_u32   (a);
}

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

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

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

--- Comment #2 from Sam James  ---
Created attachment 55697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55697=edit
matmul_i1.i

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Also reported here:
https://gcc.gnu.org/pipermail/gcc/2023-August/242212.html

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
   Target Milestone|--- |14.0
   Keywords||build, ice-checking,
   ||ice-on-valid-code
  Component|bootstrap   |target

[Bug bootstrap/110926] New: [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_o

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

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

Bug ID: 110926
   Summary: [14 regression] Bootstrap failure (matmul_i1.c:1781:1:
internal compiler error: RTL check: expected elt 0
type 'i' or 'n', have 'w' (rtx const_int) in
vpternlog_redundant_operand_mask, at
config/i386/i386.cc:19460)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

libtool: compile: 
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-p
c-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -DHAVE_CONFIG_H -I.
-I/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-202308
06/libgfortran
-iquote/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/io
-I/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/../gcc
-I/var/t
mp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/../gcc/config
-I../.././gcc
-I/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/../libgcc
-I../lib
gcc
-I/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/../libbacktrace
-I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-sty
le-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration
-Werror=vla -fcf-protection -mshstk -fcx-fortran-rules -ffunction-sections
-fdata-sections -ffast-math -ftree-vectorize -funroll-loo
ps --param max-unroll-times=4 -g -pipe -march=native -fdiagnostics-color=always
-Wreturn-type -ggdb3 -O2 -c
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_
i1.c  -fPIC -DPIC -o .libs/matmul_i1.o
during RTL pass: split1
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:
In function ‘matmul_i1_avx512f’:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:1781:1:
internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w'
(rtx const_int) in vpternlog_redundant_operand_mask, at
config/i386/i386.cc:19460
 1781 | }
  | ^
0x5559de26dc2d rtl_check_failed_type2(rtx_def const*, int, int, int, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/rtl.cc:761
0x5559de340bfe vpternlog_redundant_operand_mask(rtx_def**)
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/i386.cc:19460
0x5559dfec67a6 split_44
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/sse.md:12730
0x5559dfec67a6 split_63
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/sse.md:28428
0x5559deb8a682 try_split(rtx_def*, rtx_insn*, int)
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/emit-rtl.cc:3800
0x5559deb8adf2 try_split(rtx_def*, rtx_insn*, int)
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/emit-rtl.cc:3972
0x5559def69194 split_insn
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:3385
0x5559def70c57 split_all_insns()
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:3489
0x5559def70d0c execute
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:4413
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.

[Bug target/105504] Fails to break dependency for vcvtss2sd xmm, xmm, mem

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #8 from Hongtao.liu  ---
(In reply to Eric Gallager from comment #7)
> (In reply to CVS Commits from comment #6)
> > The master branch has been updated by hongtao Liu :
> > 
> > https://gcc.gnu.org/g:5e005393d4ff0a428c5f55b9ba7f65d6078a7cf5
> > 
> > commit r13-1009-g5e005393d4ff0a428c5f55b9ba7f65d6078a7cf5
> > Author: liuhongt 
> > Date:   Mon May 30 15:30:51 2022 +0800
> > 
> > Disparages SSE_REGS alternatives sligntly with ?v instead of *v in
> > *mov{si,di}_internal.
> > 
> > So alternative v won't be igored in record_reg_classess.
> > 
> > Similar for *r alternatives in some vector patterns.
> > 
> > It helps testcase in the PR, also RA now makes better decisions for
> > gcc.target/i386/extract-insert-combining.c
> > 
> > movd%esi, %xmm0
> > movd%edi, %xmm1
> > -   movl%esi, -12(%rsp)
> > paddd   %xmm0, %xmm1
> > pinsrd  $0, %esi, %xmm0
> > paddd   %xmm1, %xmm0
> > 
> > The patch has no big impact on SPEC2017 for both O2 and Ofast
> > march=native run.
> > 
> > And I noticed there's some changes in SPEC2017 from code like
> > 
> > mov mem, %eax
> > vmovd %eax, %xmm0
> > ..
> > mov %eax, 64(%rsp)
> > 
> > to
> > 
> > vmovd mem, %xmm0
> > ..
> > vmovd %xmm0, 64(%rsp)
> > 
> > Which should be exactly what we want?
> > 
> > gcc/ChangeLog:
> > 
> > PR target/105513
> > PR target/105504
> > * config/i386/i386.md (*movsi_internal): Change alternative
> > from *v to ?v.
> > (*movdi_internal): Ditto.
> > * config/i386/sse.md (vec_set_0): Change alternative *r
> > to ?r.
> > (*vec_extractv4sf_mem): Ditto.
> > (*vec_extracthf): Ditto.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * gcc.target/i386/pr105513-1.c: New test.
> > * gcc.target/i386/extract-insert-combining.c: Add new
> > scan-assembler-not for spill.
> 
> Did this fix it?

Yes.

[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> +FAIL: c-c++-common/Wrestrict.c  -Wc++-compat  (test for excess errors)
> Excess errors:

This is just like the builtin-sprintf-warn-23.c xfail; well except there the
warning message was already correct.


Note if we change signed_range in gcc.dg/range.h to:
static inline ptrdiff_t signed_range (ptrdiff_t min, ptrdiff_t max)
{
  ptrdiff_t val = signed_value ();
  if (val < min || max < val)
__builtin_unreachable();
  return val;
}

We get the same warning as we get with this patch. So I am definitely going to
add/change the dg-warning here because that will be the correct fix.

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
Maybe source code can be changed as
 int f(int a, int b)
{
#ifdef __BMI__
return _tzcnt_u32   (a);
#else
return _bit_scan_forward (a);
#endif
}

But looks like clang/MSVC doesn't support _bit_scan_forward, should be a bug
for them since it's in the intrinsics guide.

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #3)
> But there's difference between TZCNT and BSF
> 
>  The key difference between TZCNT and BSF instruction is that TZCNT provides
> operand size as output when source operand is zero while in the case of BSF
> instruction.
> 
> Clang looks correct since it also handle zero case, ICC seems wrong, it just
> generates 
> https://godbolt.org/z/WvrsTrjWr

MSCV seems wrong either.

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #3 from Hongtao.liu  ---
But there's difference between TZCNT and BSF

 The key difference between TZCNT and BSF instruction is that TZCNT provides
operand size as output when source operand is zero while in the case of BSF
instruction.

Clang looks correct since it also handle zero case, ICC seems wrong, it just
generates 
https://godbolt.org/z/WvrsTrjWr

[Bug libstdc++/106611] std::is_nothrow_copy_constructible returns wrong result

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #10 from Jiang An  ---
https://cplusplus.github.io/LWG/issue3967

[Bug tree-optimization/110924] [14 Regression] ICE on valid code at -O{s,2,3} on x86_64-linux-gnu: verify_ssa failed

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

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

--- Comment #2 from Andrew Pinski  ---
Confirmed, though this is undefined code unless a is always 0.

[Bug tree-optimization/110924] [14 Regression] ICE on valid code at -O{s,2,3} on x86_64-linux-gnu: verify_ssa failed

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

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

--- Comment #1 from Andrew Pinski  ---
Here is a testcase without calling main:
```

int a[1], b, c, d, e, f, g;
[[gnu::noinline]]
void h(int i, int j) {
  int *k = 0;
  if (*k)
h(0, 0);
  g = i && d;
}
int jj() {
  if (c)
goto l;
  if (!a)
while (1) {
  f = 1;
  while (f)
h(b && jj(), e);
  while (1)
;
l:;
}
  return 0;
}
```

[Bug tree-optimization/110924] [14 Regression] ICE on valid code at -O{s,2,3} on x86_64-linux-gnu: verify_ssa failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |14.0
Summary|ICE on valid code at|[14 Regression] ICE on
   |-O{s,2,3} on|valid code at -O{s,2,3} on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |verify_ssa failed   |verify_ssa failed
Version|unknown |14.0

[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+

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

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

--- Comment #9 from Andrew Pinski  ---
+FAIL: c-c++-common/Wrestrict.c  -Wc++-compat  (test for excess errors)
Excess errors:
/home/apinski/src/upstream-gcc-git/gcc/gcc/testsuite/c-c++-common/Wrestrict.c:684:3:
warning: 'strcpy' accessing 2 bytes at offsets [0, 1] and 0 overlaps between 1
and 2 bytes at offset [0, 1] [-Wrestrict]
  T (8, "0", a + r, a);   /* { dg-warning "accessing between 1 and 2 bytes at
offsets \\\[0, 1] and 0 overlaps up to 2 bytes at offset \\\[0, 1]" "strcpy" {
xfail *-*-*} } */

Looks like the dg-warning needs to be updated and the xfail removed.
we have:
```
strcpy (a+[0,1], a);
```



/home/apinski/src/upstream-gcc-git/gcc/gcc/testsuite/c-c++-common/Wrestrict.c:863:3:
warning: 'strncpy' accessing 1 byte at offsets 0 and [0, 1] may overlap 1 byte
at offset 0 [-Wrestrict]

  T ("0123", a, a + i, 1);

In this case a and a+[0,1] can overlap for strncpy even for size of 1.

/home/apinski/src/upstream-gcc-git/gcc/gcc/testsuite/c-c++-common/Wrestrict.c:866:3:
warning: 'strncpy' accessing 2 bytes at offsets 0 and [0, 1] overlaps between 1
and 2 bytes at offset [0, 1] [-Wrestrict]
  T ("0123", a, a + i, 2);   /* { dg-warning "accessing 2 bytes at offsets 0
and \\\[0, 1] may overlap 1 byte at offset 1" "strncpy" { xfail *-*-* } } */

Just like the first case.

[Bug c++/110925] Unnecessary dynamic initialization in trivial cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is basically a dup of bug 4131.

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

[Bug tree-optimization/4131] The C++ compiler doesn't place a const class object to ".rodata" section with non trivial constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||janschultke at googlemail dot 
com

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

[Bug c++/110925] New: Unnecessary dynamic initialization in trivial cases

[janschultke at googlemail dot com via Gcc-bugs]

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

Bug ID: 110925
   Summary: Unnecessary dynamic initialization in trivial cases
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

## Code to Reproduce

int z = 0;
int x = z;

## Expected Output (delivered by clang trunk -O3)

x:
.zero   4
z:
.zero   4

## Actual Output (x86_64 GCC 14 -O3) (https://godbolt.org/z/95d9hj3he)

_GLOBAL__sub_I_z:
mov eax, DWORD PTR z[rip]
mov DWORD PTR x[rip], eax
ret
x:
.zero   4
z:
.zero   4


## Explanation

The implementation is allowed to turn this into static initialization. See
https://eel.is/c++draft/basic.start.static#3. However, GCC emits unnecessary
dynamic initialization code.

[Bug c++/107962] GCC allows constexpr copy construction despite uninitialized member

[hstong at ca dot ibm.com via Gcc-bugs]

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

--- Comment #2 from Hubert Tong  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2264 suggests that
the GCC behaviour may be the desired one because copies of
partially-initialized structures are allowed in C but cause undefined behaviour
in C++.

[Bug tree-optimization/110924] New: ICE on valid code at -O{s,2,3} on x86_64-linux-gnu: verify_ssa failed

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

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

Bug ID: 110924
   Summary: ICE on valid code at -O{s,2,3} on x86_64-linux-gnu:
verify_ssa failed
   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.

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

[608] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.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 14.0.0 20230805 (experimental) (GCC)
[609] %
[609] % gcctk -O2 small.c
small.c: In function ‘main’:
small.c:8:5: error: stmt with wrong VUSE
8 | int main() {
  | ^~~~
# VUSE <.MEM_11>
e.3_2 = e;
expected .MEM_12
during GIMPLE pass: sink
small.c:8:5: internal compiler error: verify_ssa failed
0x124c54d verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.cc:1203
0xed05e5 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2095
0xed0a3b execute_todo
../../gcc-trunk/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
[610] %
[610] % cat small.c
int a[1], b, c, d, e, f, g;
void h(int i, int j) {
  int *k = 0;
  if (*k)
h(0, 0);
  g = i && d;
}
int main() {
  if (c)
goto l;
  if (!a)
while (1) {
  f = 1;
  while (f)
h(b && main(), e);
  while (1)
;
l:;
}
  return 0;
}

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:529909f9e92dd3b0ed0383f45a44d2b5f8a58958

commit r14-3012-g529909f9e92dd3b0ed0383f45a44d2b5f8a58958
Author: Roger Sayle 
Date:   Sun Aug 6 23:19:10 2023 +0100

[Committed] Avoid FAIL of gcc.target/i386/pr110792.c

My apologies (again), I managed to mess up the 64-bit version of the
test case for PR 110792.  Unlike the 32-bit version, the 64-bit case
contains exactly the same load instructions, just in a different order
making the correct and incorrect behaviours impossible to distinguish
with a scan-assembler-not.  Somewhere between checking that this test
failed in a clean tree without the patch, and getting the escaping
correct, I'd failed to notice that this also FAILs in the patched tree.
Doh!  Instead of removing the test completely, I've left it as a
compilation test.

The original fix is tested by the 32-bit test case.

Committed to mainline as obvious.  Sorry for the incovenience.

2023-08-06  Roger Sayle  

gcc/testsuite/ChangeLog
PR target/110792
* gcc.target/i386/pr110792.c: Remove dg-final scan-assembler-not.

[Bug middle-end/104296] MIN should simplify to unsigned != 0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||110262

--- Comment #2 from Andrew Pinski  ---
So another testcase:

int g2(int a)
{
  if (a < 0) __builtin_unreachable();
  int t = ((a) < (1) ? (a) : (1));
  return  t;
}


The above should be optimized to `return a != 0`. If we do that, then PR 110262
is optimized.
Now the question becomes which is canonical of how we should represent this.
`MIN_EXPR`
or
`(type)t != 0`
The MIN is "cheaper" for gimple but not decent to optimize with sometimes might
need to change between the two versions ...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110262
[Bug 110262] `t < 0 ? 1 : min(t, 1)` is not simplified down to just `t != 0`

[Bug libstdc++/110917] std::format_to(int*, ...) fails to compile because of _S_make_span

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2023-08-06
   Target Milestone|--- |13.3
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Arthur O'Dwyer from comment #0)
> libc++ and Microsoft are both completely happy with this code. libstdc++ is
> happy with `f` but unhappy with `g`. I suspect that someplace is accepting
> "contiguous iterators of any old T" when it means to limit itself to
> "contiguous iterators of char" specifically.

Indeed, it's fixed by:

   // not introduce any invalid pointer arithmetic or overflows that would not
   // have happened anyway.
   template
+requires same_as, _CharT>
 class _Iter_sink<_CharT, _OutIter> : public _Sink<_CharT>
 {
   using uint64_t = __UINTPTR_TYPE__;

Alternatively, we could replace the contiguous_iterator<_OutIter> constraint
with constructible_from, _OutIter, iter_difference_t<_OutIter>>.

[Bug tree-optimization/110923] [14 Regression] with-build-config=bootstrap-lto-lean ICEs during build during lsplit pass

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|gcc c,c++ ftbfs on ppc64le  |[14 Regression]
   ||with-build-config=bootstrap
   ||-lto-lean ICEs during build
   ||during lsplit pass
   Target Milestone|--- |14.0
 Target||powerpc64le-unknown-linux-g
   ||nu
  Component|target  |tree-optimization
   Keywords||build, ice-on-valid-code

[Bug target/110923] New: gcc c,c++ ftbfs on ppc64le

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

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

Bug ID: 110923
   Summary: gcc c,c++ ftbfs on ppc64le
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

gcc-14 FTBFS on ppc64le (lto) (gcc120.fsffrance.org for reference).

Configured with 

$ ../configure --prefix=/home/gaius/opt --libexecdir=/home/gaius/opt/lib
--enable-host-shared --enable-threads=posix --enable-clocale=gnu
--enable-checking --enable-long-longx --enable-languages=c,c++,fortran,lto
--with-build-config=bootstrap-lto-lean --disable-multilib --enable-bootstrap

/home/gaius/GCC/gcc-read-write/build/./prev-gcc/xg++
-B/home/gaius/GCC/gcc-read-write/build/./prev-gcc/
-B/home/gaius/opt/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++
-B/home/gaius/GCC/gcc-read-write/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/gaius/GCC/gcc-read-write/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/gaius/GCC/gcc-read-write/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home/gaius/GCC/gcc-read-write/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home/gaius/GCC/gcc-read-write/libstdc++-v3/libsupc++
-L/home/gaius/GCC/gcc-read-write/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/gaius/GCC/gcc-read-write/build/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie   -g -O2 -fprofile-use -fprofile-reproducible=parallel-runs
-flto=jobserver -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -no-pie -static-libstdc++
-static-libgcc  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o
c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o
c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o
c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o
c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o
c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o
c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o glibc-c.o
rs6000-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a 
-L/home/gaius/GCC/gcc-read-write/build/./isl/.libs  -lisl
-L/home/gaius/GCC/gcc-read-write/build/./gmp/.libs
-L/home/gaius/GCC/gcc-read-write/build/./mpfr/src/.libs
-L/home/gaius/GCC/gcc-read-write/build/./mpc/src/.libs -lmpc -lmpfr -lgmp
-rdynamic  -L./../zlib -lz -lzstd 
lto-wrapper: warning: jobserver is not available: ‘--jobserver-auth=’ is not
present in ‘MAKEFLAGS’
lto-wrapper: note: see the ‘-flto’ option documentation for more information
../gmp/../../gmp/primesieve.c: In function ‘first_block_primesieve’:
../gmp/../../gmp/primesieve.c:269:25: warning: ‘i’ may be used uninitialized
[-Wmaybe-uninitialized]
  269 | mask = CNST_LIMB(1) << i;
  | ^
../gmp/../../gmp/primesieve.c:248:13: note: ‘i’ was declared here
  248 |   mp_limb_t i;
  | ^
during GIMPLE pass: lsplit
../../gcc/dse.cc: In function ‘record_store’:
../../gcc/dse.cc:1359: internal compiler error: in operator/, at sreal.cc:261
 1359 | record_store (rtx body, bb_info_t bb_info)
  | 
0x10af1f33 sreal::operator/(sreal const&) const
../../gcc/sreal.cc:261
0x10af1f33 sreal::operator/(sreal const&) const
../../gcc/sreal.cc:259
0x10d6b09f split_loop
../../gcc/tree-ssa-loop-split.cc:719
0x10d6bfd3 tree_ssa_split_loops
../../gcc/tree-ssa-loop-split.cc:1769
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[4]: *** [/tmp/ccitBxAD.mk:203: /tmp/ccUerv1d.ltrans67.ltrans.o] Error 1

[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+

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

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

--- Comment #8 from Andrew Pinski  ---
Created attachment 55696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55696=edit
Patch which I am testing

[Bug target/80786] m68k: internal compiler error: in change_address_1

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

Giulio Benetti  changed:

   What|Removed |Added

 CC||giulio.benetti@benettiengin
   ||eering.com

--- Comment #3 from Giulio Benetti  ---
This bug still shows up on Gcc 13.2.0

[Bug target/110727] [14 Regression] gcc.target/aarch64/sve/aarch64-sve.exp has two new failures since commit 061f74c0673

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  ---
Fixed.

[Bug middle-end/110857] aarch64-linux-gnu profiledbootstrap broken

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #7 from Jan Hubicka  ---
Fixed.

[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104296

--- Comment #7 from Andrew Pinski  ---
For the bothone:
`(a > 1) ? 0 : a` could just be simplified to:
`(cast)(a == 1)` For unsigned types.

So:
(simplify
 (cond (gt @0 integer_onep@1) integer_zerop (convert? @0))
 (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
  (convert (eq @0 @1))
 )
)

Turns out the optional convert in the above will catch both cases.

[Bug libstdc++/108760] ranges::iota is not included in

[daniel.kruegler at googlemail dot com via Gcc-bugs]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
(In reply to 康桓瑋 from comment #0)
> It seems wrong that libstdc++ needs to include  for ranges::iota.

I agree, this looks like a defect, both std::iota and std::ranges:iota are
specified to be part of header 

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

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

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

--- Comment #2 from Andrew Pinski  ---
Testcase:
#include "x86intrin.h"

int f(int a, int b)
{
return _tzcnt_u32   (a);
}

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-08-06
 Target|x86_64-*-*,x86-*-*  |x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
(In reply to 罗勇刚(Yonggang Luo) from comment #0)
> This is for alignment with Clang and MSVC.
> 
> Also the _mm_tzcnt_32 and _mm_tzcnt_64 are added for consistence with Clang
> and MSVC

ICC acts in a similar way as clang and MSVC does too.

Confirmed.

[Bug tree-optimization/110922] `(a == b) & (a == c) & (b != c)` is not optimized to false

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

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

--- Comment #1 from Andrew Pinski  ---
I think you need the following 3 patterns, there might be more though:
(simplify
 (bit_and:c
  (bit_and:c
   (eq:c @0 @1)
   (eq:c @0 @2)
  )
  (ne:c @1 @2)
 )
 ( { falsevalue; } )
)
(simplify
 (bit_and:c
  (bit_and:c
   (eq:c @0 @1)
   (ne:c @1 @2)
  )
  (eq:c @0 @2)
 )
 ( { falsevalue; } )
)
(simplify
 (bit_and:c
  (eq:c @0 @1)
  (bit_and:c
   (ne:c @1 @2)
   (eq:c @0 @2)
  )
 )
 ( { falsevalue; } )
)

[Bug tree-optimization/110922] New: `(a == b) & (a == c) & (b != c)` is not optimized to false

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

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

Bug ID: 110922
   Summary: `(a == b) & (a == c) & (b != c)` is not optimized to
false
   Product: gcc
   Version: 14.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: ---

I noticed this while looking at PR 110919:
```
int f(int a, int b)
{
  _Bool t = a == b;
  _Bool t1 = a == 0;
  _Bool t2 = b != 0;
  return t
}
```
is not optimized to false.

[Bug tree-optimization/110919] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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


Note I think what EVRP produces for some thing makes it harder to optimize too.

EVRP does:

Folding statement: _23 = _4 != 1;
Folded into: _23 = (_Bool) _3;


And at the end we get:
  _19 = _6 == iftmp.1_8;
  _3 = iftmp.1_8 ^ 1;
  _21 = (_Bool) _3;
  _23 = _6 != 0;
  _10 = _19 & _23;
  _5 = _10 & _21;

Which is basically:
(a == b) & (a == 0) & (b != 0)

[Bug tree-optimization/110919] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||missed-optimization

[Bug tree-optimization/110918] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2331-g018e7f16408

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/110921] New: Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[luoyonggang at gmail dot com via Gcc-bugs]

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

Bug ID: 110921
   Summary: Relax _tzcnt_u32 support x86, all x86 arch support for
this instrunction
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luoyonggang at gmail dot com
  Target Milestone: ---

Created attachment 55695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55695=edit
A patch for fixes this issue in a brute way, just for demo

The compiling error:

In file included from
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/x86gprintrin.h:41,
 from
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/x86intrin.h:27,
 from C:/CI-Tools/msys64/mingw64/include/intrin.h:69,
 from ../../src/amd/addrlib/src/core/addrcommon.h:33,
 from ../../src/amd/addrlib/src/core/addrobject.h:21,
 from ../../src/amd/addrlib/src/core/addrlib.h:21,
 from ../../src/amd/addrlib/src/core/addrlib2.h:20,
 from ../../src/amd/addrlib/src/gfx10/gfx10addrlib.h:19,
 from ../../src/amd/addrlib/src/gfx10/gfx10addrlib.cpp:16:
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/bmiintrin.h:
In function 'unsigned int Addr::BitScanForward(unsigned int)':
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/bmiintrin.h:116:1:
error: inlining failed in call to 'always_inline' 'unsigned int
_tzcnt_u32(unsigned int)': target specific option mismatch
  116 | _tzcnt_u32 (unsigned int __X)
  | ^~
../../src/amd/addrlib/src/core/addrcommon.h:343:23: note: called from here
  343 | out = ::_tzcnt_u32(mask);
  |   ^~
[113/] Compiling C++ object
src/amd/compiler/libaco.a.p/aco_insert_NOPs.cpp.obj

This code can be compiled with MSVC and Clang.

Reason:

Since the TZCNT instruction behaves as BSF on non-BMI targets, there is code
that expects
to use it as a potentially faster version of BSF.

This is for alignment with Clang and MSVC.

Also the _mm_tzcnt_32 and _mm_tzcnt_64 are added for consistence with Clang and
MSVC

[Bug c++/110920] variably-length array declarations as parameters for C compatibility

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
dup

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

[Bug c++/109021] accept size parameter in extern C

[schwab--- via Gcc-bugs]

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

--- Comment #3 from Andreas Schwab  ---
*** Bug 110920 has been marked as a duplicate of this bug. ***

[Bug c++/110920] New: variably-length array declarations as parameters for C compatibility

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 110920
   Summary: variably-length array declarations as parameters for C
compatibility
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

g++ rejects variably length arrays in parameters because C++ does not have
this. This is a problem when including some C headers.

extern "C" {
extern void foo(int A, double matrix[A]);
extern void bar(int A, int B, double[A][B]);
}

g++ could simply parse and then ignore the parameter as a language extension. 

The first function 'foo' would then be directly usable form C++. For the second
function, there is no corresponding C++ type, but accepting this declaration in
headers would still allow the use of other functions. One could also consider 
the possibility to allow calling this function from C++ code with a double*.

[Bug tree-optimization/110919] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793

[scherrer.sv at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Scherrer Svenja  ---
My apologies, the assembly above is incomplete. The following shows the bug

gcc-87b0749cfb9406790b108208b466cf507ae3c431 -O3 case.c -S -o case.s
- OUTPUT -
.file   "case.c"
.text
.p2align 4
.type   g, @function
g:
.LFB3:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl%esi, %ebx
testw   %di, %di
jne .L2
xorl%eax, %eax
testl   %esi, %esi
sete%al
.L3:
movle(%rip), %edx
cmpl%eax, %edx
sete%cl
testl   %edx, %edx
setne   %dl
testb   %dl, %cl
je  .L1
testl   %eax, %eax
je  .L15
.L1:
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L2:
.cfi_restore_state
callbar151_
testl   %ebx, %ebx
je  .L1
callbar162_
xorl%eax, %eax
jmp .L3
.L15:
popq%rbx
.cfi_def_cfa_offset 8
jmp foo
.cfi_endproc
.LFE3:
.size   g, .-g
.section.text.startup,"ax",@progbits
.p2align 4
.globl  main
.type   main, @function
main:
.LFB4:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$4, %esi
xorl%edi, %edi
callg
xorl%esi, %esi
xorl%edi, %edi
callg
movl$-1, %esi
xorl%edi, %edi
callg
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE4:
.size   main, .-main
.local  e
.comm   e,4,4
.ident  "GCC: (GNU) 14.0.0 20230806 (experimental)"
.section.note.GNU-stack,"",@progbits

-- END OUTPUT -

---
gcc-2b98cc24d6af0432a74f6dad1c722ce21c1f7458 -O3 case.c -S -o case.s
- OUTPUT -
.file   "case.c"
.text
.p2align 4
.type   g, @function
g:
.LFB3:
.cfi_startproc
testw   %di, %di
jne .L11
ret
.L11:
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl%esi, %ebx
callbar151_
testl   %ebx, %ebx
je  .L1
popq%rbx
.cfi_remember_state
.cfi_restore 3
.cfi_def_cfa_offset 8
jmp bar162_
.L1:
.cfi_restore_state
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE3:
.size   g, .-g
.section.text.startup,"ax",@progbits
.p2align 4
.globl  main
.type   main, @function
main:
.LFB4:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$4, %esi
xorl%edi, %edi
callg
xorl%esi, %esi
xorl%edi, %edi
callg
movl$-1, %esi
xorl%edi, %edi
callg
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE4:
.size   main, .-main
.ident  "GCC: (GNU) 13.1.0"
.section.note.GNU-stack,"",@progbits

-- END OUTPUT -

[Bug tree-optimization/110919] New: [14 Regression] Dead Code Elimination Regression at -O3 since r14-1691-gbc5a2c2e793

[scherrer.sv at gmail dot com via Gcc-bugs]

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

Bug ID: 110919
   Summary: [14 Regression] Dead Code Elimination Regression at
-O3 since r14-1691-gbc5a2c2e793
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scherrer.sv at gmail dot com
  Target Milestone: ---

static short a, b;
static int e;
static int *j = 
void bar151_(void);
void foo(void);
void bar162_(void);
static int(d)(int k, int l) { return l == k && l - 1 ? k : 0; }
static void f();
static void g(unsigned short, unsigned);
static void h() {
  g(0, 4);
  f();
  int i = -1;
  g(0, i);
}
static void f(int k) { g(k, 0); }
static void g(unsigned short k, unsigned l) {
  if (k)
bar151_();
  if (l)
if (k)
  bar162_();
  short c = l;
  b = c == 0 || a;
  if (d(*j, b))
foo();
}
int main() { h(); }

gcc-87b0749cfb9 (trunk) -O3 cannot eliminate the call to foo but
gcc-releases/gcc-13.1.0 -O3 can.
---
gcc-87b0749cfb9406790b108208b466cf507ae3c431 -O3 case.c -S -o case.s
- OUTPUT -
main:
.LFB4:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$4, %esi
xorl%edi, %edi
callg
xorl%esi, %esi
xorl%edi, %edi
callg
movl$-1, %esi
xorl%edi, %edi
callg
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -

---
gcc-2b98cc24d6af0432a74f6dad1c722ce21c1f7458 -O3 case.c -S -o case.s
- OUTPUT -
main:
.LFB4:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$4, %esi
xorl%edi, %edi
callg
xorl%esi, %esi
xorl%edi, %edi
callg
movl$-1, %esi
xorl%edi, %edi
callg
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -

---
Bisects to r14-1691-gbc5a2c2e793

[Bug tree-optimization/110918] New: [14 Regression] Dead Code Elimination Regression at -O3 since r14-2331-g018e7f16408

[scherrer.sv at gmail dot com via Gcc-bugs]

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

Bug ID: 110918
   Summary: [14 Regression] Dead Code Elimination Regression at
-O3 since r14-2331-g018e7f16408
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scherrer.sv at gmail dot com
  Target Milestone: ---

static char b = 53;
static unsigned c;
void foo(void);
static int(a)(int d, int e) { return (d ^ e) < 0 ? d : d - e; }
int main() {
  {
int f = 2;
c = b;
b = 0;
for (; c <= 6;) {
  if (f >= 2)
f = 0;
  for (; f >= -9; f = a(f, 8))
if (!(f >= -8 && f <= 0))
  foo();
}
  }
}

gcc-87b0749cfb9 (trunk) -O3 cannot eliminate the call to foo but
gcc-releases/gcc-13.1.0 -O3 can.
---
gcc-87b0749cfb9406790b108208b466cf507ae3c431 -O3 case.c -S -o case.s
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movsbl  b(%rip), %eax
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
xorl%ebx, %ebx
movb$0, b(%rip)
movl%eax, c(%rip)
cmpl$6, %eax
ja  .L11
.p2align 4,,10
.p2align 3
.L2:
leal8(%rbx), %eax
cmpl$8, %eax
ja  .L16
.L3:
cmpl$-8, %ebx
je  .L5
cmpl$-1, %ebx
jl  .L6
movl$-8, %ebx
leal8(%rbx), %eax
cmpl$8, %eax
jbe .L3
.L16:
callfoo
subl$8, %ebx
jmp .L2
.L5:
jmp .L5
.p2align 4,,10
.p2align 3
.L6:
cmpl$6, c(%rip)
ja  .L11
.L8:
jmp .L8
.p2align 4,,10
.p2align 3
.L11:
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -

---
gcc-2b98cc24d6af0432a74f6dad1c722ce21c1f7458 -O3 case.c -S -o case.s
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movsbl  b(%rip), %edx
xorl%eax, %eax
movb$0, b(%rip)
movl%edx, c(%rip)
cmpl$6, %edx
ja  .L8
.p2align 4,,10
.p2align 3
.L2:
testl   %eax, %eax
js  .L3
subl$8, %eax
cmpl$-9, %eax
jge .L2
cmpl$6, c(%rip)
ja  .L8
.L6:
jmp .L6
.L3:
jmp .L3
.p2align 4,,10
.p2align 3
.L8:
xorl%eax, %eax
ret
-- END OUTPUT -

---
Bisects to r14-2331-g018e7f16408

[Bug middle-end/110884] strncmp false positive with -Wstringop-overread on coreutils

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #5 from Paul Eggert  ---
(In reply to Andrew Pinski from comment #4)
> PTRDIFF_MAX is required to be less than SIZE_MAX and is the max size of an
> array because otherwise a-b would be undefined ...

That is true for glibc, but it's not guaranteed by the C standard or by POSIX,
and coreutils tries to be portable to odd but conforming platforms. In theory
size_t can be 32 bits while ptrdiff_t is 64 bits. It's not much trouble to
write MIN (PTRDIFF_MAX, SIZE_MAX) in the few places where it matters.

C and POSIX also allow arrays with more than PTRDIFF_MAX elements. However,
coreutils takes pains to never create such an array, even on the non-glibc
platforms that allow them; this avoids the undefined behavior you mentioned.