[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334 --- Comment #24 from rguenther at suse dot de --- On Tue, 11 Jul 2023, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334 > > --- Comment #23 from Jan Hubicka --- > But it would be nice to see why the functions are not early inlined. Note this was on the 13 branch with the C++ fix backported, so before your changes to allow to inline into always-inline. But yes, it would be nice to confirm the issue is gone on trunk and to see where always_inline is still missing (if it is).
[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539 --- Comment #8 from Andrew Pinski --- Let me file a different bug for onezero stuff that I tried out ...
[Bug tree-optimization/110637] New: (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110637
Bug ID: 110637
Summary: (type)(zeroonep !=/== 0) should be optimized as
(type)zeroonep/zeroonep^1 earlier than vrp
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int t)
{
t &= 1;
return t != 0;
}
```
Currently this only gets optimized at -O2 (due to VRP) to:
_4 = t_1(D) & 1;
return _4;
Likewise for:
```
int g(int t)
{
t &= 1;
return t == 0;
}
```
This was originally how I was going to solve PR 110539 but when we should
optimize to those gets in the way of other optimizations so I decided to fix PR
110539 a different way.
[Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110637 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-07-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- See https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623881.html and the reply.
[Bug c/110638] New: [13 regression] memcpy should be inlined with sve loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110638
Bug ID: 110638
Summary: [13 regression] memcpy should be inlined with sve loop
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
* test:https://gcc.godbolt.org/z/39KddjbE4
```
void va(struct args_t * func_args)
{
for (int nl = 0; nl < iterations; nl++) {
for (int i = 0; i < LEN_1D; i++) {
a[i] = b[i];
}
dummy(a, b);
}
return ;
}
```
* gcc12: don't transform the loop into a memcpy call, so it can make use of the
new sve feature.
* gcc13: use a normal 'bl memcpy'
The above regression start from gcc13.
[Bug rtl-optimization/110202] _mm512_ternarylogic_epi64 generates unnecessary operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202 --- Comment #10 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:13c556d6ae84be3ee2bc245a56eafa58221de86a commit r14-2447-g13c556d6ae84be3ee2bc245a56eafa58221de86a Author: liuhongt Date: Thu Jun 29 14:25:28 2023 +0800 Break false dependence for vpternlog by inserting vpxor or setting constraint of input operand to '0' False dependency happens when destination is only updated by pternlog. There is no false dependency when destination is also used in source. So either a pxor should be inserted, or input operand should be set with constraint '0'. gcc/ChangeLog: PR target/110438 PR target/110202 * config/i386/predicates.md (int_float_vector_all_ones_operand): New predicate. * config/i386/sse.md (*vmov_constm1_pternlog_false_dep): New define_insn. (*_cvtmask2_pternlog_false_dep): Ditto. (*_cvtmask2_pternlog_false_dep): Ditto. (*_cvtmask2): Adjust to define_insn_and_split to avoid false dependence. (*_cvtmask2): Ditto. (one_cmpl2): Adjust constraint of operands 1 to '0' to avoid false dependence. (*andnot3): Ditto. (iornot3): Ditto. (*3): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr110438.c: New test. * gcc.target/i386/pr100711-6.c: Adjust testcase.
[Bug target/110438] generating all-ones zmm needs dep-breaking pxor before ternlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:13c556d6ae84be3ee2bc245a56eafa58221de86a commit r14-2447-g13c556d6ae84be3ee2bc245a56eafa58221de86a Author: liuhongt Date: Thu Jun 29 14:25:28 2023 +0800 Break false dependence for vpternlog by inserting vpxor or setting constraint of input operand to '0' False dependency happens when destination is only updated by pternlog. There is no false dependency when destination is also used in source. So either a pxor should be inserted, or input operand should be set with constraint '0'. gcc/ChangeLog: PR target/110438 PR target/110202 * config/i386/predicates.md (int_float_vector_all_ones_operand): New predicate. * config/i386/sse.md (*vmov_constm1_pternlog_false_dep): New define_insn. (*_cvtmask2_pternlog_false_dep): Ditto. (*_cvtmask2_pternlog_false_dep): Ditto. (*_cvtmask2): Adjust to define_insn_and_split to avoid false dependence. (*_cvtmask2): Ditto. (one_cmpl2): Adjust constraint of operands 1 to '0' to avoid false dependence. (*andnot3): Ditto. (iornot3): Ditto. (*3): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr110438.c: New test. * gcc.target/i386/pr100711-6.c: Adjust testcase.
[Bug target/110438] generating all-ones zmm needs dep-breaking pxor before ternlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438 --- Comment #5 from Hongtao.liu --- Should be fixed in GCC14.
[Bug target/110638] [13 regression] memcpy should be inlined with sve loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110638 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c |target --- Comment #1 from Andrew Pinski --- I don't see how this is an issue because memcpy in glibc already uses SVE too ...
[Bug target/110638] [13 regression] memcpy should be inlined with sve loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110638 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Actually this is the correct thing to do. memcpy in glibc has used SVE since glibc commit 9f298bfe1f183804bb54b54ff9071afc0494906c .
[Bug tree-optimization/110637] (type)(zeroonep !=/== 0) should be optimized as (type)zeroonep/zeroonep^1 earlier than vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110637 --- Comment #2 from Richard Biener --- Maybe zero_one_valued_p needs a (match zero_one_valued_p (bit_and @0 integer_onep)) ? (hopefully for signed 1-bit precision that doesn't match)
[Bug tree-optimization/110630] Missed optimization: bb-slp-pr95839.c not vectorised with V2SF targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110630
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2023-07-12
Ever confirmed|0 |1
Keywords||missed-optimization
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
typedef float __attribute__((vector_size(32))) v8f32;
v8f32 f(v8f32 a, v8f32 b)
{
/* Check that we vectorize this CTOR without any loads. */
return (v8f32){a[0] + b[0], a[1] + b[1], a[2] + b[2], a[3] + b[3],
a[4] + b[4], a[5] + b[5], a[6] + b[6], a[7] + b[7]};
}
fails to optimally vectorize with SSE2 on x86_64 (would need AVX2).
It works OK when avoiding ABI issues like with the following so the
importance of fixing this might be low.
typedef float __attribute__((vector_size(32))) v8f32;
v8f32 a, b;
v8f32 res;
void f()
{
/* Check that we vectorize this CTOR without any loads. */
res = (v8f32){a[0] + b[0], a[1] + b[1], a[2] + b[2], a[3] + b[3],
a[4] + b[4], a[5] + b[5], a[6] + b[6], a[7] + b[7]};
}
the issue on x86_64 is that we run into
t.c:6:10: note: vectorizing permutation op0[0] op0[1] op0[2] op0[3] op0[4]
op0[5] op0[6] op0[7]
t.c:6:10: note: vectorizing permutation op0[0] op0[1] op0[2] op0[3] op0[4]
op0[5] op0[6] op0[7]
t.c:6:10: note: as vops0[0][0] vops0[0][1] vops0[0][2] vops0[0][3],
vops0[0][4] vops0[0][5] vops0[0][6] vops0[0][7]
t.c:6:10: missed: unsupported vect permute { 4 5 6 7 }
t.c:6:10: note: Building vector operands of 0x47865f0 from scalars instead
the issue on mips with -mpaired-single is the same:
t.c:6:10: note: vectorizing permutation op0[0] op0[1] op0[2] op0[3]
t.c:6:10: note: vectorizing permutation op0[0] op0[1] op0[2] op0[3]
t.c:6:10: note: as vops0[0][0] vops0[0][1], vops0[0][2] vops0[0][3]
t.c:6:10: missed: unsupported vect permute { 2 3 }
but interestingly it doesn't emit any psABI warning so maybe it has a
defined ABI for the V4SFmode vectors.
The fix is to vectorizable_slp_permutation to try a vector extraction as well,
or for BLKmode vector operands simply allow this to go through.
[Bug target/110217] [avr] SREG: use BSET and BCLR instead of load/modify/write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110217 --- Comment #3 from Georg-Johann Lay --- At least CLI / SBI won't glitch at O0, same for ATOMIC_BLOCK. For SBI et al. you are right, they rely on insn combine. The right approach would have been compiler built-ins or API using inline asm. But the time to introduce such interfaces was 20 or so years ago...
[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 --- Comment #6 from Eric Botcazou --- Sorry, no, NetBSD/sparc is too obscure a platform to justify changing the default for the entire compiler. But you can do like Linux & Solaris and add sparc/tso.h to the tm_file list of sparc-*-netbsdelf*) in config.gcc.
[Bug middle-end/110639] New: [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639
Bug ID: 110639
Summary: [OpenMP][5.1] Predefined firstprivate for pointers -
attachment missing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
OpenMP 5.1 changed (quoting GCC impl. status):
Pointer predetermined firstprivate getting initialized to address of matching
mapped list item per 5.1, Sect. 2.21.7.2
However, looking at the examples in the OpenMP spec issue #1796 (TRAC864) this
does not handle partially mapped data correctly:
int a[100];
int *p = &a[0];
#pragma omp target teams distribute map(a[start:n])
for (int i = start; i < start+n; i++) {
p[i] = f(p[i], i);
}
Here, 'p' has an points to 'a' (actually, to the base address of 'a') but this
address is not mapped. However, it still points to the extended address range
of mapped data.
[Bug tree-optimization/110630] Missed optimization: bb-slp-pr95839.c not vectorised with V2SF targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110630 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 110630, which changed state. Bug 110630 Summary: Missed optimization: bb-slp-pr95839.c not vectorised with V2SF targets https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110630 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/110630] Missed optimization: bb-slp-pr95839.c not vectorised with V2SF targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110630 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:25f831eab368d1bbec4dc67bf058cb7cf6b721ee commit r14-2460-g25f831eab368d1bbec4dc67bf058cb7cf6b721ee Author: Richard Biener Date: Wed Jul 12 11:19:58 2023 +0200 tree-optimization/110630 - enhance SLP permute support The following enhances the existing lowpart extraction support for SLP VEC_PERM nodes to cover all vector aligned extractions. This allows the existing bb-slp-pr95839.c testcase to be vectorized with mips -mpaired-single and the new bb-slp-pr95839-3.c testcase with SSE2. PR tree-optimization/110630 * tree-vect-slp.cc (vect_add_slp_permutation): New offset parameter, honor that for the extract code generation. (vectorizable_slp_permutation_1): Handle offsetted identities. * gcc.dg/vect/bb-slp-pr95839.c: Make stricter. * gcc.dg/vect/bb-slp-pr95839-3.c: New variant testcase.
[Bug target/91103] AVX512 vector element extract uses more than 1 shuffle instruction; VALIGND can grab any element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91103 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Fixed.
[Bug middle-end/88873] missing vectorization for decomposed operations on a vector type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873 --- Comment #7 from Richard Biener --- Didn't yet help for the original testcase in the description. We RTL expand from vect__1.11_14 = MEM [(double *)&c]; vect__2.5_12 = MEM [(double *)&b]; vect__3.8_13 = MEM [(double *)&a]; vect__4.12_15 = .FMA (vect__2.5_12, vect__3.8_13, vect__1.11_14); MEM [(double *)&D.4349] = vect__4.12_15; return D.4349; and get (insn 2 21 3 2 (set (reg:DF 91) (reg:DF 20 xmm0 [ a ])) "t.c":8:1 -1 (nil)) (insn 3 2 4 2 (set (reg:DF 92) (reg:DF 21 xmm1 [ a+8 ])) "t.c":8:1 -1 (nil)) (insn 4 3 5 2 (set (reg:TI 90) (const_int 0 [0])) "t.c":8:1 -1 (nil)) (insn 5 4 6 2 (set (subreg:DF (reg:TI 90) 0) (reg:DF 91)) "t.c":8:1 -1 (nil)) (insn 6 5 7 2 (set (subreg:DF (reg:TI 90) 8) (reg:DF 92)) "t.c":8:1 -1 (nil)) (insn 7 6 8 2 (set (reg/v:TI 89 [ a ]) (reg:TI 90)) "t.c":8:1 -1 (nil)) ... (insn 23 20 24 2 (set (reg:V2DF 85 [ vect__4.12 ]) (fma:V2DF (subreg:V2DF (reg/v:TI 93 [ b ]) 0) (subreg:V2DF (reg/v:TI 89 [ a ]) 0) (subreg:V2DF (reg/v:TI 97 [ c ]) 0))) "t.c":9:18 -1 (nil)) so the ABI passess struct s_t in two %xmm regs but the backend gives it TImode. Nothing cleans this up, we end up with horrible code in the end. The subreg pass is likely "confused" by the V2DFmode subreg of the TImode pseudos, maybe it needs to learn to turn the TImode pseudo into a V2DFmode one ...
[Bug fortran/102003] [PDT] Length of character component not simplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102003 --- Comment #4 from CVS Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:f9182da3213aa57c16dd0b52862126de4a259f6a commit r14-2461-gf9182da3213aa57c16dd0b52862126de4a259f6a Author: Andre Vehreschild Date: Wed Jul 12 12:51:30 2023 +0200 gfortran: Allow ref'ing PDT's len() in parameter-initializer. Fix declaring a parameter initialized using a pdt_len reference not simplifying the reference to a constant. 2023-07-12 Andre Vehreschild gcc/fortran/ChangeLog: PR fortran/102003 * expr.cc (find_inquiry_ref): Replace len of pdt_string by constant. (simplify_ref_chain): Ensure input to find_inquiry_ref is NULL. (gfc_match_init_expr): Prevent PDT analysis for function calls. (gfc_pdt_find_component_copy_initializer): Get the initializer value for given component. * gfortran.h (gfc_pdt_find_component_copy_initializer): New function. * simplify.cc (gfc_simplify_len): Replace len() of PDT with pdt component ref or constant. gcc/testsuite/ChangeLog: * gfortran.dg/pdt_33.f03: New test.
[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 --- Comment #7 from Taylor R Campbell --- > Sorry, no, NetBSD/sparc is too obscure a platform to justify changing the > default for the entire compiler. But you can do like Linux & Solaris and > add sparc/tso.h to the tm_file list of sparc-*-netbsdelf*) in config.gcc. I don't understand, how would that help? As I understand it, whenever `-mcpu=v7', the memory model is just ignored -- even if we set it to TSO -- because all rules that depend on it are gated on TARGET_V8 || TARGET_V9 or similar. I'm not asking for you to change defaults in Linux or Solaris -- I'm just asking to be _able_ to say `-mcpu=v7 -mmemory-model=tso' and get v7-only instruction streams with the LDSTUBs needed for TSO. Right now, with `-mcpu=v7', passing `-mmemory-model=tso' has no effect.
[Bug c/110640] New: Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110640
Bug ID: 110640
Summary: Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
This looks like a regression since GCC-13. gcc produces wrong code at -O2/3.
Compiler explorer: https://godbolt.org/z/5MWe6eK8M
$ cat a.c
unsigned short a = 65535;
int b, f, g;
int *c = &b;
long d;
short e;
static int *h(int);
void i() { h(a); }
int *h(int j) {
unsigned char k;
for (; e != 8; e = e + 4)
k = 0;
for (; (unsigned char)(j-181249535) + k <= 1; k++) {
*c = d;
for (; f; f++)
;
}
return &g;
}
int main() { i(); }
$
$ gcc-tk -O0 a.c && ./a.out
$
$ gcc-tk -O2 a.c
$ ./a.out
Killed
$ gcc-tk -O3 a.c
$ ./a.out
Killed
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-322d17ae51ea0137167424e0018d7fa355948f9f/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-322d17ae51ea0137167424e0018d7fa355948f9f
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230711 (experimental) (GCC)
$
[Bug c/110641] New: ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641
Bug ID: 110641
Summary: ICE in adjust_loop_info_after_peeling, at
tree-ssa-loop-ivcanon.cc:1023
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
This looks like a recent regression.
Compiler explorer: https://godbolt.org/z/55EzjdoTK
$ cat a.c
int a, b, c, d, e, g;
int *f;
short **h;
int i() {}
int j() { return a && a <= 'F' || a >= 'a' && a <= 'f'; }
int k() {
d = 0;
for (; d < 2; d = i())
e = b = 0;
for (; e - 71 + b; b++)
;
for (;; c--) {
g = 0;
for (; j() + c + g >= 0; g--)
**h = (char)b + b || f;
}
}
int main() {}
$
$ gcc-tk -O3 a.c
during GIMPLE pass: ch_vect
crash_0_reduced.c: In function ‘k’:
crash_0_reduced.c:6:5: internal compiler error: in
adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023
6 | int k() {
| ^
0x7f7b0bec4082 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/110598] [14 Regression] wrong code on llvm-14.0.6 due to memcmp being miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110598 --- Comment #5 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:d2c18b4a16f9e1a6ed271ec1efaf94533d1c4a94 commit r14-2465-gd2c18b4a16f9e1a6ed271ec1efaf94533d1c4a94 Author: Roger Sayle Date: Wed Jul 12 14:12:34 2023 +0100 PR target/110598: Fix rega = 0; rega ^= rega regression in i386.md This patch fixes the regression PR target/110598 caused by my recent addition of a peephole2. The intention of that optimization was to simplify zeroing a register, followed by an IOR, XOR or PLUS operation on it into a move, or as described in the comment: ;; Peephole2 rega = 0; rega op= regb into rega = regb. The issue is that I'd failed to consider the (rare and unusual) case, where regb is rega, where the transformation leads to the incorrect "rega = rega", when it should be "rega = 0". The minimal fix is to add a !reg_mentioned_p check to the recent peephole2. In addition to resolving the regression, I've added a second peephole2 to optimize the problematic case above, which contains a false dependency and is therefore tricky to optimize elsewhere. This is an improvement over GCC 13, for example, that generates the redundant: xorl%edx, %edx xorq%rdx, %rdx 2023-07-12 Roger Sayle gcc/ChangeLog PR target/110598 * config/i386/i386.md (peephole2): Check !reg_mentioned_p when optimizing rega = 0; rega op= regb for op in [XOR,IOR,PLUS]. (peephole2): Simplify rega = 0; rega op= rega cases. gcc/testsuite/ChangeLog PR target/110598 * gcc.target/i386/pr110598.c: New test case.
[Bug target/91681] Missed optimization for 128 bit arithmetic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91681 --- Comment #5 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:275a2124e4928c88bd5469096356ba393b6aadfb commit r14-2466-g275a2124e4928c88bd5469096356ba393b6aadfb Author: Roger Sayle Date: Wed Jul 12 14:14:15 2023 +0100 i386: Fix FAIL of gcc.target/i386/pr91681-1.c The recent change in TImode parameter passing on x86_64 results in the FAIL of pr91681-1.c. The issue is that with the extra flexibility, the combine pass is now spoilt for choice between using either the *add3_doubleword_concat or the *add3_doubleword_zext patterns, when one operand is a *concat and the other is a zero_extend. The solution proposed below is provide an *add3_doubleword_concat_zext define_insn_and_split, that can benefit both from the register allocation of *concat, and still avoid the xor normally required by zero extension. I'm investigating a follow-up refinement to improve register allocation further by avoiding the early clobber in the =&r, and handling (custom) reloads explicitly, but this piece resolves the testcase failure. 2023-07-12 Roger Sayle gcc/ChangeLog PR target/91681 * config/i386/i386.md (*add3_doubleword_concat_zext): New define_insn_and_split derived from *add3_doubleword_concat and *add3_doubleword_zext.
[Bug c++/110006] [11/12/13/14 Regression] friend function template with constraint doesn't match existing declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110006 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Patrick Palka --- Started with r11-3261-gb28b621ac67bee
[Bug target/91681] Missed optimization for 128 bit arithmetic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91681 --- Comment #6 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:30dbfcd86c364da8491634ed4f99def184e2d042 commit r14-2467-g30dbfcd86c364da8491634ed4f99def184e2d042 Author: Roger Sayle Date: Wed Jul 12 14:43:37 2023 +0100 i386: Fix FAIL of gcc.target/i386/pr91681-1.c I committed the wrong version of this patch (with a typo). Updating to the correct bootstrapped and regression tested version as obvious. 2023-07-12 Roger Sayle gcc/ChangeLog PR target/91681 * config/i386/i386.md (*add3_doubleword_concat_zext): Typo.
[Bug c++/110642] New: Undefined behavior in same constant expression is found not always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110642
Bug ID: 110642
Summary: Undefined behavior in same constant expression is
found not always
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This lambda
auto f = [](int i) {
const auto y = i;
return [&] () {
return y;
};
};
returns another lambda that makes undefined behavior: it accesses a stack
variable (y) after the end of its life.
And it is successfully caught during constant expression evaluation by GCC and
other compilers, if verified like this:
constexpr auto g = f(3)();
static_assert( f(3)() == 3 );
Online demo: https://gcc.godbolt.org/z/3Y4cGMG15
But if one changes the order of lines:
static_assert( f(3)() == 3 );
constexpr auto g = f(3)();
then GCC stops detecting undefined behavior. Online demo:
https://gcc.godbolt.org/z/dojhKasPs
Could you please review why this happens?
[Bug c++/110584] [11/12/13/14 Regression] Constant is not visible in nested lambda with outer lambda having a default capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110584 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Patrick Palka --- Started with r8-4571-gc1051bf7d8c99d.
[Bug tree-optimization/110641] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Keywords||ice-on-valid-code Target Milestone|--- |14.0 Component|c |tree-optimization Summary|ICE in |[14 Regression] ICE in |adjust_loop_info_after_peel |adjust_loop_info_after_peel |ing, at |ing, at |tree-ssa-loop-ivcanon.cc:10 |tree-ssa-loop-ivcanon.cc:10 |23 |23
[Bug c/110640] [13/14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110640 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.2 Summary|Wrong code at -O2/3 on |[13/14 Regression] Wrong |x86_64-linux-gnu since |code at -O2/3 on |GCC-13 |x86_64-linux-gnu since ||GCC-13 Keywords||needs-bisection, wrong-code
[Bug tree-optimization/110640] [13/14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110640 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Last reconfirmed||2023-07-12 Component|c |tree-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. Adding -fno-tree-vrp avoids the issue.
[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #18 from Mikael Pettersson --- Since the fix has been backported to gcc-13 branch, can this be closed now?
[Bug target/110643] New: arm64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 Bug ID: 110643 Summary: arm64: Miscompilation at O1 level (O0 is working) Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: malat at debian dot org Target Milestone: --- I am seeing a test failure in highway test-suite when using GCC 13.1.0 compared to GCC 12.3.0. Symptoms: ``` Start 111: HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES # GetParam() = 536870912 111: Test command: /home/malat/highway/bin/tests/math_test "--gtest_filter=HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES" "--gtest_also_run_disabled_tests" 111: Working Directory: /home/malat/highway/bin 111: Test timeout computed to be: 1500 111: Running main() from ./googletest/src/gtest_main.cc 111: Note: Google Test filter = HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES 111: [==] Running 1 test from 1 test suite. 111: [--] Global test environment set-up. 111: [--] 1 test from HwyMathTestGroup/HwyMathTest 111: [ RUN ] HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES 111: Mismatch for i=14 expected 2.356194 actual 3.141593 111: Abort at /home/malat/highway/hwy/contrib/math/math_test.cc:401: Assert 0 1/1 Test #111: HwyMathTestGroup/HwyMathTest.TestAllAtan2/NEON_WITHOUT_AES # GetParam() = 536870912 ...Subprocess aborted***Exception: 0.01 sec ```
[Bug target/110643] arm64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #1 from Mathieu Malaterre --- Upstream ref: * https://github.com/google/highway/issues/1549
[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #19 from Thomas Neumann --- I think we can close this bug as fixed, but I do not have permissions to do that.
[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||xry111 at gcc dot gnu.org --- Comment #20 from Xi Ruoyao --- (In reply to Thomas Neumann from comment #19) > I think we can close this bug as fixed, but I do not have permissions to do > that. Closing.
[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 --- Comment #8 from Koakuma --- Created attachment 55529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55529&action=edit Proposed patch for relaxing the guards of barrier emission Hello, sorry that I only got to reply now. And yeah, I first noticed it when I was trying out some C++ concurrency tutorials. A bit weird, I admit... That being said, > Sorry, no, NetBSD/sparc is too obscure a platform to justify changing the > default for the entire compiler. Understood. So the memory model default should not change, that is okay. (And I believe the NetBSD folks also agree with me on this?) However... > But you can do like Linux & Solaris and add sparc/tso.h to the tm_file list > of sparc-*-netbsdelf*) in config.gcc. As Campbell has said, the thing is that this (and -mmemory-model=tso) currently does not work when targeting v7 because all the barrier emitters are gated with TARGET_V8 || TARGET_V9. (By the way, `-mcpu=v7 -mmemory-model=tso` is broken on Linux too, for the same reason) Attached is a patch to relax the barrier requirements such that it is possible to emit the ldstub barriers even when targeting v7. This does not change any defaults, but, crucially, it does allow -mmemory-model=tso to be used with v7 target. There is probably some better way to do it - I am unfamiliar with GCC internals - but so far it has been working fine to me. What do you think? Would it be okay if it is only changed in this way?
[Bug target/110643] arm64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 Andrew Pinski changed: What|Removed |Added Target|arm64 |aarch64 Keywords||wrong-code --- Comment #2 from Andrew Pinski --- arm64 is not a thing ... (ok, it is the arch name for Linux kernel but that is it).
[Bug target/110643] arm64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #3 from Andrew Pinski --- Does -ffp-contract=on help?
[Bug fortran/110644] New: Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 Bug ID: 110644 Summary: Error in gfc_format_decoder Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kyle.shores44 at gmail dot com Target Milestone: --- I moved from gcc 11 to gcc 13.1 recently. I have a library that compiled with gcc 11 but cannot be compiled with gcc 13 without moving use statements out of functions and subroutines and also changing the order of the use statements. I would like to provide a small example but I could not figure out how to replicate this when writing a smaller program. However, here is a PR (https://github.com/NCAR/tuv-x/pull/272) that shows changes to files that allow them to compile. I have not been able to compile the entire project yet, but I have noticed that in general if I put the use statements in the order that the imported content is used in the rest of the file that I can compile. Sadly, this pattern doesn't always seem to be true. After I finish getting the full project compiled, maybe I'll learn enough to create a smaller example that better reproduces the error. The error I get is not very useful: `in gfc_format_decoder, at fortran/error.cc:1078` I added the line to get the bug report, but I don't see any temporary files created.
[Bug target/110643] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-07-12 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #4 from Andrew Pinski --- We are going to need a self contained testcase to figure this out ...
[Bug target/110598] [14 Regression] wrong code on llvm-14.0.6 due to memcmp being miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110598 --- Comment #6 from Sergei Trofimovich --- The change fixed test suite on llvm-14.0.6 and on llvm-12.0.1. Thank you!
[Bug tree-optimization/110640] [13/14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110640 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > Confirmed. Adding -fno-tree-vrp avoids the issue. Using -fdisable-tree-vrp1 avoids the issue ...
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Attachment #55522|0 |1 is obsolete|| --- Comment #78 from Jakub Jelinek --- Created attachment 55530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55530&action=edit gcc14-bitint-wip.patch Division/modulo should now work too.
[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 --- Comment #9 from Eric Botcazou --- > I don't understand, how would that help? As I understand it, whenever > `-mcpu=v7', the memory model is just ignored -- even if we set it to TSO -- > because all rules that depend on it are gated on TARGET_V8 || TARGET_V9 or > simila Well, the subject of the PR is "GCC should default to TSO memory model when compiling for sparc32" so you'll get exactly that. > I'm not asking for you to change defaults in Linux or Solaris -- I'm just > asking to be _able_ to say `-mcpu=v7 -mmemory-model=tso' and get v7-only > instruction streams with the LDSTUBs needed for TSO. Right now, with > `-mcpu=v7', passing `-mmemory-model=tso' has no effect. I'm suggesting changing the default *like* on Linux or Solaris, not to change anything on Linux or Solaris. So you want to mix memory models and synchronization instructions with -mcpu=v7, although they were introduced in the V8 architecture?
[Bug tree-optimization/110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293 --- Comment #5 from Andrew Pinski --- Part 1 of the patch to fix this: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624293.html This weekend I will handle the outer != NE/EQ cases.
[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2023-July/62 |il/gcc-patches/2023-July/62 |3881.html |4293.html --- Comment #9 from Andrew Pinski --- New patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624293.html Which also gets rid of the call to foo at -O1 -fstrict-aliasing too (which was not done in GCC 13 either).
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Unfortunately, we're going to need a reduced testcase. I tried the simple instruction to build tuv-x, but don't have json-fortran.
[Bug c/110645] New: False positive -Warray-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110645 Bug ID: 110645 Summary: False positive -Warray-bounds warning Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: andres at anarazel dot de Target Milestone: --- Created attachment 55531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55531&action=edit reproducer Hi, The attached minimized reproducer (from postgres code) triggers a clearly bogus -Warray-bounds warning, even with -Warray-bounds=1. $ gcc -O1 -Wall -Warray-bounds=1 -c -o /dev/null -c repro.i In function ‘formTextDatum’, inlined from ‘spgist_name_compress’ at /tmp/cvise2/repro.i:44:9: /tmp/cvise2/repro.i:35:17: warning: ‘memcpy’ forming offset [2, 254] is out of the bounds [0, 2] [-Warray-bounds] 35 | memcpy(att->data, src, srclen); | ^~~~ This is despite srclen being strlen(src), which gcc does know is <= 1. It seems that the known range of srclen is "widened" due to the if (srclen < 0xff), causing the warning. It is somewhat interesting that removing -Wall removes the spurious warning, despite -Warray-bounds=1. This triggers for gcc-11 - HEAD at 3b007164b3e, but not in gcc-10. I looked through quite a few bugs about spurious -Warray-bounds warnings to see if this is a duplicate - quite possible, but I didn't find a real match for this. Regards, Andres
[Bug tree-optimization/105832] [13/14 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832
--- Comment #10 from Andrew Pinski ---
I think the simple way of fixing this is optimizing:
```
bool f(int g)
{
return (1 >> g) != 0;
}
```
into
```
bool f0(int g)
{
return g == 0;
}
```
In threadfull1 (before vrp1) we have:
```
[local count: 894749065]:
if (iftmp.0_6 <= 1)
goto ; [41.00%]
else
goto ; [59.00%]
[local count: 366847113]:
_3 = (int) iftmp.0_6;
_4 = 1 >> _3;
if (_4 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 183423557]:
iftmp.1_12 = iftmp.0_6 << 1;
[local count: 894749065]:
# iftmp.1_7 = PHI
```
if we optimize the bb6 to:
```
if (iftmp.0_6 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
```
We should be able to ifcombine the 2 GIMPLE to just:
iftmp.0_6 != 0 && iftmp.0_6 <= 1
Which then will unswitch correctly ...
[Bug tree-optimization/105832] [13/14 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832 --- Comment #11 from Jeffrey A. Law --- Looks viable to me. Are you thinking match.pd?
[Bug libstdc++/110646] New: gensupport.cc:643:18: error: 'stoi' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110646 Bug ID: 110646 Summary: gensupport.cc:643:18: error: 'stoi' is not a member of 'std' Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Created attachment 55532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55532&action=edit Fix for build error. g++ -std=c++11 -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwi nd-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmiss ing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include \ -o build/gensupport.o ../../gcc/gcc/gensupport.cc ../../gcc/gcc/gensupport.cc: In constructor 'conlist::conlist(const char*, unsigned int, bool)': ../../gcc/gcc/gensupport.cc:643:18: error: 'stoi' is not a member of 'std'; did you mean 'atoi'? 643 | idx = std::stoi (name); | ^~~~ | atoi Build gcc is: gcc version 12.2.1 20230420 [remotes/origin/releases/gcc-12 r12-9449-g3907147aa9 b] (GCC) libstdc++ provides std::stoi in basic_string.h when _GLIBCXX_USE_C99_STDLIB is 1. However, hpux11.11 lacks all the routines needed when _GLIBCXX_USE_C99_STDLIB is 1. But it does have strtol, atol, atoi, strtoul, strtod and atof. strtoll and strtoull are not needed on hppa64 as long long and long are equivalent. So it seems the string conversion routines could be provided in basic_string.h for this target.
[Bug fortran/110576] ICE on compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||ice-on-valid-code
CC||anlauf at gcc dot gnu.org
Last reconfirmed||2023-07-12
--- Comment #5 from anlauf at gcc dot gnu.org ---
ICE confirmed for all versions tested (>= 7 ... 14-trunk).
(gdb) l
9222
9223 bool is_pdt_type = c->ts.type == BT_DERIVED
9224 && c->ts.u.derived->attr.pdt_type;
9225
9226 cdecl = c->backend_decl;
9227 ctype = TREE_TYPE (cdecl);
9228
9229 switch (purpose)
9230{
9231
(gdb) p c->name
$5 = 0x1449f100 "i_mci"
(gdb) p c->backend_decl
$6 = (tree) 0x0
The "i_mci" is a component of type process_mci_entry_t, not a local variable.
This is better seen with a slightly further reduced reproducer.
[Bug fortran/110576] ICE on compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576 --- Comment #6 from anlauf at gcc dot gnu.org --- Created attachment 55533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55533&action=edit Slightly more reduced Commenting out any of the two marked lines avoids the ICE.
[Bug bootstrap/110646] [14 Regression] gensupport.cc:643:18: error: 'stoi' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110646 Andrew Pinski changed: What|Removed |Added Summary|gensupport.cc:643:18: |[14 Regression] |error: 'stoi' is not a |gensupport.cc:643:18: |member of 'std' |error: 'stoi' is not a ||member of 'std' Target Milestone|--- |14.0 Component|libstdc++ |bootstrap
[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110468 --- Comment #15 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:dfbe77ab8a70bc7eb48a96775da04095d933a3a6 commit r12-9767-gdfbe77ab8a70bc7eb48a96775da04095d933a3a6 Author: Patrick Palka Date: Thu Jun 29 16:10:18 2023 -0400 c++: NSDMI instantiation during overload resolution [PR110468] Here we find ourselves instantiating the NSDMI for A<1>::m when computing argument conversions during overload resolution, and thus tf_conv is set. The flag causes mark_used for the constructor used in the NSDMI to exit early and not instantiate its noexcept-spec, which eventually leads to an ICE from nothrow_spec_p. This patch fixes this by clearing any special tsubst flags during instantiation of an NSDMI, since the result should be independent of the context that requires the instantiation. PR c++/110468 gcc/cp/ChangeLog: * init.cc (maybe_instantiate_nsdmi_init): Mask out all tsubst flags except for tf_warning_or_error. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept79.C: New test. (cherry picked from commit 9479da4515f7d019b4ef282d0e21536431c44f71)
[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110468 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Patrick Palka --- Fixed for GCC 12.4/13.2/14, thanks for the bug report!
[Bug fortran/110576] ICE in structure_alloc_comps, at trans-array.cc:9227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|ICE on compilation |ICE in ||structure_alloc_comps, at ||trans-array.cc:9227 --- Comment #7 from anlauf at gcc dot gnu.org --- Adjusting summary to better reflect location of segfault.
[Bug target/110598] [14 Regression] wrong code on llvm-14.0.6 due to memcmp being miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110598 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to work||14.0 --- Comment #7 from Roger Sayle --- Many thanks to Sergei for confirming this issue is now resolved. Sorry again for the inconvenience.
[Bug target/110217] [avr] SREG: use BSET and BCLR instead of load/modify/write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110217 --- Comment #4 from Georg-Johann Lay --- At least CLI / SBI won't glitch at O0, same for ATOMIC_BLOCK. For SBI et al. you are right, they rely on insn combine. The right approach would have been compiler built-ins or API using inline asm. But the time to introduce such interfaces was 20 or so years ago...
[Bug libstdc++/110574] --enable-cstdio=stdio_pure is incompatible with LFS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2f6bbc9a7d9a62423c576e13dc46323fe16ba5aa commit r14-2476-g2f6bbc9a7d9a62423c576e13dc46323fe16ba5aa Author: Jonathan Wakely Date: Thu Jul 6 17:10:41 2023 +0100 libstdc++: Fix --enable-cstdio=stdio_pure [PR110574] When configured with --enable-cstdio=stdio_pure we need to consistently use fseek and not mix seeks on the file descriptor with reads and writes on the FILE stream. There are also a number of bugs related to error handling and return values, because fread and fwrite return 0 on error, not -1, and fseek returns 0 on success, not the file offset. libstdc++-v3/ChangeLog: PR libstdc++/110574 * acinclude.m4 (GLIBCXX_CHECK_LFS): Check for fseeko and ftello and define _GLIBCXX_USE_FSEEKO_FTELLO. * config.h.in: Regenerate. * configure: Regenerate. * config/io/basic_file_stdio.cc (xwrite) [_GLIBCXX_USE_STDIO_PURE]: Check for fwrite error correctly. (__basic_file::xsgetn) [_GLIBCXX_USE_STDIO_PURE]: Check for fread error correctly. (get_file_offset): New function. (__basic_file::seekoff) [_GLIBCXX_USE_STDIO_PURE]: Use fseeko if available. Use get_file_offset instead of return value of fseek. (__basic_file::showmanyc): Use get_file_offset.
[Bug libstdc++/95048] [11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #27 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d6384ad1a9ab7ea46990a7ed1299d5a2be4acece commit r14-2478-gd6384ad1a9ab7ea46990a7ed1299d5a2be4acece Author: Jonathan Wakely Date: Wed Jul 12 14:40:19 2023 +0100 libstdc++: Check conversion from filesystem::path to wide strings [PR95048] The testcase added for this bug only checks conversion from wide strings on construction, but the fix also covered conversion to wide stings via path::wstring(). Add checks for that, and u16string() and u32string(). libstdc++-v3/ChangeLog: PR libstdc++/95048 * testsuite/27_io/filesystem/path/construct/95048.cc: Check conversions to wide strings. * testsuite/experimental/filesystem/path/construct/95048.cc: Likewise.
[Bug bootstrap/110646] [14 Regression] gensupport.cc:643:18: error: 'stoi' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110646 --- Comment #1 from dave.anglin at bell dot net --- Note this occurs in stage1. Bug was introduced in commit 957ae90406591739b68e95ad49a0232faeb74217.
[Bug libstdc++/95048] [11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #28 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:db179779c9416cebb646758d276744f78536cc25 commit r13-7559-gdb179779c9416cebb646758d276744f78536cc25 Author: Jonathan Wakely Date: Wed Jul 12 14:40:19 2023 +0100 libstdc++: Check conversion from filesystem::path to wide strings [PR95048] The testcase added for this bug only checks conversion from wide strings on construction, but the fix also covered conversion to wide strings via path::wstring(). Add checks for that, and u16string() and u32string(). libstdc++-v3/ChangeLog: PR libstdc++/95048 * testsuite/27_io/filesystem/path/construct/95048.cc: Check conversions to wide strings. * testsuite/experimental/filesystem/path/construct/95048.cc: Likewise. (cherry picked from commit d6384ad1a9ab7ea46990a7ed1299d5a2be4acece)
[Bug libstdc++/95048] [11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #29 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:530b749c71d7aaaf965d53227911411572c35146 commit r12-9768-g530b749c71d7aaaf965d53227911411572c35146 Author: Jonathan Wakely Date: Wed Jul 12 14:40:19 2023 +0100 libstdc++: Check conversion from filesystem::path to wide strings [PR95048] The testcase added for this bug only checks conversion from wide strings on construction, but the fix also covered conversion to wide strings via path::wstring(). Add checks for that, and u16string() and u32string(). libstdc++-v3/ChangeLog: PR libstdc++/95048 * testsuite/27_io/filesystem/path/construct/95048.cc: Check conversions to wide strings. * testsuite/experimental/filesystem/path/construct/95048.cc: Likewise. (cherry picked from commit d6384ad1a9ab7ea46990a7ed1299d5a2be4acece)
[Bug libstdc++/95048] [11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 --- Comment #30 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:470f32f964574febf484edaf9e580067ac97f3b6 commit r11-10906-g470f32f964574febf484edaf9e580067ac97f3b6 Author: Jonathan Wakely Date: Wed Jul 12 14:40:19 2023 +0100 libstdc++: Check conversion from filesystem::path to wide strings [PR95048] The testcase added for this bug only checks conversion from wide strings on construction, but the fix also covered conversion to wide strings via path::wstring(). Add checks for that, and u16string() and u32string(). libstdc++-v3/ChangeLog: PR libstdc++/95048 * testsuite/27_io/filesystem/path/construct/95048.cc: Check conversions to wide strings. * testsuite/experimental/filesystem/path/construct/95048.cc: Likewise. (cherry picked from commit d6384ad1a9ab7ea46990a7ed1299d5a2be4acece)
[Bug libstdc++/95048] [11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #24) > Yes, I agree. I'll get those added. Tests updated to include conversion to wide strings with wstring().
[Bug bootstrap/110646] [14 Regression] gensupport.cc:643:18: error: 'stoi' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110646 --- Comment #2 from Jonathan Wakely --- (In reply to John David Anglin from comment #0) > libstdc++ provides std::stoi in basic_string.h when _GLIBCXX_USE_C99_STDLIB > is 1. However, hpux11.11 lacks all the routines needed when > _GLIBCXX_USE_C99_STDLIB is 1. But it does have strtol, atol, atoi, strtoul, > strtod and atof. strtoll and strtoull are not needed on hppa64 as long long > and long are equivalent. So it seems the string conversion routines could > be provided in basic_string.h for this target. Yes, those checks could be more granular. I'll split out the checks needed for std::stoi etc.
[Bug bootstrap/110646] [14 Regression] gensupport.cc:643:18: error: 'stoi' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110646 --- Comment #3 from Jonathan Wakely --- We'll still need to avoid std::stoi in stage1 because the host compiler might not have it, even if we make it available in libstdc++ for stage2 and stage3.
[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 --- Comment #10 from Taylor R Campbell --- (In reply to Eric Botcazou from comment #9) > > I don't understand, how would that help? As I understand it, whenever > > `-mcpu=v7', the memory model is just ignored -- even if we set it to TSO -- > > because all rules that depend on it are gated on TARGET_V8 || TARGET_V9 or > > simila > > Well, the subject of the PR is "GCC should default to TSO memory model when > compiling for sparc32" so you'll get exactly that. But defaulting to TSO doesn't seem to help with generating LDSTUB in sparcv7-only instruction streams, unless I misunderstand how this is different from trying to combine `-mcpu' and `-mmemory-model'? > So you want to mix memory models and synchronization instructions with > -mcpu=v7, although they were introduced in the V8 architecture? Correct. The idea is to have a way to generate code that works both on sparcv7 -- by avoiding v8-only instructions like SMUL/UMUL, as `-mcpu=v7' does -- and on sparcv8 -- by generating LDSTUB instructions where store-before-load ordering is needed, as `-mcpu=v8 -mmemory-model=tso' does. I tried to spell this request as `-mcpu=v7 -mmemory-model=tso' but that doesn't generate the LDSTUB instructions needed for store-before-load ordering. (Note that LDSTUB is available in v7 -- what's new in v8 is the relaxation of store-before-load order of TSO, in contrast to SC. So these requirements aren't contradictory.) Is that how Linux and Solaris work by default? I wasn't able to elicit that behaviour by combining explicit `-mcpu' and `-mmemory-model' options, so I assumed that it wouldn't be possible for it to be the default -- and I don't see how it could work given how the code generation rules for memory barriers are gated on TARGET_V8 || TARGET_V9 or similar.
[Bug middle-end/110647] New: 66% TSVC/s2712 regressoin on N1-neoverse between g:620a35b24a2b6edb (2023-07-01 07:24) and g:80ae426a195a0d03 (2023-07-02 01:37)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110647 Bug ID: 110647 Summary: 66% TSVC/s2712 regressoin on N1-neoverse between g:620a35b24a2b6edb (2023-07-01 07:24) and g:80ae426a195a0d03 (2023-07-02 01:37) Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=356.884.0 this seems to be off noise.
[Bug target/110647] [14 Regression] 66% TSVC/s2712 regressoin on N1-neoverse between g:620a35b24a2b6edb (2023-07-01 07:24) and g:80ae426a195a0d03 (2023-07-02 01:37)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110647 Andrew Pinski changed: What|Removed |Added Summary|66% TSVC/s2712 regressoin |[14 Regression] 66% |on N1-neoverse between |TSVC/s2712 regressoin on |g:620a35b24a2b6edb |N1-neoverse between |(2023-07-01 07:24) and |g:620a35b24a2b6edb |g:80ae426a195a0d03 |(2023-07-01 07:24) and |(2023-07-02 01:37) |g:80ae426a195a0d03 ||(2023-07-02 01:37) Version|13.1.0 |14.0 Target Milestone|--- |14.0
[Bug target/110647] [14 Regression] 66% TSVC/s2712 regressoin on N1-neoverse between g:620a35b24a2b6edb (2023-07-01 07:24) and g:80ae426a195a0d03 (2023-07-02 01:37)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110647 --- Comment #1 from Andrew Pinski --- You own patch is the only thing which could have changed code generation during that time period: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7e904d6c7f252ee947c237ed32dd43b2c248384d
[Bug tree-optimization/107053] ones bits is not tracked and popcount is not tracked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053 --- Comment #4 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:137fb7077f7711e2e09ee8f82650fe7d93de6a4d commit r14-2479-g137fb7077f7711e2e09ee8f82650fe7d93de6a4d Author: Aldy Hernandez Date: Fri Jun 30 20:40:02 2023 +0200 [range-op] Take known set bits into account in popcount [PR107053] This patch teaches popcount about known set bits which are now available in the irange. PR tree-optimization/107053 gcc/ChangeLog: * gimple-range-op.cc (cfn_popcount): Use known set bits. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr107053.c: New test.
[Bug tree-optimization/107043] range information not used in popcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043 --- Comment #5 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:7a5e47658904de9dc90f1292f3f69769177706f9 commit r14-2480-g7a5e47658904de9dc90f1292f3f69769177706f9 Author: Aldy Hernandez Date: Thu Jul 6 10:55:46 2023 +0200 [range-op] Take known mask into account for bitwise ands [PR107043] PR tree-optimization/107043 gcc/ChangeLog: * range-op.cc (operator_bitwise_and::op1_range): Update bitmask. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr107043.c: New test.
[Bug tree-optimization/107053] ones bits is not tracked and popcount is not tracked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Aldy Hernandez --- fixed in trunk
[Bug tree-optimization/107043] range information not used in popcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Aldy Hernandez --- Finally... fixed in trunk :).
[Bug c++/110648] New: Missed optimization for small returned optional leads to redundant memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110648
Bug ID: 110648
Summary: Missed optimization for small returned optional leads
to redundant memory accesses
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cfsteefel at arista dot com
Target Milestone: ---
The following code
#include
std::optional< int >
foo( int x ) {
return 1;
}
produces x86_64 assembly which does two stores into the stack, and then a load
into rax, rather than simply operating directly on rax.
i.e.:
foo(int):
mov DWORD PTR [rsp-8], 1
mov BYTE PTR [rsp-4], 1
mov rax, QWORD PTR [rsp-8]
ret
clang produces much more direct code:
foo(int):# @foo(int)
movabs rax, 4294967297
ret
Since the returned value is always returned in rax as the optional is small
enough (less than two registers wide), there is no reason for the memory
accesses here.
The code can be improved by naming the returned object, but this breaks down
again if there are any conditionals, i.e.:
std::optional< int >
foo( int x ) {
std::optional< int > ret = 1;
return ret;
}
produces better code, but there is no way to get this better code once a branch
is introduced, i.e.
std::optional< int >
foo( int x ) {
std::optional< int > ret = 1;
if ( x < 1 ) {
return std::nullopt;
}
return ret;
}
The same applies with godbolts' trunk version of gcc, as well as gcc11.3.
[Bug c++/110648] Missed optimization for small returned optional leads to redundant memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110648 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 95405 ***
[Bug rtl-optimization/95405] Unnecessary stores with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95405 Andrew Pinski changed: What|Removed |Added CC||cfsteefel at arista dot com --- Comment #6 from Andrew Pinski --- *** Bug 110648 has been marked as a duplicate of this bug. ***
[Bug middle-end/101326] std::optional returns forced through stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101326 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup *** This bug has been marked as a duplicate of bug 95405 ***
[Bug rtl-optimization/95405] Unnecessary stores with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95405 Andrew Pinski changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- *** Bug 101326 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/109281] use std::optional results in suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109281 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 95405 ***
[Bug middle-end/101926] [meta-bug] struct/complex/other argument passing and return should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926 Bug 101926 depends on bug 101326, which changed state. Bug 101326 Summary: std::optional returns forced through stack https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101326 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/95383] Poor codegen when constructing a trivial Optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95383 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 95405 ***
[Bug tree-optimization/109281] use std::optional results in suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109281 Bug 109281 depends on bug 101326, which changed state. Bug 101326 Summary: std::optional returns forced through stack https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101326 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug rtl-optimization/95405] Unnecessary stores with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95405 Andrew Pinski changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 95383 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/95405] Unnecessary stores with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95405 Andrew Pinski changed: What|Removed |Added CC||vincenzo.innocente at cern dot ch --- Comment #8 from Andrew Pinski --- *** Bug 109281 has been marked as a duplicate of this bug. ***
[Bug middle-end/101926] [meta-bug] struct/complex/other argument passing and return should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926 Bug 101926 depends on bug 95383, which changed state. Bug 95383 Summary: Poor codegen when constructing a trivial Optional https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95383 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/107053] ones bits is not tracked and popcount is not tracked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/99918] [11/12/13/14 Regression] suboptimal code for bool bitfield tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #11 from Andrew Pinski --- (In reply to Martin Sebor from comment #2) > Bisection points to r225825 as the revision where GCC started to fail to > fold the code in g(). the fold-const didn't check `types_match (type, TREE_TYPE (@0))` but rather just did the equivalent to: (simplify (ne @0 integer_zerop@1) (if (TREE_CODE (TREE_TYPE (@0)) == BOOLEAN_TYPE) (non_lvalue (convert @0 While match now does not do the convert and checks the types_match check instead.
[Bug target/110649] New: 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649 Bug ID: 110649 Summary: 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23) Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- It is seen here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=798.280.0 with -Ofast -march=native Weekly testers seems to show regressions too (all just 1 run so far, so may be a noise) Intel https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=790.280.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=790.280.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=785.280.0 zen1 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=301.280.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=299.280.0 zen3 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=467.280.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=468.280.0
[Bug target/110649] 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649 --- Comment #1 from Andrew Pinski --- 3 profile changes: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3a61ca1b9256535e1bfb19b2d46cde21f3908a5d https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d4c2e34deef8cbd81ba2ef3389fdbaf95c70e225 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2e406f0753e8d78d320437189211e3094c33b7e4 1 vectorizer change: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=224fd59b2dc8a5fa78a309a09863afe9b3cf2111
[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||missed-optimization Target||x86_64-linux-gnu Version|13.1.0 |14.0 Summary|25% sphinx3 spec2006|[14 Regression] 25% sphinx3 |regression on Ice Lake and |spec2006 regression on Ice |zen between |Lake and zen between |g:acaa441a98bebc52 |g:acaa441a98bebc52 |(2023-07-06 11:36) and |(2023-07-06 11:36) and |g:55900189ab517906 |g:55900189ab517906 |(2023-07-07 00:23) |(2023-07-07 00:23)
[Bug bootstrap/110650] New: collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650 Bug ID: 110650 Summary: collect2: fatal error: ld terminated with signal 11 [Segmentation fault] Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: ---
[Bug bootstrap/110650] collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650 --- Comment #1 from Rich Townsend --- Oops, posted without any bug description! I'm trying to build gcc 13.1.0 on Linux x86_64, and I get the following segfault: libtool: compile: /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc -shared-libgcc -B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++ -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-checking -I/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/user/sdk2-tmp/build/gcc/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility-thread-c++0x.lo -g -O2 -D_GNU_SOURCE -std=gnu++11 -c /home/user/sdk2-tmp/build/gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc -o compatibility-thread-c++0x.o >/dev/null 2>&1 /bin/sh ../libtool --tag CXX --mode=link /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc -shared-libgcc -B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++ -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-checking -Wl,-O1 -Wl,-z,relro -Wl,--gc-sections -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:31:0 -Wl,--version-script=libstdc++-symbols.ver -lm -rpath /home/user/sdk2-tmp/mesasdk/lib/../lib64 compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-atomic-c++0x.lo compatibility-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo compatibility-thread-c++0x.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la ../src/c++20/libc++20convenience.la libtool: link: /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc -shared-libgcc -B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++ -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-checking -fPIC -DPIC -D_GLIBCXX_SHARED -shared -nostdlib /usr/lib/../lib64/crti.o /home/user/sdk2-tmp/build/gcc-build/./gcc/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o .libs/compatibility-thread-c++0x.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a ../src/c++17/.libs/libc++17convenience.a ../src/c++20/.libs/libc++20convenience.a -Wl,--no-whole-archive -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -lm -L/home/user/sdk2-tmp/build/gcc-build/./gcc -L/lib/../lib64 -L/usr/lib/../lib64 -lc -lgcc_s /home/user/sdk2-tmp/build/gcc-build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o -Wl,-O1 -Wl,-z -Wl,relro -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.31 collect2: fatal error: ld terminated with signal 11 [Segmentation fault] compilation terminated. make[6]: *** [libstdc++.la] Error 1 make[6]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3' make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[2]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build' make: *** [all] Error 2 FAILED in make for gcc Action install failed for package gcc/gcc-13.1.0
[Bug bootstrap/110650] collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2023-07-13 --- Comment #2 from Andrew Pinski --- Can you provide what version of ld you are using? This is most likely not a gcc bug.
[Bug tree-optimization/88540] Issues with vectorization of min/max operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88540 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #6 from Hongtao.liu --- Note, x86 MINSS/MAXSS is not IEEE-conformant minimum and maximum operations, it always return the second operand when there's NAN, but for fmin/fmax_optab it should return the other operand.
