[Bug c/68193] _Generic -Woverflow false alarm

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #7 from Martin Uecker  ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626319.html

[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #2 from Martin Uecker  ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626319.html

[Bug c/110703] Incorrect "-Wfloat-conversion" diagnostic with _Generic

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #2 from Martin Uecker  ---
PATCH

https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626319.html

[Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++ modes

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
How about:

-std=c++XY: enabled by default (as per the proposal)
-std=gnu++XY: enabled by -Wall and/or -Wextra (in addition to being enabled by
-pedantic like it already is)

[Bug target/82666] [11/12/13/14 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #14 from Jeffrey A. Law  ---
A better approach might be to to try and create COND_EXPRs for the conditional
move in the gimple code.  The biggest problem I see with that is the
gimple->rtl converters aren't great at creating efficient code on targets
without conditional moves.

Meaning that we could well end up improving x86, but making several other
targets worse.  

I know this because I was recently poking at a similar problem.  We expressed a
conditional move of 0, C as a multiply of a boolean by C in gimple.  It really
should just have been a COND_EXPR, but when we generate that form targets
without good conditional move expanders will end up recreating branchy code :(

[Bug modula2/110779] SysClock can not read the clock

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

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

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

Here is a proposed fix together with three regression tests.

[Bug libstdc++/110854] constructor of std::counting_semaphore is not constexpr

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #2 from Jiang An  ---
The constructor of the internal __platform_semaphore class currently calls
sem_init, which make it incompatible with constexpr...

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

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

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Hao Liu :

https://gcc.gnu.org/g:4d8b5563179f3a7ca268b64f71731a4878635497

commit r14-2973-g4d8b5563179f3a7ca268b64f71731a4878635497
Author: Hao Liu 
Date:   Fri Aug 4 10:32:52 2023 +0800

AArch64: Avoid the ICE on empty reduction definition in info_for_reduction
[PR110625]

Fix the assertion failure on empty reduction define in info_for_reduction.
Even a stmt is live, it may still have empty reduction define.  Check the
reduction definition instead of live info before calling
info_for_reduction.

gcc/ChangeLog:

PR target/110625
* config/aarch64/aarch64.cc (aarch64_force_single_cycle): check
STMT_VINFO_REDUC_DEF to avoid failures in info_for_reduction.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr110625_3.c: New testcase.

[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 #9 from Jiang An  ---
(In reply to Nikolas Klauser from comment #8)
> I agree that the wording is a bit  ambiguous, but GCC should decide on one
> of them instead of returning different results between the type trait
> builtins and the noexcept operator.

The result of noexcept operator is unambiguously specified in the standard and
GCC is already correct. So the suggestion is equivalent to detecting the
exception specifications only.

I've mailed the LWG Chair to submit an LWG issue that requests clarification of
"is known not to throw any exceptions".


FYI, there's at least one library implementor holding the same opinion as
yours.
https://quuxplusone.github.io/blog/2023/04/17/noexcept-false-equals-default/

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
Copying Thomas on this and adding myself.

[Bug target/84251] [11/12/13/14 Regression] Performance regression in gcc 8/9/10/11/12 when comparing floating point numbers

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

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

--- Comment #20 from Andrew Pinski  ---
Hmm: we have:
```
(jump_insn 8 7 9 2 (set (pc)
(if_then_else (ordered (reg:CCFP 17 flags)
(const_int 0 [0]))
(label_ref 12)
(pc))) "/app/example.cpp":5:6 1055 {*jcc}
 (expr_list:REG_DEAD (reg:CCFP 17 flags)
(int_list:REG_BR_PROB 1073741831 (nil)))
 -> 12)
(note 9 8 10 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(call_insn 10 9 12 3 (call (mem:QI (symbol_ref:DI ("abort") [flags 0x41] 
) [0 __builtin_abort S1 A8])
(const_int 0 [0])) "/app/example.cpp":6:5 1062 {*call}
 (expr_list:REG_CALL_DECL (symbol_ref:DI ("abort") [flags 0x41] 
)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)
(nil))
(code_label 12 10 13 4 2 (nil) [1 uses])
(note 13 12 15 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 15 13 16 4 (set (reg:QI 91)
(ordered:QI (reg:CCFP 17 flags)
(const_int 0 [0]))) "/app/example.cpp":7:12 1050 {*setcc_qi}
 (expr_list:REG_DEAD (reg:CCFP 17 flags)
(nil)))
```
We know in insn 16 at this point (ordered:QI (reg:CCFP 17 flags) (const_int 0
[0])) is 1. Isn't there a pass which does that?
Or is it because the differences in the modes (VOIDmode vs QImode) causing that
not to happen?

[Bug target/82666] [11/12/13/14 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)

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

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

--- Comment #13 from Andrew Pinski  ---
I don't know if this could help here but combine does produce:
Trying 37, 34 -> 38:
   37: flags:CCGC=cmp(r82:SI,0x7f)
  REG_DEAD r82:SI
   34: {r92:DI=r87:DI+r89:DI;clobber flags:CC;}
  REG_DEAD r89:DI
  REG_UNUSED flags:CC
   38: r87:DI={(flags:CCGC>0)?r92:DI:r87:DI}
  REG_DEAD r92:DI
  REG_DEAD flags:CCGC
Failed to match this instruction:
(set (reg/v:DI 87 [  ])
(plus:DI (mult:DI (gt:DI (reg:SI 82 [ _4 ])
(const_int 127 [0x7f]))
(reg:DI 89 [ _4 ]))
(reg/v:DI 87 [  ])))

I don't know if we could catch this in the backend and split this into 3
instructions if that would do the right thing ...

[Bug rtl-optimization/82454] Possible future performance regression in x86 for 64-bit constant expansions

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

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

--- Comment #5 from Andrew Pinski  ---
Actually this looks almost exactly the same as PR 82339 .

[Bug rtl-optimization/82454] Possible future performance regression in x86 for 64-bit constant expansions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2017-10-09 00:00:00 |2023-8-3
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82339

--- Comment #4 from Andrew Pinski  ---
Note the -Os regression part was improved via r8-3504-g2891beff1aa8e6 (PR
82339).

[Bug tree-optimization/82446] [11/12/13/14 Regression] Missed equalities in dr_group_sort_cmp

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

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

--- Comment #11 from Andrew Pinski  ---
Is this still true?

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

[nikolasklauser at berlin dot de via Gcc-bugs]

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

--- Comment #8 from Nikolas Klauser  ---
I agree that the wording is a bit  ambiguous, but GCC should decide on one of
them instead of returning different results between the type trait builtins and
the noexcept operator.

[Bug target/110897] RISC-V: Fail to vectorize shift

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

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

--- Comment #2 from JuzheZhong  ---
Yes, (In reply to Andrew Pinski from comment #1)
> Does the riscv backend support uint32_t shifting? How about extending and
> contracting to/from uint16_t to uint32_t?

Yes, RISC-V port support uint32_t shifting.

Try this code (I explictly add conversion ((uint32_t) a[i]) >> b[i]):


#include 

#define TEST2_TYPE(TYPE)\
  __attribute__((noipa))\
  void vshiftr_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)  \
  { \
for (int i = 0; i < n; i++) \
  dst[i] = ((uint32_t) a[i]) >> b[i];  
\
  }

#define TEST_ALL()  \
 TEST2_TYPE(uint16_t)   \

TEST_ALL()

.L4:
vsetvli a5,a3,e8,mf4,ta,ma
vle16.v v3,0(a1)
vle16.v v2,0(a2)
vsetivlizero,4,e32,m1,ta,ma
vzext.vf2   v1,v3
vsetvli zero,zero,e16,mf2,ta,ma
sllia4,a5,1
vnsrl.wvv1,v1,v2
sub a3,a3,a5
vsetvli zero,a5,e16,mf2,ta,ma
vse16.v v1,0(a0)
add a1,a1,a4
add a2,a2,a4
add a0,a0,a4
bne a3,zero,.L4
ret

It vectorize it successfully.
But I think compiler recognize it since LLVM can do the job:
https://godbolt.org/z/ecKjYco5b

LLVM doesn't need the explicit conversion codes still can vectorize it.

[Bug target/110897] RISC-V: Fail to vectorize shift

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

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

--- Comment #1 from Andrew Pinski  ---
Does the riscv backend support uint32_t shifting? How about extending and
contracting to/from uint16_t to uint32_t?

[Bug c/110897] New: RISC-V: Fail to vectorize shift

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

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

Bug ID: 110897
   Summary: RISC-V: Fail to vectorize shift
   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: ---

Since this commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=29370f1387274ad5a35a020db6a5d06c0324e6c1

causes RISCV a bunch of fails related to shift vectorization:
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv32gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsrl\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/shift-rv64gcv.c scan-assembler-times
\\tvsra\\.vv 4
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsra\\.wv 6
FAIL: gcc.target/riscv/rvv/autovec/binop/narrow-1.c scan-assembler-times
\\tvnsrl\\.wv 5


When trying this simple case:
#define TEST1_TYPE(TYPE)\
  __attribute__((noipa))\
  void vshl_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n) \
  { \
for (int i = 0; i < n; i++) \
  dst[i] = a[i] << b[i];\
  }

#define TEST2_TYPE(TYPE)\
  __attribute__((noipa))\
  void vshiftr_##TYPE (TYPE *dst, TYPE *a, TYPE *b, int n)  \
  { \
for (int i = 0; i < n; i++) \
   

[Bug c++/110894] [modules] Program terminates with signal SIGSEGV

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Johel Ernesto Guerrero Peña  ---
Reduced: .

If you comment out the use of `.data()` at the end of `my_string_view.hpp` it
works.
It originally comes from ``'s specialization of `hash`,
`  { return std::_Hash_impl::hash(__str.data(), __str.length()); }`.

[Bug other/110895] [14 regression] ICE compiling gcc.c-torture/compile/pr33133.c after r14-2925-g2bae476b511dc4

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 110874 where I submitted a second version of the patch this morning.

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

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

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

[Bug sanitizer/81981] [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Fixed, Open PR 110896 for the new issue and for the xfail testcase. Note the
issue there is unrelated to -fsanitize=undefined which is why I opened a new
bug report.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 81981 Summary: [8 Regression] -fsanitize=undefined makes a 
-Wmaybe-uninitialized warning disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981

   What|Removed |Added

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

[Bug tree-optimization/110896] [12/13/14 Regression] gcc.dg/ubsan/pr81981.c is xfailed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4

[Bug tree-optimization/110896] New: [12/13/14 Regression] gcc.dg/ubsan/pr81981.c is xfailed

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

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

Bug ID: 110896
   Summary: [12/13/14 Regression] gcc.dg/ubsan/pr81981.c is
xfailed
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic, xfail
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 24639
  Target Milestone: ---

The original issue in PR 81981 is fixed. The problem here is we don't even warn
without -fsanitize=undefined too.
Testcase from that PR:
```
int foo (int i)
{
  int t[1], u[1];
  int n = 0;

  if (i)
{
  t[n] = i;
  u[0] = i;
}

  return t[0] + u[0];
}

```
we don't warn about `u[0]` being unintinialized with just `-O2 -Wall -Wextra`
starting in GCC 12 via r12-4625 (the fix for pr102681). That is the issue is
unrelated to -fsanitize=undefined now.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug other/110895] New: [14 regression] ICE compiling gcc.c-torture/compile/pr33133.c after r14-2925-g2bae476b511dc4

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

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

Bug ID: 110895
   Summary: [14 regression] ICE compiling
gcc.c-torture/compile/pr33133.c after
r14-2925-g2bae476b511dc4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:2bae476b511dc441bf61da8a49cca655575e7dd6, r14-2925-g2bae476b511dc4

make  -k check-gcc RUNTESTFLAGS="compile.exp=gcc.c-torture/compile/pr33133.c"
FAIL: gcc.c-torture/compile/pr33133.c   -O2  (internal compiler error:
Segmentation fault signal terminated program cc1)
FAIL: gcc.c-torture/compile/pr33133.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33133.c   -Os  (internal compiler error:
Segmentation fault signal terminated program cc1)
FAIL: gcc.c-torture/compile/pr33133.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33133.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error: Segmentation fault signal
terminated program cc1)
FAIL: gcc.c-torture/compile/pr33133.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
# of expected passes5
# of unexpected failures6

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ -fdiagnostics-plain-output -O2 -flto
-fno-use-linker-plugin -flto-partition=none -w -c -o pr33133.o
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/compile/pr33133.c
xgcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
compiler exited with status 1
FAIL: gcc.c-torture/compile/pr33133.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error: Segmentation fault signal
terminated program cc1)


Hmmm.  No traceback.

commit 2bae476b511dc441bf61da8a49cca655575e7dd6 (HEAD, refs/bisect/bad)
Author: Andrew Pinski 
Date:   Sat Jul 29 13:00:04 2023 -0700

Move `~X & X` and `~X | X` over to use bitwise_inverted_equal_p


So, running it from gdb I see:

#0  0x10e3dab0 in operand_compare::verify_hash_value (this=, 
arg0=, arg1=, 
flags=, ret=)
at /home/seurer/gcc/git/gcc-test/gcc/fold-const.cc:4068
#1  0x10e35c60 in operand_compare::operand_equal_p (this=0x13d16e38
, arg0=0x75c21170, arg1=0x75c21680, flags=16)
at /home/seurer/gcc/git/gcc-test/gcc/fold-const.cc:3090
#2  0x10e3db40 in operand_compare::verify_hash_value (this=0x13d16e38
, arg0=0x75c21170, arg1=0x75c21680, flags=0,
ret=0x7c00022e)
at /home/seurer/gcc/git/gcc-test/gcc/fold-const.cc:4074
#3  0x10e35c60 in operand_compare::operand_equal_p (this=0x13d16e38
, arg0=0x75c21170, arg1=0x75c21680, flags=0)
at /home/seurer/gcc/git/gcc-test/gcc/fold-const.cc:3090
#4  0x10e3dd34 in operand_equal_p (arg0=0x75c21170,
arg1=0x75c21680, flags=0) at
/home/seurer/gcc/git/gcc-test/gcc/fold-const.cc:4105
#5  0x12ca6368 in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21680, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:284
#6  0x12ca642c in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21a28, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:293
#7  0x12ca642c in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21680, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:293
#8  0x12ca642c in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21a28, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:293
#9  0x12ca642c in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21680, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:293
#10 0x12ca642c in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21a28, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:293
#11 0x12ca642c in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21680, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:293
#12 0x12ca642c in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21a28, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:293
#13 0x12ca642c in gimple_bitwise_inverted_equal_p
(expr1=0x75c21170, expr2=0x75c21680, valueize=0x119a59f8
)
at /home/seurer/gcc/git/gcc-test/gcc/gimple-match-head.cc:293
#14 0x00

