[Bug target/111335] New: fmaddpch seems not commutative for operands[1] and operands[2] due to precision loss

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 111335
   Summary: fmaddpch seems not commutative for operands[1] and
operands[2] due to precision loss
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

fmaddcph is complex _Float16 fma.

cat test.c

#include 
#include 

void func(_Float16 a[], _Float16 b[], _Float16 c[])

{
   const __m128h r0 = _mm_loadu_ph(a);
   const __m128h r1 = _mm_loadu_ph(b);
   const __m128h r2 = _mm_loadu_ph(c);
   const __m128h mul = _mm_fmadd_pch(r0, r1, r2);
   printf("%f %f\n", (float)mul[0], (float)mul[1]);
}

int main()

{
  _Float16 a[8] = {-0.7949218f16, +0.2739257f16};
  _Float16 b[8] = {+0.0010070f16, +0.0015659f16};
  _Float16 c[8] = {-0.0010366f16, -0.0018014f16};
  func(a, b, c);
  return 0;
}


g++ -O0 -march=sapphirerapids test.c, we get fmaddpch a, b, c, and the result
is 
-0.002266 -0.002769

g++ -O0 -march=sapphirerapids test.c, we get fmaddpch b, a, c, and the result
is 
-0.002266 -0.002771

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

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

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

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

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

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

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Yeah, rewriting it to an inline function sounds like the right
fix to me FWIW.  The call looks valid.

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

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

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

--- Comment #10 from Andrew Pinski  ---
And here is the fix for phiopt:
```
diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
index 9993bbe5b76..9b44ca9758a 100644
--- a/gcc/tree-ssa-phiopt.cc
+++ b/gcc/tree-ssa-phiopt.cc
@@ -2073,7 +2073,7 @@ minmax_replacement (basic_block cond_bb, basic_block
middle_bb, basic_block alt_

  /* We need BOUND <= LARGER.  */
  if (!integer_nonzerop (fold_build2 (LE_EXPR, boolean_type_node,
- bound, larger)))
+ bound, arg_false)))
return false;
}
  else if (operand_equal_for_phi_arg_p (arg_false, smaller)
@@ -2104,7 +2104,7 @@ minmax_replacement (basic_block cond_bb, basic_block
middle_bb, basic_block alt_

  /* We need BOUND >= SMALLER.  */
  if (!integer_nonzerop (fold_build2 (GE_EXPR, boolean_type_node,
- bound, smaller)))
+ bound, arg_false)))
return false;
}
  else
@@ -2144,7 +2144,7 @@ minmax_replacement (basic_block cond_bb, basic_block
middle_bb, basic_block alt_

  /* We need BOUND >= LARGER.  */
  if (!integer_nonzerop (fold_build2 (GE_EXPR, boolean_type_node,
- bound, larger)))
+ bound, arg_true)))
return false;
}
  else if (operand_equal_for_phi_arg_p (arg_true, smaller)
@@ -2171,7 +2171,7 @@ minmax_replacement (basic_block cond_bb, basic_block
middle_bb, basic_block alt_

  /* We need BOUND <= SMALLER.  */
  if (!integer_nonzerop (fold_build2 (LE_EXPR, boolean_type_node,
- bound, smaller)))
+ bound, arg_true)))
return false;
}
  else


```

Now I understand both patches even too.

[Bug c++/107800] confusing message with to_address in C++17

