[Bug tree-optimization/112281] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
Doesn't happen with -fharden-control-flow-redundancy on trunk.

[Bug fortran/104555] ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-5003-gf3e44d079747daf56307ada8a2e2e56b64934014
Author: Paul Thomas 
Date:   Mon Oct 30 07:12:40 2023 +

Fortran: Fix a problem with SELECT TYPE selectors [PR104555].

2023-10-30  Paul Thomas  

gcc/fortran
PR fortran/104555
* resolve.cc (resolve_select_type): If the selector expression
has no class component references and the expression is a
derived type, copy the typespec of the symbol to that of the
expression.

gcc/testsuite/
PR fortran/104555
* gfortran.dg/pr104555.f90: New test.

[Bug c++/66487] sanitizer/warnings for lifetime DSE

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #26 from Alexander Monakov  ---
RFC patch for detecting lifetime-dse issues via Valgrind (rather than MSan):
https://inbox.sourceware.org/gcc-patches/20231024141124.210708-1-exactl...@ispras.ru/

[Bug target/93808] [11/12/13/14 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

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

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #37 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #32)
> (In reply to John Paul Adrian Glaubitz from comment #31)
> > Ah, I forgot to add -O1 and -fno-cross-jumping to CFLAGS.
> > 
> > Are the builtin_traps() optimized out for -O2?
> > 
> > I'm building with the correct flags now.
> 
> Traps also didn't trigger with -O1 and -fno-cross-jumping.

Adrian, what happened to this issue in the end?  Do you remember?

[Bug d/112285] New: `in` class parameter with `gdc -fpreview=in` causes ICE

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

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

Bug ID: 112285
   Summary: `in` class parameter with `gdc -fpreview=in` causes
ICE
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gcc.gnu.org at webfreak dot org
  Target Milestone: ---

```
gdc (GCC) 13.2.1 20230801
Copyright (C) 2023 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.

(from ArchLinux packages)
```

reduced reproduction code:

```
// test.d
struct NativePath
{
}

class Package {
NativePath m_path;

void getSubConfiguration(in Package )
{
}
}
```

CLI:

```
gdc -fpreview=in -freport-bug test.d
```

error:

```
d21: internal compiler error: in layout_aggregate_type, at d/types.cc:562
0x1bceda4 internal_error(char const*, ...)
???:0
0x7bbfc5 fancy_abort(char const*, int, char const*)
???:0
0xa14ad3 build_ctype(Type*)
???:0
0xa234e2 Target::preferPassByRef(Type*)
???:0
0x9d7562 typeSemantic(Type*, Loc const&, Scope*)
???:0
0x8a1c1e DsymbolSemanticVisitor::funcDeclarationSemantic(FuncDeclaration*)
???:0
0x8780f0
_D3dmd7dsymbol14foreachDsymbolFPSQBf4root5array__T5ArrayTCQCeQCd7DsymbolZQxMDFQvZvZv
???:0
0x8869fb DsymbolSemanticVisitor::visit(ClassDeclaration*)
???:0
0x8780f0
_D3dmd7dsymbol14foreachDsymbolFPSQBf4root5array__T5ArrayTCQCeQCd7DsymbolZQxMDFQvZvZv
???:0
0x87c94d DsymbolSemanticVisitor::visit(Module*)
???:0
0x87e9ed dsymbolSemantic(Dsymbol*, Scope*)
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug target/93808] [11/12/13/14 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #38 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #37)
> (In reply to John Paul Adrian Glaubitz from comment #32)
> > (In reply to John Paul Adrian Glaubitz from comment #31)
> > > Ah, I forgot to add -O1 and -fno-cross-jumping to CFLAGS.
> > > 
> > > Are the builtin_traps() optimized out for -O2?
> > > 
> > > I'm building with the correct flags now.
> > 
> > Traps also didn't trigger with -O1 and -fno-cross-jumping.
> 
> Adrian, what happened to this issue in the end?  Do you remember?

Ruby is still being built with -fno-crossjumping on sh4. Let me check, whether
we can drop the flag nowadays with Ruby 3.1 and gcc-13.

[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)

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

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

--- Comment #4 from Sam James  ---
Minimised.

```
$ gcc -O3 -c rijndael.i -march=arch13 -mzarch
rijndael.i:30:18: warning: passing argument 1 of ‘buf_put_le64’ makes pointer
from integer without a cast [-Wint-conversion]
   30 | buf_put_le64(cipher_bulk_ops_t_outbuf_arg, __trans_tmp_5 ^
tweak_lo);
  |  ^~~~
  |  |
  |  int
rijndael.i:8:25: note: expected ‘void *’ but argument is of type ‘int’
8 | void buf_put_le64(void *_buf, long long val) {
  |   ~~^~~~
rijndael.i:32:47: warning: passing argument 1 of ‘buf_put_le64’ makes pointer
from integer without a cast [-Wint-conversion]
   32 | buf_put_le64(cipher_bulk_ops_t_outbuf_arg + 8, __trans_tmp_2 ^
tweak_hi);
  |  ~^~~
  |   |
  |   int
rijndael.i:8:25: note: expected ‘void *’ but argument is of type ‘int’
8 | void buf_put_le64(void *_buf, long long val) {
  |   ~~^~~~
during GIMPLE pass: ccp
rijndael.i:12:6: internal compiler error: Segmentation fault
   12 | void cipher_bulk_ops_t() {
  |  ^
0x578bc41b internal_error(char const*, ...)
???:0
0x5611d4f6 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long
long>)
???:0
0x56cbfcbb s390_vectorize_vec_perm_const(machine_mode, machine_mode, rtx_def*,
rtx_def*, rtx_def*, vec_perm_indices const&)
???:0
0x5656e4b3 can_vec_perm_const_p(machine_mode, machine_mode, vec_perm_indices
const&, bool)
???:0
0x57784b87 gimple_simplify_VEC_PERM_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*, tree_node*)
???:0
0x56e5b3cf gimple_simplify(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*, tree_node*)
???:0
0x56f95e7f gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
???:0
0x562568b1 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
???:0
0x569fca5f ssa_propagation_engine::simulate_stmt(gimple*)
???:0
0x569fcdd3 ssa_propagation_engine::simulate_block(basic_block_def*)
???:0
0x569fd411 ssa_propagation_engine::ssa_propagate()
???: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.
```

```
$ cat rijndael.i
typedef struct {
  long long a;
} bufhelp_u64_t;

int cipher_bulk_ops_t_outbuf_arg, cipher_bulk_ops_t_nblocks,
cipher_bulk_ops_t__buf;
long long cipher_bulk_ops_t___trans_tmp_4;
long long buf_get_le64(int _buf) { return __builtin_bswap64(((bufhelp_u64_t
*)_buf)->a); }
void buf_put_le64(void *_buf, long long val) {
  bufhelp_u64_t *out = _buf;
  out->a = __builtin_bswap64(val);
}
void cipher_bulk_ops_t() {
  long long __trans_tmp_5, __trans_tmp_3, __trans_tmp_2, tweak_lo, tweak_hi,
  tweak_next_lo, tweak_next_hi, carry;
  { __trans_tmp_3 = __builtin_bswap64(cipher_bulk_ops_t__buf); }
  tweak_next_lo = __trans_tmp_3;
  {
int _buf;
cipher_bulk_ops_t___trans_tmp_4 = __builtin_bswap64(_buf);
  }
  tweak_next_hi = cipher_bulk_ops_t___trans_tmp_4;
  while (cipher_bulk_ops_t_nblocks) {
tweak_lo = tweak_next_lo;
tweak_hi = tweak_next_hi;
tweak_next_hi = tweak_next_lo = carry;
{
  __trans_tmp_5 =
  __builtin_bswap64(((bufhelp_u64_t
*)cipher_bulk_ops_t_outbuf_arg)->a);
}
buf_put_le64(cipher_bulk_ops_t_outbuf_arg, __trans_tmp_5 ^ tweak_lo);
__trans_tmp_2 = buf_get_le64(cipher_bulk_ops_t_outbuf_arg + 8);
buf_put_le64(cipher_bulk_ops_t_outbuf_arg + 8, __trans_tmp_2 ^ tweak_hi);
cipher_bulk_ops_t_nblocks--;
  }
}
```

[Bug fortran/104555] ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
It should be noted that the revision in comment 2 introduced select rank.
Before that, the select rank statement gave an "unclassifiable statement" error
and the resulting error cascade.

Fixed on mainline. Closing for now but I am inclined to backport with the patch
for pr104625 in a few weeks time.

Thanks for the report.

Paul

[Bug tree-optimization/112281] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

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

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

Sam James  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] wrong |[12/13/14 Regression] wrong
   |code at -O3 on  |code at -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r12-2097-g9f34b780b0461e
 CC||rguenth at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #4 from Sam James  ---
9f34b780b0461ec7b2b2defe96e44ab616ea2aa3 is the first bad commit
commit 9f34b780b0461ec7b2b2defe96e44ab616ea2aa3
Author: Richard Biener 
Date:   Wed Jul 7 11:41:03 2021 +0200

tree-optimization/99728 - improve LIM for loops with aggregate copies

i.e. r12-2097-g9f34b780b0461e

That commit also came up in PR111554.

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

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #17 from Sam James  ---
fwiw I backported this downstream a while ago and it's been in production
since, no complaints

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu since r14-4777-g88c27070c25309

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

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

--- Comment #8 from Tamar Christina  ---
Thanks for the report, that's very odd..

It looks like loop control is broken and `u` never gets incremented.  It's even
more strange since the structures getting lowered are both unused so should not
have had any effect at all..

will take a look.

[Bug testsuite/111462] [14 regression] gcc.dg/tree-ssa/ssa-sink-18.c fails after r14-4089-gd45ddc2c04e471

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
Hm, so with -fno-ivopts there's not much useful sinking left.  That means
the only way to make the testcase less fragile is to add to the list of
xfail ..

I'm going to add powerpc64le-*-* there.

I think the gcc.dg/vect/vect-117.c fallout is sth different and Honzas area
(separate PRs always help ..).

[Bug testsuite/111462] [14 regression] gcc.dg/tree-ssa/ssa-sink-18.c fails after r14-4089-gd45ddc2c04e471

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

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

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

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

commit r14-5005-gff4cea05a6e6d034eed5212109133c4b5da8520c
Author: Richard Biener 
Date:   Mon Oct 30 11:01:17 2023 +0100

PR testsuite/111462 - add powerpc64le to list of ssa-sink-18.c XFAIL

PR testsuite/111462
gcc/testsuite/
* gcc.dg/tree-ssa/ssa-sink-18.c: XFAIL also powerpc64le.

[Bug testsuite/111462] [14 regression] gcc.dg/tree-ssa/ssa-sink-18.c fails after r14-4089-gd45ddc2c04e471

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug go/112286] New: Go does not support LoongArch

[robinlee.sysu at gmail dot com via Gcc-bugs]

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

Bug ID: 112286
   Summary: Go does not support LoongArch
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: robinlee.sysu at gmail dot com
  Target Milestone: ---

Follow-up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c2

libgo runtime needs an update.
gccgo build scripts need to support loongarch64.

[Bug go/112286] Go does not support LoongArch

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-30
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug rtl-optimization/96388] scheduling takes forever with -fPIC

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

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

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

--- Comment #14 from Maxim Kuvyrkov  ---
Taking.

[Bug target/112287] New: gcc.target/i386/pr111698.c fails on x86_64-darwin

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

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

Bug ID: 112287
   Summary: gcc.target/i386/pr111698.c fails on x86_64-darwin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

The fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111698 introduced
testsuite failures on x86_64-apple-darwin21:

PASS: gcc.target/i386/pr111698.c (test for excess errors)
FAIL: gcc.target/i386/pr111698.c scan-assembler-not testl
gcc.target/i386/pr111698.c: testb found 0 times
FAIL: gcc.target/i386/pr111698.c scan-assembler-times testb 1
gcc.target/i386/pr111698.c: testw found 0 times
FAIL: gcc.target/i386/pr111698.c scan-assembler-times testw 1

The assembly produced is the following:

.build_version macos,  12, 0
.text
.p2align 4
.globl _foo
_foo:
LFB0:
testl   $655360, _m(%rip)
setne   %al
ret
LFE0:
.p2align 4
.globl _bar
_bar:
LFB1:
testl   $10526720, _m(%rip)
setne   %al
ret
LFE1:
.globl _m
.zerofill __DATA,__common,_m,4,2
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long   0
.byte   0x3
.ascii "zR\0"
.uleb128 0x1
.sleb128 -8
.uleb128 0x10
.uleb128 0x1
.byte   0x10
.byte   0xc
.uleb128 0x7
.uleb128 0x8
.byte   0x90
.uleb128 0x1
.align 3
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.long   LASFDE1-EH_frame1
.quad   LFB0-.
.set L$set$2,LFE0-LFB0
.quad L$set$2
.uleb128 0
.align 3
LEFDE1:
LSFDE3:
.set L$set$3,LEFDE3-LASFDE3
.long L$set$3
LASFDE3:
.long   LASFDE3-EH_frame1
.quad   LFB1-.
.set L$set$4,LFE1-LFB1
.quad L$set$4
.uleb128 0
.align 3
LEFDE3:
.subsections_via_symbols

[Bug target/112287] gcc.target/i386/pr111698.c fails on x86_64-darwin

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-10-30
 Target||x86_64-apple-darwin21
 Status|UNCONFIRMED |NEW
 CC||ubizjak at gmail dot com
   Host||x86_64-apple-darwin21
  Build||x86_64-apple-darwin21

[Bug target/106907] gcc/config/rs6000/rs6000.cc:23155: strange expression ?

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by jeevitha :

https://gcc.gnu.org/g:36a52cdc23383e51359630e566b62fa62011428d

commit r14-5006-g36a52cdc23383e51359630e566b62fa62011428d
Author: Jeevitha 
Date:   Mon Oct 30 04:07:07 2023 -0500

rs6000: Change bitwise xor to an equality operator [PR106907]

PR106907 has a few warnings spotted from cppcheck. These warnings
are related to the need of precedence clarification. Instead of using xor,
it has been changed to equality check, which achieves the same result.
Additionally, comment indentation has been fixed.

2023-10-11  Jeevitha Palanisamy  

gcc/
PR target/106907
* config/rs6000/rs6000.cc (altivec_expand_vec_perm_const): Change
bitwise
xor to an equality and fix comment indentation.

[Bug target/112287] gcc.target/i386/pr111698.c fails on x86_64-darwin

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

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

--- Comment #1 from Andrew Pinski  ---
My bet is that the testcase just needs a -march option since iirc Darwin
defaults to core2.

[Bug go/112286] Go does not support LoongArch

[chenglulu at loongson dot cn via Gcc-bugs]

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

chenglulu  changed:

   What|Removed |Added

 CC||chenglulu at loongson dot cn

--- Comment #1 from chenglulu  ---
(In reply to Robin Lee from comment #0)
> Follow-up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c2
> 
> libgo runtime needs an update.
> gccgo build scripts need to support loongarch64.

Do I have to use gccgo? Since the version of go in gcc is relatively low, this
transplant requires some work. We have discussed with our colleagues who are
working on the Go compiler that if it is not necessary to use gccgo, we will
not do the transplant.

Thanks!

[Bug go/112286] Go does not support LoongArch

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

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

--- Comment #2 from Xi Ruoyao  ---
(In reply to chenglulu from comment #1)
> (In reply to Robin Lee from comment #0)
> > Follow-up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c2
> > 
> > libgo runtime needs an update.
> > gccgo build scripts need to support loongarch64.
> 
> Do I have to use gccgo? Since the version of go in gcc is relatively low,
> this transplant requires some work.

GCC will eventually bump the Go version but it requires some non-trivial work:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c6.  So I'd like to defer
the transplant after Ian completes all these.

[Bug go/112286] Go does not support LoongArch

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

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

--- Comment #3 from Xi Ruoyao  ---
FWIW one nice aspect of gccgo is we don't need a pre-installed Go binary to
build it.

[Bug go/112286] Go does not support LoongArch

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #4 from chenglulu  ---
(In reply to Xi Ruoyao from comment #2)
> (In reply to chenglulu from comment #1)
> > (In reply to Robin Lee from comment #0)
> > > Follow-up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c2
> > > 
> > > libgo runtime needs an update.
> > > gccgo build scripts need to support loongarch64.
> > 
> > Do I have to use gccgo? Since the version of go in gcc is relatively low,
> > this transplant requires some work.
> 
> GCC will eventually bump the Go version but it requires some non-trivial
> work: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c6.  So I'd like
> to defer the transplant after Ian completes all these.

Do you know when the version of gccgo will be upgraded?

[Bug go/112286] Go does not support LoongArch

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

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

--- Comment #5 from Xi Ruoyao  ---
(In reply to chenglulu from comment #4)
> (In reply to Xi Ruoyao from comment #2)
> > (In reply to chenglulu from comment #1)
> > > (In reply to Robin Lee from comment #0)
> > > > Follow-up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c2
> > > > 
> > > > libgo runtime needs an update.
> > > > gccgo build scripts need to support loongarch64.
> > > 
> > > Do I have to use gccgo? Since the version of go in gcc is relatively low,
> > > this transplant requires some work.
> > 
> > GCC will eventually bump the Go version but it requires some non-trivial
> > work: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c6.  So I'd like
> > to defer the transplant after Ian completes all these.
> 
> Do you know when the version of gccgo will be upgraded?

No but anyway we should be struggling to make it match the latest Google Go
compiler.  If we cannot keep up one day I guess gccgo will be simply removed.

[Bug go/112286] Go does not support LoongArch

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #6 from chenglulu  ---
(In reply to Xi Ruoyao from comment #5)
> (In reply to chenglulu from comment #4)
> > (In reply to Xi Ruoyao from comment #2)
> > > (In reply to chenglulu from comment #1)
> > > > (In reply to Robin Lee from comment #0)
> > > > > Follow-up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c2
> > > > > 
> > > > > libgo runtime needs an update.
> > > > > gccgo build scripts need to support loongarch64.
> > > > 
> > > > Do I have to use gccgo? Since the version of go in gcc is relatively 
> > > > low,
> > > > this transplant requires some work.
> > > 
> > > GCC will eventually bump the Go version but it requires some non-trivial
> > > work: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682#c6.  So I'd like
> > > to defer the transplant after Ian completes all these.
> > 
> > Do you know when the version of gccgo will be upgraded?
> 
> No but anyway we should be struggling to make it match the latest Google Go
> compiler.  If we cannot keep up one day I guess gccgo will be simply removed.

Ok, I see. Thanks!

[Bug go/112286] Go does not support LoongArch

[robinlee.sysu at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Robin Lee  ---
(In reply to Xi Ruoyao from comment #3)
> FWIW one nice aspect of gccgo is we don't need a pre-installed Go binary to
> build it.

Yes. In Freedesktop SDK project[1], we need gccgo to bootstrap gc go.

[1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/

[Bug target/112287] gcc.target/i386/pr111698.c fails on x86_64-darwin

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

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

--- Comment #2 from Francois-Xavier Coudert  ---
(In reply to Andrew Pinski from comment #1)
> My bet is that the testcase just needs a -march option since iirc Darwin
> defaults to core2.

Thanks, it works. Patch posted to the list.

[Bug c++/112288] New: internal compiler error: in instantiate_decl, at cp/pt.cc:26861

[falemagn at gmail dot com via Gcc-bugs]

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

Bug ID: 112288
   Summary: internal compiler error: in instantiate_decl, at
cp/pt.cc:26861
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: falemagn at gmail dot com
  Target Milestone: ---

It's a regression, it compiles fine with v13.2.1.

[Bug c++/112288] internal compiler error: in instantiate_decl, at cp/pt.cc:26861

[falemagn at gmail dot com via Gcc-bugs]

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

Fabio Alemagna  changed:

   What|Removed |Added

  Attachment #56472|0   |1
is obsolete||
 CC||falemagn at gmail dot com

--- Comment #1 from Fabio Alemagna  ---
Created attachment 56474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56474&action=edit
Generated with -freport-bug

[Bug c/112289] New: '-fstore-merging' causing instrument loss

[Sean.XiaoXiang at outlook dot com via Gcc-bugs]

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

Bug ID: 112289
   Summary: '-fstore-merging' causing instrument loss
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Sean.XiaoXiang at outlook dot com
  Target Milestone: ---

[Bug d/112290] New: self-referencing `in` parameter with `-fpreview=in` causes ICE

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

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

Bug ID: 112290
   Summary: self-referencing `in` parameter with `-fpreview=in`
causes ICE
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gcc.gnu.org at webfreak dot org
  Target Milestone: ---

minial reproduction:

```
// file.d
struct Dependency {
PathEntry* m_value;

bool opEquals(in Dependency ) {
return m_value == m_value;
}
}

struct PathEntry {
string m_name;
}
```

```
gdc -fpreview=in -freport-bug -fdebug -g -Werror -Wall file.d
```

results in errors

```
file.d:9:1: internal compiler error: in get_symbol_decl, at d/decl.cc:1210
9 | struct PathEntry {
  | ^
0x1bceda4 internal_error(char const*, ...)
???:0
0x7bbfc5 fancy_abort(char const*, int, char const*)
???:0
0xa185b3 build_expr(Expression*, bool, bool)
???:0
0xa159da build_decl_tree(Dsymbol*)
???:0
0xa40ba0 build_module_tree(Module*)
???:0
0xa159da build_decl_tree(Dsymbol*)
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
```

possibly related to 112285

[Bug c/112289] '-fstore-merging' causing instrument loss

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-10-30
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Did you accidentally press the button to submit before writing something?

[Bug c/112289] '-fstore-merging' causing instrument loss

[Sean.XiaoXiang at outlook dot com via Gcc-bugs]

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

--- Comment #2 from xiao xiang  ---
Yes,  exactly what I did. sorry about that. Already fixed 😊

从 Windows 版邮件发送

发件人: pinskia at gcc dot gnu.org
发送时间: 2023年10月30日 20:44
收件人: sean.xiaoxi...@outlook.com
主题: [Bug c/112289] '-fstore-merging' causing instrument loss

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-10-30
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Did you accidentally press the button to submit before writing something?

--
You are receiving this mail because:
You reported the bug.

[Bug d/112291] New: cyclic reference struct with `in` parameter and `-fpreview=in` causes bogus error: overlapping initializer for field ...

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

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

Bug ID: 112291
   Summary: cyclic reference struct with `in` parameter and
`-fpreview=in` causes bogus error: overlapping
initializer for field ...
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gcc.gnu.org at webfreak dot org
  Target Milestone: ---

minimal reproduction case:

```
// dependency.d
module dependency;

import package_;

struct PackageDependency {
Dependency spec;
int anythingEitherBeforeOrAfter;
}

struct Dependency {
}

void getTopologicalPackageList(in Package)
{
}
```

```
// package_.d
module package_;

import dependency;

class Package {
PackageDependency getAllDependencies()
{
return PackageDependency.init;
}
}
```

CLI:

```
gdc -fpreview=in -I. dependency.d
```

causing:

```
dependency.d:5:1: error: overlapping initializer for field
‘PackageDependency’.‘anythingEitherBeforeOrAfter’
5 | struct PackageDependency {
  | ^
```

compiling both dependency.d and package_.d in the same CLI causes multiple
errors:

```
dependency.d:5:1: error: overlapping initializer for field
‘PackageDependency’.‘anythingEitherBeforeOrAfter’
5 | struct PackageDependency {
  | ^
package_.d: In function ‘getAllDependencies’:
package_.d:8:24: error: overlapping initializer for field
‘PackageDependency’.‘anythingEitherBeforeOrAfter’
8 | return PackageDependency.init;
  |^
```

compiling only package_.d alone does not cause any errors.

removing `anythingEitherBeforeOrAfter` makes the error go away

copying package_.d into dependency.d (flattening the import) also makes the
error go away

[Bug tree-optimization/112113] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2852-gf5fb9ff2396fd4

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c/112289] '-fstore-merging' causing instrument loss

[Sean.XiaoXiang at outlook dot com via Gcc-bugs]

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

--- Comment #3 from xiao xiang  ---
Hello,

Have I submited information successful? It shows success, but I can’t read the
history I submited anywhere.

Thank you very much.

Sean

从 Windows 版邮件发送

发件人: gcc-bugzi...@gcc.gnu.org
发送时间: 2023年10月30日 20:51
收件人: xiao xiang
主题: Re: 回复: [Bug c/112289] '-fstore-merging' causing instrument loss

Attachments with a MIME type of "text/html" are not allowed on this
installation.

xiao xiang wrote:
> Yes,  exactly what I did. sorry about that. Already fixed 😊
>
> 从 Windows 版邮件å‘é€
>
> å‘件人: pinskia at gcc dot gnu.org
> å‘é€æ—¶é—´: 2023å¹´10月30æ—¥ 20:44
> 收件人: sean.xiaoxi...@outlook.com
> 主题: [Bug c/112289] '-fstore-merging' causing instrument loss
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112289
>
> Andrew Pinski  changed:
>
>What|Removed |Added
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2023-10-30
>  Ever confirmed|0   |1
>
> --- Comment #1 from Andrew Pinski  ---
> Did you accidentally press the button to submit before writing something?

[Bug c/112289] '-fstore-merging' causing instrument loss

[Sean.XiaoXiang at outlook dot com via Gcc-bugs]

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

--- Comment #4 from xiao xiang  ---
--- description 
some store instructions will be lost under certain conditions.
1、  GCC version >= 12.1
2、  Optimization enable at ‘-Os’ (actually is -fstore-merging)
3、  Code like the sample below

We also had some tests and the results (based on GCC version 13.2.0)
Fails with -Os
Passes with -Os -fno-store-merging
Passes with -Os -fno-ipa-modref
Passes with -Os -fno-ssa-phiopt
Passes with -Os -fno-tree-dse
Passes with -Os -fno-tree-pta

Passes with -O1
Fails with -O1 -fstore-merging

---Sample code merge.c 
#include 
typedef union {
struct {
int bit0:1;
int bit1:1;
int bit2:1;
};

int data;
} BITS;

void init(BITS *val, int flag)
{
val->bit1 = 1;
val->bit2 = 1;
if (flag > 1) {
val->bit2 = 0;
}
return;
}

int main(int argc, char **argv)
{
(void)argv;
BITS value;
value.data = 0;
value.bit0 = 1; // lost instrument
init(&value, argc);
printf("%x\n", value);
return 0;
}

--- command line 
--- compile option 
--- expected and actual behavior 
$ gcc -Os merge.c
$ ./a.exe
6  <- expect 7, but bit0 not set

--- system 
windows 10 with mingw64
Linux x86_64 tested the same

--- gcc version 
$ gcc -v
Using built-in specs.
COLLECT_GCC=D:\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=D:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-13.2.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--prefix=/mingw64--with-sysroot=/c/buildroot/x86_64-1320-posix-seh-msvcrt-rt_v11-rev0/mingw64
--enable-host-shared --disable-multilib --enable-languages=c,c++,fortran,lto
--enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--enable-libstdcxx-filesystem-ts=yes --disable-libssp --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-bootstrap --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2
--with-libiconv --with-system-zlib
--with-gmp=/c/buildroot/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/buildroot/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/buildroot/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/buildroot/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-Builds project'
--with-bugurl=https://github.com/niXman/mingw-builds CFLAGS='-O2 -pipe
-fno-ident
-I/c/buildroot/x86_64-1320-posix-seh-msvcrt-rt_v11-rev0/mingw64/opt/include
-I/c/buildroot/prerequisites/x86_64-zlib-static/include
-I/c/buildroot/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -fno-ident
-I/c/buildroot/x86_64-1320-posix-seh-msvcrt-rt_v11-rev0/mingw64/opt/include
-I/c/buildroot/prerequisites/x86_64-zlib-static/include
-I/c/buildroot/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/buildroot/x86_64-1320-posix-seh-msvcrt-rt_v11-rev0/mingw64/opt/include
-I/c/buildroot/prerequisites/x86_64-zlib-static/include
-I/c/buildroot/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe
-fno-ident
-L/c/buildroot/x86_64-1320-posix-seh-msvcrt-rt_v11-rev0/mingw64/opt/lib
-L/c/buildroot/prerequisites/x86_64-zlib-static/lib
-L/c/buildroot/prerequisites/x86_64-w64-mingw32-static/lib '
LD_FOR_TARGET=/c/buildroot/x86_64-1320-posix-seh-msvcrt-rt_v11-rev0/mingw64/bin/ld.exe
--with-boot-ldflags=' -Wl,--disable-dynamicbase -static-libstdc++
-static-libgcc'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (x86_64-posix-seh-rev0, Built by MinGW-Builds project)

[Bug tree-optimization/112117] Missed optimization of LICM that might need to be combined with partial loop unrolling

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Peeling a single iteration might look like the easiest way here,
the trick is to see we can then eliminate an add and a PHI node in the loop.

Note with the current pass ordering this would come quite late since the
required store-motion is performed only before PRE.  It could also be
seen as hoisting opportunity, transforming

# a_lsm.7_16 = PHI 
_3 = c.0_1 + a_lsm.7_16;

into

tem1 = c.0_1 + c.0_1;
tem2 = c.0_1 + a_lsm.7_6;
# _3 = PHI 

but the rest wouldn't reduce as nicely to a multiplication then.

[Bug tree-optimization/112123] Missed optimization of loop deletion because loop invariants are not identified

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/112265] [14 Regression] GCN offloading 'libgomp.c-c++-common/for-5.c': 'internal compiler error: maximum number of generated reload insns per insn achieved (90)'

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

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

--- Comment #3 from Richard Biener  ---
-fno-tree-loop-im?

[Bug c/112289] '-fstore-merging' causing instrument loss

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.4.0, 14.0
 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0
  Known to fail||12.1.0, 12.3.0, 13.1.0,
   ||13.2.0

[Bug c/112289] '-fstore-merging' causing instrument loss

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Dup of bug 111613.

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

[Bug ipa/111613] [12/13/14 Regression] Bit field stores can be incorrectly optimized away when -fstore-merging is in effect

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Sean.XiaoXiang at outlook dot 
com

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

[Bug tree-optimization/112266] `constcall(a)` and `constcall(&a->b[0])` is not being optimized to one call

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-30

--- Comment #1 from Richard Biener  ---
  __BB(2):
  c_2 = &b_1(D)->b;
  t_4 = constcall (c_2);
  t1_5 = constcall (b_1(D));
  _6 = t_4 + t1_5;
  return _6;

diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index 0b2c10dcc1a..c52a846abed 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -3975,6 +3975,8 @@ vn_reference_lookup (tree op, tree vuse, vn_lookup_kind
kind,
  == sext_hwi (off.coeffs[0], TYPE_PRECISION (sizetype
{
  gcc_assert (operands[i-1].opcode == MEM_REF);
+ if (known_eq (off, 0))
+   return operands[i].op0;
  tree ops[2];
  ops[0] = operands[i].op0;
  ops[1] = wide_int_to_tree (sizetype, off);

Mine.

[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

vincenzo Innocente  changed:

   What|Removed |Added

 CC||ian at gcc dot gnu.org
  Component|libstdc++   |libbacktrace

--- Comment #2 from vincenzo Innocente  ---
I suspect libbacktrace even if I do not have ways to test it outside
std::stacktrace

[Bug rtl-optimization/111554] [12/13/14 regression] Timeout with with "-O3 -fno-dse -fno-inline -fno-store-merging -fno-toplevel-reorder -fno-tree-dce -fno-tree-dse" since r12-2097-g9f34b780b0461e

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

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

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

--- Comment #9 from Maxim Kuvyrkov  ---
Taking.

[Bug c++/112293] New: Enhance error reporting with fix-it for missing in gcc 14

[arkamar at atlas dot cz via Gcc-bugs]

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

Bug ID: 112293
   Summary: Enhance error reporting with fix-it for missing
 in gcc 14
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arkamar at atlas dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

We encountered an issue while attempting to build the rspamd package using
gcc-14 on Gentoo Linux. The build process fails with a somewhat ambiguous error
message [1]. However, the same package compiles successfully with gcc-13.

The issue appears to arise from internal changes in libstdc++ that now require
the explicit inclusion of the  header (this part is likely a bug
within rspamd). Is it possible to enhance the error messaging, perhaps with a
fix-it hint, to suggest that  needs to be explicitly included for
clarity?

Here is the minimized snippet to reproduce the issue:

#include 
#include 
struct test;
std::vector v;
auto f(test *t) {
  auto it = std::remove(begin(v), end(v), t);
}

which currently fails with the following error message:

test.cxx: In function _auto f(test*)_:
test.cxx:6:30: error: cannot convert _std::vector::iterator_ to _const
char*_
6 |   auto it = std::remove(begin(v), end(v), t);
  | ~^~~
  |  |
  |  std::vector::iterator
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/cstdio:42,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/ext/string_conversions.h:45,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/basic_string.h:4158,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/string:54,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/stdexcept:39,
 from test.cxx:2:
/usr/include/stdio.h:157:32: note:   initializing argument 1 of _int
remove(const char*)_
  157 | extern int remove (const char *__filename) __THROW;
  |

I tested this with: gcc version 14.0.0 20231022 (experimental) (Gentoo
14.0.0_pre20231022-r1 p7)

[1] https://bugs.gentoo.org/916438

[Bug tree-optimization/112277] Missed optimization of loop deletion because of missed loopUnswitch and useless instruction elimination

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  This seems to be a limit of loop splitting which should handle this
situation but is hindered by us having only a single forwarder from the
branch (on the false edge).  It only considers "edges" where it has a block
that only executes on the path which makes it not try "both" directions here
and fail.  (get_cond_invariant_branch, branch_removable_p and the dominance
check)

if (c_lsm.6_6 < 0)
  goto ; [41.00%]
else
  goto ; [59.00%]

 [local count: 563821836]:

 [local count: 955630226]:
# c_lsm.6_4 = PHI 
# c_lsm_flag.7_10 = PHI 

[Bug ada/111909] Filename case sensitivity defaulted wrongly on macOS

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

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

Eric Gallager  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-October
   ||/634636.html
   Keywords||patch
   Last reconfirmed||2023-10-30
   Assignee|unassigned at gcc dot gnu.org  |simon at pushface dot 
org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Patch posted to mailing lists:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634636.html

[Bug target/112294] New: thread_local13.C and thread_local14.C fail on x86_64-darwin

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

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

Bug ID: 112294
   Summary: thread_local13.C and thread_local14.C fail on
x86_64-darwin
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

The following test failures:

FAIL: g++.dg/tls/thread_local13.C  -std=gnu++14 execution test
FAIL: g++.dg/tls/thread_local13.C  -std=gnu++17 execution test
FAIL: g++.dg/tls/thread_local13.C  -std=gnu++20 execution test
FAIL: g++.dg/tls/thread_local14.C  -std=gnu++14 execution test
FAIL: g++.dg/tls/thread_local14.C  -std=gnu++17 execution test
FAIL: g++.dg/tls/thread_local14.C  -std=gnu++20 execution test

have been present in (at least) GCC 14 and 13 for some months:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-May/783122.html

The runtime failure is a segfault, and the backtrace (obtained by adding -g to
the compilation flags) is:

Process 72865 launched: '/Users/fx/ibin-20231029/gcc/thread_local13.exe'
(x86_64)
Process 72865 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x00013df3 thread_local13.exe`baz() at
thread_local13.C:17:13
   14   {
   15 while (1)
   16   {
-> 17 t.foo ();
   18 if (!bar ())
   19   return false;
   20   }
Target 0: (thread_local13.exe) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
  * frame #0: 0x00013df3 thread_local13.exe`baz() at
thread_local13.C:17:13
frame #1: 0x00013e79 thread_local13.exe`main + 9
frame #2: 0x00010001552e dyld`start + 462

[Bug target/112294] thread_local13.C and thread_local14.C fail on x86_64-darwin

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Host||x86_64-apple-darwin21
   Last reconfirmed||2023-10-30
  Known to fail||13.1.0, 14.0
 Status|UNCONFIRMED |NEW
 Target||x86_64-apple-darwin21
   Keywords||testsuite-fail
  Build||x86_64-apple-darwin21
 CC||iains at gcc dot gnu.org

[Bug tree-optimization/112266] `constcall(a)` and `constcall(&a->b[0])` is not being optimized to one call

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

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

--- Comment #2 from Richard Biener  ---
Whee - late diagnostic fallout galore!  Putting on hold.

[Bug tree-optimization/112266] `constcall(a)` and `constcall(&a->b[0])` is not being optimized to one call

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

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

--- Comment #3 from Richard Biener  ---
Created attachment 56475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56475&action=edit
patch

 Running target unix
+FAIL: c-c++-common/Warray-bounds.c  -std=gnu++98  (test for warnings, line
183)
+FAIL: c-c++-common/Warray-bounds.c  -std=gnu++14  (test for warnings, line
183)
+FAIL: c-c++-common/Warray-bounds.c  -std=gnu++17  (test for warnings, line
183)
+FAIL: c-c++-common/Warray-bounds.c  -std=gnu++20  (test for warnings, line
183)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++98  (test for warnings,
line 28)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++98  (test for warnings,
line 58)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++98  (test for warnings,
line 88)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++98  (test for warnings,
line 118)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++14  (test for warnings,
line 28)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++14  (test for warnings,
line 58)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++14  (test for warnings,
line 88)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++14  (test for warnings,
line 118)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++17  (test for warnings,
line 28)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++17  (test for warnings,
line 58)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++17  (test for warnings,
line 88)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++17  (test for warnings,
line 118)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++20  (test for warnings,
line 28)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++20  (test for warnings,
line 58)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++20  (test for warnings,
line 88)
+FAIL: c-c++-common/Wstringop-truncation-4.c  -std=gnu++20  (test for warnings,
line 118)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++98  (test for warnings,
line 299)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++98  (test for warnings,
line 300)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++98 member array (test for
warnings, line 302)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++98  (test for warnings,
line 373)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++98  (test for warnings,
line 429)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++98  (test for warnings,
line 430)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++14  (test for warnings,
line 299)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++14  (test for warnings,
line 300)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++14 member array (test for
warnings, line 302)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++14  (test for warnings,
line 373)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++14  (test for warnings,
line 429)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++14  (test for warnings,
line 430)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++17  (test for warnings,
line 299)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++17  (test for warnings,
line 300)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++17 member array (test for
warnings, line 302)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++17  (test for warnings,
line 373)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++17  (test for warnings,
line 429)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++17  (test for warnings,
line 430)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++20  (test for warnings,
line 299)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++20  (test for warnings,
line 300)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++20 member array (test for
warnings, line 302)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++20  (test for warnings,
line 373)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++20  (test for warnings,
line 429)
+FAIL: c-c++-common/Wstringop-truncation.c  -std=gnu++20  (test for warnings,
line 430)
+FAIL: g++.dg/warn/Wstringop-overflow-1.C  -std=c++98  (test for warnings, line
14)
+FAIL: g++.dg/warn/Wstringop-overflow-1.C  -std=c++14  (test for warnings, line
14)
+FAIL: g++.dg/warn/Wstringop-overflow-1.C  -std=c++17  (test for warnings, line
14)
+FAIL: g++.dg/warn/Wstringop-overflow-1.C  -std=c++20  (test for warnings, line
14)
 FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 23 p == 40
+FAIL: g++.dg/tree-prof/devirt.C scan-tree-dump-times tracer "folding virtual
function call to virtual unsigned int mozPersonalDictionary::_ZThn16" 1
 FAIL: g++.dg/tsan/pthread_cond_clockwait.C   -O0  execution test
 FAIL: g++.dg/tsan/pthread_cond_clockwait.C   -O2  execution test

=== g++ Summary ===

-# of expected passes   248265
-# of unexpected failures   3
+# of expected passes   2482

[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Petr Vaněk from comment #0)
> The issue appears to arise from internal changes in libstdc++ that now
> require the explicit inclusion of the  header (this part is
> likely a bug within rspamd).

The C++ standard always required the explicit inclusion of  for the
std::remove algorithm. This is definitely a bug in rspamd.

> Is it possible to enhance the error messaging,
> perhaps with a fix-it hint, to suggest that  needs to be
> explicitly included for clarity?

That would be difficult, because std::remove is overloaded and another overload
was found here (the one declared in ). Usually we only provide fix-it
hints when name lookup doesn't find anything.

> Here is the minimized snippet to reproduce the issue:
> 
> #include 
> #include 
> struct test;
> std::vector v;
> auto f(test *t) {
>   auto it = std::remove(begin(v), end(v), t);
> }

This is broken in two ways, you need to include both  *and* 
for this program.

[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This is broken in two ways, you need to include both  *and*
>  for this program.

Actually three ways. There is no guarantee that std::vector's iterators have
namespace std as an associated namespace, so begin(v) and end(v) are not
guaranteed to find std::begin and std::end. You should qualify them or add
using declarations.

[Bug target/112295] New: RISC-V: Short forward branch pessimisation for ALU operations

[macro at orcam dot me.uk via Gcc-bugs]

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

Bug ID: 112295
   Summary: RISC-V: Short forward branch pessimisation for ALU
operations
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: macro at orcam dot me.uk
  Target Milestone: ---
Target: riscv*-*-*

We have a pessimisation in the RISC-V backend for TARGET_SFB_ALU.
This code:

int
addsifeq (double w, double x, int y, int z)
{
  return w == x ? y + z : y;
}

built with:

$ gcc -mtune=sifive-7-series -O1 addsifeq.c

compiles to this:

feq.d   a4,fa0,fa1
addwa5,a0,a1
bne a4,zero,1f  # movcc
mv  a5,a0
1:
mv  a0,a5
ret

however by avoiding the SFB optimisation, e.g. with:

$ gcc -mtune=sifive-5-series -O1 addsifeq.c

we get clearly superior code, which actually still benefits from SFB:

feq.d   a5,fa0,fa1
beq a5,zero,.L2
addwa0,a0,a1
.L2:
ret

This can be fixed by providing `addMcc' patterns for TARGET_SFB_ALU,
but how about other ALU operations?

Filing as a PR as I may or may not have time to work on this, so let's
have it written down.

[Bug tree-optimization/112281] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |13.2.1
   Priority|P3  |P2
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Richard Biener  ---
Possibly a mixup of dependence direction somewhere.  If c would not iterate
backwards the transform would be correct.

We compute

(build_classic_dist_vector
  dist_vector = (1 0
  )

and then possibly get partition order wrong.  With 11 we had fixes there,
possibly this broke it.

I will have a look.  At some point ...

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu since r14-4777-g88c27070c25309

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|unknown |14.0

[Bug c++/112296] New: __builtin_constant_p doesn't propagate through member functions

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 112296
   Summary: __builtin_constant_p doesn't propagate through member
functions
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Here's a short example:

using size_t = decltype(sizeof(0));

struct Span {
int const* ptr;
size_t len;

inline constexpr auto size() const noexcept -> size_t { return len; }
};

inline int direct(Span span) {
return __builtin_constant_p(span.size());
}

inline int indirect(Span span) {
size_t s = span.size();
return __builtin_constant_p(s);
}

int call_direct(int const* p) {
return direct({.ptr=p, .len=8});
}

int call_indirect(int const* p) {
return indirect({.ptr=p, .len=8});
}



The functions direct() and indirect() do the same thing - try to see if span's
size is constant, with direct checking size() directly and indirect first
caching it to a local variable and checking that variable. In both cases, the
size is constant - but on -O3 call_direct() returns 0 while call_indirect()
returns 1. That is, __builtin_constant_p tells me the size is constant - but
only if I put it into a variable first. 

Checking __builtin_constant_p(span.len) also returns 1, but in the real code
the member variable is private and my only access to it is via the size()
function.

[Bug c++/112288] [14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Target Milestone|--- |14.0

[Bug c++/82594] Please provide better parameter / argument mismatch warnings/notes for no overloads case

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> But with only one overload, GCC produces:
> t88.c: In function 'void initialize()':
> t88.c:13:35: error: cannot convert 'void (*)(S2*)' to 'S1*' for argument '1'
> to 'void set_delete_thread(S1*, void (*)(S2*))'
>set_delete_thread (delete_thread);
>^

This is pretty bad. Why do we complain about not being able to convert the
argument, when the bigger problem is that the number of arguments is wrong? It
doesn't matter whether the first argument matches or not, the other two args
are missing.

For the example in PR 112293 it would have been much better to point out that
the only visible overload of std::remove expects one argument instead of the
irrelevant diagnostic about converting vector::iterator to const char*.

[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14

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

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

--- Comment #3 from Jonathan Wakely  ---
As I wrote in PR 82594, the error should say that the number of arguments is
wrong instead of the irrelevant error about converting to const char*.

I don't think a fix-it is likely here though.

[Bug c++/112296] __builtin_constant_p doesn't propagate through member functions

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

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

--- Comment #1 from Richard Biener  ---
__builtin_constant_p is limited by inlining, maybe you want to use
if constexpr for this or the standard library facility I can't remember
right now.

[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14

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

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

--- Comment #4 from Jonathan Wakely  ---
FWIW the change in transitive includes was r14-1459-g940645cec500ab

[Bug target/112297] New: Failure of pr100936.c on x86_64-apple-darwin21

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

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

Bug ID: 112297
   Summary: Failure of pr100936.c on x86_64-apple-darwin21
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

FAIL: gcc.target/i386/pr100936.c (test for excess errors)

The error is:

pr100936.s:8:2: error: 32-bit absolute addressing is not supported in 64-bit
mode
lea _var, %rax
^


The testcase is compiled to:

.build_version macos,  12, 0
.text
.p2align 4
.globl _baz
_baz:
LFB2:
# 12 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/pr100936.c" 1
lea _var, %rax
# 0 "" 2
# 22 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/pr100936.c" 1
mov %gs:(%rax), %eax
# 0 "" 2
ret
LFE2:
.globl _var
.zerofill __DATA,__common,_var,4,2
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long   0
.byte   0x3
.ascii "zR\0"
.uleb128 0x1
.sleb128 -8
.uleb128 0x10
.uleb128 0x1
.byte   0x10
.byte   0xc
.uleb128 0x7
.uleb128 0x8
.byte   0x90
.uleb128 0x1
.align 3
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.long   LASFDE1-EH_frame1
.quad   LFB2-.
.set L$set$2,LFE2-LFB2
.quad L$set$2
.uleb128 0
.align 3
LEFDE1:
.ident  "GCC: (GNU) 14.0.0 20231029 (experimental) [master
c6929b08558]"
.subsections_via_symbols

[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14

[arkamar at atlas dot cz via Gcc-bugs]

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

--- Comment #5 from Petr Vaněk  ---
Thank you for the quick response and clarifications. I'll work on patching
rspamd to adhere to these requirements.

As for std::begin and std::end, rspamd uses them correctly, the std:: was
actually reduced by cvise in this case.

[Bug target/112297] Failure of pr100936.c on x86_64-apple-darwin21

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

  Build||x86_64-apple-darwin21
 Status|UNCONFIRMED |NEW
   Host||x86_64-apple-darwin21
   Keywords||testsuite-fail
 CC||iains at gcc dot gnu.org
 Target||x86_64-apple-darwin21
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-30

--- Comment #1 from Francois-Xavier Coudert  ---
I don't know enough to see if the asm in the code is incompatible with darwin
syntax, or if the middle-end should emit different asm.

[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> That would be difficult, because std::remove is overloaded and another
> overload was found here (the one declared in ). Usually we only
> provide fix-it hints when name lookup doesn't find anything.

This is also a very unusual case. Most C++ std::lib functions are not
overloaded in C stdlib headers. Any change here would be quite specific to
std::remove, possibly even unique. There's std::bind which collides with POSIX
::bind. There are also std::isalnum etc. but I don't think it's possible to get
the problem there, since they're declared in the same header as the std::locale
type that you call them with.

[Bug c++/112296] __builtin_constant_p doesn't propagate through member functions

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

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

--- Comment #2 from Jonathan Wakely  ---
I think you mean std::is_constant_evaluated, but that doesn't check values, it
checks if the function is being evaluated as constexpr. And if-constexpr can't
be used here either, that works like templates, so only on static types, not
runtime values.

[Bug c++/112296] __builtin_constant_p doesn't propagate through member functions

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Barry Revzin from comment #0)
> inline int direct(Span span) {
> return __builtin_constant_p(span.size());
> }
> 
> inline int indirect(Span span) {
> size_t s = span.size();
> return __builtin_constant_p(s);
> }

If the problem is that bcp is limited by inlining, you'd think that the first
one would be more likely to work. It does less.

Clearly inlining can see through the member function, because in 'indirect' it
can propagate its return value through 's' and to the bcp call.

But in 'direct' the return value is somehow not constant when used directly. It
is only constant if propagated through a local variable. That seems like an
unnecessary limitation.

[Bug target/112298] New: Poor code for DImode operations on H8 port

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

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

Bug ID: 112298
   Summary: Poor code for DImode operations on H8 port
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

long long foo(long long x) { return x << 1; }

Highlights several code inefficiencies WRT DImode values on the H8.

I would expect that defining a reasonable adddi3 and some DImode shifts would
likely help this problem considerably.

I'm not currently working on this problem.

[Bug target/112298] Poor code for DImode operations on H8 port

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Target||h8300
   Priority|P3  |P4

[Bug target/112299] New: Cross compiling to loongarch64-linux-gnuf64 fails because "HAVE_AS_TLS was not declared" after r14-4925-g1b30ef7cea773e

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

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

Bug ID: 112299
   Summary: Cross compiling to loongarch64-linux-gnuf64 fails
because "HAVE_AS_TLS was not declared" after
r14-4925-g1b30ef7cea773e
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: chenxiaolong at loongson dot cn
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: loongarch64-linux-gnuf64

Starting with r14-4925-g1b30ef7cea773e, when I try to test that cross
compilation to target loongarch64-linux-gnuf64 still works by configuring gcc
with:

$ ../src/configure --target=loongarch64-linux-gnuf64 --disable-bootstrap
--enable-languages=c,c++ --disable-multilib  --enable-obsolete

and then building just the compiler with:

$ make -j64 all-host CXXFLAGS="-O0 -g" CFLAGS="-O0 -g"

The compilation fails with:

../../src/gcc/config/loongarch/loongarch.md:3655:2: error: ‘HAVE_AS_TLS’ was
not declared in this scope
 3655 |   "HAVE_AS_TLS"
  |  ^~~
config.status: executing libtool commands
../../src/gcc/config/loongarch/loongarch.md:3655:2: error: ‘HAVE_AS_TLS’ was
not declared in this scope
 3655 |   "HAVE_AS_TLS"
  |  ^~~
../../src/gcc/config/loongarch/loongarch.md:3655:2: error: ‘HAVE_AS_TLS’ was
not declared in this scope
 3655 |   "HAVE_AS_TLS"
  |  ^~~
../../src/gcc/config/loongarch/loongarch.md:3655:2: error: ‘HAVE_AS_TLS’ was
not declared in this scope
 3655 |   "HAVE_AS_TLS"
  |  ^~~
make[1]: *** [Makefile:2958: build/gencondmd.o] Error 1
make[1]: *** Waiting for unfinished jobs
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[1]: Leaving directory '/home/mjambor/gcc/mine/obj/gcc'

According to our buildbot, building a cross for loongarch64-linux-gnuf32 and
loongarch64-linux-gnusf also fails, likely because of the same issue.

[Bug target/112300] New: Cross compiling to mipsisa64r2-sde-elf fails because "HEAP_TRAMPOLINES_INIT was not declared in this scope" since r14-4821-g28d8c680aaea46

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

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

Bug ID: 112300
   Summary: Cross compiling to mipsisa64r2-sde-elf fails because
"HEAP_TRAMPOLINES_INIT was not declared in this scope"
since r14-4821-g28d8c680aaea46
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: aburgess at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: mipsisa64r2-sde-elf

Starting with r14-4821-g28d8c680aaea46, when I try to test that cross
compilation to target mipsisa64r2-sde-elf works by configuring gcc with:

$ ../src/configure --target=mipsisa64r2-sde-elf --disable-bootstrap
--enable-languages=c,c++ --disable-multilib  --enable-obsolete

and then building just the compiler with:

$ make -j64 all-host CXXFLAGS="-O0 -g" CFLAGS="-O0 -g"

The compilation fails with:

g++  -fno-PIE -c   -O0 -g   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-fno-PIE -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include 
-I../../src/gcc/../libcpp/include -I../../src/gcc/../libcody 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o options.o -MT options.o
-MMD -MP -MF ./.deps/options.TPo options.cc
options.cc:3246:3: error: ‘HEAP_TRAMPOLINES_INIT’ was not declared in this
scope
 3246 |   HEAP_TRAMPOLINES_INIT ? TRAMPOLINE_IMPL_HEAP : TRAMPOLINE_IMPL_STACK,
/* flag_trampoline_impl */
  |   ^
options.cc:3247:3: error: ‘HEAP_TRAMPOLINES_INIT’ was not declared in this
scope
 3247 |   HEAP_TRAMPOLINES_INIT, /* flag_trampolines */
  |   ^
make[1]: *** [Makefile:1188: options.o] Error 1
make[1]: Leaving directory '/home/mjambor/gcc/mine/obj/gcc'
make: *** [Makefile:4660: all-gcc] Error 2

[Bug target/112298] Poor code for DImode operations on H8 port

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1
   Last reconfirmed||2023-10-30

[Bug c++/112301] New: Double destruction of returned object when exiting the scope causes an exception which gets rethrown

[alexander.grund--- via Gcc-bugs]

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

Bug ID: 112301
   Summary: Double destruction of returned object when exiting the
scope causes an exception which gets rethrown
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.gr...@tu-dresden.de
  Target Milestone: ---

Created attachment 56476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56476&action=edit
More complete example with logging pointers

I debugged a heap corruption I traced back to a use-after-free caused by an
extra destructor call.

I suspect the cause could be the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799 where a throwing destructor
led to a missing destructor call.
It could be similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12751 which
also had an extra destructor call generated for an already destructed instance.

Minimized code sample:

#include 
#include 

int num = 0;
struct ptr{
ptr(){
++num;
}
ptr(ptr&&){
++num;
}
~ptr(){
assert(num-- > 0);
}
};

struct ThrowOnExit{
~ThrowOnExit() noexcept(false){
throw std::runtime_error("");
}
};

ptr foo(ptr x){
try{
ThrowOnExit _;
return x;
}catch (const std::exception&) {
throw;
}
}

void wrapper(){
try{
foo(ptr{});
}catch(const std::exception&){}
}

int main(){
wrapper();
}


The assertion fails, although it should not. Logging the constructions and
destructions and removing the assert gives me this:

construct 0x7ffd4538088e
move construct 0x7ffd4538088f
free 0x7ffd4538088f
free 0x7ffd4538088f
free 0x7ffd4538088e

[Bug rtl-optimization/110717] Double-word sign-extension missed-optimization

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

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

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

https://gcc.gnu.org/g:31cc9824d1cd5e0f7fa145d0831a923479333cd6

commit r14-5013-g31cc9824d1cd5e0f7fa145d0831a923479333cd6
Author: Roger Sayle 
Date:   Mon Oct 30 16:17:42 2023 +

ARC: Improved ARC rtx_costs/insn_cost for SHIFTs and ROTATEs.

This patch overhauls the ARC backend's insn_cost target hook, and makes
some related improvements to rtx_costs, BRANCH_COST, etc.  The primary
goal is to allow the backend to indicate that shifts and rotates are
slow (discouraged) when the CPU doesn't have a barrel shifter. I should
also acknowledge Richard Sandiford for inspiring the use of set_cost
in this rewrite of arc_insn_cost; this implementation borrows heavily
for the target hooks for AArch64 and ARM.

The motivating example is derived from PR rtl-optimization/110717.

struct S { int a : 5; };
unsigned int foo (struct S *p) {
  return p->a;
}

With a barrel shifter, GCC -O2 generates the reasonable:

foo:ldb_s   r0,[r0]
asl_s   r0,r0,27
j_s.d   [blink]
asr_s   r0,r0,27

What's interesting is that during combine, the middle-end actually
has two shifts by three bits, and a sign-extension from QI to SI.

Trying 8, 9 -> 11:
8: r158:SI=r157:QI#0<<0x3
  REG_DEAD r157:QI
9: r159:SI=sign_extend(r158:SI#0)
  REG_DEAD r158:SI
   11: r155:SI=r159:SI>>0x3
  REG_DEAD r159:SI

Whilst it's reasonable to simplify this to two shifts by 27 bits when
the CPU has a barrel shifter, it's actually a significant pessimization
when these shifts are implemented by loops.  This combination can be
prevented if the backend provides accurate-ish estimates for insn_cost.

Previously, without a barrel shifter, GCC -O2 -mcpu=em generates:

foo:ldb_s   r0,[r0]
mov lp_count,27
lp  2f
add r0,r0,r0
nop
2:  # end single insn loop
mov lp_count,27
lp  2f
asr r0,r0
nop
2:  # end single insn loop
j_s [blink]

which contains two loops and requires about ~113 cycles to execute.
With this patch to rtx_cost/insn_cost, GCC -O2 -mcpu=em generates:

foo:ldb_s   r0,[r0]
mov_s   r2,0;3
add3r0,r2,r0
sexb_s  r0,r0
asr_s   r0,r0
asr_s   r0,r0
j_s.d   [blink]
asr_s   r0,r0

which requires only ~6 cycles, for the shorter shifts by 3 and sign
extension.

2023-10-30  Roger Sayle  

gcc/ChangeLog
* config/arc/arc.cc (arc_rtx_costs): Improve cost estimates.
Provide reasonable values for SHIFTS and ROTATES by constant
bit counts depending upon TARGET_BARREL_SHIFTER.
(arc_insn_cost): Use insn attributes if the instruction is
recognized.  Avoid calling get_attr_length for type "multi",
i.e. define_insn_and_split patterns without explicit type.
Fall-back to set_rtx_cost for single_set and pattern_cost
otherwise.
* config/arc/arc.h (COSTS_N_BYTES): Define helper macro.
(BRANCH_COST): Improve/correct definition.
(LOGICAL_OP_NON_SHORT_CIRCUIT): Preserve previous behavior.

[Bug rtl-optimization/106594] [13/14 Regression] sign-extensions no longer merged into addressing mode

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

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

--- Comment #27 from Segher Boessenkool  ---
(In reply to Roger Sayle from comment #21)
> Segher has proposed that object code size correlates with the quality of

It isn't a proposition, it is a simple and obvious fact.  But, this isn't
exactly
what I say :-)

Code size strongly correlates with number of instructions, almost 1-1 on most
targets.  Number of instructions is exactly what combine tries to reduce.

Whether that makes the code actually better is something completely separate as
well.  If your instruction cost function (and please use insn_cost, it is much
easier to use, and thus gives better results than rtx_costs) is good, this of
course should work fine.  And there is a hook (TARGET_LEGITIMATE_COMBINED_INSN)
for the very nasty cases.

But the whole "fewer insns that do the same thing, is better" thing is not
actually true on some targets.  Such targets are incredibly hard to optimise
for.  There is no way combine can do a good job for such targets.  It is
incredibly hard for human programmers to write good machine code for such
systems
by hand as well.

I do use object code size **of a huge sample** as a quick and dirty sniff test
to see if a change to combines is good or bad.  After that I always look at the
actual changes as well.  I do realise all pitfalls associated with this :-)

[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534' since r14-4796-g3e3d73ed5e85e7

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

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

--- Comment #5 from Patrick Palka  ---
I can't reproduce any of these testsuite failures on trunk with x86_64 -m32...
could you provide a preprocessed source file perhaps?

[Bug middle-end/101955] (signed<<

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

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

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

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

commit r14-5014-ga3da9adeb457d4f01c4e695a9621f90c2e2a5e68
Author: Roger Sayle 
Date:   Mon Oct 30 16:21:28 2023 +

ARC: Convert (signed<<31)>>31 to -(signed&1) without barrel shifter.

This patch optimizes PR middle-end/101955 for the ARC backend.  On ARC
CPUs with a barrel shifter, using two shifts is optimal as:

asl_s   r0,r0,31
asr_s   r0,r0,31

but without a barrel shifter, GCC -O2 -mcpu=em currently generates:

and r2,r0,1
ror r2,r2
add.f   0,r2,r2
sbc r0,r0,r0

with this patch, we now generate the smaller, faster and non-flags
clobbering:

bmsk_s  r0,r0,0
neg_s   r0,r0

2023-10-30  Roger Sayle  

gcc/ChangeLog
PR middle-end/101955
* config/arc/arc.md (*extvsi_1_0): New define_insn_and_split
to convert sign extract of the least significant bit into an
AND $1 then a NEG when !TARGET_BARREL_SHIFTER.

gcc/testsuite/ChangeLog
PR middle-end/101955
* gcc.target/arc/pr101955.c: New test case.

[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |ice-on-valid-code
Summary|[14 Regression] ICE -   |[11/12/13/14 Regression]
   |internal compiler error: in |ICE - internal compiler
   |instantiate_decl, at|error: in instantiate_decl,
   |cp/pt.cc:26861  |at cp/pt.cc:26861
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2023-10-30
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.  Started with r6-6830-g20a0c6f9bdbd78:

commit 20a0c6f9bdbd781ed5d413a10a06764a174dc394
Author: Patrick Palka 
Date:   Mon Feb 8 23:02:50 2016 +

Fix PR c++/69283 (auto deduction fails when ADL is required)

but reverting that fix doesn't make the ICE go away.

[Bug c++/112301] [Regression 12/13/14] Double destruction of returned object when exiting the scope causes an exception which gets rethrown

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|Double destruction of   |[Regression 12/13/14]
   |returned object when|Double destruction of
   |exiting the scope causes an |returned object when
   |exception which gets|exiting the scope causes an
   |rethrown|exception which gets
   ||rethrown
 CC||jason at gcc dot gnu.org
   Last reconfirmed||2023-10-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed as a regression starting with r12-6333-gb10e031458d541

Author: Jason Merrill
Date:   Wed Jan 5 22:01:12 2022

c++: destroy retval on throwing cleanup in try [PR33799]

My earlier attempt to fix this bug didn't handle the case where both the
return and the throwing cleanup are within a try-block that catches and
discards the exception.  Fixed by adding the retval cleanup to any
try-blocks as well as the function body.  PR102191 pointed out that we also
weren't handling templates properly, so I moved the call out of the parser.

PR c++/33799
PR c++/102191

[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861

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

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

--- Comment #3 from Marek Polacek  ---
// PR c++/112288

namespace {

template 
class counter
{
public:
 template 
 static constexpr int next()
 {
  return next(0)*Step+Start;
 }

private:
 template 
 struct slot
 {
  template 
  friend constexpr auto slot_allocated(Dummy, slot);
 };

 template 
 struct allocate_slot {
  template 
  friend constexpr auto slot_allocated(Dummy, slot) {
   return true;
  }

  enum { value = I };
 };


 template ())>
 static constexpr int next(int)
 {
  return next(0);
 }


 template 
 static constexpr int next(double)
 {
  return allocate_slot::value;
 }
};

}


template 
struct U;

struct C: counter>{};

int a = C::next();
int b = C::next();

[Bug target/111635] Objects built with -flto cannot be linked with Xcode

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #4 from Francois-Xavier Coudert  ---
(In reply to Amyspark from comment #0)
> It is still easily
> reproducible by building https://github.com/blackmagic-debug/bmpflash with
> `meson setup build -Db_lto=true --buildtype=debug` followed by `meson
> compile -C build`.

I tried but could not reproduce on aarch64-apple-darwin23. The first try failed
because the code was updated and refuses to build with LTO. I checked out
commit f87ad307ddc1822e3a770e234ae2adcbe5ea855b

The second try failed because:

libusb| Run-time dependency iokit found: NO (tried framework)
deps/libusb/meson.build:112:2: ERROR: Dependency "IOKit" not found, tried
framework

[Bug target/111635] Objects built with -flto cannot be linked with Xcode

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

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

--- Comment #5 from Francois-Xavier Coudert  ---
Third try (on aarch64-darwin): I installed Homebrew's libusb. But now, the
build succeeds…

⌁ [fx:/tmp/bmpflash] f87ad30 6s ± meson compile -C build
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /opt/homebrew/bin/ninja -C
/private/tmp/bmpflash/build
ninja: Entering directory `/private/tmp/bmpflash/build'
[27/27] Linking target src/bmpflash

[Bug ipa/111157] [14 Regression] 416.gamess fails with a run-time abort when compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:1437df40f12ade35fd1f1a3e4cbba4b4656cab0b

commit r14-5016-g1437df40f12ade35fd1f1a3e4cbba4b4656cab0b
Author: Martin Jambor 
Date:   Mon Oct 30 18:34:59 2023 +0100

ipa-cp: Templatize filtering of m_agg_values

PR 57 points to another place where IPA-CP collected aggregate
compile-time constants need to be filtered, in addition to the one
place that already does this in ipa-sra.  In order to re-use code,
this patch turns the common bit into a template.

The functionality is still covered by testcase gcc.dg/ipa/pr108959.c.

gcc/ChangeLog:

2023-09-13  Martin Jambor  

PR ipa/57
* ipa-prop.h (ipcp_transformation): New member function template
remove_argaggs_if.
* ipa-sra.cc (zap_useless_ipcp_results): Use remove_argaggs_if to
filter aggreagate constants.

[Bug ipa/111157] [14 Regression] 416.gamess fails with a run-time abort when compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:997c8219f020091d00fd225c81270aa551bfe9e4

commit r14-5017-g997c8219f020091d00fd225c81270aa551bfe9e4
Author: Martin Jambor 
Date:   Mon Oct 30 18:34:59 2023 +0100

ipa: Prune any IPA-CP aggregate constants known by modref to be killed
(57)

PR 57 shows that IPA-modref and IPA-CP (when plugged into value
numbering) can optimize out a store both before a call (because the
call will overwrite it) and in the call (because the store is of the
same value) and by eliminating both create miscompilation.

This patch fixes that by pruning any constants from the list of IPA-CP
aggregate value constants that it knows the contents of the memory can
be "killed."  Unfortunately, doing so is tricky.  First, IPA-modref
loads override kills and so only stores not loaded are truly not
necessary.  Looking stuff up there means doing what most of what
modref_may_alias may do but doing exactly what it does is tricky
because it takes also aliasing into account and has bail-out counters.

To err on the side of caution in order to avoid this miscompilation we
have to prune a constant when in doubt.  However, pruning can
interfere with the mechanism of how clone materialization
distinguishes between the cases when a parameter was entirely removed
and when it was both IPA-CPed and IPA-SRAed (in order to make up for
the removal in debug info, which can bump into an assert when
compiling g++.dg/torture/pr103669.C when we are not careful).

Therefore this patch:

  1) marks constants that IPA-modref has in its kill list with a new
 "killed" flag, and
  2) prunes the list from entries with this flag after materialization
 and IPA-CP transformation is done using the template introduced in
 the previous patch

It does not try to look up anything in the load lists, this will be
done as a follow-up in order to ease review.

gcc/ChangeLog:

2023-10-27  Martin Jambor  

PR ipa/57
* ipa-prop.h (struct ipa_argagg_value): Newf flag killed.
* ipa-modref.cc (ipcp_argagg_and_kill_overlap_p): New function.
(update_signature): Mark any any IPA-CP aggregate constants at
positions known to be killed as killed.  Move check that there is
clone_info after this pruning.
* ipa-cp.cc (ipa_argagg_value_list::dump): Dump the killed flag.
(ipa_argagg_value_list::push_adjusted_values): Clear the new flag.
(push_agg_values_from_plats): Likewise.
(ipa_push_agg_values_from_jfunc): Likewise.
(estimate_local_effects): Likewise.
(push_agg_values_for_index_from_edge): Likewise.
* ipa-prop.cc (write_ipcp_transformation_info): Stream the killed
flag.
(read_ipcp_transformation_info): Likewise.
(ipcp_get_aggregate_const): Update comment, assert that encountered
record does not have killed flag set.
(ipcp_transform_function): Prune all aggregate constants with
killed
set.

gcc/testsuite/ChangeLog:

2023-09-18  Martin Jambor  

PR ipa/57
* gcc.dg/lto/pr57_0.c: New test.
* gcc.dg/lto/pr57_1.c: Second file of the same new test.

[Bug ipa/111157] [14 Regression] 416.gamess fails with a run-time abort when compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Jambor  ---
Fixed.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 57 Summary: [14 Regression] 416.gamess fails with a run-time abort when 
compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57

   What|Removed |Added

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

[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861

[falemagn at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Fabio Alemagna  ---
(In reply to Marek Polacek from comment #2)
> Confirmed.  Started with r6-6830-g20a0c6f9bdbd78:
> 
> commit 20a0c6f9bdbd781ed5d413a10a06764a174dc394
> Author: Patrick Palka 
> Date:   Mon Feb 8 23:02:50 2016 +
> 
> Fix PR c++/69283 (auto deduction fails when ADL is required)
> 
> but reverting that fix doesn't make the ICE go away.

That seems wy to old to be the cause of the issue.

As said, it works with v13.2.1

[Bug tree-optimization/111878] [14 Regression] ICE: in get_loop_exit_edges, at cfgloop.cc:1204 with -O3 -fgraphite-identity -fsave-optimization-record/-fdump-tree-graphite/-fopt-info

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

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

--- Comment #4 from Martin Jambor  ---
I am not 100% certain if it is the same bug (I am happy to open a separate bug
report if not), but I'm getting an ICE on the same spot, also with graphite,
when running

gfortran ~/gcc/trunk/src/libgomp/testsuite/libgomp.fortran/simd7.f90
-floop-nest-optimize -O1

with master revision 89e97f655d6 gfortran (and the above libgomp test).

[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Fabio Alemagna from comment #4)
> (In reply to Marek Polacek from comment #2)
> > Confirmed.  Started with r6-6830-g20a0c6f9bdbd78:
> > 
> > commit 20a0c6f9bdbd781ed5d413a10a06764a174dc394
> > Author: Patrick Palka 
> > Date:   Mon Feb 8 23:02:50 2016 +
> > 
> > Fix PR c++/69283 (auto deduction fails when ADL is required)
> > 
> > but reverting that fix doesn't make the ICE go away.
> 
> That seems wy to old to be the cause of the issue.
> 
> As said, it works with v13.2.1

Note the trunk has extra checkings enabled compared to a release if not
configured with `--enable-checking=release` so you might be seeing that effect
here.

[Bug target/112295] RISC-V: Short forward branch pessimisation for ALU operations

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-10-30
 Ever confirmed|0   |1
 CC||palmer at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from palmer at gcc dot gnu.org ---
IIRC something along these lines came up when originally doing the SFB stuff. 
I don't remember if the SiFive 7-series can fuse the proposed code as there's
an extra a0 read in there.  I do remember missing some fusion opportunities but
deciding they weren't worth worrying about at the time as the CMOV got most of
the benefit.

Even if SiFive can't fuse these, we'll probably end up with implementations
that can at some point.  So IMO it's a valid missed optimization.

[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861

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

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

--- Comment #6 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Fabio Alemagna from comment #4)
> > (In reply to Marek Polacek from comment #2)
> > > Confirmed.  Started with r6-6830-g20a0c6f9bdbd78:
> > > 
> > > commit 20a0c6f9bdbd781ed5d413a10a06764a174dc394
> > > Author: Patrick Palka 
> > > Date:   Mon Feb 8 23:02:50 2016 +
> > > 
> > > Fix PR c++/69283 (auto deduction fails when ADL is required)
> > > 
> > > but reverting that fix doesn't make the ICE go away.
> > 
> > That seems wy to old to be the cause of the issue.
> > 
> > As said, it works with v13.2.1
> 
> Note the trunk has extra checkings enabled compared to a release if not
> configured with `--enable-checking=release` so you might be seeing that
> effect here.

That's right.  Trunk configured with --enable-checking=release doesn't ICE,
either.

[Bug target/112276] [14 Regression] wrong code with -O2 -msse4.2 since r14-4964-g7eed861e8ca3f5

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #6 from Zdenek Sojka  ---
Created attachment 56477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56477&action=edit
testcase failing at -O2

$ x86_64-pc-linux-gnu-gcc -O2 testcase.c
$ ./a.out 
Aborted

[Bug target/112297] Failure of pr100936.c on x86_64-apple-darwin21

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

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

--- Comment #2 from Andrew Pinski  ---
Most likely the testcase needs:
/* { dg-require-effective-target nonpic } */

Or something like that.

[Bug tree-optimization/112266] `constcall(a)` and `constcall(&a->b[0])` is not being optimized to one call

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> Whee - late diagnostic fallout galore!  Putting on hold.

I was expecting that. Many of the diagnostic for strings and array bounds, etc.
depend on the original form from the front-end and not a canonical form .

THough I see:
+FAIL: g++.dg/tree-prof/devirt.C scan-tree-dump-times tracer "folding virtual
function call to virtual unsigned int mozPersonalDictionary::_ZThn16" 1


Which is a missed optimization with respect to the devirtualizer depending on
the address form in gimple ...


On the other non-diagnostic issues:

+FAIL: gcc.dg/tree-ssa/pr21294.c scan-tree-dump-times vrp1 "Folding predicate"
1
This just fre now can optimize away the comparison too so disabling fre is
needed now

+FAIL: gcc.dg/tree-ssa/loadpre6.c scan-tree-dump-times pre "Insertions: 1" 1

Most likely a canonical form change.