[Bug testsuite/106682] Powerpc test gcc.target/powerpc/pr86731-fwrapv-longlong.c fails on power8, passes on power9/power10

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #4 from Kewen Lin  ---
*** Bug 101444 has been marked as a duplicate of this bug. ***

[Bug testsuite/101444] [12/13/14 regression] gcc.target/powerpc/pr86731-fwrapv-longlong.c fails after r12-2266

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #4 from Kewen Lin  ---
Dup.

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

[Bug target/113196] [14 Regression] Failure to use ushll{,2}

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug tree-optimization/113227] Maybe optimization (a>0) && (b>0) with or&<0

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

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

--- Comment #3 from Andrew Pinski  ---
Yes `(a > 0) & (b > 0)` is not the same as `(a|b) > 0`. I think we already
catch all of the related `(a CMP 0) &/| (b CMP 0)`; see PR 95731 for those.

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

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

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

--- Comment #7 from Andrew Pinski  ---
This seems like a reduced testcase, where is the original testcase from? Or is
it an automated code generator?

[Bug c++/104221] member functions defined in separate files of classes declared in module partitions won't compile

[nathanieloshead at gmail dot com via Gcc-bugs]

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nathanieloshead at gmail dot 
com

--- Comment #1 from Nathaniel Shead  ---
I think this is IFNDR; you cannot have more than one partition with the same
name. See https://eel.is/c++draft/module.unit#3:

> A module partition is a module unit whose module-declaration contains
> a module-partition. A named module shall not contain multiple module
> partitions with the same module-partition. All module partitions of a
> module that are module interface units shall be directly or indirectly
> exported by the primary module interface unit ([module.import]).
> No diagnostic is required for a violation of these rules.

And in particular, unlike a module implementation unit, a module partition does
not implicitly import anything; see https://eel.is/c++draft/module.unit#8 which
says:

> A module-declaration that contains neither an export-keyword nor a
> module-partition implicitly imports the primary module interface unit
> of the module as if by a module-import-declaration.

So this is working as specified. I don't think there'd be any good way of
improving the diagnostics for this either.

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

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

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

--- Comment #6 from Andrew Pinski  ---
What match is doing is correct, what reassoc is doing looks to be ok, but the
gimplifier just falls over on `SSA_NAME != 0`.

This fixes the ICE but I don't understand how the gimplifier was handling
SSA_NAME before if it ever was, the code mentioned here has not changed since
the tuples was merged in:
```
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 15b540646c2..0cbe159b383 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3304,6 +3304,9 @@ recalculate_side_effects (tree t)
   int len = TREE_OPERAND_LENGTH (t);
   int i;

+  if (code == SSA_NAME)
+return;
+
   switch (TREE_CODE_CLASS (code))
 {
 case tcc_expression:
@@ -18253,7 +18256,7 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
case SSA_NAME:
  /* Allow callbacks into the gimplifier during optimization.  */
  ret = GS_ALL_DONE;
- break;
+ goto dont_recalculate;

case OMP_PARALLEL:
  gimplify_omp_parallel (expr_p, pre_p);

```

[Bug target/113206] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

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

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

--- Comment #8 from JuzheZhong  ---
It seems that we still didn't locate the real problem of failed SPEC you ran.
Do you have any other ideas to locale the real problem ?

Li Pan didn't locate the problem neither.

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

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

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

--- Comment #5 from Andrew Pinski  ---
```
#6  0x00d4594f in force_gimple_operand_gsi (gsi=0x7fffd3c0,
expr=0x779fe6e0, simple_p=true, var=0x0, before=true, m=GSI_SAME_STMT) at
../../gcc/gimplify-me.cc:141
141   return force_gimple_operand_gsi_1 (gsi, expr,
(gdb) p expr
$1 = (tree) 0x779fe6e0
(gdb) p debug_tree(expr)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77822b28 precision:1 min  max >

arg:0 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x778225e8 precision:32 min  max

pointer_to_this >
visited var 
def_stmt k$0_17 = PHI <_23(4), 0(3)>
version:17
ptr-info 0x779ed390>
arg:1 
constant 0>
t.c:15:21 start: t.c:15:16 finish: t.c:15:24>
$2 = void
(gdb) p debug_generic_expr(expr)
k$0_17 != 0

```

Exactly what I had expected. and yes it is exposed by that ...

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Patrick O'Neill from comment #1)
>   int k[3];

It would better if we didn't depend on an uninitialized variable (I have a
patch against reassoc to not handle uninitialized/undef names) and initializing
k as:
```
int k[3]={0,0,0};
```

Still shows the issue ...

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

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

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

--- Comment #3 from Andrew Pinski  ---
(gdb) p debug_tree(*expr_p)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7741c5e8 precision:32 min  max

pointer_to_this >
visited var 
def_stmt k$0_17 = PHI <_24(4), k$0_28(D)(3)>
version:17
ptr-info 0x77343cc0>

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-04
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed, I am 99% sure this was exposed by
r14-6420-g85c5efcffed19ca6160eeecc2d4faebd9fee63aa 

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Testcase:
int a;
long b;
signed c;
short d;
short i;
void f() {
  int k[3];
  int *l = 
  d = 0;
  for (; c; c--) {
i = 0;
for (; i <= 9; i++) {
  b = 1;
  for (; b <= 4; b++)
k[0] = k[0] == 0;
  *l |= k[d];
}
  }
}

[Bug tree-optimization/113227] Maybe optimization (a>0) && (b>0) with or&<0

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

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

YunQiang Su  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from YunQiang Su  ---
It is not correct.