[Bug target/80491] [11/12/13/14 Regression] Compiler regression for long-add case.

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

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

--- Comment #25 from Andrew Pinski  ---
Hmm, I thought Jakub's recent work on PR 79173 would have fixed this but no it
didn't.

[Bug tree-optimization/79534] [11/12/13/14 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

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

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

--- Comment #22 from Andrew Pinski  ---
For the original testcase, since GCC 13, ifcombine does not combine the ifs. I
have not looked into why though.

[Bug tree-optimization/102556] equality comparison of a [static N] parameter to null not folded

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #2 from Martin Uecker  ---
PATCH

https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625559.html

[Bug c/110878] -Wstringop-overflow incorrectly warns about arguments to functions with static array parameter declarations

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #5 from Martin Uecker  ---

It is true that there is no UB, but the warning is not directly related to
whether something is UB or not.  It simply assumes that 16 is an upper bound
although the standard does require this.

[Bug target/110892] [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

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

--- Comment #4 from Edwin Lu  ---
Fixed. See Patrick's comment for details

[Bug target/110892] [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #3 from Patrick O'Neill  ---
These failures are fixed as of d61efa3cd3378be38738bfb5139925d1505c1325

Confirmed using rv32 newlib.
https://github.com/patrick-rivos/riscv-gnu-toolchain/issues/139

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

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:93236ad9e8fa9208e754e8806dc369e1a79dbdf7

commit r14-2966-g93236ad9e8fa9208e754e8806dc369e1a79dbdf7
Author: Jan Hubicka 
Date:   Thu Aug 3 22:42:27 2023 +0200

Fix profiledbootstrap

Profiledbootstrap fails with ICE in
update_loop_exit_probability_scale_dom_bbs
called from loop unroling.
The reason is that under relatively rare situations, we may run into case
where
loop has multiple exits and all are considered as likely but then we scale
down
the profile and one of the exits becomes unlikely.

We pass around unadjusted_exit_count to scale exit probability correctly. 
In this
case we may end up using uninitialized value and profile-count type
intentionally
bombs on that.

gcc/ChangeLog:

PR bootstrap/110857
* cfgloopmanip.cc (scale_loop_profile): (Un)initialize
unadjusted_exit_count.

[Bug c++/110894] [modules] Program terminates with signal SIGSEGV

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://cpp2.godbolt.org/z/ |
   |7YrvenrzT   |
 Depends on|103524  |109953
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98761
 Blocks||103524

--- Comment #2 from Andrew Pinski  ---
https://cpp2.godbolt.org/z/7YrvenrzT

Most likely a dup of bug 109953.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109953
[Bug 109953] [c++modules] segmentation fault with import "functional" during
program execution

[Bug c++/110893] [modules] ICE Segmentation fault during GIMPLE pass modref

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://cpp2.godbolt.org/z/ |
   |8q9c3P6vY   |

--- Comment #1 from Andrew Pinski  ---
https://cpp2.godbolt.org/z/8q9c3P6vY

[Bug c++/110894] [modules] Program terminates with signal SIGSEGV

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
If instead I use `std::string_view` in `-O3` (`-O0` works),
it also diagnoses ():

```
In file included from /app/module.cpp:2,
of module hello, imported at /app/main.cpp:2:
In member function 'constexpr const std::basic_string_view<_CharT,
_Traits>::value_type* std::basic_string_view<_CharT, _Traits>::data() const
[with _CharT = char; _Traits = std::char_traits]',
inlined from 'std::basic_ostream<_CharT, _Traits>&
std::operator<<(basic_ostream<_CharT, _Traits>&, basic_string_view<_CharT,
_Traits>) [with _CharT = char; _Traits = char_traits]' at
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/string_view:762:30,
inlined from 'int main()' at /app/main.cpp:3:46:
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/string_view:292:22:
warning: 'this' is used uninitialized [-Wuninitialized]
  292 |   { return this->_M_str; }
  |  ^~
In file included from
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/bits/basic_string.h:47,
 from
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/string:54,
 from
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/bits/locale_classes.h:40,
 from
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/bits/ios_base.h:41,
 from
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/ios:44,
 from
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/ostream:40,
 from
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/iostream:41,
 from /app/main.cpp:1:
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/string_view: In
function 'int main()':
/opt/compiler-explorer/gcc-trunk-20230801/include/c++/14.0.0/string_view:760:5:
note: 'this' was declared here
  760 | operator<<(basic_ostream<_CharT, _Traits>& __os,
  | ^~~~
```

[Bug c++/110894] New: [modules] Program terminates with signal SIGSEGV

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 110894
   Summary: [modules] Program terminates with signal SIGSEGV
   Product: gcc
   Version: 14.0
   URL: https://cpp2.godbolt.org/z/7YrvenrzT
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

Please, see .
It has the source files,
and in the output,
the compile commands along with the errors.

```
$ cat module.cpp 
module;
#include 
export module hello;
export auto hello() -> std::string { return "Hello";  }
$ cat main.cpp 
#include 
import hello;
auto main() -> int { std::cout << hello() << ", modules!\n";  }
```

```
[1/6] /opt/compiler-explorer/clang-16.0.0/bin/clang-scan-deps -format=p1689 --
/opt/compiler-explorer/gcc-snapshot/bin/g++   -O0 -std=c++2b -pedantic-errors
-Wall -Wextra -Wconversion -Werror=unused-result -isystem
/opt/compiler-explorer/gcc-snapshot/bin/../lib/gcc/x86_64-linux-gnu/14.0.0/include
-x c++ /app/module.cpp -c -o CMakeFiles/main.dir/module.cpp.o -MT
CMakeFiles/main.dir/module.cpp.o.ddi -MD -MF
CMakeFiles/main.dir/module.cpp.o.ddi.d > CMakeFiles/main.dir/module.cpp.o.ddi
[2/6] /opt/compiler-explorer/clang-16.0.0/bin/clang-scan-deps -format=p1689 --
/opt/compiler-explorer/gcc-snapshot/bin/g++   -O0 -std=c++2b -pedantic-errors
-Wall -Wextra -Wconversion -Werror=unused-result -isystem
/opt/compiler-explorer/gcc-snapshot/bin/../lib/gcc/x86_64-linux-gnu/14.0.0/include
-x c++ /app/main.cpp -c -o CMakeFiles/main.dir/main.cpp.o -MT
CMakeFiles/main.dir/main.cpp.o.ddi -MD -MF CMakeFiles/main.dir/main.cpp.o.ddi.d
> CMakeFiles/main.dir/main.cpp.o.ddi
[3/6] /opt/compiler-explorer/cmake-v3.26.1/bin/cmake -E cmake_ninja_dyndep
--tdi=CMakeFiles/main.dir/CXXDependInfo.json --lang=CXX --modmapfmt=gcc
--dd=CMakeFiles/main.dir/CXX.dd @CMakeFiles/main.dir/CXX.dd.rsp
[4/6] /opt/compiler-explorer/gcc-snapshot/bin/g++   -O0 -std=c++2b
-pedantic-errors -Wall -Wextra -Wconversion -Werror=unused-result -MD -MT
CMakeFiles/main.dir/module.cpp.o -MF CMakeFiles/main.dir/module.cpp.o.d
-fmodules-ts -Mno-modules
-fmodule-mapper=CMakeFiles/main.dir/module.cpp.o.modmap -x c++ -o
CMakeFiles/main.dir/module.cpp.o -c /app/module.cpp
[5/6] /opt/compiler-explorer/gcc-snapshot/bin/g++   -O0 -std=c++2b
-pedantic-errors -Wall -Wextra -Wconversion -Werror=unused-result -MD -MT
CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d
-fmodules-ts -Mno-modules -fmodule-mapper=CMakeFiles/main.dir/main.cpp.o.modmap
-x c++ -o CMakeFiles/main.dir/main.cpp.o -c /app/main.cpp
[6/6] : && /opt/compiler-explorer/gcc-snapshot/bin/g++ -O0 -std=c++2b
-pedantic-errors -Wall -Wextra -Wconversion -Werror=unused-result -L/app
-Wl,-rpath,/app -Wl,-rpath,/opt/compiler-explorer/gcc-snapshot/lib64
-Wl,-rpath,/opt/compiler-explorer/gcc-snapshot/lib32
CMakeFiles/main.dir/main.cpp.o CMakeFiles/main.dir/module.cpp.o -o main   && :
Program returned: 139
Program terminated with signal: SIGSEGV
```

[Bug c++/110893] New: [modules] ICE Segmentation fault during GIMPLE pass modref

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 110893
   Summary: [modules] ICE Segmentation fault during GIMPLE pass
modref
   Product: gcc
   Version: 14.0
   URL: https://cpp2.godbolt.org/z/8q9c3P6vY
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

Please, see .
It has the source files,
and in the output,
the compile commands along with the errors.

```
$ cat module.cpp 
module;
#include 
export module hello;
export auto hello() -> std::string { return "Hello";  }
$ cat main.cpp 
#include 
import hello;
auto main() -> int { std::cout << hello() << ", modules!\n";  }
```

```
[1/6] /opt/compiler-explorer/clang-16.0.0/bin/clang-scan-deps -format=p1689 --
/opt/compiler-explorer/gcc-snapshot/bin/g++   -O3 -std=c++2b -pedantic-errors
-Wall -Wextra -Wconversion -Werror=unused-result -isystem
/opt/compiler-explorer/gcc-snapshot/bin/../lib/gcc/x86_64-linux-gnu/14.0.0/include
-x c++ /app/module.cpp -c -o CMakeFiles/main.dir/module.cpp.o -MT
CMakeFiles/main.dir/module.cpp.o.ddi -MD -MF
CMakeFiles/main.dir/module.cpp.o.ddi.d > CMakeFiles/main.dir/module.cpp.o.ddi
[2/6] /opt/compiler-explorer/clang-16.0.0/bin/clang-scan-deps -format=p1689 --
/opt/compiler-explorer/gcc-snapshot/bin/g++   -O3 -std=c++2b -pedantic-errors
-Wall -Wextra -Wconversion -Werror=unused-result -isystem
/opt/compiler-explorer/gcc-snapshot/bin/../lib/gcc/x86_64-linux-gnu/14.0.0/include
-x c++ /app/main.cpp -c -o CMakeFiles/main.dir/main.cpp.o -MT
CMakeFiles/main.dir/main.cpp.o.ddi -MD -MF CMakeFiles/main.dir/main.cpp.o.ddi.d
> CMakeFiles/main.dir/main.cpp.o.ddi
[3/6] /opt/compiler-explorer/cmake-v3.26.1/bin/cmake -E cmake_ninja_dyndep
--tdi=CMakeFiles/main.dir/CXXDependInfo.json --lang=CXX --modmapfmt=gcc
--dd=CMakeFiles/main.dir/CXX.dd @CMakeFiles/main.dir/CXX.dd.rsp
[4/6] /opt/compiler-explorer/gcc-snapshot/bin/g++   -O3 -std=c++2b
-pedantic-errors -Wall -Wextra -Wconversion -Werror=unused-result -MD -MT
CMakeFiles/main.dir/module.cpp.o -MF CMakeFiles/main.dir/module.cpp.o.d
-fmodules-ts -Mno-modules
-fmodule-mapper=CMakeFiles/main.dir/module.cpp.o.modmap -x c++ -o
CMakeFiles/main.dir/module.cpp.o -c /app/module.cpp
[5/6] /opt/compiler-explorer/gcc-snapshot/bin/g++   -O3 -std=c++2b
-pedantic-errors -Wall -Wextra -Wconversion -Werror=unused-result -MD -MT
CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d
-fmodules-ts -Mno-modules -fmodule-mapper=CMakeFiles/main.dir/main.cpp.o.modmap
-x c++ -o CMakeFiles/main.dir/main.cpp.o -c /app/main.cpp
FAILED: CMakeFiles/main.dir/main.cpp.o 
/opt/compiler-explorer/gcc-snapshot/bin/g++   -O3 -std=c++2b -pedantic-errors
-Wall -Wextra -Wconversion -Werror=unused-result -MD -MT
CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d
-fmodules-ts -Mno-modules -fmodule-mapper=CMakeFiles/main.dir/main.cpp.o.modmap
-x c++ -o CMakeFiles/main.dir/main.cpp.o -c /app/main.cpp
during GIMPLE pass: modref
main.cpp: In destructor 'constexpr
std::__cxx11::basic_string::_Alloc_hider::~_Alloc_hider()':
main.cpp:3:63: internal compiler error: Segmentation fault
3 | auto main() -> int { std::cout << hello() << ", modules!\n";  }
  |   ^
0x24732fe internal_error(char const*, ...)
???:0
0x1066600 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
???: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.
```

[Bug target/107479] bpf: add __builtin_btf_type_id

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Cupertino Miranda :

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

commit r14-2962-ge0a81559c198153923f0a1a3be7c25df545f3964
Author: Cupertino Miranda 
Date:   Thu Apr 6 15:22:48 2023 +0100

bpf: Implementation of BPF CO-RE builtins

This patch updates the support for the BPF CO-RE builtins
__builtin_preserve_access_index and __builtin_preserve_field_info,
and adds support for the CO-RE builtins __builtin_btf_type_id,
__builtin_preserve_type_info and __builtin_preserve_enum_value.

These CO-RE relocations are now converted to __builtin_core_reloc which
abstracts all of the original builtins in a polymorphic relocation
specific builtin.

The builtin processing is now split in 2 stages, the first (pack) is
executed right after the front-end and the second (process) right before
the asm output.

In expand pass the __builtin_core_reloc is converted to a
unspec:UNSPEC_CORE_RELOC rtx entry.

The data required to process the builtin is now collected in the packing
stage (after front-end), not allowing the compiler to optimize any of
the relevant information required to compose the relocation when
necessary.
At expansion, that information is recovered and CTF/BTF is queried to
construct the information that will be used in the relocation.
At this point the relocation is added to specific section and the
builtin is expanded to the expected default value for the builtin.

In order to process __builtin_preserve_enum_value, it was necessary to
hook the front-end to collect the original enum value reference.
This is needed since the parser folds all the enum values to its
integer_cst representation.

More details can be found within the core-builtins.cc.

Regtested in host x86_64-linux-gnu and target bpf-unknown-none.

gcc/ChangeLog:

PR target/107844
PR target/107479
PR target/107480
PR target/107481
* config.gcc: Added core-builtins.cc and .o files.
* config/bpf/bpf-passes.def: Removed file.
* config/bpf/bpf-protos.h (bpf_add_core_reloc,
bpf_replace_core_move_operands): New prototypes.
* config/bpf/bpf.cc (enum bpf_builtins, is_attr_preserve_access,
maybe_make_core_relo, bpf_core_field_info, bpf_core_compute,
bpf_core_get_index, bpf_core_new_decl, bpf_core_walk,
bpf_is_valid_preserve_field_info_arg, is_attr_preserve_access,
handle_attr_preserve, pass_data_bpf_core_attr, pass_bpf_core_attr):
Removed.
(def_builtin, bpf_expand_builtin, bpf_resolve_overloaded_builtin):
Changed.
* config/bpf/bpf.md (define_expand mov): Changed.
(mov_reloc_core): Added.
* config/bpf/core-builtins.cc (struct cr_builtin, enum
cr_decision struct cr_local, struct cr_final, struct
core_builtin_helpers, enum bpf_plugin_states): Added types.
(builtins_data, core_builtin_helpers, core_builtin_type_defs):
Added variables.
(allocate_builtin_data, get_builtin-data, search_builtin_data,
remove_parser_plugin, compare_same_kind, compare_same_ptr_expr,
compare_same_ptr_type, is_attr_preserve_access, core_field_info,
bpf_core_get_index, compute_field_expr,
pack_field_expr_for_access_index,
pack_field_expr_for_preserve_field,
process_field_expr, pack_enum_value, process_enum_value, pack_type,
process_type, bpf_require_core_support, make_core_relo, read_kind,
kind_access_index, kind_preserve_field_info, kind_enum_value,
kind_type_id, kind_preserve_type_info,
get_core_builtin_fndecl_for_type,
bpf_handle_plugin_finish_type, bpf_init_core_builtins,
construct_builtin_core_reloc, bpf_resolve_overloaded_core_builtin,
bpf_expand_core_builtin, bpf_add_core_reloc,
bpf_replace_core_move_operands): Added functions.
* config/bpf/core-builtins.h (enum bpf_builtins): Added.
(bpf_init_core_builtins, bpf_expand_core_builtin,
bpf_resolve_overloaded_core_builtin): Added functions.
* config/bpf/coreout.cc (struct bpf_core_extra): Added.
(bpf_core_reloc_add, output_asm_btfext_core_reloc): Changed.
* config/bpf/coreout.h (bpf_core_reloc_add) Changed prototype.
* config/bpf/t-bpf: Added core-builtins.o.
* doc/extend.texi: Added documentation for new BPF builtins.

[Bug target/107480] bpf: add __builtin_preserve_type_info

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Cupertino Miranda :

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

commit r14-2962-ge0a81559c198153923f0a1a3be7c25df545f3964
Author: Cupertino Miranda 
Date:   Thu Apr 6 15:22:48 2023 +0100

bpf: Implementation of BPF CO-RE builtins

This patch updates the support for the BPF CO-RE builtins
__builtin_preserve_access_index and __builtin_preserve_field_info,
and adds support for the CO-RE builtins __builtin_btf_type_id,
__builtin_preserve_type_info and __builtin_preserve_enum_value.

These CO-RE relocations are now converted to __builtin_core_reloc which
abstracts all of the original builtins in a polymorphic relocation
specific builtin.

The builtin processing is now split in 2 stages, the first (pack) is
executed right after the front-end and the second (process) right before
the asm output.

In expand pass the __builtin_core_reloc is converted to a
unspec:UNSPEC_CORE_RELOC rtx entry.

The data required to process the builtin is now collected in the packing
stage (after front-end), not allowing the compiler to optimize any of
the relevant information required to compose the relocation when
necessary.
At expansion, that information is recovered and CTF/BTF is queried to
construct the information that will be used in the relocation.
At this point the relocation is added to specific section and the
builtin is expanded to the expected default value for the builtin.

In order to process __builtin_preserve_enum_value, it was necessary to
hook the front-end to collect the original enum value reference.
This is needed since the parser folds all the enum values to its
integer_cst representation.

More details can be found within the core-builtins.cc.

Regtested in host x86_64-linux-gnu and target bpf-unknown-none.

gcc/ChangeLog:

PR target/107844
PR target/107479
PR target/107480
PR target/107481
* config.gcc: Added core-builtins.cc and .o files.
* config/bpf/bpf-passes.def: Removed file.
* config/bpf/bpf-protos.h (bpf_add_core_reloc,
bpf_replace_core_move_operands): New prototypes.
* config/bpf/bpf.cc (enum bpf_builtins, is_attr_preserve_access,
maybe_make_core_relo, bpf_core_field_info, bpf_core_compute,
bpf_core_get_index, bpf_core_new_decl, bpf_core_walk,
bpf_is_valid_preserve_field_info_arg, is_attr_preserve_access,
handle_attr_preserve, pass_data_bpf_core_attr, pass_bpf_core_attr):
Removed.
(def_builtin, bpf_expand_builtin, bpf_resolve_overloaded_builtin):
Changed.
* config/bpf/bpf.md (define_expand mov): Changed.
(mov_reloc_core): Added.
* config/bpf/core-builtins.cc (struct cr_builtin, enum
cr_decision struct cr_local, struct cr_final, struct
core_builtin_helpers, enum bpf_plugin_states): Added types.
(builtins_data, core_builtin_helpers, core_builtin_type_defs):
Added variables.
(allocate_builtin_data, get_builtin-data, search_builtin_data,
remove_parser_plugin, compare_same_kind, compare_same_ptr_expr,
compare_same_ptr_type, is_attr_preserve_access, core_field_info,
bpf_core_get_index, compute_field_expr,
pack_field_expr_for_access_index,
pack_field_expr_for_preserve_field,
process_field_expr, pack_enum_value, process_enum_value, pack_type,
process_type, bpf_require_core_support, make_core_relo, read_kind,
kind_access_index, kind_preserve_field_info, kind_enum_value,
kind_type_id, kind_preserve_type_info,
get_core_builtin_fndecl_for_type,
bpf_handle_plugin_finish_type, bpf_init_core_builtins,
construct_builtin_core_reloc, bpf_resolve_overloaded_core_builtin,
bpf_expand_core_builtin, bpf_add_core_reloc,
bpf_replace_core_move_operands): Added functions.
* config/bpf/core-builtins.h (enum bpf_builtins): Added.
(bpf_init_core_builtins, bpf_expand_core_builtin,
bpf_resolve_overloaded_core_builtin): Added functions.
* config/bpf/coreout.cc (struct bpf_core_extra): Added.
(bpf_core_reloc_add, output_asm_btfext_core_reloc): Changed.
* config/bpf/coreout.h (bpf_core_reloc_add) Changed prototype.
* config/bpf/t-bpf: Added core-builtins.o.
* doc/extend.texi: Added documentation for new BPF builtins.

[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Cupertino Miranda :

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

commit r14-2962-ge0a81559c198153923f0a1a3be7c25df545f3964
Author: Cupertino Miranda 
Date:   Thu Apr 6 15:22:48 2023 +0100

bpf: Implementation of BPF CO-RE builtins

This patch updates the support for the BPF CO-RE builtins
__builtin_preserve_access_index and __builtin_preserve_field_info,
and adds support for the CO-RE builtins __builtin_btf_type_id,
__builtin_preserve_type_info and __builtin_preserve_enum_value.

These CO-RE relocations are now converted to __builtin_core_reloc which
abstracts all of the original builtins in a polymorphic relocation
specific builtin.

The builtin processing is now split in 2 stages, the first (pack) is
executed right after the front-end and the second (process) right before
the asm output.

In expand pass the __builtin_core_reloc is converted to a
unspec:UNSPEC_CORE_RELOC rtx entry.

The data required to process the builtin is now collected in the packing
stage (after front-end), not allowing the compiler to optimize any of
the relevant information required to compose the relocation when
necessary.
At expansion, that information is recovered and CTF/BTF is queried to
construct the information that will be used in the relocation.
At this point the relocation is added to specific section and the
builtin is expanded to the expected default value for the builtin.

In order to process __builtin_preserve_enum_value, it was necessary to
hook the front-end to collect the original enum value reference.
This is needed since the parser folds all the enum values to its
integer_cst representation.

More details can be found within the core-builtins.cc.

Regtested in host x86_64-linux-gnu and target bpf-unknown-none.

gcc/ChangeLog:

PR target/107844
PR target/107479
PR target/107480
PR target/107481
* config.gcc: Added core-builtins.cc and .o files.
* config/bpf/bpf-passes.def: Removed file.
* config/bpf/bpf-protos.h (bpf_add_core_reloc,
bpf_replace_core_move_operands): New prototypes.
* config/bpf/bpf.cc (enum bpf_builtins, is_attr_preserve_access,
maybe_make_core_relo, bpf_core_field_info, bpf_core_compute,
bpf_core_get_index, bpf_core_new_decl, bpf_core_walk,
bpf_is_valid_preserve_field_info_arg, is_attr_preserve_access,
handle_attr_preserve, pass_data_bpf_core_attr, pass_bpf_core_attr):
Removed.
(def_builtin, bpf_expand_builtin, bpf_resolve_overloaded_builtin):
Changed.
* config/bpf/bpf.md (define_expand mov): Changed.
(mov_reloc_core): Added.
* config/bpf/core-builtins.cc (struct cr_builtin, enum
cr_decision struct cr_local, struct cr_final, struct
core_builtin_helpers, enum bpf_plugin_states): Added types.
(builtins_data, core_builtin_helpers, core_builtin_type_defs):
Added variables.
(allocate_builtin_data, get_builtin-data, search_builtin_data,
remove_parser_plugin, compare_same_kind, compare_same_ptr_expr,
compare_same_ptr_type, is_attr_preserve_access, core_field_info,
bpf_core_get_index, compute_field_expr,
pack_field_expr_for_access_index,
pack_field_expr_for_preserve_field,
process_field_expr, pack_enum_value, process_enum_value, pack_type,
process_type, bpf_require_core_support, make_core_relo, read_kind,
kind_access_index, kind_preserve_field_info, kind_enum_value,
kind_type_id, kind_preserve_type_info,
get_core_builtin_fndecl_for_type,
bpf_handle_plugin_finish_type, bpf_init_core_builtins,
construct_builtin_core_reloc, bpf_resolve_overloaded_core_builtin,
bpf_expand_core_builtin, bpf_add_core_reloc,
bpf_replace_core_move_operands): Added functions.
* config/bpf/core-builtins.h (enum bpf_builtins): Added.
(bpf_init_core_builtins, bpf_expand_core_builtin,
bpf_resolve_overloaded_core_builtin): Added functions.
* config/bpf/coreout.cc (struct bpf_core_extra): Added.
(bpf_core_reloc_add, output_asm_btfext_core_reloc): Changed.
* config/bpf/coreout.h (bpf_core_reloc_add) Changed prototype.
* config/bpf/t-bpf: Added core-builtins.o.
* doc/extend.texi: Added documentation for new BPF builtins.

[Bug target/107481] bpf: add __builtin_preserve_enum_value

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Cupertino Miranda :

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

commit r14-2962-ge0a81559c198153923f0a1a3be7c25df545f3964
Author: Cupertino Miranda 
Date:   Thu Apr 6 15:22:48 2023 +0100

bpf: Implementation of BPF CO-RE builtins

This patch updates the support for the BPF CO-RE builtins
__builtin_preserve_access_index and __builtin_preserve_field_info,
and adds support for the CO-RE builtins __builtin_btf_type_id,
__builtin_preserve_type_info and __builtin_preserve_enum_value.

These CO-RE relocations are now converted to __builtin_core_reloc which
abstracts all of the original builtins in a polymorphic relocation
specific builtin.

The builtin processing is now split in 2 stages, the first (pack) is
executed right after the front-end and the second (process) right before
the asm output.

In expand pass the __builtin_core_reloc is converted to a
unspec:UNSPEC_CORE_RELOC rtx entry.

The data required to process the builtin is now collected in the packing
stage (after front-end), not allowing the compiler to optimize any of
the relevant information required to compose the relocation when
necessary.
At expansion, that information is recovered and CTF/BTF is queried to
construct the information that will be used in the relocation.
At this point the relocation is added to specific section and the
builtin is expanded to the expected default value for the builtin.

In order to process __builtin_preserve_enum_value, it was necessary to
hook the front-end to collect the original enum value reference.
This is needed since the parser folds all the enum values to its
integer_cst representation.

More details can be found within the core-builtins.cc.

Regtested in host x86_64-linux-gnu and target bpf-unknown-none.

gcc/ChangeLog:

PR target/107844
PR target/107479
PR target/107480
PR target/107481
* config.gcc: Added core-builtins.cc and .o files.
* config/bpf/bpf-passes.def: Removed file.
* config/bpf/bpf-protos.h (bpf_add_core_reloc,
bpf_replace_core_move_operands): New prototypes.
* config/bpf/bpf.cc (enum bpf_builtins, is_attr_preserve_access,
maybe_make_core_relo, bpf_core_field_info, bpf_core_compute,
bpf_core_get_index, bpf_core_new_decl, bpf_core_walk,
bpf_is_valid_preserve_field_info_arg, is_attr_preserve_access,
handle_attr_preserve, pass_data_bpf_core_attr, pass_bpf_core_attr):
Removed.
(def_builtin, bpf_expand_builtin, bpf_resolve_overloaded_builtin):
Changed.
* config/bpf/bpf.md (define_expand mov): Changed.
(mov_reloc_core): Added.
* config/bpf/core-builtins.cc (struct cr_builtin, enum
cr_decision struct cr_local, struct cr_final, struct
core_builtin_helpers, enum bpf_plugin_states): Added types.
(builtins_data, core_builtin_helpers, core_builtin_type_defs):
Added variables.
(allocate_builtin_data, get_builtin-data, search_builtin_data,
remove_parser_plugin, compare_same_kind, compare_same_ptr_expr,
compare_same_ptr_type, is_attr_preserve_access, core_field_info,
bpf_core_get_index, compute_field_expr,
pack_field_expr_for_access_index,
pack_field_expr_for_preserve_field,
process_field_expr, pack_enum_value, process_enum_value, pack_type,
process_type, bpf_require_core_support, make_core_relo, read_kind,
kind_access_index, kind_preserve_field_info, kind_enum_value,
kind_type_id, kind_preserve_type_info,
get_core_builtin_fndecl_for_type,
bpf_handle_plugin_finish_type, bpf_init_core_builtins,
construct_builtin_core_reloc, bpf_resolve_overloaded_core_builtin,
bpf_expand_core_builtin, bpf_add_core_reloc,
bpf_replace_core_move_operands): Added functions.
* config/bpf/core-builtins.h (enum bpf_builtins): Added.
(bpf_init_core_builtins, bpf_expand_core_builtin,
bpf_resolve_overloaded_core_builtin): Added functions.
* config/bpf/coreout.cc (struct bpf_core_extra): Added.
(bpf_core_reloc_add, output_asm_btfext_core_reloc): Changed.
* config/bpf/coreout.h (bpf_core_reloc_add) Changed prototype.
* config/bpf/t-bpf: Added core-builtins.o.
* doc/extend.texi: Added documentation for new BPF builtins.

[Bug tree-optimization/77568] [11/12/13/14 regression] CSE/PRE/Hoisting blocks common instruction contractions

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

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

--- Comment #20 from Andrew Pinski  ---
(In reply to Wilco from comment #0)
> void f3(char *p, int x)
> {
>   if (x & 1) p[0] = 0;
>   if (x & 2) p[1] = 0;
>   if (x & 4) p[2] = 0;
>   if (x & 8) p[2] = 0;
>   g(0,0);
>   if (x & 1) p[3] = 0;
>   if (x & 2) p[4] = 0;
>   if (x & 4) p[5] = 0;
>   if (x & 8) p[6] = 0;
> }

Maybe for the above the instruction selection gimple pass could duplicate the
`x & 1` (etc). and do an `uncse`. 

For other case, maybe the FMA part of the widening pass just needs to be
smarter when it comes to cross over branches because it does handle this just
fine:
```
float g(float x, float y, float z, float *a)
{
*a=y*z+x;
return y*z-x;
}
```

[Bug c++/110158] Cannot use union with std::string inside in constant expression

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110245

--- Comment #2 from Patrick Palka  ---
It works if we activate the union's member:

constexpr bool f() {
union U{
std::string s = {};
constexpr ~U(){ s.~basic_string(); }
} u{};
return true;
}

static_assert( f() );

So perhaps this is a dup of PR110245?

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

[rjmccall at gmail dot com via Gcc-bugs]

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

--- Comment #12 from John McCall  ---
While it's theoretically possible to split a computed-goto edge, in practice
you want to avoid doing so if you at all can, because the split-edge pattern
defeats the interpreter optimization that's the primary purpose for computed
goto to exist.  Users should take care to ensure that their jumps are from a
"neutral" scope instead.  That's why Clang chose to diagnose computed gotos
that potentially leave destructor/cleanup scopes instead of just making it
work, and I expect we would continue doing that even if GCC started doing
edge-splitting.

`asm goto` is different, in my opinion, and that edge could productively be
split.  Clang isn't doing that right now only because diagnosing was the
quickest path to correctness (as opposed to skipping the cleanup); I think
we're looking into splitting as the more long-term solution.

[Bug target/110892] [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #2 from Patrick O'Neill  ---
Seems like a fix was pushed:
https://inbox.sourceware.org/gcc-patches/89dfe3c2-ef96-3000-de87-74ff83354...@gmail.com/T/#m09608208a2dcc2bbf88a4f3419b062b4b4b349c5

We'll test it and update the issue once it's confirmed to be fixed.

[Bug target/110892] [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||missed-optimization,
   ||testsuite-fail

--- Comment #1 from Andrew Pinski  ---
Most seem like the cost model missed the vector use case of IF_THEN_ELSE ?

[Bug target/110892] New: [14 Regression] Risc-V rvv testsuite failures caused by conditional move costing

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 110892
   Summary: [14 Regression] Risc-V rvv testsuite failures caused
by conditional move costing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Created attachment 55682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55682&action=edit
testsuite failures

Seeing 129 new failures on 36 rvv test cases.

Bisected using https://github.com/patrick-rivos/riscv-gnu-toolchain/issues/127

Confirmed to work:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cf58b896a26390c98ae5382377fcdf44e8ae209f
Confirmed to fail - rv32 newlib:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e15d0b6680d10d7666195e9db65581364ad5e5df
Confirmed to fail - other linux/newlib risc-v targets:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2d73f2eb80caf328bc4dd1324d475e7bf6b56837

Seems to be caused by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e15d0b6680d10d7666195e9db65581364ad5e5df
"[PATCH 3/5] [RISC-V] RISC-V Conditional Move costing [was:Generate Zicond
instruction for select pattern with condition eq or neq to 0]"

Most(all?) failures appear to be regex match failures.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Tomas Kalibera  ---
(In reply to Tomas Kalibera from comment #16)
> (In reply to Julian Waters from comment #15)
> > It seems like the patch also doesn't fix the strftime case too, strangely
> > enough. gcc with that patch applied still causes a compilation failure in
> > the Windows JDK when encountering strftime with the %T specifier
> 
>
> I don't easily see why the patch doesn't help with %T in strftime. In
> MinGW-W64 10, strftime doesn't seem to have a format attribute at all, so
> the patch couldn't help. But in MinGW-W64 11, the gnu_strftime format
> attribute is present.

The older version of the patch I use with gcc 12 doesn't seem to be helping
with %T, but the newer one (patch_master.diff) helps with %T on the current gcc
master (gcc 14) and the current gcc 13 branch (gcc 13.2). Tested with MinGW-W64
11.0.1.

[Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed.
The first major IR difference between GCC 13 and trunk happens in DOM2 where 13
would thread some jumps:
_10  : [irange] int [0, 5] NONZERO 0x5
  Threaded jump 6 --> 7 to 10
  Threaded jump 5 --> 7 to 10

While the trunk does not.

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

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

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

--- Comment #11 from Michael Matz  ---
(In reply to Michael Matz from comment #9)
> Just for completeness: I agree with Andrew that the initial code example in
> comment #0 doesn't show any problem.  The edge from asmgoto to l0 doesn't
> cross
> the scope of the variable, hence no cleanups should be run.  The cleanup
> call that is there is from the edge that leaves the function scope before
> return, and it's placed correctly.

I was reminded that this is incorrect.  Though it isn't documented that way
(AFAICS) the cleanup attribute itself create a scope, as we're using the
try/finally middle-end mechanisms to implement this attribute.  We can't change
that behaviour anymore of course, so that's how it has to be: jumping in front
of the decl of 'x' _is_ supposed to run the cleanup.

The initial example essentially boils down to:

void test4(void) {
l0:;
try { /* implicit scope per instantiation of __cleanup__ variable */
int x __attribute__((cleanup(test4cleanup)));
asm goto("# %l0"l0); /* <-- leaves scope created by x */
} finally {
test4cleanup();
}
}

[Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/110891] New: [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175

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

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

Bug ID: 110891
   Summary: [14 Regression] Dead Code Elimination Regression since
r14-2674-gd0de3bf9175
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/njdE3xof4

Given the following code:

void foo(void);
static int a, c = 7, d, o, q;
static int *b = &a, *f, *j = &d, *n = &c, *ae;
static short e, m;
static short *i = &e;
static char r;
void __assert_fail(char *, char *, int, char *) __attribute__((__noreturn__));
static const short g();
static void h();
static int *k(int) {
(*i)++;
*j ^= *b;
return &a;
}
static void l(unsigned p) {
int *aa = &o;
h();
o = 5 ^ g() && p;
if (f == &d || f == &c || f == &a)
;
else {
foo();
__assert_fail("", "", 3, __PRETTY_FUNCTION__);
}
*aa ^= *n;
if (*aa)
if (!(((p) >= 0) && ((p) <= 0))) {
__builtin_unreachable();
}
k(p);
}
static const short g() { return q; }
static void h() {
unsigned ag = c;
d = ag > r ? ag : 0;
ae = k(c);
f = ae;
if (ae == &d || ae == &c || ae == &a)
;
else
__assert_fail("", "", 4, __PRETTY_FUNCTION__);
}
int main() {
l(a);
m || (*b |= 64);
*b &= 5;
}

gcc-trunk -O2 does not eliminate the call to foo:

main:
subq$8, %rsp
movlc(%rip), %eax
movl%eax, d(%rip)
callk.isra.0
cmpq$c, %rax
movq%rax, f(%rip)
sete%cl
cmpq$a, %rax
sete%dil
cmpq$d, %rax
sete%dl
orb %cl, %dl
jne .L4
testb   %dil, %dil
je  .L15
.L4:
cmpq$d, %rax
je  .L6
testb   %cl, %cl
jne .L6
testb   %dil, %dil
je  .L16
.L6:
callk.isra.0
andl$5, a(%rip)
xorl%eax, %eax
addq$8, %rsp
ret
.L16:
callfoo
movl$.LC0, %esi
movl$__PRETTY_FUNCTION__.1, %ecx
movl$3, %edx
movq%rsi, %rdi
call__assert_fail
.L15:
movl$.LC0, %esi
movl$__PRETTY_FUNCTION__.0, %ecx
movl$4, %edx
movq%rsi, %rdi
call__assert_fail

gcc-13.2.0 -O2 eliminates the call to foo:

main:
subq$8, %rsp
movlc(%rip), %eax
movl%eax, d(%rip)
callk.isra.0
cmpq$c, %rax
movq%rax, f(%rip)
sete%dl
cmpq$d, %rax
sete%cl
orb %cl, %dl
jne .L4
cmpq$a, %rax
jne .L6
.L4:
callk.isra.0
andl$5, a(%rip)
xorl%eax, %eax
addq$8, %rsp
ret
.L6:
movl$.LC0, %esi
movl$__PRETTY_FUNCTION__.0, %ecx
movl$4, %edx
movq%rsi, %rdi
call__assert_fail

Bisects to r14-2674-gd0de3bf9175

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

[ndesaulniers at google dot com via Gcc-bugs]

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

--- Comment #10 from Nick Desaulniers  ---
(In reply to Michael Matz from comment #9)
> That has to do with how we need to (possibly)
> split
> critical edges, which changes label identity, which in turn might actually
> be the thing that's required by the asmgoto.

(Addressing just this point for now.)

I don't think that's a problem for users of asm goto; GCC (and Clang) will
already split critical edges when using asm goto with outputs (thus creating
the case you describe where the label that the asm will jump to has been
synthesized and may differ from the final actual destination).

For example:

```c
void bar (void);

int foo (int y) {
int x;

if (y)
goto end;

asm goto ("# %1 %2":"=r"(x):"i"(&&end)::end);
bar();
return 0;
end:
return x;
}
```

in the above, %1 may not equal %2.

I documented this behavior in clang
https://github.com/llvm/llvm-project/commit/329ef60f3e21fd6845e8e8b0da405cae7eb27267#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97
which will be in the clang-17 release notes once clang-17 ships (currently in
-rc).

I also don't see that being a problem for the Linux kernel at the moment,
though they may need to consider that behavior.

[Bug analyzer/110882] [13 Regression] ICE with -fanalyzer on zero-sized array

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #6 from David Malcolm  ---
*** Bug 108171 has been marked as a duplicate of this bug. ***

[Bug analyzer/108171] [13/14 Regression] ICE in binding_key::make, at analyzer/store.cc:132 since r13-4529-gdfe2ef7f2b6cac70

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

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #7 from David Malcolm  ---
Thanks for filing this; marking it as a duplicate.

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

[Bug analyzer/110882] [13 Regression] ICE with -fanalyzer on zero-sized array

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

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

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

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

commit r14-2957-gf80efa49b7a1639b0d6e9bcea8cf38850d037a02
Author: David Malcolm 
Date:   Thu Aug 3 10:47:22 2023 -0400

testsuite, analyzer: add test case [PR108171]

The ICE in PR analyzer/108171 appears to be a dup of the recently fixed
PR analyzer/110882 and is likewise fixed by it; adding this test case.

gcc/testsuite/ChangeLog:
PR analyzer/108171
* gcc.dg/analyzer/pr108171.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/108171] [13/14 Regression] ICE in binding_key::make, at analyzer/store.cc:132 since r13-4529-gdfe2ef7f2b6cac70

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r14-2957-gf80efa49b7a1639b0d6e9bcea8cf38850d037a02
Author: David Malcolm 
Date:   Thu Aug 3 10:47:22 2023 -0400

testsuite, analyzer: add test case [PR108171]

The ICE in PR analyzer/108171 appears to be a dup of the recently fixed
PR analyzer/110882 and is likewise fixed by it; adding this test case.

gcc/testsuite/ChangeLog:
PR analyzer/108171
* gcc.dg/analyzer/pr108171.c: New test.

Signed-off-by: David Malcolm 

[Bug middle-end/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

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

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #9 from Michael Matz  ---
Just for completeness: I agree with Andrew that the initial code example in
comment #0 doesn't show any problem.  The edge from asmgoto to l0 doesn't cross
the scope of the variable, hence no cleanups should be run.  The cleanup
call that is there is from the edge that leaves the function scope before
return, and it's placed correctly.

But the example from comment #8 indeed shows a problem with asm-goto.  But it
may be impossible to fix.  That has to do with how we need to (possibly) split
critical edges, which changes label identity, which in turn might actually
be the thing that's required by the asmgoto.  Like in such situation:

--
extern int printf (const char *, ...);
extern void doit(void *p);

void foo (int cond)
{
  {
int x __attribute__((cleanup(doit)));
if (cond)
  asm goto("# A %l0"out);
else
  asm goto("# B %l0"out);
  }
  printf("...");
  out:
}
--

The calls to doit need to be emitted on the two edges asm1->out and asm2->out,
but must _not_ be emitted on the fallthrough printf->out (of course, because
the cleanup was already done on the edge x-scope->printf).  The only
way to do that is by splitting those edges which introduces new labels:

{
  {
int x;
if (cond)
  asm goto("# A %l0"out1);
else
  asm goto("# B %l0"out2);
doit();
  }
  printf("...");
 out:
  return;
out1: doit(); goto out;
out2: doit(); goto out;
}

(In this easy example we could save ourself by realizing that the out1 and out2
code sequences are the same, and hence could get away with just emitting
one new label instead of two.  In general that's not possible.)

That's the CFG manipulation that needs happening.  The question is what
it does to the asmgoto: both now receive different labels, whereas before
they received the same.  If whatever the asm does relies on the identity of
these label then this will break things.

Now, asm gotos were specifically introduced to be able to jump to stuff,
not to capture the identity of labels/code-addresses (as is done for instance
in the linux kernel alternative mechanism), so it may be fine to do the edge
splitting and associated renaming of labels.  But that needs to be a conscious
decision.

[Bug analyzer/108171] [13/14 Regression] ICE in binding_key::make, at analyzer/store.cc:132 since r13-4529-gdfe2ef7f2b6cac70

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from David Malcolm  ---
Possibly a dupe of PR analyzer/110882

[Bug c++/104278] ICE with class non-type template parameter with a value depdenent constexpr call

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 13

[Bug c++/102553] ICE (seg fault) in strip_array_types with NTTP and template alias

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #11 from Patrick Palka  ---
Fixed for GCC 13

[Bug c++/103346] ICE on template specialization via alias template with a non-type parameter pack, and fold expression on lambda calls

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 13

[Bug analyzer/110882] [13 Regression] ICE with -fanalyzer on zero-sized array

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

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

David Malcolm  changed:

   What|Removed |Added

Summary|[13/14 Regression] ICE with |[13 Regression] ICE with
   |-fanalyzer on zero-sized|-fanalyzer on zero-sized
   |array   |array

--- Comment #4 from David Malcolm  ---
Should be fixed on trunk for gcc 14 by the above patch.

Keeping open to track backporting this to gcc 13.

[Bug analyzer/110882] [13/14 Regression] ICE with -fanalyzer on zero-sized array

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r14-2955-gc62f93d1e0383def445d4ef2b812468cb7cdaf05
Author: David Malcolm 
Date:   Thu Aug 3 09:47:44 2023 -0400

analyzer: fix ICE on zero-sized arrays [PR110882]

gcc/analyzer/ChangeLog:
PR analyzer/110882
* region.cc (int_size_in_bits): Fail on zero-sized types.

gcc/testsuite/ChangeLog:
PR analyzer/110882
* gcc.dg/analyzer/pr110882.c: New test.

Signed-off-by: David Malcolm 

[Bug tree-optimization/110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0

--- Comment #9 from Richard Biener  ---
Fixed on trunk.  I think the issue is present on the branches as well in that
we generate

  vect_patt_48.21_145 = VIEW_CONVERT_EXPR(vect_patt_49.20_143);
  vect_patt_48.21_146 = VIEW_CONVERT_EXPR(vect_patt_49.20_144);
  vect_patt_46.22_147 = vect_patt_48.21_145 >> 31;
  vect_patt_46.22_148 = vect_patt_48.21_146 >> 31;

and

psraw   $31, %xmm3
psraw   $31, %xmm2

so we have out-of-bound arithmetic vector shifts here which might or might
not cause issues on other targets than x86.  psraw documents
"If the value specified by the count operand is greater than 15 (for words)
[...], each destination data element is fille with the initial value of
the sign bit of the element." which is what we intended to compute.

[Bug tree-optimization/110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:29370f1387274ad5a35a020db6a5d06c0324e6c1

commit r14-2952-g29370f1387274ad5a35a020db6a5d06c0324e6c1
Author: Richard Biener 
Date:   Mon Jul 31 14:44:52 2023 +0200

tree-optimization/110838 - vectorization of widened shifts

The following makes sure to limit the shift operand when vectorizing
(short)((int)x >> 31) via (short)x >> 31 as the out of bounds shift
operand otherwise invokes undefined behavior.  When we determine
whether we can demote the operand we know we at most shift in the
sign bit so we can adjust the shift amount.

Note this has the possibility of un-CSEing common shift operands
as there's no good way to share pattern stmts between patterns.
We'd have to separately pattern recognize the definition.

PR tree-optimization/110838
* tree-vect-patterns.cc (vect_recog_over_widening_pattern):
Adjust the shift operand of RSHIFT_EXPRs.

* gcc.dg/torture/pr110838.c: New testcase.

[Bug tree-optimization/110702] [12/13 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] Wrong |[12/13 Regression] Wrong
   |code at -O1 on  |code at -O1 on
   |x86_64-linux-gnu|x86_64-linux-gnu
   |(regression since GCC-12.2) |(regression since GCC-12.2)
   Priority|P3  |P2
  Known to work||14.0

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:13dfb01e5c30c3bd09333ac79d6ff96a617fea67

commit r14-2951-g13dfb01e5c30c3bd09333ac79d6ff96a617fea67
Author: Richard Biener 
Date:   Thu Aug 3 13:11:12 2023 +0200

tree-optimization/110702 - avoid zero-based memory references in IVOPTs

Sometimes IVOPTs chooses a weird induction variable which downstream
leads to issues.  Most of the times we can fend those off during costing
by rejecting the candidate but it looks like the address description
costing synthesizes is different from what we end up generating so
the following fixes things up at code generation time.  Specifically
we avoid the create_mem_ref_raw fallback which uses a literal zero
address base with the actual base in index2.  For the case in question
we have the address

  type = unsigned long
  offset = 0
  elements = {
[0] = &e * -3,
[1] = (sizetype) a.9_30 * 232,
[2] = ivtmp.28_44 * 4
  }

from which we code generate the problematical

  _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4];

which references the object at address zero.  The patch below
recognizes the fallback after the fact and transforms the
TARGET_MEM_REF memory reference into a LEA for which this form
isn't problematic:

  _24 = &MEM[(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4];
  _3 = *_24;

hereby avoiding the correctness issue.  We'd later conclude the
program terminates at the null pointer dereference and make the
function pure, miscompling the main function of the testcase.

PR tree-optimization/110702
* tree-ssa-loop-ivopts.cc (rewrite_use_address): When
we created a NULL pointer based access rewrite that to
a LEA.

* gcc.dg/torture/pr110702.c: New testcase.

[Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
Version|unknown |13.2.0

--- Comment #4 from Richard Biener  ---
There's probably a duplicate about this.  I'll note that both -gsplit-dwarf and
more specifically -fdebug-types-section are unmaintained.  As a workaround
you can use -gdwarf-3 it seems.

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

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||97048

--- Comment #2 from Richard Biener  ---
Note you are basically trying to use strcmp (a, b), so why not do that?

 _Bool
  equal_buffers (char *a, char *b)
  {
#ifdef FIXED_SIZE_BUFFERS
return strncmp (a, b, SIZE) == 0;
#else
return strcmp (a, b) == 0;
#endif
  }

?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
[Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings

[Bug libstdc++/110879] [14 Regression] Unnecessary reread from memory in a loop with std::vector

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|Unnecessary reread from |[14 Regression] Unnecessary
   |memory in a loop|reread from memory in a
   ||loop with std::vector
  Component|c++ |libstdc++

[Bug tree-optimization/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

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

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

--- Comment #5 from Richard Biener  ---
The issue for this seems to be that create_mem_ref gets

  type = unsigned long
  offset = 0
  elements = {
[0] = &e *
0xfffd,
 
[1] = (sizetype) a.9_30 * 232, 
[2] = ivtmp.28_44 * 4
  }

via get_computation_aff and addr_to_parts fills out no suitable symbol/base

$113 = {symbol = , base = , 
  index = , step = , 
  offset = }

so we hit

  else /* !POINTER_TYPE_P */
{
  base = build_int_cst (build_pointer_type (type), 0);
  index2 = addr->base;

in create_mem_ref_raw.

But get_address_cost sees the address split as aff_inv

  type = unsigned long
  offset = 0
  elements = {
[0] = &e *
0xfffd,
 
[1] = (sizetype) a.9_30 * 232
  }

and aff_var

  type = unsigned long
  offset = 0
  elements = {
[0] = ivtmp.28 * 4
  }

and eventually ends up with parts

$108 = {symbol = , base = , 
  index = , step = , 
  offset = }

so the address we cost is different from the address we eventually generate
(the address we cost doesn't contain all parts - we ignore aff_var).

[Bug libstdc++/110860] std::format("{:f}",2e304) invokes undefined behaviour

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

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

--- Comment #4 from Jonathan Wakely  ---
__builtin_log10 isn't generic either. I was hoping to avoid including all of
 here, which is why I used the built-ins.

[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

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

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

--- Comment #16 from YunQiang Su  ---
(In reply to Roger Sayle from comment #15)
> Is MIPS64 actually a TRULY_NOOP_TRUNCATION_TARGET?  If SImode is implicitly
> assumed to be (sign?) extended, then an arbitrary DImode value/register
> can't be used as an SImode value without appropriately setting/clearing the
> upper bits.
> i.e. thus this integer truncation isn't a no-op.
> 

in gcc/config/mips/mips.cc, there are lines:

static bool
mips_truly_noop_truncation (poly_uint64 outprec, poly_uint64 inprec)
{
  return !TARGET_64BIT || inprec <= 32 || outprec > 32;
}


So for mips_truly_noop_truncation(64, 32), it is true, aka we can convert
32bit value to 64bit value without any insn.

This setting is based on that most (if not all) word (32bit) operation insns
are all sign-extend.

For example, when we run these instructions on a MIPS64 CPU
  li $a1, 0x7fff
  add $a3, $a1, $a1
The result of $a3 will be:
  0x fffe

And for theses instructions:
  li $a1, 0x7fff
  dadd $a3, $a1, $a1  # note, add -> dadd
Then the content of $a3 will be:
 0x fffe


And MIPS has the single instruction for: branch less than zero, for both
MIPS32, MIPS64.

Let me explain example 1:
if the code is running on a 32bit CPU, the result of $a3 will be
0xfffe, which is -2.
if the code is running on a 64bit CPU, since the result of $a3 will be
sign-extend to 0x fffe,
   it is still -2.

That's how MIPS make 32bit binaries run smoothly on a 64bit CPU 
without any mode switch.

> I suspect that the underlying problem is that the backend is relying on
> implicit invariants, not explicitly represented in the RTL, and then
> surprised when valid RTL transformations don't preserve those
> invariants/assumptions.
> 
> I wonder why the zero_extract followed by sign_extend example mentioned in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626137.html isn't
> already being considered as a try_combine candidate, allowing the backend to
> simply recognize or split it.  I'll investigate.

Thanks.

[Bug tree-optimization/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|NEW |ASSIGNED
 CC||hubicka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
  Component|middle-end  |tree-optimization

--- Comment #4 from Richard Biener  ---
I think the bisected rev just exposes an existing issue.  Namely IVOPTs
generates

  _1 = MEM[(long int *)_52];
  _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4];
  _4 = (int) _3;
  _2 = (int) _1;
  _5 = _2 | _4;

with -fno-ivopts it works fine and we sink

  _1 = e[0][0][b.7_29];
  _3 = e[a.9_30][b.7_29][a.9_30];

the issue is without IVOPTs the late pure-const pass correctly does nothing
but with IVOPTs and the above MEMs we get it to produce pure because:

  scanning: _1 = MEM[(long int *)_52];
Indirect ref read is not const
  NULL memory access; terminating BB

which is because infer_nonnull_range_by_dereference eventually does

static bool
check_loadstore (gimple *, tree op, tree, void *data)
{
  if (TREE_CODE (op) == MEM_REF || TREE_CODE (op) == TARGET_MEM_REF)
{   
  /* Some address spaces may legitimately dereference zero.  */
  addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (op));
  if (targetm.addr_space.zero_address_valid (as))
return false;

  return operand_equal_p (TREE_OPERAND (op, 0), (tree)data, 0);

[Bug c++/110890] std::is_array and std::extent incorrectly choose a partial specialization when the size of an array exceeds INT32_MAX

[y1079700998 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Kaiyuan Yang  ---
(In reply to Andrew Pinski from comment #2)
> Dup of bug 88829.
> 
> *** This bug has been marked as a duplicate of bug 88829 ***

Ah, thanks for the quick reply! Also, my apologies for the trouble.(I only
searched with "is_array" and "extent".)

[Bug c++/110890] std::is_array and std::extent incorrectly choose a partial specialization when the size of an array exceeds INT32_MAX

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 88829.

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

[Bug c++/88829] Failure to deduce size of array of 2^31 chars

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||y1079700998 at gmail dot com

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

[Bug c++/110890] std::is_array and std::extent incorrectly choose a partial specialization when the size of an array exceeds INT32_MAX

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

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

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
#include 
using T1 = char[1ul + (unsigned long)INT32_MAX];


template 
  inline constexpr bool is_array_v = false;
template 
  inline constexpr bool is_array_v<_Tp[]> = true;
template 
  inline constexpr bool is_array_v<_Tp[_Num]> = true;

static_assert(is_array_v);
```

The question will T1 be a valid array definition?
For 32bit it is not. For 64bit it might be ...

[Bug ipa/110753] [14 Regression] ICE in meet_with_1, at ipa-cp.cc:1057

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
The intersection of two mask/value pairs is being pessimized incorrectly.

MASK 0x0 VALUE 0x1 (value is known to be 1)
MASK 0xfffc VALUE 0x0 (low 2 bits are known to be 1, everything
else is unknown).

irange_bitmask::intersect() is intersecting these to:

MASK 0x VALUE 0x0

(i.e. totally unknown value).

This is causing union_bitmask() to return a change when none actually occurred,
because we end up losing the bitmask.

Mine.

[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #15 from Roger Sayle  ---
Is MIPS64 actually a TRULY_NOOP_TRUNCATION_TARGET?  If SImode is implicitly
assumed to be (sign?) extended, then an arbitrary DImode value/register can't
be used as an SImode value without appropriately setting/clearing the upper
bits.
i.e. thus this integer truncation isn't a no-op.

I suspect that the underlying problem is that the backend is relying on
implicit invariants, not explicitly represented in the RTL, and then surprised
when valid RTL transformations don't preserve those invariants/assumptions.

I wonder why the zero_extract followed by sign_extend example mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626137.html isn't already
being considered as a try_combine candidate, allowing the backend to simply
recognize or split it.  I'll investigate.

[Bug c++/110890] New: std::is_array and std::extent incorrectly choose a partial specialization when the size of an array exceeds INT32_MAX

[y1079700998 at gmail dot com via Gcc-bugs]

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

Bug ID: 110890
   Summary: std::is_array and std::extent incorrectly choose a
partial specialization when the size of an array
exceeds INT32_MAX
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: y1079700998 at gmail dot com
  Target Milestone: ---

#include 
#include 
#include 

using T1 = char[1ul + INT32_MAX];

int main() {
std::cout << std::is_array_v << '\n';
std::cout << std::extent_v << '\n';
}

When compiled with `g++ array_test.cpp -g -std=c++17 -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
-fsanitize=undefined`, this script generates a result of "0 0". This behavior
was also observed with GCC 13.2 on godbolt.

When using clang++(tested with 10.0.0), however, the script generates the
expected result of "1 2147483648".

I discovered this behavior while performing some edge testing. It's probably
very rare to have an array of such a size in a real application.

[Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument

[linh.lrd at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Ling Nguyen  ---
Thanks for quick responses.

A further look into the issue:
I believe there is bug in this piece of code:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/dwarf2out.cc;h=fa0fe4c41bbd5b13aa5fe6cad6e7d39bbd82174a;hb=HEAD#l8501

It should probably be:
if (is_template_instantiation (c))
  {
/* Instantiated templates do not need to be cloned into the
   type unit.  Just move the DIE and its children back to
   the skeleton tree (in the main CU).  */
remove_child_with_prev (c, prev);
generate_skeleton_ancestor_tree (parent);
add_child_die (parent->new_die, c);
c = prev;
  }

Don't mean to teach a fish to swim here, because I'm no expert. Just want to
help to reduce the search space.
By the way, any chance for a fix (whenever it is) to land on gcc 10.2, as we
are fixed to it?

[Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|"undefined reference" when  |[10/11/12/13/14 Regression]
   |using both  |"undefined reference" when
   |"-fdebug-types-section" and |using both
   |"-gsplit-dwarf" |"-fdebug-types-section" and
   ||"-gsplit-dwarf" and inline
   ||function as a template
   ||argument
   Target Milestone|--- |11.5
   Last reconfirmed||2023-08-03

--- Comment #2 from Andrew Pinski  ---
Simplified testcase:
```
inline void foo() {}

struct Y
{
template
static void bar() {}
};

int main()
{
Y::bar();
return 0;
}
```

Confirmed.

[Bug libstdc++/110862] format out of bounds read on format string "{0:{0}"

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

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

--- Comment #3 from Jonathan Wakely  ---
https://gcc.gnu.org/git?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/format;h=9d5981e4882991cc2cbfb9353d399372030e8722;hb=refs/heads/master#l3535
needs to throw if begin()==end() || *begin() != '}'

Fix incoming as soon as I have a decent WiFi signal.

[Bug debug/110885] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf"

[linh.lrd at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ling Nguyen  ---
Consider this program:
struct X
{
static void foo() {}
};

struct Y
{
template
static void bar() {}
};

int main()
{
Y::bar();
return 0;
}

If it's compiled using something like: gcc -gsplit-dwarf -fdebug-types-section.
the linker will complain: undefined reference to `X::foo()'
More details here: https://godbolt.org/z/qnj56e769

[Bug web/110889] Arts

[pipare7258 at quipas dot com via Gcc-bugs]

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

--- Comment #1 from JD Official  ---
Created attachment 55681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55681&action=edit
https://steameastus.com/";>Steam East US

[Bug web/110889] New: Arts

[pipare7258 at quipas dot com via Gcc-bugs]

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

Bug ID: 110889
   Summary: Arts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pipare7258 at quipas dot com
  Target Milestone: ---

https://steameastus.com/";>Steam East US

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||shaohua.li at inf dot ethz.ch

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

[Bug c/110887] ICE: gcc: internal compiler error: Segmentation fault signal terminated program cc1 since r14-2925-g2bae476b511

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 110874.

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

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

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

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

--- Comment #1 from Rimvydas (RJ)  ---
Created attachment 55680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55680&action=edit
possible fix

With this patch an extra register is freed and compiler produces expected code
on x86_64:
movsd   (%rdi), %xmm0
mulsd   (%rsi), %xmm0
movsd   %xmm0, (%rdx)
ret

Patch could be expanded to consider inlining trivial matmul cases even for
known arrays of size 1 with rank > 2.

[Bug fortran/110888] New: Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

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

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

Bug ID: 110888
   Summary: Missing optimization for trivial MATMUL cases,
requires -fno-signed-zeros
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

$ cat foo.f90
subroutine foo(x,y,z)
  implicit none
  real(kind=selected_real_kind(9,99)) :: x(1), y(1,1), z(1)
  z = matmul(x,y)
end subroutine

$ gfortran -c -S -Wall -Wextra -O2 -fdump-tree-optimized foo.f90

The do loop get reduced in matmul intrinsic implementation, however redundant
accumulator store is not optimized out during PRE if
-ffast-math(-fno-signed-zeros) is not used:
[local count: 536870912]:
   __builtin_memset (z_11(D), 0, 8);
-  _18 = (*z_11(D))[0];
   _19 = (*x_13(D))[0];
   _20 = (*y_14(D))[0];
   _21 = _19 * _20;
-  _22 = _18 + _21;
+  _22 = _21 + 0.0;
   (*z_11(D))[0] = _22;
   return;

Not sure if it is possible to mark accumulator expr as artificial so that
optimizers could ignore side effects by default, but luckily it is easily
avoidable in frontend itself.

[Bug c/110887] New: ICE: gcc: internal compiler error: Segmentation fault signal terminated program cc1 since r14-2925-g2bae476b511

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

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

Bug ID: 110887
   Summary: ICE: gcc: internal compiler error: Segmentation fault
signal terminated program cc1 since
r14-2925-g2bae476b511
   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
  Target Milestone: ---

gcc at -O2 crashes on the test case.

Bisected to r14-2925-g2bae476b511

$ cat a.c
int printf(const char *, ...);
short a;
char b;
long c;
int d;
int main() {
  int e = 0;
  for (; e <= 9; e++) {
d &= 1;
if (a)
  c = d ^= 1;
b ^= --d;
  }
  printf("%d\n", b);
}
$
$ gcc-2bae476b511dc441bf61da8a49cca655575e7dd6 -O2 a.c
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
$

[Bug middle-end/110886] [14 Regression] ICE on linux-6.4.7: SIGSEGV on gimple_bitwise_inverted_equal_p (infinite recursion?)

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

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

--- Comment #2 from Sergei Trofimovich  ---
Forgot the reproducer itself:

// $ cat altera.c.c
int altera_export_bool_array_count_i, altera_export_bool_array_count_line, r;
unsigned altera_export_bool_array_count_k;
void altera_export_bool_array_count() {
  int offset;
  altera_export_bool_array_count_line = 0;
  if (altera_export_bool_array_count_line < 1)
offset = r;
  altera_export_bool_array_count_k = 0;
  for (;;) {
altera_export_bool_array_count_i =
altera_export_bool_array_count_k + offset;
if (altera_export_bool_array_count_i & 3)
  ;
  }
}