[amatuladeeba at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Amatul Adeeba  ---
I mean even after trying the typo that is mentioned above, the error still
occurs.

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

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

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

--- Comment #9 from Andrew Pinski  ---
Actually this is the fix for the match pattern:
```
diff --git a/gcc/match.pd b/gcc/match.pd
index 8c24dae71cd..c7b6db4b543 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5438,11 +5438,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 }
 (if ((cmp == LT_EXPR || cmp == LE_EXPR)
 && code == MIN_EXPR
- && integer_nonzerop (fold_build2 (LE_EXPR, boolean_type_node, @3,
@1)))
+ && integer_nonzerop (fold_build2 (LE_EXPR, boolean_type_node, @3,
@4)))
  (min @2 @4)
  (if ((cmp == GT_EXPR || cmp == GE_EXPR)
  && code == MAX_EXPR
-  && integer_nonzerop (fold_build2 (GE_EXPR, boolean_type_node, @3,
@1)))
+  && integer_nonzerop (fold_build2 (GE_EXPR, boolean_type_node, @3,
@4)))
   (max @2 @4))

 #if GIMPLE
```

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

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|ICE is reported during the  |[14 regression] ICE is
   |combine pass optimization   |reported during the combine
   ||pass optimization
   Keywords||ice-on-valid-code

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

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

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

--- Comment #6 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #5)
> (In reply to chenglulu from comment #3)
> > This involves the template di3_fake:
> > (define_insn "di3_fake"
> >   [(set (match_operand:DI 0 "register_operand" "=r,,")
> > (sign_extend:DI
> >   (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> >   (match_operand:DI 2 "register_operand" "r,r,r"]
> >   ""
> > {
> >   return loongarch_output_division (".w\t%0,%1,%2", operands);
> > }
> >   [(set_attr "type" "idiv")
> >(set_attr "mode" "SI")
> >(set (attr "enabled")
> >   (if_then_else
> > (match_test "!!which_alternative == loongarch_check_zero_div_p()")
> > (const_string "yes")
> > (const_string "no")))])
> > 
> > 
> > I think there is a problem with the implementation of this template. 
> > First, the instructions generated in the template are [u]div.w[u], etc. The
> > description of such instructions in the instruction manual is that if the
> > upper 32 bits are not extended by the 31st bit sign then the result is
> > uncertain.
> 
> I think this reason alone makes the pattern looks very wrong.
> 
> I'll take a look...

Hmm, I guess we should just make di3_fake an UNSPEC because there is no way to
use div.w and its friends out of 3.

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

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #5 from Xi Ruoyao  ---
(In reply to chenglulu from comment #3)
> This involves the template di3_fake:
> (define_insn "di3_fake"
>   [(set (match_operand:DI 0 "register_operand" "=r,,")
> (sign_extend:DI
>   (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
>   (match_operand:DI 2 "register_operand" "r,r,r"]
>   ""
> {
>   return loongarch_output_division (".w\t%0,%1,%2", operands);
> }
>   [(set_attr "type" "idiv")
>(set_attr "mode" "SI")
>(set (attr "enabled")
>   (if_then_else
> (match_test "!!which_alternative == loongarch_check_zero_div_p()")
> (const_string "yes")
> (const_string "no")))])
> 
> 
> I think there is a problem with the implementation of this template. 
> First, the instructions generated in the template are [u]div.w[u], etc. The
> description of such instructions in the instruction manual is that if the
> upper 32 bits are not extended by the 31st bit sign then the result is
> uncertain.

I think this reason alone makes the pattern looks very wrong.

I'll take a look...

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #9 from d_vampile  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to d_vampile from comment #7)
> > In terms of runtime, this code is the best.
> 
> Depends on the core 
> What does -mtune=native provide for the core which you are running on?
> Also what core are you testing with?

I also tried GCC11 and GCC12, using the same compilation options, but not even
the instruction ' vextracti128 ', so the program runs longer and performs
worse.

the assembly instruction is not change by use -mtune=native，and the test
results were still worse than gcc7.

CPU info:
Intel(R) Xeon(R) Gold 6348 CPU @ 2.60GHz
-mtune=generic

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to d_vampile from comment #7)
> In terms of runtime, this code is the best.

Depends on the core 
What does -mtune=native provide for the core which you are running on?
Also what core are you testing with?

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #4 from Andrew Pinski  ---
(In reply to chenglulu from comment #3)
> This involves the template di3_fake:
> (define_insn "di3_fake"
>   [(set (match_operand:DI 0 "register_operand" "=r,,")
> (sign_extend:DI
>   (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
>   (match_operand:DI 2 "register_operand" "r,r,r"]

That pattern definitely looks broken.
Divide's operands' mode must match the mode of the divide IIRC.

[Bug c/111334] ICE is reported during the combine pass optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #3 from chenglulu  ---
This involves the template di3_fake:
(define_insn "di3_fake"
  [(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
  (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
  (match_operand:DI 2 "register_operand" "r,r,r"]
  ""
{
  return loongarch_output_division (".w\t%0,%1,%2", operands);
}
  [(set_attr "type" "idiv")
   (set_attr "mode" "SI")
   (set (attr "enabled")
  (if_then_else
(match_test "!!which_alternative == loongarch_check_zero_div_p()")
(const_string "yes")
(const_string "no")))])


I think there is a problem with the implementation of this template. 
First, the instructions generated in the template are [u]div.w[u], etc. The
description of such instructions in the instruction manual is that if the upper
32 bits are not extended by the 31st bit sign then the result is uncertain.
The second port, I don't know if the following is correct.
  (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
  (match_operand:DI 2 "register_operand" "r,r,r"]
I try to modify this template：
(define_insn "di3_fake"
  [(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
  (unspec:SI [(any_div:SI (match_operand:DI 1 "register_operand"
"r,r,0")
  (match_operand:DI 2 "register_operand" "r,r,r"))]
   UNSPEC_ANY_DIV)))]
  ""
{
  return loongarch_output_division (".w\t%0,%1,%2", operands);
}
  [(set_attr "type" "idiv")
   (set_attr "mode" "SI")
   (set (attr "enabled")
  (if_then_else
(match_test "!!which_alternative == loongarch_check_zero_div_p()")
(const_string "yes")
(const_string "no")))])

This problem can be solved. But I don't know if what I'm doing is correct．．．

[Bug c/111334] ICE is reported during the combine pass optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #2 from chenglulu  ---
This problem occurred after adding the r14-3511 optimization.

However, during the debugging process, it was discovered that it was due to the
attempt to generate rtx during the combine pass optimization.

(set (reg:DI 124)
(zero_extend:DI (subreg:QI (umod:SI (reg:DI 122 [ reg ])
(ior:DI (if_then_else:DI (eq:DI (reg:DI 114)
(const_int 0 [0]))
(reg:DI 112)
(const_int 0 [0]))
(reg:DI 118))) 0)))

During the optimization process, the function simplify_context::simplify_subreg
will make the following judgments:

rtx
simplify_context::simplify_subreg (machine_mode outermode, rtx op,
   machine_mode innermode, poly_uint64 byte)
{
  /* Little bit of sanity checking.  */
  gcc_assert (innermode != VOIDmode);
  gcc_assert (outermode != VOIDmode);
  gcc_assert (innermode != BLKmode);
  gcc_assert (outermode != BLKmode);

  gcc_assert (GET_MODE (op) == innermode
  || GET_MODE (op) == VOIDmode);
...

op is (reg:DI 122 [ reg ]) but innermode is SI_mode,so wrong.

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629650.html

[Bug c/111334] ICE is reported during the combine pass optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #1 from chenglulu  ---
$ gcc test.c -o - -S -O1

test.c: 在函数‘add_startpgm’中:
test.c:33:1: 编译器内部错误：在 simplify_subreg 中，于 simplify-rtx.cc:7538
   33 | }
  | ^
0x13506f4 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/simplify-rtx.cc:7537
0x1351ea3 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/simplify-rtx.cc:7787
0x135264c simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/simplify-rtx.cc:7858
0xd1684f simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/rtl.h:3549
0x1e4aa06 if_then_else_cond
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:9400
0x1e4a21e if_then_else_cond
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:9265
0x1e3ddb8 combine_simplify_rtx
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5748
0x1e3d79a subst
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5609
0x1e3df1f combine_simplify_rtx
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5769
0x1e3d79a subst
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5609
0x1e3d50d subst
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5536
0x1e35f40 try_combine
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:3339
0x1e305a0 combine_instructions
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:1285
0x1e5addb rest_of_handle_combine
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:15063
0x1e5ae98 execute
   
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:15107

[Bug c/111334] New: ICE is reported during the combine pass optimization

[chenglulu at loongson dot cn via Gcc-bugs]

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

Bug ID: 111334
   Summary: ICE is reported during the combine pass optimization
   Product: gcc
   Version: rust/master
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chenglulu at loongson dot cn
  Target Milestone: ---

Created attachment 55852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55852=edit
test

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #7 from d_vampile  ---
(In reply to Andrew Pinski from comment #3)
> GCC 11+ produces:
> .L3:
> vmovdqu (%rsi), %ymm2
> vmovdqu 32(%rsi), %ymm1
> subq$-128, %rdi
> subq$-128, %rsi
> vmovdqu -64(%rsi), %ymm0
> vmovdqu -32(%rsi), %ymm3
> vmovdqu %ymm2, -128(%rdi)
> vmovdqu %ymm3, -32(%rdi)
> vmovdqu %ymm1, -96(%rdi)
> vmovdqu %ymm0, -64(%rdi)
> cmpq%rax, %rdi
> jne .L3
> 
> Which is the best code ...

GCC 7.3.0 produces:
extern __inline __m256i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_loadu_si256 (__m256i_u const *__P)
{
  return *__P;
  401170:   c5 fa 6f 1e vmovdqu (%rsi),%xmm3
dst = (uint8_t *)dst + 128;
  401174:   48 83 ef 80 sub$0xff80,%rdi
src = (const uint8_t *)src + 128;
  401178:   48 83 ee 80 sub$0xff80,%rsi
  40117c:   c5 fa 6f 56 a0  vmovdqu -0x60(%rsi),%xmm2
  401181:   c4 e3 65 38 5e 90 01vinserti128
$0x1,-0x70(%rsi),%ymm3,%ymm3
  401188:   c5 fa 6f 4e c0  vmovdqu -0x40(%rsi),%xmm1
  40118d:   c4 e3 6d 38 56 b0 01vinserti128
$0x1,-0x50(%rsi),%ymm2,%ymm2
  401194:   c5 fa 6f 46 e0  vmovdqu -0x20(%rsi),%xmm0
  401199:   c4 e3 75 38 4e d0 01vinserti128
$0x1,-0x30(%rsi),%ymm1,%ymm1
  4011a0:   c4 e3 7d 38 46 f0 01vinserti128
$0x1,-0x10(%rsi),%ymm0,%ymm0
}

extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_storeu_si256 (__m256i_u *__P, __m256i __A)
{
  *__P = __A;
  4011a7:   c5 f8 11 5f 80  vmovups %xmm3,-0x80(%rdi)
  4011ac:   c4 e3 7d 39 5f 90 01vextracti128 $0x1,%ymm3,-0x70(%rdi)
  4011b3:   c5 f8 11 57 a0  vmovups %xmm2,-0x60(%rdi)
  4011b8:   c4 e3 7d 39 57 b0 01vextracti128 $0x1,%ymm2,-0x50(%rdi)
  4011bf:   c5 f8 11 4f c0  vmovups %xmm1,-0x40(%rdi)
  4011c4:   c4 e3 7d 39 4f d0 01vextracti128 $0x1,%ymm1,-0x30(%rdi)
  4011cb:   c5 f8 11 47 e0  vmovups %xmm0,-0x20(%rdi)
  4011d0:   c4 e3 7d 39 47 f0 01vextracti128 $0x1,%ymm0,-0x10(%rdi)
while (n >= 128) {
  4011d7:   48 39 c7cmp%rax,%rdi
  4011da:   75 94   jne401170 
  4011dc:   c5 f8 77vzeroupper

In terms of runtime, this code is the best.

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #6 from d_vampile  ---
GCC 7.3.0 produces:
extern __inline __m256i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_loadu_si256 (__m256i_u const *__P)
{
  return *__P;
  401170:   c5 fa 6f 1e vmovdqu (%rsi),%xmm3
dst = (uint8_t *)dst + 128;
  401174:   48 83 ef 80 sub$0xff80,%rdi
src = (const uint8_t *)src + 128;
  401178:   48 83 ee 80 sub$0xff80,%rsi
  40117c:   c5 fa 6f 56 a0  vmovdqu -0x60(%rsi),%xmm2
  401181:   c4 e3 65 38 5e 90 01vinserti128
$0x1,-0x70(%rsi),%ymm3,%ymm3
  401188:   c5 fa 6f 4e c0  vmovdqu -0x40(%rsi),%xmm1
  40118d:   c4 e3 6d 38 56 b0 01vinserti128
$0x1,-0x50(%rsi),%ymm2,%ymm2
  401194:   c5 fa 6f 46 e0  vmovdqu -0x20(%rsi),%xmm0
  401199:   c4 e3 75 38 4e d0 01vinserti128
$0x1,-0x30(%rsi),%ymm1,%ymm1
  4011a0:   c4 e3 7d 38 46 f0 01vinserti128
$0x1,-0x10(%rsi),%ymm0,%ymm0
}

extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_storeu_si256 (__m256i_u *__P, __m256i __A)
{
  *__P = __A;
  4011a7:   c5 f8 11 5f 80  vmovups %xmm3,-0x80(%rdi)
  4011ac:   c4 e3 7d 39 5f 90 01vextracti128 $0x1,%ymm3,-0x70(%rdi)
  4011b3:   c5 f8 11 57 a0  vmovups %xmm2,-0x60(%rdi)
  4011b8:   c4 e3 7d 39 57 b0 01vextracti128 $0x1,%ymm2,-0x50(%rdi)
  4011bf:   c5 f8 11 4f c0  vmovups %xmm1,-0x40(%rdi)
  4011c4:   c4 e3 7d 39 4f d0 01vextracti128 $0x1,%ymm1,-0x30(%rdi)
  4011cb:   c5 f8 11 47 e0  vmovups %xmm0,-0x20(%rdi)
  4011d0:   c4 e3 7d 39 47 f0 01vextracti128 $0x1,%ymm0,-0x10(%rdi)
while (n >= 128) {
  4011d7:   48 39 c7cmp%rax,%rdi
  4011da:   75 94   jne401170 
  4011dc:   c5 f8 77vzeroupper

In terms of runtime, this code is the best.

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #5 from d_vampile  ---
According to the analysis, the following two prs may cause the preceding
problems:
PR1:https://github.com/gcc-mirror/gcc/commit/dd9b529f08c3c6064c37234922d298336d78caf7
PR2:https://github.com/gcc-mirror/gcc/commit/e7bf9583fa2a16e9edd5d5347407ad8acc8f9794

I revert PR1 on gcc10.3.0 and found that the assembly instructions changed to
vmovups and vmovups.

And revert PR2, the order of assembly instructions can be consistent with that
of instructions generated during gcc7.3.0 compilation. However, the effects  of
these two PRs and the potential risks of code rollback are still noclear.

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

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

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

--- Comment #8 from Andrew Pinski  ---
The tree-ssa-phiopt.cc code is much more complex.

But not testing arg_true/arg_false against alt_larger/alt_smaller does fix the
issue.

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/111333] Runtime failure for fcmulcph instrinsic

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Yes this is an exact dup.

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

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

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

[Bug target/111333] Runtime failure for fcmulcph instrinsic

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

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

--- Comment #3 from Andrew Pinski  ---
Isn't this a dup of bug 111306 ?

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Anyways the tuning was fixed for GCC 11. GCC 10 is no longer supported so
closing as fixed for GCC 11.

[Bug target/111333] Runtime failure for fcmulcph instrinsic

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
The test failed since GCC12 when the pattern is added

[Bug target/111333] Runtime failure for fcmulcph instrinsic

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
fmulcph/fmaddcph is commutative for operands[1] and operands[2], but
fcmulcph/fcmaddcph is not, since it's Complex conjugate operations.

Below change fixes the issue.

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6d3ae8dea0c..833546c5228 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -6480,6 +6480,14 @@ (define_int_attr complexpairopname
[(UNSPEC_COMPLEX_FMA_PAIR "fmaddc")
 (UNSPEC_COMPLEX_FCMA_PAIR "fcmaddc")])

+(define_int_attr int_comm
+   [(UNSPEC_COMPLEX_FMA "%")
+(UNSPEC_COMPLEX_FMA_PAIR "%")
+(UNSPEC_COMPLEX_FCMA "")
+(UNSPEC_COMPLEX_FCMA_PAIR "")
+(UNSPEC_COMPLEX_FMUL "%")
+(UNSPEC_COMPLEX_FCMUL "")])
+
 (define_int_attr conj_op
[(UNSPEC_COMPLEX_FMA "")
 (UNSPEC_COMPLEX_FCMA "_conj")
@@ -6593,7 +6601,7 @@ (define_expand "cmla4"
 (define_insn "fma__"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=")
(unspec:VHF_AVX512VL
- [(match_operand:VHF_AVX512VL 1 "" "%v")
+ [(match_operand:VHF_AVX512VL 1 ""
"v")
   (match_operand:VHF_AVX512VL 2 ""
"")
   (match_operand:VHF_AVX512VL 3 "" "0")]
   UNSPEC_COMPLEX_F_C_MA))]
@@ -6658,7 +,7 @@ (define_insn_and_split
"fma___fma_zero"
 (define_insn "fma___pair"
  [(set (match_operand:VF1_AVX512VL 0 "register_operand" "=")
(unspec:VF1_AVX512VL
-[(match_operand:VF1_AVX512VL 1 "vector_operand" "%v")
+[(match_operand:VF1_AVX512VL 1 "vector_operand" "v")
  (match_operand:VF1_AVX512VL 2 "bcst_vector_operand" "vmBr")
  (match_operand:VF1_AVX512VL 3 "vector_operand" "0")]
  UNSPEC_COMPLEX_F_C_MA_PAIR))]
@@ -6727,7 +6735,7 @@ (define_insn
"___mask"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=")
(vec_merge:VHF_AVX512VL
  (unspec:VHF_AVX512VL
-   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand" "%v")
+   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand"
"v")
 (match_operand:VHF_AVX512VL 2 "nonimmediate_operand"
"")
 (match_operand:VHF_AVX512VL 3 "register_operand" "0")]
 UNSPEC_COMPLEX_F_C_MA)
@@ -6752,7 +6760,7 @@ (define_expand "cmul3"
 (define_insn "__"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=")
  (unspec:VHF_AVX512VL
-   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand" "%v")
+   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand"
"v")
 (match_operand:VHF_AVX512VL 2 "nonimmediate_operand"
"")]
 UNSPEC_COMPLEX_F_C_MUL))]
   "TARGET_AVX512FP16 && "

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||6.4.0
  Known to fail||7.3.0, 7.5.0, 8.5.0, 9.5.0

--- Comment #3 from Andrew Pinski  ---
GCC 11+ produces:
.L3:
vmovdqu (%rsi), %ymm2
vmovdqu 32(%rsi), %ymm1
subq$-128, %rdi
subq$-128, %rsi
vmovdqu -64(%rsi), %ymm0
vmovdqu -32(%rsi), %ymm3
vmovdqu %ymm2, -128(%rdi)
vmovdqu %ymm3, -32(%rdi)
vmovdqu %ymm1, -96(%rdi)
vmovdqu %ymm0, -64(%rdi)
cmpq%rax, %rdi
jne .L3

Which is the best code ...

[Bug target/111333] New: Runtime failure for fcmulcph instrinsic

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 111333
   Summary: Runtime failure for fcmulcph instrinsic
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

cat main.cpp

#include 
#include 

__attribute__((optimize("O0")))
auto func0(_Float16 *a, _Float16 *b, int n, _Float16 *c) {
  __m512h rA = _mm512_loadu_ph(a);
  for (int i = 0; i < n; i += 32) {
__m512h rB = _mm512_loadu_ph(b + i);
_mm512_storeu_ph(c + i, _mm512_fcmul_pch(rB, rA));
  }
}

__attribute__((optimize("O2")))
auto func1(_Float16 *a, _Float16 *b, int n, _Float16 *c) {
  __m512h rA = _mm512_loadu_ph(a);
  for (int i = 0; i < n; i += 32) {
__m512h rB = _mm512_loadu_ph(b + i);
_mm512_storeu_ph(c + i, _mm512_fcmul_pch(rB, rA));
  }
}

int main() {
  int n = 32;

  _Float16 a[n], b[n], c[n];
  for (int i = 1; i <= n; i++) {
a[i - 1] = i & 1 ? -i : i;
b[i - 1] = i;
  }
  printf("a = %f + %fi \n", (float)a[0], (float)a[1]);
  printf("b = %f + %fi \n", (float)b[0], (float)b[1]);
  printf("b * conj(a) = %f + %fi \n\n", (float)(a[0]*b[0] + a[1]*b[1]),
(float)(a[0]*b[1] - a[1]*b[0]));

  func0(a, b, n, c);
for (int i = 0; i < n / 32 * 2; i++) {
  printf("%f ", (float)c[i]);
}
printf("\n");

  func1(a, b, n, c);
for (int i = 0; i < n / 32 * 2; i++) {
  printf("%f ", (float)c[i]);
}
printf("\n");

  return 0;
}

g++ -march=sapphirerapids main.cpp -o test
sde -spr-- ./test

a = -1.00 + 2.00i
b = 1.00 + 2.00i
b * conj(a) = 3.00 + -4.00i

3.00 -4.00
3.00 4.00

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

--- Comment #2 from d_vampile  ---
gcc7.3.0 program use vmovups and vmovups instructions , but gcc10.3.0 program
only use vmovups instructions.In addition, the order of the two assembly
instructions is not consistent.

[Bug target/111332] Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

d_vampile  changed:

   What|Removed |Added

 CC||d_vampile at 163 dot com

--- Comment #1 from d_vampile  ---
Created attachment 55851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55851=edit
Assembly Instruction Differences

This figure shows the assembly instructions. The left one is gcc7.3.0, and the
right one is gcc10.3.0.

[Bug target/111332] New: Using GCC7.3.0 and GCC10.3.0 to compile the same test case, assembler file instructions are different and performance fallback is obvious.

[d_vampile at 163 dot com via Gcc-bugs]

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

Bug ID: 111332
   Summary: Using GCC7.3.0 and GCC10.3.0 to compile the same test
case, assembler file instructions are different and
performance fallback is obvious.
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d_vampile at 163 dot com
  Target Milestone: ---

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

Created Attachment

Test platform: x86_64

Compiler Options:  
gcc main.c -g -o main -O2 -msse4.2 -mavx2 -fno-inline

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

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


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

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

Programs compiled with gcc10.3.0 run significantly longer than gcc7.3.0

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #7 from Andrew Pinski  ---
Fix for the trunk -O0 issue:
```
diff --git a/gcc/match.pd b/gcc/match.pd
index 8c24dae71cd..f67bb9c12e7 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5435,6 +5435,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(with
 {
   tree_code code = minmax_from_comparison (cmp, @0, @1, @0, @4);
+  /* For LT and GT, @4 and @1 needs to be the same.\
+For an example:
+ _3 > 28 ? MIN_EXPR <_3, 28> : 29
+is not the same as
+ MAX_EXPR , 29>
+But `_3 >= 28` would be. */
+  if (cmp != LE_EXPR
+  && cmp != GE_EXPR
+  && !operand_equal_p (@1, @4))
+code = ERROR_MARK;
 }
 (if ((cmp == LT_EXPR || cmp == LE_EXPR)
 && code == MIN_EXPR
```

But we still fail the original testcase at -O1 because the code in phiopt is
still needs to be fixed ...

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
I am going to fix this.

[Bug tree-optimization/111148] Missing boolean optimizations due to comparisons

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

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

--- Comment #2 from Andrew Pinski  ---
The one which I had missed:

_Bool f(int x, int y, int w, int z)
{
  _Bool a = z == w;
  _Bool b = x == y;
  return (a & !b) | (a ^ b); // a ^ b
}

[Bug analyzer/110529] Analyzer fails to handle computed goto

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

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

David Malcolm  changed:

   What|Removed |Added

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

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

[Bug analyzer/110529] Analyzer fails to handle computed goto

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

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

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

https://gcc.gnu.org/g:1b761fede44afac5fa72e77caced9beda93fb381

commit r14-3796-g1b761fede44afac5fa72e77caced9beda93fb381
Author: David Malcolm 
Date:   Thu Sep 7 18:43:05 2023 -0400

analyzer: basic support for computed gotos (PR analyzer/110529)

PR analyzer/110529 notes that -fanalyzer was giving up on execution
paths that follow a computed goto, due to ignoring CFG edges with the
flag EDGE_ABNORMAL set.

This patch implements enough handling for them to allow analysis of
such execution paths to continue.

gcc/analyzer/ChangeLog:
PR analyzer/110529
* program-point.cc (program_point::on_edge): Don't reject
EDGE_ABNORMAL for computed gotos.
* region-model.cc (region_model::maybe_update_for_edge): Handle
computed goto statements.
(region_model::apply_constraints_for_ggoto): New.
* region-model.h (region_model::apply_constraints_for_ggoto): New
decl.
* supergraph.cc (supernode::get_label): New.
* supergraph.h (supernode::get_label): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/110529
* c-c++-common/analyzer/computed-goto-1.c: New test.
* gcc.dg/analyzer/computed-goto-pr110529.c: New test.

Signed-off-by: David Malcolm 

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||14.0

--- Comment #5 from Andrew Pinski  ---
here is a testcase that fails even at -O0 on the trunk due to the match
patches:
```
int a;
int b;

int main() {
  int d = b+30;
  {
int t;
t = d < 29 ? 29 : ((d > 28) ? 28 : d);
a = t;
  }
  volatile int t = a;
  if (a != 28)
__builtin_trap();
}
```

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

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

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

--- Comment #4 from Andrew Pinski  ---
Reduced testcase:
```
int a;
int b;

int main() {
  int d = b+30;
  {
int t;
if (d < 29)
  t =  29;
else
  t = (d > 28) ? 28 : d;
a = t;
  }
  volatile int t = a;
  if (a != 28)
__builtin_trap();
}
```

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

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

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

--- Comment #3 from Andrew Pinski  ---
For the trunk the problem is in match (and phiopt)
Match pattern:
/* Optimize (a CMP CST1) ? max : a */



r6-7425-ga9fee7cdc3c62d0e51730b6a9814909c557d3070 most likely introduced it for
GCC 6.

For the trunk the issue is also dealing with minmax_from_comparison .

[Bug tree-optimization/111331] Wrong code at -O1 on x86_64-linux-gnu since

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

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

--- Comment #2 from Andrew Pinski  ---
For the trunk:
```
phiopt match-simplify trying:
_3 > 28 ? _9 : 29
Applying pattern match.pd:5446, gimple-match-3.cc:3125

phiopt match-simplify back:
_5 = MAX_EXPR <_9, 29>;
result: _5
accepted the phiopt match-simplify.
statement un-sinked:
_9 = MIN_EXPR <_3, 28>;
```
IR before the first phiopt:
```
  if (_3 <= 28)
goto ; [34.00%]
  else
goto ; [66.00%]

   :
  _9 = MIN_EXPR <_3, 28>;

   :
  # _14 = PHI <29(2), _9(3)>
```
There is a mix match between the 29 and the 28 here ...

[Bug analyzer/110830] -Wanalyzer-use-of-uninitialized-value false negative due to use-after-free::supercedes_p.

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Benjamin Priour :

https://gcc.gnu.org/g:7d2274b9e346f44f8f6598b9dbb9fa95259274a2

commit r14-3794-g7d2274b9e346f44f8f6598b9dbb9fa95259274a2
Author: benjamin priour 
Date:   Fri Sep 1 20:21:41 2023 +0200

analyzer: Call off a superseding when diagnostics are unrelated [PR110830]

Before this patch, a saved_diagnostic would supersede another at
the same statement if and only its vfunc supercedes_p returned true
for the other diagnostic's kind.
That both warning were unrelated - i.e. resolving one would not fix
the other - was not considered in making the above choice.

This patch makes it so that two saved_diagnostics taking a different
outcome of at least one common conditional branching cannot supersede
each other.

Signed-off-by: Benjamin Priour 
Co-authored-by: David Malcolm 
Signed-off-by: David Malcolm 

gcc/analyzer/ChangeLog:

PR analyzer/110830
* diagnostic-manager.cc
(compatible_epaths_p): New function.
(saved_diagnostic::supercedes_p): Now calls the above
to determine if the diagnostics do overlap and the superseding
may proceed.

gcc/testsuite/ChangeLog:

PR analyzer/110830
* c-c++-common/analyzer/pr110830.c: New test.

[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow

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

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

--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Kees Cook from comment #11)
> The trouble with "optimize" is that it just doesn't work. The kernel has
> banned its use because it results in all other optimization options being
> forgotten for the function in question.

How about Jacub's another suggestion in comment#10:

"If you don't want to use optimize attribute, there is always the option to
just do the arithmetics in unsigned types in the few selected functions where
you don't want the sanitization"?

is it possible to use "unsigned" integer instead of "signed" integer for the
cases you want the "wrap around" behavior when overflow? 

if not, what's the major issue with this workaround?

[Bug tree-optimization/111331] Wrong code at -O1 on x86_64-linux-gnu since

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-07
   Target Milestone|--- |11.5
  Known to work||5.1.0
   Keywords||needs-bisection, wrong-code
  Known to fail||6.1.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, note that patch just exposed a latent bug. Here is a testcase which
shows the failure even in GCC 6 but works in GCC 5:
```

int a;
int b;
int c(int d, int e, int f) {
  if (d < e)
return e;
  return (d > f) ? f : d;
}
int main() {
  int g = -1;
  a = c(b + 30, 29, g + 29);
  volatile int t = a;
  if (a != 28)
__builtin_trap();
}
```

[Bug c/111331] New: Wrong code at -O1 on x86_64-linux-gnu since

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

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

Bug ID: 111331
   Summary: Wrong code at -O1 on x86_64-linux-gnu since
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc at -O1 produced the wrong code.

Bisected to r9-3606-g1cab645d3e3

Compiler explorer: https://godbolt.org/z/5YEv44PTa

$ cat a.c
int printf(const char *, ...);
int a;
int b;
int c(int d, int e, int f) {
  if (d < e)
return e;
  if (d > f)
return f;
  return d;
}
int main() {
  int g = -1;
  a = c(b + 30, 29, g + 29);
  printf("%d\n", a);
}
$
$ gcc -O0 a.c && ./a.out
28
$ gcc -O1 a.c && ./a.out
29
$

[Bug fortran/108957] Fortran FE memleak with interfaces

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Mikael,

are you still onto it?

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

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

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

Bug ID: 111330
   Summary: [13 Regression] Bootstrap failure building SeqFile.lo
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I've done a successful Fedora distro build of GCC 13
r13-7622-g3e9aaa9bcb2fc64e64
based snapshot and that and all earlier ones went fine, but when trying to
build
a r13-7778-g78f63dd9fa9ff29949 based snapshot, I'm seeing weird Modula 2
failures.
See https://kojipkgs.fedoraproject.org//work/tasks/4565/105824565/build.log
or https://kojipkgs.fedoraproject.org//work/tasks/4525/105824525/build.log
etc., it is all arches.  What I see in the logs is:
/bin/sh ../libtool --tag=CC   --mode=compile
/builddir/build/BUILD/gcc-13.2.1-20230906/obj-x86_64-redhat-linux/./gcc/gm2
-B/builddir/build/BUILD/gcc-13.2.1-20230906/obj-x86_64-redhat-linux/./gcc/ -c
-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -O2 -fexceptions -g
-grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fm2-pathname=m2iso -I. -Ilibm2iso
-I/builddir/build/BUILD/gcc-13.2.1-20230906/gcc/m2/gm2-libs-iso
-fm2-pathname=m2pim -I/builddir/build/BUILD/gcc-13.2.1-20230906/gcc/m2/gm2-libs
-fiso -fextended-opaque -fm2-g -g -Wreturn-type -fcase -fm2-prefix=m2iso
../../../../libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/SeqFile.mod -o SeqFile.lo
libtool: compile: 
/builddir/build/BUILD/gcc-13.2.1-20230906/obj-x86_64-redhat-linux/./gcc/gm2
-B/builddir/build/BUILD/gcc-13.2.1-20230906/obj-x86_64-redhat-linux/./gcc/ -c
-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -O2 -fexceptions -g
-grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fm2-pathname=m2iso -I. -Ilibm2iso
-I/builddir/build/BUILD/gcc-13.2.1-20230906/gcc/m2/gm2-libs-iso
-fm2-pathname=m2pim -I/builddir/build/BUILD/gcc-13.2.1-20230906/gcc/m2/gm2-libs
-fiso -fextended-opaque -fm2-g -g -Wreturn-type -fcase -fm2-prefix=m2iso
../../../../libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/SeqFile.mod  -fPIC -DPIC
-o .libs/SeqFile.o
../../gcc/m2/gm2-compiler/M2SymInit.def:1:case statement has no matching
selection
make[5]: *** [Makefile:912: SeqFile.lo] Error 1

Now, I have no idea if this case statement has no matching selection message is
an error or not and if it is, if it is what caused SeqFile.lo to fail building.

I've reproduced it in a local Fedora mock, but when I do make -j32 in the
libgm2 build directory afterwards, everything including SeqFile.lo builds fine,
so I wonder if it isn't another case of missing Makefile dependencies or
something similar.

Any ideas (including ideas what I could try to understand what's going on)?

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Ah, actually that patch changed the definition of pp_wide_int macro
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/pretty-print.h;h=6eb99b1f6901e4367687081dcd21298719ccdc40;hp=369be6e7ba767bfbf2ccf74d5e602371279726f4;hb=4f4fa2501186e4;hpb=6b96de22d6bcadb45530c1898b264e4738afa4fd
because with the larger precision wide_int the fixed size buffer isn't enough.
Now, in the analyzer case, seems it is used with a function call
  pp_wide_int (pp, get_last_byte_offset (), SIGNED);
and perhaps the const wide_int_ref in that case binds to a temporary which goes
out of scope at the end of the statement.
So, if we want to support such usages, wonder if I don't need to rewrite
pp_wide_int macro into an inline function and perhaps use there an out of line
function for the larger precision case (because XALLOCAVEC will cause inlining
to fail).

[Bug tree-optimization/110875] [14 Regression] Dead Code Elimination Regression since r14-2501-g285c9d042e9

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Macleod  ---
When range_of_stmt invokes prefill_name to evaluate unvisited dependencies it
should not mark visited names as always_current.

when ranger_cache::get_globaL_range() is invoked with the optional  "current_p"
flag, it triggers additional functionality. This call is meant to be from
within ranger and it is understood that if the current value is not current, 
set_global_range will always be called later with a value.  Thus it sets the
always_current flag in the temporal cache to avoid computation cycles.

the prefill_stmt_dependencies () mechanism within ranger is intended to emulate
the bahaviour of range_of_stmt on an arbitrarily long series of unresolved
dependencies without triggering the overhead of huge call chains from the
range_of_expr/range_on_entry/range_on_exit routines.  Rather, it creates a
stack of unvisited names, and invokes range_of_stmt on them directly in order
to get initial cache values for each ssa-name.

The issue in this PR was that routine was incorrectly invoking the
get_global_cache to determine whether there was a global value.  If there was,
it would move on to the next dependency without invoking set_global_range to
clear the always_current flag.

What it should have been doing was simply checking if there as a global value,
and if there was not, add the name for processing and THEN invoke
get_global_value to do all the special processing.
fixed.

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

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

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

--- Comment #3 from seurer at gcc dot gnu.org ---
It is the one that appears to trigger this failure, though.  And as for being a
duplicate of that other one I see this on both powerpc64 BE and LE.

git bisect log

git bisect start
# good: [1b4c70d4271a00514ae20970d483c3b78d9d66ef] RISC-V: Fix VSETVL PASS
AVL/VL fetch bug[111295]
git bisect good 1b4c70d4271a00514ae20970d483c3b78d9d66ef
# bad: [52e270e847d240fb68a27c88ee60189515a6] Additional _BitInt test
coverage [PR102989]
git bisect bad 52e270e847d240fb68a27c88ee60189515a6
# bad: [8c984a1c3693df63520558631c827bb2c2d8b5bc] C _BitInt support [PR102989]
git bisect bad 8c984a1c3693df63520558631c827bb2c2d8b5bc
# bad: [b38deff6127778fed453bb647e32738ba5c78e33] i386: Enable _BitInt on
x86-64 [PR102989]
git bisect bad b38deff6127778fed453bb647e32738ba5c78e33
# bad: [4f4fa2501186e43d115238ae938b3df322c9e02a] Middle-end _BitInt support
[PR102989]
git bisect bad 4f4fa2501186e43d115238ae938b3df322c9e02a
# good: [6b96de22d6bcadb45530c1898b264e4738afa4fd] RISC-V: Fix incorrect mode
tieable which cause ICE in RA[PR111296]
git bisect good 6b96de22d6bcadb45530c1898b264e4738afa4fd
# first bad commit: [4f4fa2501186e43d115238ae938b3df322c9e02a] Middle-end
_BitInt support [PR102989]


g:6b96de22d6bcadb45530c1898b264e4738afa4fd, r14-3744-g6b96de22d6bcad
make  -k check-gcc
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c"
# of expected passes4


g:4f4fa2501186e43d115238ae938b3df322c9e02a, r14-3745-g4f4fa2501186e4
make  -k check-gcc
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c"
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c expected multiline
pattern lines 17-39
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c 2 blank line(s) in output
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c (test for excess errors)
# of expected passes2
# of unexpected failures3

[Bug tree-optimization/110875] [14 Regression] Dead Code Elimination Regression since r14-2501-g285c9d042e9

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r14-3792-gcf2ae3fff4ee9bf884b122ee6cd83bffd791a16f
Author: Andrew MacLeod 
Date:   Thu Sep 7 11:15:50 2023 -0400

Some ssa-names get incorrectly marked as always_current.

When range_of_stmt invokes prefill_name to evaluate unvisited dependencies
it should not mark already visited names as always_current.

PR tree-optimization/110875
gcc/
* gimple-range.cc (gimple_ranger::prefill_name): Only invoke
cache-prefilling routine when the ssa-name has no global value.

gcc/testsuite/
* gcc.dg/pr110875.c: New.

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed||2023-09-07
   Severity|normal  |enhancement
 CC||pinskia at gcc dot gnu.org

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

So using the local range in this case is ok. There might be only a few times we
don't want to use it though in match.

Here is a testcase where we should just change it into "return x;" but don't
yet:
```
typedef unsigned int INT;

INT
foo (INT x, INT y)
{
  if (x > 100 || y > 100)
return x;
  return (x * y) / y;
}
```

Note clang is able to change it though.

[Bug tree-optimization/111328] ICE: verify_flow_info failed since r14-3459-g0c78240fd7d

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
  Component|c   |tree-optimization
   Keywords||ice-checking,
   ||ice-on-valid-code

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

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

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

--- Comment #2 from David Malcolm  ---
Possibly another duplicate of bug 110483.

[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |WAITING

--- Comment #12 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14.

Shall we close it?  Or does it deserve backporting?

[Bug c++/111226] constexpr doesn't detect change of union to empty member

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-07

--- Comment #1 from Patrick Palka  ---
Confirmed.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't think that is a correct bi-section, I don't think my patch has anything
to do with that.
I see zero difference in the output between r14-3744 and r14-3745, in fact I
don't see any difference in output between r14-2029 (when these options were
introduced) and latest trunk.
But the test includes , perhaps that header changed?

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #19 from Iain Sandoe  ---
(In reply to François Dumont from comment #17)
> (In reply to Iain Sandoe from comment #15)

Your proposed patch for the friend issue does fix the libstdc++ cases for my
Darwin patchset.

> > many of the c++ fails are of this form:
> > 
> > contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to
> > `handle_contract_violation(std::experimental::contract_violation const&)'
> 
> I'm surprised that my patch can have an impact on the C++ front end but I'll
> give it a try. 

I do not think it's affecting the FE as such - but rather that some of the
tests include stdc++ headers (I try to avoid it in the testsuite, but obviously
things like coroutines cannot avoid it)

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

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

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

Bug ID: 111329
   Summary: [14 regression]
gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails
after r14-3745-g4f4fa2501186e4
   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:4f4fa2501186e43d115238ae938b3df322c9e02a, r14-3745-g4f4fa2501186e4
make  -k check-gcc
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c"
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c expected multiline
pattern lines 17-39
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c 2 blank line(s) in output
FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c (test for excess errors)
# of expected passes2
# of unexpected failures3

commit 4f4fa2501186e43d115238ae938b3df322c9e02a (HEAD, refs/bisect/bad)
Author: Jakub Jelinek 
Date:   Wed Sep 6 17:25:49 2023 +0200

Middle-end _BitInt support [PR102989]

[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from sandra at gcc dot gnu.org ---
Should be fixed now.

[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Sandra Loosemore :

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

commit r14-3791-gab4bdad49716eb1c60e22e0e617d5eb56b0bac6f
Author: Sandra Loosemore 
Date:   Thu Sep 7 16:12:20 2023 +

OpenMP: Fix ICE in fixup_blocks_walker [PR111274]

This ICE was caused by an invalid assumption that all BIND_EXPRs have
a non-null BIND_EXPR_BLOCK.  In C++ these do exist and are used for
temporaries introduced in expressions that are not full-expressions.
Since they have no block to fix up, the traversal can just ignore
these tree nodes.

gcc/cp/ChangeLog
PR c++/111274
* parser.cc (fixup_blocks_walker): Check for null BIND_EXPR_BLOCK.

gcc/testsuite/ChangeLog
PR c++/111274
* g++.dg/gomp/pr111274.C: New test case.

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #18 from Iain Sandoe  ---
for changes to libstdc++ or the FE I usually run "make check-c++" which does
the library (plus the libgomp and itm deps) and the FE.

My guess is that the FE is referencing something that needs to have an inline
namespace added.

There are also some failing coroutine tests (because their scan strings need to
account for the inline namespace - I have a WIP patch for that, it's just
tedious editing of pattern matches).

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #17 from François Dumont  ---
(In reply to Iain Sandoe from comment #15)
> 
> many of the c++ fails are of this form:
> 
> contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to
> `handle_contract_violation(std::experimental::contract_violation const&)'

I'm surprised that my patch can have an impact on the C++ front end but I'll
give it a try. Did you first run those without my patches ?

I've never run the C++ tests. They can be run without a proper libstdc++ build,
no ?

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #16 from Iain Sandoe  ---
(In reply to François Dumont from comment #14)
> Good news then.
> 
> On my side I only had some failures due to a faulty friend declaration in
> gnu-versioned-namespace mode in  for which I've submitted a patch:
> https://gcc.gnu.org/pipermail/libstdc++/2023-August/056560.html

Ah so probably that covers most of the libstdc++ cases - they do seem to be
format-related.

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #15 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Iain Sandoe from comment #12)
> > (In reply to Iain Sandoe from comment #11)
> > > (In reply to François Dumont from comment #10)
> > > > This is because you are facing the PR65762 issue. I just attached a path
> > > > proposal to it that you need to apply too to be able to run your test.
> > > > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I 
> > > > made
> > > > cxx11 abi the default in this case.

> It looks like this was a merge artefact, which I resolved and now it builds
> - I have some testsuite fails to examine.

With both patches applied (on top of trunk from yesterday) on both Linux and
Darwin I am seeing regressions in the C++ and libstdc++ test suites.  For the
darwin case, I could perhaps have another merge error - but the Linux case has
only your two patches and configured with
--enable-symvers=gnu-versioned-namespace (only).

---

many of the libstdc++ fails are of this form:

/home/iains/gcc-master/bld-patched/x86_64-pc-linux-gnu/32/libstdc++-v3/include/format:3519:
error: 'std::__format::_Arg_store<_Context, _Args>::_Arg_store(_Tp& ...) [with
_Tp = {const std::chrono::time_point > >}; _Context =
std::basic_format_context, char>; _Args =
{std::basic_format_arg,
char> >::handle}]' is private within this context

many of the c++ fails are of this form:

contracts-tmpl-spec1.C:(.text+0x6f): undefined reference to
`handle_contract_violation(std::experimental::contract_violation const&)'

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

--- Comment #14 from François Dumont  ---
Good news then.

On my side I only had some failures due to a faulty friend declaration in
gnu-versioned-namespace mode in  for which I've submitted a patch:
https://gcc.gnu.org/pipermail/libstdc++/2023-August/056560.html

[Bug c++/111274] ice in fixup_blocks_walker with -O1 and -fopenmp

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

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

--- Comment #12 from sandra at gcc dot gnu.org ---
Improved and tested patch posted here:

https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629616.html

IIUC the temporaries introduced in non-full-expressions are bound in a block
that encloses the entire full-expression.  The restructuring that moves
intervening code into the loop body operates on whole statements, not
subexpressions, so I convinced myself there should be nothing to do here.

[Bug libgomp/111044] [OpenMP] Use additional kinds of libmemkind for allocators; make libgomp.texi doc more explicit

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

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

--- Comment #1 from Tobias Burnus  ---
Additionally: OpenMP states for omp_init_allocator:

"if an allocator based on the requirements cannot be created then the special
omp_null_allocator handle is returned."

libgomp's routine currently only returns omp_null_allocator if either an
invalid value has been used for the memory space / trait key / trait value - or
when pinned memory has been requested (as it is not yet implemented).

I think that's fine - but needs to be better documented. This applies to the
predefined allocators and to those created by OMP_ALLOCATOR,
omp_init_allocator, and by the 'using_allocators' directive (all using
internally omp_init_allocator).

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|13.2|13.3

--- Comment #23 from anlauf at gcc dot gnu.org ---
The fix was applied to 13-branch after the 13.2 release.
Updating target milestone appropriately.

[Bug fortran/111321] Segmentation fault with associate construct

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from anlauf at gcc dot gnu.org ---
Duplicate.

Fixed in 13.3.

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

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alexandre.poux at coria dot fr

--- Comment #22 from anlauf at gcc dot gnu.org ---
*** Bug 111321 has been marked as a duplicate of this bug. ***

[Bug c/111328] New: ICE: verify_flow_info failed since r14-3459-g0c78240fd7d

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

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

Bug ID: 111328
   Summary: ICE: verify_flow_info failed since
r14-3459-g0c78240fd7d
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: jh at suse dot cz
  Target Milestone: ---

gcc at -O3 crashes on the following testcase.

Bisected to r14-3459-g0c78240fd7d

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


$ cat a.c
int a, b, c, d;
short e;
int f(g, h) { return h == 0 || g == 83647 && h == 1 ?: g / h; }
char *i(char *g) {
  if (a)
do
  if (*g++ == 0)
return 0;
while (a);
  return g;
}
int j() {
  char k = 0, l = *i() = l;
  for (; b; b++) {
c = 1;
for (; d + c >= 0; c--)
  ;
  }
  for (;;)
if (f(e))
  break;
}
int main() {}
$ gcc -O2 a.c
: In function 'f':
:3:5: warning: type of 'g' defaults to 'int' [-Wimplicit-int]
3 | int f(g, h) { return h == 0 || g == 83647 && h == 1 ?: g / h; }
  | ^
:3:5: warning: type of 'h' defaults to 'int' [-Wimplicit-int]
: In function 'j':
:12:5: error: count of bb 32 not initialized
   12 | int j() {
  | ^
:12:5: error: count of bb 33 not initialized
:12:5: error: count of bb 34 not initialized
:12:5: error: count of bb 35 not initialized
:12:5: error: count of bb 37 not initialized
during GIMPLE pass: vect
:12:5: internal compiler error: verify_flow_info failed
0x21d80ae internal_error(char const*, ...)
???:0
0xb8c64f verify_flow_info()
???:0
0x112933f cleanup_tree_cfg(unsigned int)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1
$

[Bug target/111263] test case gfortran.dg/ieee/comparisons_3.F90 fails

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
No, that is not failing.

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from Wilco  ---
This is really a user error, not a compiler issue. Just write it like:

struct Storage {
std::atomic fp1;
float padding;
std::atomic fp2;
} storage;

This ensures the correct alignment required for atomic accesses of fp1/fp2.

[Bug target/95751] [aarch64] Consider using ldapr for __atomic_load_n(acquire) on ARMv8.3-RCPC

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |13.0

--- Comment #2 from Wilco  ---
Fixed in GCC13.

[Bug target/111225] ICE in curr_insn_transform, unable to generate reloads for xor, since r14-2447-g13c556d6ae84be

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r14-3783-gf7bca44d97ad01b39f9d6e7809df7bf517eeb2fb
Author: Vladimir N. Makarov 
Date:   Thu Sep 7 09:59:10 2023 -0400

[LRA]: Don't reuse chosen insn alternative with special memory constraint

To speed up GCC, LRA reuses chosen alternative from previous
constraint subpass.  A spilled pseudo is considered ok for any memory
constraint although stack slot assigned to the pseudo later might not
satisfy the chosen alternative constraint.  As we don't consider all insn
alternatives on the subsequent LRA sub-passes, it might result in LRA
failure
to generate the correct insn.  This patch solves the problem.

gcc/ChangeLog:

PR target/111225
* lra-constraints.cc (goal_reuse_alt_p): New global flag.
(process_alt_operands): Set up the flag.  Clear flag for chosen
alternative with special memory constraints.
(process_alt_operands): Set up used insn alternative depending on
the flag.

gcc/testsuite/ChangeLog:

PR target/111225
* gcc.target/i386/pr111225.c: New test.

[Bug tree-optimization/111326] [14 Regression] Dead Code Elimination Regression since r14-376-g47a76439911

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug libstdc++/111327] New: std::bind_front doesn't perfectly forward according to value category of the call wrapper object

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

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

Bug ID: 111327
   Summary: std::bind_front doesn't perfectly forward according to
value category of the call wrapper object
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

Testcase:

#include 

struct F {
  void operator()() & = delete; // #1
  void operator()() const &;// #2
};

int main() {
  auto f = F{};
  auto g = std::bind_front(F{});
  f(); // error: use of deleted function
  g(); // incorrectly calls #2 instead of being ill-formed
}

Since f isn't invocable as a non-const lvalue, g shouldn't be either.

[Bug fortran/111321] Segmentation fault with associate construct

[kopper at iag dot uni-stuttgart.de via Gcc-bugs]

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

Patrick Kopper  changed:

   What|Removed |Added

 CC||kopper at iag dot 
uni-stuttgart.de

--- Comment #2 from Patrick Kopper  ---
Can reproduce both with the program by Alexandre and our own code base. Tested
with gfortran 13.1.1 (Arch), 13.2.1 (Arch) and 13.2.0 (Homebrew). gfortran
12.2.1 (Arch) confirmed to compile without error or warnings.

```
#> gfortran bug.f90
f951: internal compiler error: Segmentation fault: 11
#> gfortran --version
GNU Fortran (Homebrew GCC 13.2.0) 13.2.0
```

[Bug c++/107800] confusing message with to_address in C++17

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

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

--- Comment #5 from Jonathan Wakely  ---
What is not working?

[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors

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

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

--- Comment #4 from Jonathan Wakely  ---
The new bind_back call wrapper still needs to be added (which will need to be
done before https://wg21.link/p2714r1 can be implemented for C++26).

[Bug tree-optimization/111326] New: [14 Regression] Dead Code Elimination Regression since r14-376-g47a76439911

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

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

Bug ID: 111326
   Summary: [14 Regression] Dead Code Elimination Regression since
r14-376-g47a76439911
   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/fv3szWMTE

Given the following code:

void foo(void);
static int a = 253, d, e, f, h, i, k;
static char j, m;
static short l, n;
static char(o)(char b, char c) { return b + c; }
void(p)(int);
short(q)(short);
static short(r)(int g) {
if (!(((g) >= 253) && ((g) <= 253))) {
__builtin_unreachable();
}
return 0;
}
static void s(char ab, short) {
int ac;
ab = 27;
for (; ab > 13; ab = ab - 9) {
j |= 10 | ac;
e = 0;
if (o(ab ^ a, d)) {
--l;
f = 0;
if (a)
;
else {
p(i);
k ^= q(0);
}
i = 5;
} else {
ac = 0;
for (; ac <= 38; ac = ac + 5) foo();
k = h &= 0 >= 0;
n = 0;
}
}
}
static unsigned t() {
s(m, a);
if (l)
;
else
r(3);
return f;
}
int main() {
d = a;
t();
r(a);
printf("", e, n);
}

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

main:
pushq   %rbp
movl$253, %edx
movl$27, %ebp
pushq   %rbx
subq$8, %rsp
movl$253, d(%rip)
.L5:
movl%ebp, %eax
orb $42, j(%rip)
movl$0, e(%rip)
xorl$-3, %eax
addb%dl, %al
je  .L6
subw$1, l(%rip)
movl$0, f(%rip)
movl$5, i(%rip)
.L3:
cmpb$18, %bpl
je  .L4
movld(%rip), %edx
movl$18, %ebp
jmp .L5
.p2align 4,,10
.p2align 3
.L4:
movswl  n(%rip), %edx
movle(%rip), %esi
movl$.LC0, %edi
xorl%eax, %eax
callprintf
addq$8, %rsp
xorl%eax, %eax
popq%rbx
popq%rbp
ret
.L6:
movl$8, %ebx
.L2:
callfoo
callfoo
subl$2, %ebx
jne .L2
movw$0, n(%rip)
movlh(%rip), %eax
andl$1, %eax
movl%eax, h(%rip)
movl%eax, k(%rip)
jmp .L3

gcc-13.2.0 -O3 eliminates the call to foo:

main:
subq$8, %rsp
movswl  n(%rip), %edx
xorl%esi, %esi
xorl%eax, %eax
movl$.LC0, %edi
orb $42, j(%rip)
subw$2, l(%rip)
movl$253, d(%rip)
movl$0, e(%rip)
movl$0, f(%rip)
movl$5, i(%rip)
callprintf
xorl%eax, %eax
addq$8, %rsp
ret

Bisects to r14-376-g47a76439911

[Bug libstdc++/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #3 from Xi Ruoyao  ---
Confirm the issue anyway, I saw it several times recently.

[Bug c++/107800] confusing message with to_address in C++17

[amatuladeeba at gmail dot com via Gcc-bugs]

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

Amatul Adeeba  changed:

   What|Removed |Added

 CC||amatuladeeba at gmail dot com

--- Comment #4 from Amatul Adeeba  ---
Tried the above typo mentioned, still not working.

[Bug libstdc++/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao  ---
(In reply to Rimvydas (RJ) from comment #0)
> The GCC configured with --enable-default-pie gives:
> 
> === libstdc++ tests ===
> 
> Running target unix
> FAIL: 19_diagnostics/stacktrace/entry.cc execution test
> FAIL: 19_diagnostics/stacktrace/stacktrace.cc execution test
> 
> libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc:39: void
> test_members(): Assertion 'e1.source_line() == (__LINE__ - 5)' failed.
> libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc:132: void
> test_assign(): Assertion 's0.at(0).source_line() == (__LINE__ - 4)' failed.
> 
> In both cases source_line() methods return 0.
> 
> Also, the -fno-pie option cannot be used when linking these tescases:
> /usr/bin/ld: /tmp/ccv2BTff.o: relocation R_X86_64_32 against symbol
> `_ZNSt16stacktrace_entry14_S_err_handlerEPvPKci' can not be used when making
> a PIE object; recompile with -fPIE

You need to use both -no-pie and -fno-pie.  -fno-pie only tells the compiler
not to emit code for PIE, -no-pie tells the linker not to link the code for
PIE.

[Bug target/110277] RISC-V: ICE when build RVV intrinsic float reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.

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

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

Kito Cheng  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kito at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Kito Cheng  ---
Fixed on trunk

[Bug target/110299] RISC-V: ICE when build RVV intrinsic widen with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.

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

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

Kito Cheng  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kito at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Kito Cheng  ---
Fixed on trunk

[Bug target/111037] RISC-V: Invalid vsetvli fusion

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #3 from Kito Cheng  ---
Fixed

[Bug target/111074] RISC-V: segmentation fault during RTL pass: vsetvl

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

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

Kito Cheng  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||kito at gcc dot gnu.org

--- Comment #2 from Kito Cheng  ---
Fixed

[Bug libstdc++/111323] [RISC_V]with CFLAGS +=-std=gnu11 "unknown relocation type 57" observed during Insmod

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||xry111 at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Xi Ruoyao  ---
You are misusing the kernel building system:

1. The kernel building system explicitly specifies -std=gnu11 so you don't need
to add it.  You should be able to see it via "make KDIR=... V=1".

2. "hello-y := hello.o" introduces a circular dependency.

3. The kernel building system suggests to use ccflags-y += ..., not CFLAGS +=
...

Read https://www.kernel.org/doc/html/latest/kbuild/modules.html.

Not a GCC issue anyway.

[Bug target/110560] internal compiler error: in extract_constrain_insn_cached, at recog.cc:2704

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #3 from Kito Cheng  ---
Should fixed now

[Bug target/109773] RISC-V: ICE when build RVV Intrinsic in Both GCC 13 && GCC 14

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #3 from Kito Cheng  ---
Fixed on upstream for a while.

[Bug bootstrap/111325] New: config/acx.m4: _FOR_TARGET are not usable at top level

[pexu--- via Gcc-bugs]

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

Bug ID: 111325
   Summary: config/acx.m4: _FOR_TARGET are not usable at top
level
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Hi.

`_FOR_TARGET' environment variables are not usable if used at top level
configure when build == host and build != target.

The problem is that ACX_CHECK_INSTALLED_TARGET_TOOL first checks for . 
If cache variable `ac_cv_path_' (`VAR'=`_FOR_TARGET') is empty,
attempts to use AC_PATH_PROG(VAR, PROG, ...) (defined at
lib/autoconf/programs.m4).  Unfortunately, AC_PATH_PROG always sets `' to
cache variable `ac_cv_path_' (that we know is potentially empty), i.e.
`_FOR_TARGET'=`ac_cv_path__FOR_TARGET'.  If  is not found,
the (empty) cache variable is not touched, thus overwriting any user provided
`_FOR_TARGET' value.

Then, NCN_STRICT_CHECK_TARGET_TOOLS tries to look for . 
If `_FOR_TARGET' should be used ( is not available),
it comes up now empty due to earlier AC_PATH_PROG call.

Ultimately, `_FOR_TARGET' is set to a default value 
for any subsequent configure runs and the user provided value is not picked up.
 This very likely will not work, given user attempted to override this using
`_FOR_TARGET'.

config/acx.m4:
340: AC_DEFUN([ACX_CHECK_INSTALLED_TARGET_TOOL], [
... # NB: Omitted when build == host and build != target.
359: if test -z "$ac_cv_path_$1" && test -n "$gcc_cv_tool_dirs"; then
360:   AC_PATH_PROG([$1], [$2], [], [$gcc_cv_tool_dirs]) # NB:
$1=$ac_cv_path_$1 if $1 is not found from $gcc_cv_tool_dirs.
361: fi
362: if test -z "$ac_cv_path_$1" ; then
363:   NCN_STRICT_CHECK_TARGET_TOOLS([$1], [$2])
364: else
365:   $1=$ac_cv_path_$1
366: fi
367: ]) []dnl # ACX_CHECK_INSTALLED_TARGET_TOOL

[Bug go/111310] BITINT_TYPE unsupported in godump.cc

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

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

--- Comment #3 from Jakub Jelinek  ---
Note, there is no guarantee that _BitInt(32) or _BitInt(64) are
passed/returned/laid out exactly like int32_t or int64_t (ditto for 8 and 16
bits), but on the current single target which supports them it is so far the
case.  _BitInt(128) has different alignment from __int128 though.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #111 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:18c90eaa25363d34b5bef444fbbad04f5da2522d

commit r14-3774-g18c90eaa25363d34b5bef444fbbad04f5da2522d
Author: Jakub Jelinek 
Date:   Thu Sep 7 11:17:04 2023 +0200

middle-end: Avoid calling targetm.c.bitint_type_info inside of gcc_assert
[PR102989]

On Thu, Sep 07, 2023 at 10:36:02AM +0200, Thomas Schwinge wrote:
> Minor comment/question: are we doing away with the property that
> 'assert'-like "calls" must not have side effects?  Per 'gcc/system.h',
> this is "OK" for 'gcc_assert' for '#if ENABLE_ASSERT_CHECKING' or
> '#elif (GCC_VERSION >= 4005)' -- that is, GCC 4.5, which is always-true,
> thus the "offending" '#else' is never active.  However, it's different
> for standard 'assert' and 'gcc_checking_assert', so I'm not sure if
> that's a good property for 'gcc_assert' only?  For example, see also
>  "warn about asserts with side effects", or
> recent 
> "RFE: could -fanalyzer warn about assertions that have side effects?".

You're right, the
  #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
fallback definition is incompatible with the way I've used it, so for
--disable-checking built by non-GCC it would not work properly.

2023-09-07  Jakub Jelinek  

PR c/102989
* expr.cc (expand_expr_real_1): Don't call
targetm.c.bitint_type_info
inside gcc_assert, as later code relies on it filling info
variable.
* gimple-fold.cc (clear_padding_bitint_needs_padding_p,
clear_padding_type): Likewise.
* varasm.cc (output_constant): Likewise.
* fold-const.cc (native_encode_int, native_interpret_int):
Likewise.
* stor-layout.cc (finish_bitfield_representative, layout_type):
Likewise.
* gimple-lower-bitint.cc (bitint_precision_kind): Likewise.

[Bug libgcc/111322] non-canonical reference to canonical protected function `__pthread_key_create'

[wbx at openadk dot org via Gcc-bugs]

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

Waldemar Brodkorb  changed:

   What|Removed |Added

 CC||wbx at openadk dot org

--- Comment #3 from Waldemar Brodkorb  ---
uClibc is doing this nearly since the beginning (commit
f91e94f6c5a1f1d6dfd3e5a535df303b805bf321 in 2001). I think normally this is
okay, because uClibc tries to be compatible to glibc. There are cornercases
like this issue. I think the patch is useful and should be applied.

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

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

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

--- Comment #1 from Jiu Fu Guo  ---
In match.pd, there is a pattern:

/* Simplify (t * 2) / 2) -> t.  */
(for div (trunc_div ceil_div floor_div round_div exact_div)
 (simplify
  (div (mult:c @0 @1) @1)
  (if (ANY_INTEGRAL_TYPE_P (type))
   (if (TYPE_OVERFLOW_UNDEFINED (type))
@0
#if GIMPLE
(with
 {
   bool overflowed = true;
   value_range vr0, vr1;
   if (INTEGRAL_TYPE_P (type)
   && get_global_range_query ()->range_of_expr (vr0, @0)
   && get_global_range_query ()->range_of_expr (vr1, @1)
   && !vr0.varying_p () && !vr0.undefined_p ()
   && !vr1.varying_p () && !vr1.undefined_p ())
 {

Here, "get_global_range_query" is able to get the value-range info for SSA.
But it does not handle the case t.c. "get_range_query" can handle it.

[Bug middle-end/111324] New: More optimization about "(X * Y) / Y"

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

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

Bug ID: 111324
   Summary: More optimization about "(X * Y) / Y"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

For case:
-- t.c
typedef unsigned int INT;

INT
foo (INT x, INT y)
{
  if (x > 100 || y > 100)
return 0;
  return (x * y) / y;
}
-
gcc -O2 t.c -S -fdump-tree-optimized

   [local count: 467721933]:
  _1 = x_3(D) * y_4(D);
  _5 = _1 / y_4(D);

   [local count: 1073741824]:
  # _2 = PHI <0(2), _5(4), 0(3)>
  return _2;

While for the below case, it can be optimized.

--
typedef unsigned int INT;

INT
foo (INT x, INT y)
{
  if (x > 100 || y > 100)
return 0;
  INT x1 = x + 1;
  INT y1 = y + 1;
  return (x1 * y1) / y1;
}
---

The "(x1 * y1) / y1" is optimized to "x1". 

   [local count: 467721933]:
  x1_4 = x_2(D) + 1;

   [local count: 1073741824]:
  # _1 = PHI <0(2), x1_4(4), 0(3)>
  return _1;

[Bug libstdc++/111323] New: [RISC_V] During Insmod "unknown relocation type 57" type in kernel space observed

[akhilesh.k at samsung dot com via Gcc-bugs]

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

Bug ID: 111323
   Summary: [RISC_V] During Insmod "unknown relocation type 57"
type in kernel space observed
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akhilesh.k at samsung dot com
  Target Milestone: ---

Hello 

with gcc 13.1 open source RISC-V Toolchain I observed "unknown relocation type
57" error message during insmod my kernel modules it seems this issue could
occurs in RISC-V when we  try to assemble or link a program, and the toolchain
encounters a relocation type that it doesn't recognize or support.

as per latest kernel 6.1 (which i am using code) doesn't support RELOC_NUMBER
(R_RISCV_32_PCREL, 57) . 


Here is my sample driver makefile 
=
CFLAGS +=-std=gnu11 #with this option getting "unknown relocation type 57"
obj-m := hello.o
hello-y := hello.o
all:
make  -C ${KDIR} M=$(PWD) modules
clean:
make  -C ${KDIR} M=$(PWD) clean


My dummy drive hello.c 



#include 
#include 

int init_module(void)  { printk(KERN_INFO "Hello
world.\n"); return 0; }

void cleanup_module(void)  { printk(KERN_INFO "Goodbye
world.\n"); }
 MODULE_LICENSE("GPL");

==


Using -std=gnu11 with gcc 13 generates R_RISCV_SET6 relocation in eh_frame
section which is not generated without -std=gnu11 flag even with same compiler
optimisations:

My insmod logs 
=
/bin # insmod hello.ko 
[   11.807337] hello: loading out-of-tree module taints kernel.
[   11.809680] hello: Unknown relocation type 57
insmod: can't insert 'hello.ko': invalid parameter

=




readelf output with -std=gnu11


Relocation section '.rela.eh_frame' at offset 0xb08 contains 10 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
001c  001e0039 R_RISCV_32_PCREL   .L0  + 0
0020  001f0023 R_RISCV_ADD32 0022 .L0  + 0
0020  001e0027 R_RISCV_SUB32  .L0  + 0
0031  00200035 R_RISCV_SET6  001a .L0  + 0
0031  00210034 R_RISCV_SUB6  0008 .L0  + 0
0044  00220039 R_RISCV_32_PCREL  0022 .L0  + 0
0048  00230023 R_RISCV_ADD32 0042 .L0  + 0
0048  00220027 R_RISCV_SUB32 0022 .L0  + 0
0059  00240035 R_RISCV_SET6  003c .L0  + 0
0059  00250034 R_RISCV_SUB6  002a .L0  + 0

readelf output without -std=gnu11

Relocation section '.rela.text.unlikely' at offset 0x920 contains 6 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
0008  00190017 R_RISCV_PCREL_HI2  .LC0 + 0
000c  001a0018 R_RISCV_PCREL_LO1 0008 .L0  + 0
0010  00200013 R_RISCV_CALL_PLT   _printk + 0
002a  001b0017 R_RISCV_PCREL_HI2 0010 .LC1 + 0
002e  001c0018 R_RISCV_PCREL_LO1 002a .L0  + 0
0032  00200013 R_RISCV_CALL_PLT   _printk + 


As a workaround i have two options either remove -std=gnu11 and use default
standards (-std=gnu17) or use KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
-fno-unwind-tables option 

but my query is why such relocations are generated with -std=gnu11