[Bug middle-end/113228] New: [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 113228
   Summary: [14 Regression] ICE: recalculate_side_effects, at
gimplify.cc:3347
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56987=edit
-freport-bug output

> /scratch/tc-testing/tc-jan-3-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -O3 red.c -o rv64gcv.out
during GIMPLE pass: reassoc
red.c: In function 'f':
red.c:15:21: internal compiler error: in recalculate_side_effects, at
gimplify.cc:3347
   15 | k[0] = k[0] == 0;
  |~^~~~
0x9ec97b recalculate_side_effects
../../../gcc/gcc/gimplify.cc:3347
0xf7c9ee gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../../gcc/gcc/gimplify.cc:18589
0xfa2791 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
../../../gcc/gcc/gimplify-me.cc:78
0xfa28f1 force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
../../../gcc/gcc/gimplify-me.cc:115
0xfa28f1 force_gimple_operand_gsi(gimple_stmt_iterator*, tree_node*, bool,
tree_node*, bool, gsi_iterator_update)
../../../gcc/gcc/gimplify-me.cc:141
0x14afa61 force_into_ssa_name
../../../gcc/gcc/tree-ssa-reassoc.cc:2765
0x14b4b28 update_range_test
../../../gcc/gcc/tree-ssa-reassoc.cc:2972
0x14c0b77 optimize_range_tests
../../../gcc/gcc/tree-ssa-reassoc.cc:4139
0x14c36b6 reassociate_bb
../../../gcc/gcc/tree-ssa-reassoc.cc:7100
0x14c38a8 reassociate_bb
../../../gcc/gcc/tree-ssa-reassoc.cc:7265
0x14c38a8 reassociate_bb
../../../gcc/gcc/tree-ssa-reassoc.cc:7265
0x14c38a8 reassociate_bb
../../../gcc/gcc/tree-ssa-reassoc.cc:7265
0x14c5ef3 do_reassoc
../../../gcc/gcc/tree-ssa-reassoc.cc:7377
0x14c5ef3 execute_reassoc
../../../gcc/gcc/tree-ssa-reassoc.cc:7466
0x14c5ef3 execute
../../../gcc/gcc/tree-ssa-reassoc.cc:7507
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.

Found on riscv but also shows up on x86/arm

Godbolt: https://godbolt.org/z/j4786cav7

[Bug tree-optimization/113227] Maybe optimization (a>0) && (b>0) with or&<0

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

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

--- Comment #1 from YunQiang Su  ---
Sorry for noise. This proposal is wrong.

[Bug target/113206] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #7 from Patrick O'Neill  ---
527 still fails on zvl128. I'll let the rest of spec run overnight and let you
know the status of 549 once it finishes.

[Bug tree-optimization/113227] New: Maybe optimization (a>0) && (b>0) with or&<0

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

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

Bug ID: 113227
   Summary: Maybe optimization (a>0) && (b>0) with or&<0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at gcc dot gnu.org
  Target Milestone: ---

_Bool f (int a, int b) {
return a > 0 && b > 0;
}


_Bool f (int a, int b)
{
  _Bool _1;
  _Bool _6;
  _Bool _7;

   [local count: 1073741824]:
  _6 = b_3(D) > 0;
  _7 = a_2(D) > 0;
  _1 = _6 & _7;
  return _1;

}


maybe we can do it like this?

_Bool f (int a, int b)
{
   int _1 = (a | b);
   return ((_1) > 0);
}

[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #9 from Jiang An  ---
(In reply to Peter Dimov from comment #3)
> I think that the compiler is correct; string literal address comparisons
> aren't constant expressions. Clang gives the same error:
> https://godbolt.org/z/xPWEf4z63.

This looks weird... It seems that `+"abc" == +"def"` is never unspecified (must
be false, but Clang rejects it in constant evaluation), while `"abcd" + 1 ==
+"bcd"` is unspecified.

It's unclear to me whether we can practically detect all kinds of
unspecifiedness in pointer comparision involving string literals.

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

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

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

--- Comment #24 from GCC Commits  ---
The master branch has been updated by YunQiang Su :

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

commit r14-6905-g65d4b32dee2508f5bcdd999a132332cd46cf8a4d
Author: YunQiang Su 
Date:   Sat Dec 30 00:17:52 2023 +0800

MIPS: Add pattern insqisi_extended and inshisi_extended

This match pattern allows combination (zero_extract:DI 8, 24, QI)
with an sign-extend to 32bit INS instruction on TARGET_64BIT.

For SI mode, if the sign-bit is modified by bitops, we will need a
sign-extend operation.  Since 32bit INS instruction can be sure that
result is sign-extended, and the QImode src register is safe for INS, too.

(insn 19 18 20 2 (set (zero_extract:DI (reg/v:DI 200 [ val ])
(const_int 8 [0x8])
(const_int 24 [0x18]))
(subreg:DI (reg:QI 205) 0)) "../xx.c":7:29 -1
 (nil))
(insn 20 19 23 2 (set (reg/v:DI 200 [ val ])
(sign_extend:DI (subreg:SI (reg/v:DI 200 [ val ]) 0)))
"../xx.c":7:29 -1
 (nil))

Combine try to merge them to:

(insn 20 19 23 2 (set (reg/v:DI 200 [ val ])
(sign_extend:DI (ior:SI (and:SI (subreg:SI (reg/v:DI 200 [ val ])
0)
(const_int 16777215 [0xff]))
(ashift:SI (subreg:SI (reg:QI 205 [ MEM[(const unsigned
char *)buf_8(D) + 3B] ]) 0)
(const_int 24 [0x18]) "../xx.c":7:29 18
{*insv_extended}
 (expr_list:REG_DEAD (reg:QI 205 [ MEM[(const unsigned char *)buf_8(D)
+ 3B] ])
(nil)))

And do similarly for 16/16 pair:
(insn 13 12 14 2 (set (zero_extract:DI (reg/v:DI 198 [ val ])
(const_int 16 [0x10])
(const_int 16 [0x10]))
(subreg:DI (reg:HI 201 [ MEM[(const short unsigned int *)buf_6(D) +
2B] ]) 0)) "xx.c":5:30 286 {*insvdi}
 (expr_list:REG_DEAD (reg:HI 201 [ MEM[(const short unsigned int
*)buf_6(D) + 2B] ])
(nil)))
(insn 14 13 17 2 (set (reg/v:DI 198 [ val ])
(sign_extend:DI (subreg:SI (reg/v:DI 198 [ val ]) 0))) "xx.c":5:30
241 {extendsidi2}
 (nil))
>
(insn 14 13 17 2 (set (reg/v:DI 198 [ val ])
(sign_extend:DI (ior:SI (ashift:SI (subreg:SI (reg:HI 201 [
MEM[(const short unsigned int *)buf_6(D) + 2B] ]) 0)
(const_int 16 [0x10]))
(zero_extend:SI (subreg:HI (reg/v:DI 198 [ val ]) 0)
"xx.c":5:30 284 {*inshisi_extended}
 (expr_list:REG_DEAD (reg:HI 201 [ MEM[(const short unsigned int
*)buf_6(D) + 2B] ])
(nil)))

Let's accept these patterns, and set the cost to 1 instruction.

gcc

PR rtl-optimization/104914
* config/mips/mips.md (insqisi_extended): New patterns.
(inshisi_extended): Ditto.

gcc/testsuite

* gcc.target/mips/pr104914.c: New test.

[Bug target/113010] [RISCV] sign-extension lost in comparison with constant embedded in comma-op expression

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #2 from Patrick O'Neill  ---
Andrew I don't think this is a duplicate of pr112758 (or at least it wasn't
resolved by the fix for pr112758).

I still see the behavior on r14-6902-g4a0a8dc1b88.

> /scratch/tc-testing/tc-jan-3-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -O2 -march=rv64gc red.c -o user-config.out   
> 
> QEMU_CPU=rv64,zbs=true timeout --verbose -k 0.1 1 
> /scratch/tc-testing/tc-jan-3-trunk/build-rv64gcv/bin/qemu-riscv64 
> user-config.out
> echo $?   
>  1

[Bug target/113209] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick O'Neill  ---
Confirmed resolved.

[Bug target/113206] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick O'Neill  ---
Confirmed fixed, thanks for the quick fix!
I've kicked off a spec run.

[Bug middle-end/29215] [4.3 Regression] extra store for memcpy

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

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

Bug 30271 Summary: -mstrict-align can add an store extra for struct argument 
passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

   What|Removed |Added

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

[Bug other/16996] [meta-bug] code size improvements

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

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

Bug 30271 Summary: -mstrict-align can add an store extra for struct argument 
passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

   What|Removed |Added

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

[Bug middle-end/101926] [meta-bug] struct/complex/other argument passing and return should be improved

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

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

Bug 30271 Summary: -mstrict-align can add an store extra for struct argument 
passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

   What|Removed |Added

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

[Bug target/30271] -mstrict-align can add an store extra for struct argument passing

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

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

--- Comment #15 from Jiu Fu Guo  ---
Fix was committed.

[Bug testsuite/113226] New: [14 Regression] testsuite/std/ranges/iota/max_size_type.cc fails for cris-elf after r14-6888-ga138b99646a555

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

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

Bug ID: 113226
   Summary: [14 Regression]
testsuite/std/ranges/iota/max_size_type.cc fails for
cris-elf after r14-6888-ga138b99646a555
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---

After r14-6888-ga138b99646a555, I see, for cris-elf (32-bit target, no 128bit):
FAIL: std/ranges/iota/max_size_type.cc  -std=gnu++20 execution test
FAIL: std/ranges/iota/max_size_type.cc  -std=gnu++26 execution test

And in the .log:

spawn cris-elf-run ./max_size_type.exe^
Inconsistency found: 1 0 -100 -100^
/x/gcc/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc:246: void
test02() [with bool signed_p = true; bool shorten_p = false]: Assertion '0'
failed.
program stopped with signal 6 (Aborted).
FAIL: std/ranges/iota/max_size_type.cc  -std=gnu++20 execution test

Changing all s/ok &=/VERIFY/ (plus adding one level of parentheses to one of
the lines) show:

/x/gcc/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc:217: void
test02() [with bool signed_p = true; bool shorten_p = false]: Assertion 'i*j ==
shorten_type(max_type(i)*j)' failed.
program stopped with signal 6 (Aborted).

Further instrumentation, adding among other lines:
```
  if (signed_p && ! shorten_p)
std::cerr << "j == " << int64_t(j) << std::endl;
  if (!(i*j == shorten_type(max_type(i)*j)))
{
  std::cerr << "i == " << int64_t(i) << ", j == " << j << ", i*j ==
" << int64_t(i*j) << ", max_type(i) == \
" << int64_t(max_type(i));
  std::cerr << ", max_type(i)*j == " << int64_t(max_type(i)*j) <<
std::endl;
}
''' 

shows that this is (see above for template parameters):
i == 1, j == -100, i*j == 4294967196, max_type(i) == 1, max_type(i)*j == -100

and that large number is as you might guess, (unsigned) -100.

Not sure if this is a bug in the testcase or elsewhere, but I'll start my
guessing with testsuite.

[Bug target/113206] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

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

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

--- Comment #5 from JuzheZhong  ---
Both PR113206 and PR113209 are the same root cause and I have fixed both of
them.

Could you try the latest upstream GCC test SPEC 527/549 again to see whether it
fixes the bugs in SPEC?

[Bug middle-end/101926] [meta-bug] struct/complex/other argument passing and return should be improved

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

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

Bug 112525 Summary: fail to eliminate unused store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525

   What|Removed |Added

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

[Bug rtl-optimization/112525] fail to eliminate unused store

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

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

--- Comment #8 from Jiu Fu Guo  ---
Fix committed.

[Bug target/113209] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-6902-g4a0a8dc1b88408222b88e10278017189f6144602
Author: Juzhe-Zhong 
Date:   Thu Jan 4 06:38:43 2024 +0800

RISC-V: Fix bug of earliest fusion for infinite loop[VSETVL PASS]

As PR113206 and PR113209, the bugs happens on the following situation:

li  a4,32
...
vsetvli zero,a4,e8,m8,ta,ma
...
slliw   a4,a3,24
sraiw   a4,a4,24
bge a3,a1,.L8
sb  a4,%lo(e)(a0)
vsetvli zero,a4,e8,m8,ta,ma  --> a4 is polluted value not the
expected "32".
...
.L7:
j   .L7 ---> infinite loop.

The root cause is that infinite loop confuse earliest computation and let
earliest fusion
happens on unexpected place.

Disable blocks that belong to infinite loop to fix this bug since applying
ealiest LCM fusion
on infinite loop seems quite complicated and we don't see any benefits.

Note that disabling earliest fusion on infinite loops doesn't hurt the
vsetvli performance,
instead, it does improve codegen of some cases.

Tested on both RV32 and RV64 no regression.

PR target/113206
PR target/113209

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (invalid_opt_bb_p): New function.
(pre_vsetvl::compute_lcm_local_properties): Disable earliest fusion
on
blocks belong to infinite loop.
(pre_vsetvl::emit_vsetvl): Remove fake edges.
* config/riscv/t-riscv: Add a new include file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/avl_single-23.c: Adapt test.
* gcc.target/riscv/rvv/vsetvl/vlmax_call-1.c: Robostify test.
* gcc.target/riscv/rvv/vsetvl/vlmax_call-2.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_call-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_conflict-5.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-1.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-2.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-4.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/pr113206-1.c: New test.
* gcc.target/riscv/rvv/autovec/pr113206-2.c: New test.
* gcc.target/riscv/rvv/autovec/pr113209.c: New test.

[Bug target/113206] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-6902-g4a0a8dc1b88408222b88e10278017189f6144602
Author: Juzhe-Zhong 
Date:   Thu Jan 4 06:38:43 2024 +0800

RISC-V: Fix bug of earliest fusion for infinite loop[VSETVL PASS]

As PR113206 and PR113209, the bugs happens on the following situation:

li  a4,32
...
vsetvli zero,a4,e8,m8,ta,ma
...
slliw   a4,a3,24
sraiw   a4,a4,24
bge a3,a1,.L8
sb  a4,%lo(e)(a0)
vsetvli zero,a4,e8,m8,ta,ma  --> a4 is polluted value not the
expected "32".
...
.L7:
j   .L7 ---> infinite loop.

The root cause is that infinite loop confuse earliest computation and let
earliest fusion
happens on unexpected place.

Disable blocks that belong to infinite loop to fix this bug since applying
ealiest LCM fusion
on infinite loop seems quite complicated and we don't see any benefits.

Note that disabling earliest fusion on infinite loops doesn't hurt the
vsetvli performance,
instead, it does improve codegen of some cases.

Tested on both RV32 and RV64 no regression.

PR target/113206
PR target/113209

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (invalid_opt_bb_p): New function.
(pre_vsetvl::compute_lcm_local_properties): Disable earliest fusion
on
blocks belong to infinite loop.
(pre_vsetvl::emit_vsetvl): Remove fake edges.
* config/riscv/t-riscv: Add a new include file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/avl_single-23.c: Adapt test.
* gcc.target/riscv/rvv/vsetvl/vlmax_call-1.c: Robostify test.
* gcc.target/riscv/rvv/vsetvl/vlmax_call-2.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_call-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_conflict-5.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-1.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-2.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-4.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/pr113206-1.c: New test.
* gcc.target/riscv/rvv/autovec/pr113206-2.c: New test.
* gcc.target/riscv/rvv/autovec/pr113209.c: New test.

[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86521

--- Comment #10 from Patrick Palka  ---
N.B. the comment #4 testcase is similar to the one from PR86521, and I based
the above analysis off of that PR..

[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #9 from Patrick Palka  ---
The original testcase should be fixed for GCC 14 after r14-6899.

[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #8 from Patrick Palka  ---
(In reply to m.cencora from comment #4)
> This also might be a just another symptom of the same root cause:
> 
> struct bar
> {
> bar() = default;
> 
> bar(const bar&);
> bar(bar&&);
> 
> bar& operator=(const bar&);
> bar& operator=(bar&&);
> };
> 
> struct foo
> {
> operator const bar& () const &;
> 
> operator bar& () &;
> 
> operator bar&&() &&;
> };
> 
> void test()
> {
> bar a = foo{}; // ok

It seems this copy-init is valid according to
http://eel.is/c++draft/dcl.init#general-16.6.3 -- we first choose the best
conversion function according to the destination type bar (and independent of
bar's constructors) which in this case is operator bar&&() &&, and then perform
overload resolution of bar's constructors using the result of that conversion
function as the argument, which leads to bar(bar&&) unambiguously winning.

> 
> a = foo{}; // not ok - ambiguous call, but why? &&-qualified looks like
> a better match

Whereas here, we perform the expected overload resolution of bar's constructor
set using the original argument, which gives two viable candidates

  bar(const bar&) through operator const bar&() const&
  bar(bar&&) through operator bar&&() &&

and user-defined conversion sequences that use different conversion functions
are incomparable, so the candidates are ambiguous.

> 
> foo f;
> a = f; // ok
> 
> a = static_cast(foo{}); // ok
> }

[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int

[admin--- via Gcc-bugs]

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

--- Comment #5 from Thorsten Otto  ---
I don't mind. If your patch also contains a test case, just use that.

[Bug libfortran/113223] NAMELIST internal write missing leading blank character

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

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

--- Comment #2 from Jerry DeLisle  ---
(In reply to kargl from comment #1)
> Jerry can you take a look at this issue.

Will do. Minor tweak I hope.

[Bug c++/113219] Overloaded ref-qualified conversion operator triggers bogus -Wconversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This is documented this way too:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Warning-Options.html#index-Wconversion
```
For C++, also warn for confusing overload resolution for user-defined
conversions; and conversions that never use a type conversion operator:
conversions to void, the same type, a base class or a reference to them.
Warnings about conversions between signed and unsigned integers are disabled by
default in C++ unless -Wsign-conversion is explicitly enabled.

```


Don't use -Wconversion if you don't wan this warning ...

Note this warning was originally not part of -Wconversion but always on (in GCC
2.95.3) and then in GCC 3.4.0 was moved to part of -Wconversion; this was PR
10784 was about even.

[Bug libfortran/113223] NAMELIST internal write missing leading blank character

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Jerry can you take a look at this issue.

[Bug sanitizer/113214] false-positive -Wstringop-overflow warning with thread sanitizer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||88443

--- Comment #1 from Andrew Pinski  ---
Note the GCC manual does say:
```
Note that sanitizers tend to increase the rate of false positive warnings, most
notably those around -Wmaybe-uninitialized. We recommend against combining
-Werror and [the use of] sanitizers.
```

So I suspect this should be closed as won't fix ...


Referenced Bugs:

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

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/113218] gcc -pg fails on contemporary FreeBSD

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-03
 Status|UNCONFIRMED |NEW

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

[Bug target/113218] gcc -pg fails on contemporary FreeBSD

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

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

--- Comment #1 from Andrew Pinski  ---
Basically FBSD_LIB_SPEC in gcc/config/freebsd-spec.h should be modified to
`%{pg:` related parts. But only do that for FBSD_MAJOR >= 14 ...

[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Sergey Fedorov from comment #6)
> > I am getting a similar-looking error with gcc-13.2.0 now:
> > https://github.com/NGSolve/ngsolve/issues/68
> 
> Both clang and GCC reject the original testcase still 
> So I doubt this is the same issue ...

Also the testcase in comment #2 works with GCC 13.2.0 while fails with GCC
13.1.0 ...

[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Sergey Fedorov from comment #6)
> I am getting a similar-looking error with gcc-13.2.0 now:
> https://github.com/NGSolve/ngsolve/issues/68

Both clang and GCC reject the original testcase still 
So I doubt this is the same issue ...

[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous

[vital.had at gmail dot com via Gcc-bugs]

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

Sergey Fedorov  changed:

   What|Removed |Added

 CC||vital.had at gmail dot com

--- Comment #6 from Sergey Fedorov  ---
Has this ever been addressed?

I am getting a similar-looking error with gcc-13.2.0 now:
https://github.com/NGSolve/ngsolve/issues/68

[Bug target/113225] New: bpf: attributekernel_helper function declarations create a BTF_FUNC_EXTERN.

[cupertino.miranda at oracle dot com via Gcc-bugs]

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

Bug ID: 113225
   Summary: bpf: attributekernel_helper function declarations
create a BTF_FUNC_EXTERN.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cupertino.miranda at oracle dot com
  Target Milestone: ---

When using attribute kernel_helper such as the one in the example:

extern int foo (int arg) __attribute__((kernel_helper (666)));

int bar ()
{
  return foo (20);
}

The following BTF entries are created: 

[1] int 'int'(1U#B) size=4U#B offset=0UB#b bits=32UB#b SIGNED 
[2] func_proto  type=1
 param '' type=1
[3] func_proto  type=1
[4] func 'foo'(5U#B) type=2 linkage=0 (extern)
[5] func 'bar'(9U#B) type=3 linkage=1 (global)

BTF information is generated for the extern function declaration, imposing some
problem to tools such as bpftool that relies on BTF information to validate
completeness of the BTF information.
Since kernel helpers are not true functions the BTF information created,
although accurate with how the function is declared, it is not accurate with
its semantics.

Plan resolution is to skip btf output to any attributed kernel_helper function
declaration, since the BTF information in this case is not really required.

[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-6899-g1c522c9eafa5b86b78cd7b3044e120762fb4c879
Author: Patrick Palka 
Date:   Wed Jan 3 15:43:28 2024 -0500

c++: bad direct reference binding via conv fn [PR113064]

When computing a direct reference binding via a conversion function
yields a bad conversion, reference_binding incorrectly commits to that
conversion instead of trying a conversion via a temporary.  This causes
us to reject the first testcase because the bad direct conversion to B&&
via the && conversion operator prevents us from considering the good
conversion via the & conversion operator and a temporary.  (Similar
story for the second testcase.)

This patch fixes this by making reference_binding not prematurely commit
to such a bad direct conversion.  We still fall back to it if using a
temporary also fails (otherwise the diagnostic for cpp0x/explicit7.C
regresses).

PR c++/113064

gcc/cp/ChangeLog:

* call.cc (reference_binding): Still try a conversion via a
temporary if a direct conversion was bad.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/rv-conv4.C: New test.
* g++.dg/cpp0x/rv-conv5.C: New test.

[Bug tree-optimization/113224] Warning "is used uninitialized" raised for an initialized variable

[gandalf at winds dot org via Gcc-bugs]

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

--- Comment #3 from gandalf at winds dot org ---
Thank you for the suggestion. I'll try the union.

[Bug tree-optimization/113224] Warning "is used uninitialized" raised for an initialized variable

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

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

--- Comment #2 from Andrew Pinski  ---
>In an attempt to convert a float value bytewise to an integer,

You should use memcpy instead (or an union which itself a GCC extension).

[Bug tree-optimization/113224] Warning "is used uninitialized" raised for an initialized variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
This code is undefined for violating C/C++ aliasing rules.
The warning is because of the undefinedness of the code.

[Bug tree-optimization/113224] New: Warning "is used uninitialized" raised for an initialized variable

[gandalf at winds dot org via Gcc-bugs]

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

Bug ID: 113224
   Summary: Warning "is used uninitialized" raised for an
initialized variable
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

In an attempt to convert a float value bytewise to an integer, this function
returns the following unexpected GCC warnings at optimization level -O2 and -O3
on x86_64:

unsigned int myfunc() {
  float _f=2.5;
  unsigned int *_x=(unsigned int *)&_f;
  return *_x;
}

gcc -O2 -Wall test12.c -c

test12.c: In function 'myfunc':
test12.c:4:10: warning: '_f' is used uninitialized
test12.c:2:9: note: '_f' declared here

It compiles correctly, at least. The warning goes away when
-fno-strict-aliasing is applied.

[Bug analyzer/113222] ICE with -fanalyzer seen on Linux kernel kernel/sched/core.c

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-03
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
I'm testing a fix

[Bug libfortran/113223] NAMELIST internal write missing leading blank character

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug libfortran/113223] New: NAMELIST internal write missing leading blank character

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

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

Bug ID: 113223
   Summary: NAMELIST internal write missing leading blank
character
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Found at https://github.com/llvm/llvm-project/issues/76798

Program test_namelist_blank
  Integer :: i,j
  Character(300) ::s
  Namelist /nml1/i,j

  i = 99
  j = 42
  Write (s,NML=nml1)
  Write (*,'("Internal ",A)') Merge('ok ','bug',s(1:1)==' ')
  Write (*,NML=nml1)
End Program test_namelist_blank

F2018
13.11.4.3 Namelist output records
...
Except for new records created by explicit formatting within a defined
output procedure or by continuation of delimited character sequences,
each output record begins with a blank character.

Patch

diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index f94e180ba33..a7cf5d9b233 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -2466,6 +2466,8 @@ namelist_write (st_parameter_dt *dtp)
dtp->u.p.nml_delim = '\0';
 }

+  if (is_internal_unit (dtp))
+write_character (dtp, " ", 1, 1, NODELIM);
   write_character (dtp, "&", 1, 1, NODELIM);

   /* Write namelist name in upper case - f95 std.  */

[Bug tree-optimization/19347] Invariant load not moved out of loop

[phosit at autistici dot org via Gcc-bugs]

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

--- Comment #10 from Phosit  ---
The analysis in my previous comment is wrong.
I don't know why there is no alias-check at -O2.
Also the loop _is_ removed at -O3.

[Bug tree-optimization/19347] Invariant load not moved out of loop

[phosit at autistici dot org via Gcc-bugs]

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

Phosit  changed:

   What|Removed |Added

 CC||phosit at autistici dot org

--- Comment #9 from Phosit  ---
When there are few iterations (likely when it is unroled) there is no
alias-check:

void fill(int* data, int& value)
{
for(unsigned long i{0}; i != 4; ++i)
data[i] = value;
}

--- at -O2 results in:
fill(int*, int&):
movdxmm1, DWORD PTR [rsi]
pshufd  xmm0, xmm1, 0xe0
movqQWORD PTR [rdi], xmm0
movdxmm0, DWORD PTR [rsi]
pshufd  xmm0, xmm0, 0xe0
movqQWORD PTR [rdi+8], xmm0
ret

---
At -O3 the loop isn't removed and (thus) there is an alias-check.

[Bug analyzer/113222] New: ICE with -fanalyzer seen on Linux kernel kernel/sched/core.c

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

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

Bug ID: 113222
   Summary: ICE with -fanalyzer seen on Linux kernel
kernel/sched/core.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
  Target Milestone: ---

Given:


struct sched_class
{
  int f;
};
extern struct sched_class __end_sched_classes[];

int
test ()
{
  const struct sched_class* class = ((__end_sched_classes - 1));
  return class->f;
}


trunk with -fanalyzer ICEs with:

/tmp/t.c: In function ‘test’:
/tmp/t.c:11:15: warning: buffer under-read [CWE-127] [-Wanalyzer-out-of-bounds]
   11 |   return class->f;
  |  ~^~~
  ‘test’: event 1
|
|   11 |   return class->f;
|  |  ~^~~
|  |   |
|  |   (1) out-of-bounds read from byte -4 till byte -1 but
‘__end_sched_classes’ starts at byte 0
|
during IPA pass: analyzer
/tmp/t.c:11:15: internal compiler error: Segmentation fault
   11 |   return class->f;
  |  ~^~~
0x10708aa crash_signal
../../src/gcc/toplev.cc:316
0x2299a65 tree_check6(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code, tree_code, tree_code)
../../src/gcc/tree.h:3726
0x2299a65 ana::valid_region_spatial_item::add_boundaries(ana::boundaries&,
ana::logger*) const
../../src/gcc/analyzer/access-diagram.cc:1337
0x229e2e0 ana::access_diagram_impl::find_boundaries() const
../../src/gcc/analyzer/access-diagram.cc:2197
0x229e2e0 ana::access_diagram_impl::access_diagram_impl(ana::access_operation
const&, diagnostic_event_id_t, text_art::style_manager&, text_art::theme
const&, ana::logger*)
../../src/gcc/analyzer/access-diagram.cc:2064
0x229283b std::enable_if::value,
std::unique_ptr > >::type
make_unique(ana::access_operation const&, diagnostic_event_id_t&,
text_art::style_manager&, text_art::theme const&, ana::logger*&)
../../src/gcc/make-unique.h:41
0x229283b ana::access_diagram::access_diagram(ana::access_operation const&,
diagnostic_event_id_t, text_art::style_manager&, text_art::theme const&,
ana::logger*)
../../src/gcc/analyzer/access-diagram.cc:2666
0x212b331 ana::out_of_bounds::make_access_diagram(ana::access_operation const&,
text_art::style_manager&, text_art::theme const&, ana::logger*) const
../../src/gcc/analyzer/bounds-checking.cc:208
0x212b331 ana::out_of_bounds::maybe_show_diagram(ana::logger*) const
../../src/gcc/analyzer/bounds-checking.cc:187
0x212b803
ana::concrete_buffer_under_read::emit(ana::diagnostic_emission_context&)
../../src/gcc/analyzer/bounds-checking.cc:806
0x214ff37 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic&)
../../src/gcc/analyzer/diagnostic-manager.cc:1617
0x2153ba6 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../src/gcc/analyzer/diagnostic-manager.cc:1472
0x215053f ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
../../src/gcc/analyzer/diagnostic-manager.cc:1524
0x1479be4 ana::impl_run_checkers(ana::logger*)
../../src/gcc/analyzer/engine.cc:6226
0x147ab56 ana::run_checkers()
../../src/gcc/analyzer/engine.cc:6300
0x146be6c execute
../../src/gcc/analyzer/analyzer-pass.cc:87
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.


Trunk:affected: https://godbolt.org/z/11axozEc1
GCC 13.2: not affected: https://godbolt.org/z/43sdrx9jf


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #2 from Andrew Pinski  ---
IRA decided to combine:
```
(insn 9 8 19 3 (set (reg/f:DI 104)
(lo_sum:DI (reg/f:DI 105)
(symbol_ref:DI ("bar") [flags 0x41]  ))) "t.c":5:10 discrim 1 -1
 (expr_list:REG_DEAD (reg/f:DI 105)
(expr_list:REG_EQUAL (symbol_ref:DI ("bar") [flags 0x41] 
)
(nil
...
(insn 21 20 11 3 (set (reg/f:DI 110)
(lo_sum:DI (reg/f:DI 109)
(symbol_ref:DI ("bar") [flags 0x41]  ))) "t.c":5:10 discrim 1 -1
 (expr_list:REG_DEAD (reg/f:DI 109)
(expr_list:REG_EQUAL (symbol_ref:DI ("bar") [flags 0x41] 
)
(nil
(insn 11 21 27 3 (parallel [
(set (reg:DI 106)
(plus:DI (reg:DI 106)
(const_int 4 [0x4])))
(set (mem:SI (reg:DI 106) [0  S4 A8])
(subreg:SI (reg/f:DI 104) 0))
(set (mem:SI (plus:DI (reg:DI 106)
(const_int 4 [0x4])) [0  S4 A8])
(subreg:SI (reg/f:DI 110) 0))
]) "t.c":5:10 discrim 1 102 {*storewb_post_pair_4}
 (nil))

```



to:
```
(insn 11 20 27 3 (parallel [
(set (reg:DI 106)
(plus:DI (reg:DI 106)
(const_int 4 [0x4])))
(set (mem:SI (reg:DI 106) [0  S4 A8])
(subreg:SI (lo_sum:DI (reg/f:DI 105)
(symbol_ref:DI ("bar") [flags 0x41]  )) 0))
(set (mem:SI (plus:DI (reg:DI 106)
(const_int 4 [0x4])) [0  S4 A8])
(subreg:SI (lo_sum:DI (reg/f:DI 109)
(symbol_ref:DI ("bar") [flags 0x41]  )) 0))
]) "t.c":5:10 discrim 1 102 {*storewb_post_pair_4}
 (expr_list:REG_DEAD (reg/f:DI 109)
(expr_list:REG_DEAD (reg/f:DI 105)
(nil

```

But I have no idea why though ...

[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, but the IR from the ldp_fusion pass looks ok:
```
(insn 30 29 15 3 (set (reg/f:DI 110)
(lo_sum:DI (reg/f:DI 109)
(symbol_ref:DI ("_Z3barv") [flags 0x41]  ))) "/app/example.cpp":5:10 discrim 1 -1
 (expr_list:REG_DEAD (reg/f:DI 109)
(expr_list:REG_EQUAL (symbol_ref:DI ("_Z3barv") [flags 0x41] 
)
(nil
(insn 15 30 32 3 (parallel [
(set (reg:DI 106)
(plus:DI (reg:DI 106)
(const_int 4 [0x4])))
(set (mem:SI (reg:DI 106) [0  S4 A8])
(subreg:SI (reg/f:DI 104) 0))
(set (mem:SI (plus:DI (reg:DI 106)
(const_int 4 [0x4])) [0  S4 A8])
(subreg:SI (reg/f:DI 110) 0))
]) "/app/example.cpp":5:10 discrim 1 102 {*storewb_post_pair_4}
 (nil))
```

[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug target/113221] New: [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113221
   Summary: [14 Regression][aarch64]ICE in extract_insn, at
recog.cc:2812 since r14-6605-gc0911c6b357ba9
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: acoplan at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Compiling reduced testcase gcc.dg/debug/pr43972.c results in ICE since
r14-6605-gc0911c6b357ba9.

$ cat pr43972.c
void bar();
void foo(int* b) {
  for (;;)
*b++ = (long)bar;
}


$ aarch64-linux-gnu-gcc pr43972.c -O1 -fno-move-loop-invariants
-funroll-all-loops
pr43972.c: In function ‘foo’:
pr43972.c:5:1: error: unrecognizable insn:
5 | }
  | ^
(insn 80 0 0 (set (reg:SI 130)
(subreg:SI (lo_sum:DI (reg/f:DI 105)
(symbol_ref:DI ("bar") [flags 0x41] )) 0)) -1
 (nil))
during RTL pass: reload
pr43972.c:5:1: internal compiler error: in extract_insn, at recog.cc:2812
0x16e9be0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x16e9c21 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:116
0x169a764 extract_insn(rtx_insn*)
/home/mjires/git/GCC/master/gcc/recog.cc:2812
0x147d140 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
/home/mjires/git/GCC/master/gcc/ira.cc:5381
0x14d574a remove_insn_scratches
/home/mjires/git/GCC/master/gcc/lra.cc:2154
0x14d112b lra_emit_move(rtx_def*, rtx_def*)
/home/mjires/git/GCC/master/gcc/lra.cc:513
0x14eb151 curr_insn_transform
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:4669
0x14ed78c lra_constraints(bool)
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:5414
0x14d6064 lra(_IO_FILE*, int)
/home/mjires/git/GCC/master/gcc/lra.cc:2442
0x147e4d3 do_reload
/home/mjires/git/GCC/master/gcc/ira.cc:5973
0x147e970 execute
/home/mjires/git/GCC/master/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240103 (experimental) (GCC)

[Bug tree-optimization/113201] [14 Regression] internal compiler error: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.cc:2058

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 56986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56986=edit
gcc14-pr113201.patch

So, do we want just avoid trying to propagate constants to rslt uses if it is
used in abnormal PHI like in this patch, or punt on doing final value
replacement in that case altogether?

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #34 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #32)
> > /tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437:
> > warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
> > writing between 2 and 9223372036854775806 bytes into a region of size 0
> > overflows the destination [-Wstringop-overflow=]
> 
> It warns on:
> 
>   template
> struct __copy_move<_IsMove, true, random_access_iterator_tag>
> {
>   template
> _GLIBCXX20_CONSTEXPR
> static _Up*
> __copy_m(_Tp* __first, _Tp* __last, _Up* __result)
> {
>   const ptrdiff_t _Num = __last - __first;
>   if (__builtin_expect(_Num > 1, true))
> __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
>   else if (_Num == 1)
> std::__copy_move<_IsMove, false, random_access_iterator_tag>::
>   __assign_one(__result, __first);
>   return __result + _Num;
> }
> };
> 
> It is likely false positive on a code path that never happens in real
> code, but we now optimize it better.
> 

We end up with:
   [local count: 64736968]:
  __builtin_memcpy (1B, v$_M_impl$D10203$_M_start_448, _354);

IIRC the statement variant is created by jump threading (specifically
thread2).

Moreover, if I understand the comment in compute_objsize_r about the
INTEGER_CST case correctly, small integers are considered potential
"result of erroneous null pointer addition/subtraction."  So not
warning on a constant 1 destination does not seem to be desirable.

[Bug target/113217] [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Most likely we should only handle stores instructions which cannot throw,
> insn_nothrow_p .

s/stores/stores and loads/ really.

[Bug target/113217] [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #2 from Andrew Pinski  ---
From:
```
(insn 7 2 8 2 (set (mem:SI (reg/f:DI 103 [ this ]) [1 MEM[(struct vector
*)this_4(D)].D.4476._M_end_of_storage+0 S4 A32])
(const_int 0 [0])) "/app/example.cpp":6:27 69 {*movsi_aarch64}
 (nil))
(debug_insn 8 7 11 2 (debug_marker:BLK) "/app/example.cpp":6:3 -1
 (nil))
(insn 11 8 42 2 (set (mem:SI (plus:DI (reg/f:DI 103 [ this ])
(const_int 4 [0x4])) [1 MEM[(struct vector *)this_4(D) +
4B].D.4476._M_end_of_storage+0 S4 A32])
(const_int 0 [0])) "/app/example.cpp":6:27 69 {*movsi_aarch64}
 (expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
```

To:
```
(insn 7 2 8 2 (set (mem:V2x4QI (reg/f:DI 103 [ this ]) [0 +0 S8 A32])
(unspec:V2x4QI [
(const_int 0 [0]) repeated x2
] UNSPEC_STP)) "/app/example.cpp":6:27 90 {*store_pair_4}
 (expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
(debug_insn 8 7 42 2 (debug_marker:BLK) "/app/example.cpp":6:3 -1
 (nil))
(note 42 8 44 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
```

Most likely we should only handle stores instructions which cannot throw,
insn_nothrow_p .

[Bug target/113217] [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

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

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

Alex Coplan  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-03
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Alex Coplan  ---
Confirmed, mine (but I'm looking at PR113070 first).

[Bug target/113217] [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug target/113220] [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133

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

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

Richard Sandiford  changed:

   What|Removed |Added

 CC|richard.sandiford at arm dot com   |rsandifo at gcc dot 
gnu.org
   Last reconfirmed||2024-01-03
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Sandiford  ---
Mine

[Bug target/113220] New: [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113220
   Summary: [aarch64] ICE Segmentation fault with
r14-6178-g8d29b7aca15133
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: richard.sandiford at arm dot com
  Target Milestone: ---
Target: aarch64

Compiling reduced testcase gcc.target/aarch64/sme/zt0_state_5.c results in ICE
with r14-6178-g8d29b7aca15133.

$ cat zt0_state_5.c
#pragma GCC target "+sme2"
void inout_zt0() __arm_inout("zt0") {
  int ptr;
  ptr += 1;
}


$ aarch64-linux-gnu-gcc zt0_state_5.c -ftrapv -fstack-clash-protection
during RTL pass: mode_sw
zt0_state_5.c: In function ‘inout_zt0’:
zt0_state_5.c:5:1: internal compiler error: Segmentation fault
5 | }
  | ^
0x1787d3a crash_signal
/home/mjires/git/GCC/master/gcc/toplev.cc:316
0x16f07c8 rtx_properties::try_to_add_pattern(rtx_def const*)
/home/mjires/git/GCC/master/gcc/rtlanal.cc:2246
0x16f0d4b rtx_properties::try_to_add_insn(rtx_insn const*, bool)
/home/mjires/git/GCC/master/gcc/rtlanal.cc:2356
0x1c83f7b growing_rtx_properties::add_insn(rtx_insn
const*, bool)::{lambda()#1}::operator()() const
/home/mjires/git/GCC/master/gcc/rtlanal.h:288
0x1c866a2 void
growing_rtx_properties::repeat::add_insn(rtx_insn
const*,
bool)::{lambda()#1}>(growing_rtx_properties::add_insn(rtx_insn
const*, bool)::{lambda()#1})
/home/mjires/git/GCC/master/gcc/rtlanal.h:246
0x1c83fda growing_rtx_properties::add_insn(rtx_insn
const*, bool)
/home/mjires/git/GCC/master/gcc/rtlanal.h:288
0x1c79afe aarch64_mode_emit
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64.cc:29400
0x2b318d1 optimize_mode_switching
/home/mjires/git/GCC/master/gcc/mode-switching.cc:1210
0x2b31b7a execute
/home/mjires/git/GCC/master/gcc/mode-switching.cc:1309
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240103 (experimental) (GCC)

[Bug c++/113219] New: Overloaded ref-qualified conversion operator triggers bogus -Wconversion

[m.cencora at gmail dot com via Gcc-bugs]

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

Bug ID: 113219
   Summary: Overloaded ref-qualified conversion operator triggers
bogus -Wconversion
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Following code when compiled on any gcc version (checked all available on
godbolt since gcc-7) triggers conversion warnings.
I consider it bogus because it tells user that it has chosen a better overload
(which is good thing, right?).
Clang doesn't print any related warning even with -Weverything

g++ -std=c++17 -Wconversion

template 
struct wrapper
{
operator T() const&;

operator T&&() &&;
};

wrapper createInt();

int test()
{
return createInt();
}

Output is:
:13:21: warning: choosing 'wrapper::operator T&&() && [with T =
int]' over 'wrapper::operator T() const & [with T = int]' [-Wconversion]
   13 | return createInt();
  |~^~
:13:21: warning:   for conversion from 'wrapper' to 'int'
[-Wconversion]
:13:21: note:   because conversion sequence for the argument is better

[Bug driver/113218] New: gcc -pg fails on contemporary FreeBSD

[emaste at freebsd dot org via Gcc-bugs]

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

Bug ID: 113218
   Summary: gcc -pg fails on contemporary FreeBSD
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emaste at freebsd dot org
  Target Milestone: ---

FreeBSD retired _p profiled libraries in FreeBSD 14.0, so GCC specs need to be
updated.

Demonstrated below using the default FreeBSD devel/gcc port, but looking at gcc
git I don't see any change.

FreeBSD version:

root@14:~ # uname -a
FreeBSD 14 14.0-RELEASE FreeBSD 14.0-RELEASE #0
releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

GCC:

root@14:~ # gcc --version
gcc (FreeBSD Ports Collection) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Failure:

root@14:~ # gcc -pg hello.c
/usr/local/bin/ld: cannot find -lc_p: No such file or directory

Invocation, from gcc -v:

collect2: error: ld returned 1 exit status
 /usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/collect2
-plugin
/usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/liblto_plugin.so
-plugin-opt=/usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp//ccGg5YU1.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc_p
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr -m elf_x86_64_fbsd -V -dynamic-linker /libexec/ld-elf.so.1
/usr/lib/gcrt1.o /usr/lib/crti.o
/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/crtbegin.o
-L/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0
-L/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/../../../../../x86_64-portbld-freebsd14.0/lib
-L/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/../../..
/tmp//cckdrIDm.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc_p -lgcc
--push-state --as-needed -lgcc_s --pop-state
/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/crtend.o
/usr/lib/crtn.o

[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.

[stefan at bytereef dot org via Gcc-bugs]

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

--- Comment #4 from Stefan Krah  ---
> Or, if the intention is that all calls to the function within its TU
> are inlined and not the other ones, split the function into two, one
> always_inline which is used from within the TU and another one which
> just calls it and is used from other TUs.

Yes, that's the intention. The real project has more than 100 functions in
mpdecimal.c. I'm using C99 inline to both automatically inline functions
specifically in that TU but generate regular functions for the other TUs
and libmpdec.so.

C99 saves the work of creating the wrappers manually.


Do note that this issue started with gcc-12, same as in:

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


So it's a behavior change. I agree that the combination of "-flto -Og" is not
particularly important. But is it guaranteed that the above C99 scheme will
always work with -O{1,2,3}? Or are there other loopholes that might show up
in the future?

I guess that in order to be safe I'll remove always_inline and use your wrapper
suggestion some time in the future.

[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
(In reply to Thorsten Otto from comment #3)
> Created attachment 55837 [details]
> Avoid segmentation fault when calling assign_temp with a NULL type pointer
> 
> Attached is a potential patch to fix that.
> 
> The above mentioned commit was made for gcc 4.3, and all compiler versions
> after that are affected by it.

This patch also fixes PR82420. That PR contains a tidied up patch with a test
case and proper attribution to your original. Will you submit your patch or
should I submit mine?

[Bug testsuite/113175] [11/12/13/14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #14 from Patrick Palka  ---
Fixed.

[Bug testsuite/113175] [11/12/13/14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:2110667d43486174dda37a95f73d71941b394655

commit r11-11179-g2110667d43486174dda37a95f73d71941b394655
Author: Patrick Palka 
Date:   Tue Jan 2 21:31:20 2024 -0500

libstdc++: testsuite: Reduce max_size_type.cc exec time [PR113175]

The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
inadvertently increased the execution time of this test by over 5x due
to making the two main loops actually run in the signed_p case instead
of being dead code.

To compensate, this patch cuts the relevant loops' range [-1000,1000] by
10x as proposed in the PR.  This shouldn't significantly weaken the test
since the same important edge cases are still checked in the smaller range
and/or elsewhere.  On my machine this reduces the test's execution time by
roughly 10x (and 1.6x relative to before r14-205).

PR testsuite/113175

libstdc++-v3/ChangeLog:

* testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce
'limit' to 100 from 1000 and adjust 'log2_limit' accordingly.
(test03): Likewise.

(cherry picked from commit a138b99646a5551c53b860648521adb5bfe8c2fa)

[Bug target/82420] ICE with -malign-int and -m68000

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mikael Pettersson  ---
Created attachment 56985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56985=edit
proposed fix

[Bug testsuite/113175] [11/12/13/14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Patrick Palka
:

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

commit r12-10079-g1fb2b5c9a7fb212a5936cc702e49175ef988e5ad
Author: Patrick Palka 
Date:   Tue Jan 2 21:31:20 2024 -0500

libstdc++: testsuite: Reduce max_size_type.cc exec time [PR113175]

The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
inadvertently increased the execution time of this test by over 5x due
to making the two main loops actually run in the signed_p case instead
of being dead code.

To compensate, this patch cuts the relevant loops' range [-1000,1000] by
10x as proposed in the PR.  This shouldn't significantly weaken the test
since the same important edge cases are still checked in the smaller range
and/or elsewhere.  On my machine this reduces the test's execution time by
roughly 10x (and 1.6x relative to before r14-205).

PR testsuite/113175

libstdc++-v3/ChangeLog:

* testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce
'limit' to 100 from 1000 and adjust 'log2_limit' accordingly.
(test03): Likewise.

(cherry picked from commit a138b99646a5551c53b860648521adb5bfe8c2fa)

[Bug tree-optimization/90693] Missing popcount simplifications

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

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 56984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56984=edit
gcc14-pr90693.patch

Untested patch to do that.

[Bug testsuite/113175] [11/12/13/14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

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

commit r13-8189-gaf767e0b9e926fa1ef217087ce3b076be361965f
Author: Patrick Palka 
Date:   Tue Jan 2 21:31:20 2024 -0500

libstdc++: testsuite: Reduce max_size_type.cc exec time [PR113175]

The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
inadvertently increased the execution time of this test by over 5x due
to making the two main loops actually run in the signed_p case instead
of being dead code.

To compensate, this patch cuts the relevant loops' range [-1000,1000] by
10x as proposed in the PR.  This shouldn't significantly weaken the test
since the same important edge cases are still checked in the smaller range
and/or elsewhere.  On my machine this reduces the test's execution time by
roughly 10x (and 1.6x relative to before r14-205).

PR testsuite/113175

libstdc++-v3/ChangeLog:

* testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce
'limit' to 100 from 1000 and adjust 'log2_limit' accordingly.
(test03): Likewise.

(cherry picked from commit a138b99646a5551c53b860648521adb5bfe8c2fa)

[Bug target/113217] New: [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113217
   Summary: [14 Regression][aarch64] ICE in rtl_verify_bb_insns,
at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: acoplan at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Compiling reduced testcase g++.dg/vect/pr45470-b.cc results in ICE since
r14-6605-gc0911c6b357ba9.

$ cat pr45470-b.cc
struct _Vector_base {
  int _M_end_of_storage;
};
struct vector : _Vector_base {
  vector() : _Vector_base() {}
  ~vector();
};
struct LoadGraph {
  LoadGraph();
  vector colors;
  vector data_block;
};
LoadGraph::LoadGraph() {}


$ aarch64-linux-gnu-g++ pr45470-b.cc -fnon-call-exceptions
-fvar-tracking-assignments-toggle -Ofast
pr45470-b.cc: In constructor ‘LoadGraph::LoadGraph()’:
pr45470-b.cc:13:25: error: in basic block 2:
   13 | LoadGraph::LoadGraph() {}
  | ^
pr45470-b.cc:13:25: error: flow control insn inside a basic block
(insn 7 6 8 2 (set (mem:V2x4QI (reg/f:DI 103 [ this ]) [0 +0 S8 A32])
(unspec:V2x4QI [
(const_int 0 [0]) repeated x2
] UNSPEC_STP)) "pr45470-b.cc":5:27 90 {*store_pair_4}
 (expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
during RTL pass: ldp_fusion
pr45470-b.cc:13:25: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.cc:2802
0x1b09b2e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x148d06f rtl_verify_bb_insns
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2802
0x148d337 rtl_verify_flow_info_1
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2889
0x148da96 rtl_verify_flow_info
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:3134
0x147202e verify_flow_info()
/home/mjires/git/GCC/master/gcc/cfghooks.cc:283
0x1a37384 execute_function_todo
/home/mjires/git/GCC/master/gcc/passes.cc:2100
0x1a35faa do_per_function
/home/mjires/git/GCC/master/gcc/passes.cc:1687
0x1a37509 execute_todo
/home/mjires/git/GCC/master/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ aarch64-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-g++
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240103 (experimental) (GCC)

[Bug c++/106653] [C++23] P2582 - Class template argument deduction from inherited constructors

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 Status|NEW |RESOLVED

--- Comment #2 from Patrick Palka  ---
Implemented in r14-6551-g83088b331cde08 for GCC 14.

[Bug c++/98940] Implement C++23 language features

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

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

Bug 106653 Summary: [C++23] P2582 - Class template argument deduction from 
inherited constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106653

   What|Removed |Added

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

[Bug libgomp/113192] [11/12/13/14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2024-01-02 10:21 a.m., tschwinge at gcc dot gnu.org wrote:
> Aha, sorry.  Does it work if you changes:
>
>  -AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock)
>  +AC_CHECK_PROG(FLOCK, perl, $ac_abs_srcdir/testsuite/flock)
No, we get:
ERROR: couldn't execute "/testsuite/flock": no such file or directory

I see top_srcdir is used in some files.

[Bug tree-optimization/113120] during GIMPLE pass: bitintlower ICE: SIGSEGV with _BitInt() at -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 56983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56983=edit
gcc14-pr113120.patch

Untested fix.

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

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

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

--- Comment #13 from Jonathan Wakely  ---
Although this is accepted even though it's in a template, so it's more
complicated than just template vs non-template:

template
consteval void f( char const* p )
{
  char buf[N]{};

  if (p == buf) // unspecified
return;

  for (int i = 0; i < 5; ++i)
buf[i] = p[i];
}

int main()
{
  f("test");
}

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

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

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

--- Comment #12 from Jonathan Wakely  ---
If the comparison happens in a template, GCC rejects it (see PR 113200).

[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #7)
> Why does GCC accept this reduced version, which is invalid for the same
> reason as the original?

Looks like PR 70248

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2020-10-15 00:00:00 |2024-1-3

--- Comment #11 from Jonathan Wakely  ---
And another:

struct S
{
char data_[ 5 ];

constexpr S( char const* p ) : data_()
{
  if (p == data_)
return;

  for (int i = 0; i < 5; ++i)
data_[i] = p[i];
}
};

constexpr S s( "test" );

[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal

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

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

--- Comment #7 from Jonathan Wakely  ---
Why does GCC accept this reduced version, which is invalid for the same reason
as the original?

#include 

constexpr int N = 5;
struct S
{
char data_[ N ];

constexpr S( char const* p )
{
std::char_traits::move( data_, p, N );
}
};

constexpr S s( "test" );


Clang rejects it the same way.

[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Peter Dimov from comment #7)
> > You don't necessarily need dynamic_cast because facets are always installed
> > and obtained by their exact type, not via a reference to base.
> 
> Is that true? std::use_facet will return a reference to a facet with
> X::id but it could actually be something derived from X. e.g. a user can
> install their own facet derived from std::ctype, which overrides some
> members. Code that does std::use_facet>(loc) will get the
> user's facet, but via reference to base.

And conversely, for std::use_facet the locale might contain a base class of
Y, with the same id as Y::id, but there is no Y present. For example, given the
OP's my_codecvt, the following code must throw std::bad_cast:

std::locale loc;
(void) std::use_facet(loc);

There is no my_codecvt present. There is a facet with the same id, but its
dynamic type is std::codecvt not my_codecvt.

I don't see a way to avoid using dynamic_cast without an ABI change to the
std::locale in libstdc++.

[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.2

--- Comment #14 from Jonathan Wakely  ---
(In reply to andysem from comment #13)
> (In reply to Jonathan Wakely from comment #12)
> > (In reply to andysem from comment #11)
> > > > I'm not sure what you mean by "the compiler is free to generate code 
> > > > that takes it into account." Takes what into account? What problem does 
> > > > that freedom cause?
> > > 
> > > I mean the compiler could move (some part of) dynamic_cast to precede the
> > > check for the standard facet. I.e. of something like this:
> > > 
> > >   template< typename _Facet >
> > >   const _Facet* __try_use_facet(locale const& loc)
> > >   {
> > > const size_t __i = _Facet::id._M_id();
> > > const locale::facet** __facets = __loc._M_impl->_M_facets;
> > > const _Facet* __dyn_facet = __dynamic_cast< const _Facet*
> > > >(__facets[__i]);
> > > 
> > > // checks for every standard facet type
> > > if (__is_same(_Facet, ...))
> > >   return static_cast(__facets[__i]);
> > > 
> > > return __dyn_facet;
> > >   }
> > 
> > But why? Maybe I'm being slow but I still don't understand what problem is
> > being solved here.
> > 
> > Also this would defeat the optimization that avoids the unnecessary overhead
> > of dynamic_cast for standard facets.
> 
> I have seen gcc sometimes reorder code like this (i.e. move code from under
> a branch before it), presumably to improve ILP or prefetch data, I'm not
> sure. Yes, that defeats the branch, if it is used as an optimization, and I
> had to prevent this by adding compiler fences in those cases. Granted, in my
> case it happened with inlined code, but I imagine LTO makes it possible to
> perform similar code transformations with out-of-line code as well.


Building libstdc++ with LTO is unsupported (and doesn't happen when building
GCC, it requires making custom changes to the build process, which again is
unsupported). That's a non-issue.

> I'm not saying this is what actually happens. I'm just pointing out that
> even the code that is apparently unreachable may influence codegen and cause
> ODR issues.

I'm still not seeing an actual problem here, just speculation.

The compiler knows that `if (__is_same(T,T))` is true, and will not move
unreachable code before it unless that code has no side effects. And if it has
no side effects, there's no problem.

Since GCC 13.2 there is no change in semantics or observable side effects when
the explicit instantiations for std::use_facet (which are compiled with -frtti)
are used, or the function is inlined (which might be compiled with -fno-rtti).

For the gcc-11 and gcc-12 branches would could suppress the explicit
instantiation declarations for -fno-rtti, so that the extern template
definitions do not try to use dynamic_cast on a type that has no RTTI. But then
we'd need to backport (at least part of) the PR 103755 changes to use
static_cast for standard facets. Otherwise std::use_facet and std::has_facet
would always fail, even for the standard facets which are guaranteed to be
present. I don't think we want to do that on the stable branches, so I think
this is WONTFIX for GCC 13.1 and earlier, and FIXED for 13.2 and later.

[Bug target/113115] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler

[mjires at suse dot cz via Gcc-bugs]

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

Michal Jireš  changed:

   What|Removed |Added

 CC||jeevitha at gcc dot gnu.org,
   ||mjires at suse dot cz

--- Comment #1 from Michal Jireš  ---
Bisected to r14-3592-g9ea1248604d7b6.

[Bug libgomp/113216] New: [OpenMP] Improve omp_target_is_accessible

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

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

Bug ID: 113216
   Summary: [OpenMP] Improve omp_target_is_accessible
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

For omp_target_is_accessible + unified address:

* it is not 100% correct to assume that any address is accessible on the host,
  it might be a device-only address

(For handling NULL, see also PR 113213)

Likewise for the nonhost device:

* memory might be accessible even if only unified address

* * *

The host case is a bit trickier as no generic documentation seems to be
available albeit some ranges like 0x7F.. seem to denote device addresses +
a superset has to be formed.

* * *

For the device side, an API function might be available to check for it.

* * 

In case of nvptx / CUDA, the following function seems to be suitable:

CUresult cuMemGetAccess ( unsigned long long* flags,
  const CUmemLocation* location, CUdeviceptr ptr )

checking for flags == CU_MEM_ACCESS_FLAGS_PROT_READWRITE, if I understand it
correctly.

typedef enum CUmemAccess_flags_enum {
 CU_MEM_ACCESS_FLAGS_PROT_NONE   = 0x0,  /**< Default, make the address range
not accessible */
  CU_MEM_ACCESS_FLAGS_PROT_READ  = 0x1,  /**< Make the address range read
accessible */
  CU_MEM_ACCESS_FLAGS_PROT_READWRITE = 0x3,  /**< Make the address range
read-write accessible */
  CU_MEM_ACCESS_FLAGS_PROT_MAX   = 0x7FFF
} CUmemAccess_flags;

* *

In case of HSA/ROCm, I bet there is also some function.

For instance, hipPointerGetAttribute{,s} + hipDrvPointerGetAttributes permit to
query some pointer data.

[Bug middle-end/113215] New: gimple FE can't handle static local variable with initializer

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

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

Bug ID: 113215
   Summary: gimple FE can't handle static local variable with
initializer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following testcase is accepted:

int __GIMPLE (ssa)
f ()
{
static int x;
__BB(2):
return 1;
}

but adding an initializer to the static variable, it gets rejected:

$ cat > t.c
int __GIMPLE (ssa)
f ()
{
static int x = 1;
__BB(2):
return 1;
}
$ gcc/xgcc -B gcc -c -fgimple t.c
t.c: In function ‘f’:
t.c:4:18: error: expected ‘;’ before ‘=’ token
4 | static int x = 1;
  |  ^
t.c: At top level:
t.c:5:10: error: expected declaration specifiers or ‘...’ before numeric
constant
5 | __BB(2):
  |  ^
t.c:7:1: error: expected identifier or ‘(’ before ‘}’ token
7 | }
  | ^

such IL can be generated by dumping optimized GIMPLE as seen e.g. with the
following testcase:

$ cat t2.c
int f() {
  static int x = 1;
  return x;
}
$ gcc/xgcc -B gcc -c t2.c -fdump-tree-optimized-gimple=-
int __GIMPLE (ssa)
f ()
{
  static int x = 1;
  int D_4434;
  int _2;

  __BB(2):
  _2 = x;
  goto __BB3;

  __BB(3):
L0:
  return _2;

}

[Bug sanitizer/113214] New: false-positive -Wstringop-overflow warning with thread sanitizer

[arnd at linaro dot org via Gcc-bugs]

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

Bug ID: 113214
   Summary: false-positive -Wstringop-overflow warning with thread
sanitizer
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I came across another -Wstringop-overflow warning while building the kernel in
a newly added device driver, when the thread sanitizer is enabled. Reduced my
test case to

void _dev_warn(const void *dev, ...);

struct xe_uc {
int guc;
};

struct xe_gt { 
struct xe_tile *tile;
struct pf_queue {
unsigned int data[128];
unsigned int tail;
} pf_queue[4];
struct xe_uc uc;
};
#define container_of(ptr, type, member) ({  \
void *__mptr = (void *)(ptr);   \
((type *)(__mptr - __builtin_offsetof(type, member))); })


void xe_guc_pagefault_handler(struct xe_uc *uc, int asid, void *msg, int len)
{
struct xe_gt *gt = container_of(uc, struct xe_gt, uc);
void *xe = gt->tile;
struct pf_queue *pf_queue;
if (len != 4)
return;
pf_queue = >pf_queue[asid % 4];
__builtin_memcpy(pf_queue->data + pf_queue->tail,
 msg, len * sizeof(unsigned int));

_dev_warn(xe);
}

Original source code at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/xe/xe_gt_pagefault.c?h=next-20240103#n322

Reproducer at https://godbolt.org/z/MMaz8rqcj

aarch64-linux-gcc-13.2 -Wall -O2 -fsanitize=thread -Werror=stringop-overflow
-Wall -c xe_gt_pagefault.c 
xe_gt_pagefault.c: In function 'xe_guc_pagefault_handler':
xe_gt_pagefault.c:26:9: error: writing 16 bytes into a region of size 0
[-Werror=stringop-overflow=]
   26 | __builtin_memcpy(pf_queue->data + pf_queue->tail,
  | ^
   27 |  msg, len * sizeof(unsigned int));
  |  
xe_gt_pagefault.c:6:25: note: at offset 8 into destination object 'tile' of
size 8
6 | struct xe_tile *tile;
  | ^~~~
cc1: some warnings being treated as errors

Currently I see this with gcc-13.x and gcc-14.0 but not gcc-12.

[Bug target/113116] [14 Regression] ~11-17% exec time regression of 436.cactusADM on aarch64

[fkastl at suse dot cz via Gcc-bugs]

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

--- Comment #3 from Filip Kastl  ---
(In reply to Tamar Christina from comment #2)
> Did you mean -Ofast native PGO? both linked runs are PGO.

Yes I did. I meant PGO and wrote LTO. My bad :).