[Bug other/112485] datestamp on -v recently broken ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112485 --- Comment #3 from David Binderman --- $ for i in results.202311*n/bin/gcc > do > echo $i > $i -v 2>&1 | grep exp > done results.20231102.asan.ubsan/bin/gcc gcc version 14.0.0 20231102 (experimental) (01c18f58d37865d5) results.20231103.asan.ubsan/bin/gcc gcc version 14.0.0 20231103 (experimental) (751fc7bcdcdf25e7) results.20231106.asan.ubsan/bin/gcc gcc version 14.0.0 20231106 (experimental) (b2075291af881079) results.20231107.asan.ubsan/bin/gcc gcc version 14.0.0 20231107 (experimental) (86c913ec92c1b8e8) results.20231108.asan.ubsan/bin/gcc gcc version 14.0.0 20231108 (experimental) (fdd912690344fdfa) results.20231109.asan.ubsan/bin/gcc gcc version 14.0.0 20231109 (experimental) (e01c2eeb2b654abc) results.20231110.asan.ubsan/bin/gcc gcc version 14.0.0 20231109 (experimental) (5dbaf4851bbf56b6) results.2023.asan.ubsan/bin/gcc gcc version 14.0.0 20231109 (experimental) (391f9798b35ec75c) results.20231112.asan.ubsan/bin/gcc gcc version 14.0.0 20231109 (experimental) (e0787da263322fc1) gcc $ So it looks ok with g:e01c2eeb2b654abc and wrong with g:5dbaf4851bbf56b6
[Bug c/112486] New: GCC: 14: hangs with always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112486
Bug ID: 112486
Summary: GCC: 14: hangs with always_inline
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/3n34j7fPT
When try to compile this program with `gcc-14 -O2`:
```
unsigned long flg = 0;
int n_1 = {0};
__attribute__((always_inline))
long sub(unsigned long n) {
int a, b;
if (n_1 >= 2) {
if (n_1 % 2 == 0) {
a = sub(n_1 / 2);
{ return (a & 2 >> sub(n_1 / 2 - 1)) * a; };
} else {
a = sub(n_1 / 2 + 1);
b = sub(n_1 / 2);
return (sub(n_1 / 2)) * a + b * b;
}
} else
return (long)n_1;
}
int main(void) {
if (sub(30) != 832040L) flg |= 0x100L;
if (flg) abort();
exit(0);
}
```
GCC 14 hangs with a lot of output, according to the output, it seems GCC tries
to recursively expand all invocation to `sub`.
The partial output pasted from compiler explorer:
```
In function 'sub',
inlined from 'sub' at :13:11,
inlined from 'sub' at :12:11,
inlined from 'sub' at :13:11,
inlined from 'sub' at :10:26,
inlined from 'sub' at :10:26,
inlined from 'sub' at :10:26,
inlined from 'sub' at :10:26,
inlined from 'sub' at :9:11,
inlined from 'sub' at :9:11,
inlined from 'sub' at :12:11,
inlined from 'sub' at :12:11,
inlined from 'main' at :21:7:
:5:6: error: inlining failed in call to 'always_inline' 'sub':
recursive inlining
5 | long sub(unsigned long n) {
| ^~~
:10:26: note: called from here
10 | { return (a & 2 >> sub(n_1 / 2 - 1)) * a; };
| ^~~~
:5:6: error: inlining failed in call to 'always_inline' 'sub':
recursive inlining
5 | long sub(unsigned long n) {
| ^~~
:9:11: note: called from here
9 | a = sub(n_1 / 2);
| ^~~~
:5:6: error: inlining failed in call to 'always_inline' 'sub':
recursive inlining
5 | long sub(unsigned long n) {
| ^~~
:13:11: note: called from here
13 | b = sub(n_1 / 2);
| ^~~~
:5:6: error: inlining failed in call to 'always_inline' 'sub':
recursive inlining
5 | long sub(unsigned long n) {
| ^~~
:12:11: note: called from here
12 | a = sub(n_1 / 2 + 1);
| ^~~~
In function 'sub',
inlined from 'sub' at :13:11,
inlined from 'sub' at :13:11,
inlined from 'sub' at :10:26,
inlined from 'sub'
[Truncated]
Compiler returned: 143
```
[Bug ipa/112486] GCC: 14: hangs with always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112486 Andrew Pinski changed: What|Removed |Added Component|c |ipa CC||marxin at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- I don't think this is exactly a bug. Gcc recursively inlines sub as much as it can and then it starts to bails out and since there are many calls of sub that it is failing at it takes for every to outputs error messages.
[Bug c/112487] New: GCC: 14: internal compiler error: in setup_one_parameter, at tree-inline.cc:3565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112487
Bug ID: 112487
Summary: GCC: 14: internal compiler error: in
setup_one_parameter, at tree-inline.cc:3565
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Compiler explorer: https://gcc.godbolt.org/z/fjErPvrvP
When compile this program with `gcc-14 -O1`, gcc crashes:
```
struct A { char i; };
struct B {
struct C *p;
struct A *q;
};
struct C { struct B a[1]; };
struct T { struct U *ptr; };
volatile struct T v;
void f1(volatile struct T v) { f2(v); }
void f2(volatile struct T *const v) { }
void bar() {
struct U *ptr;
f1(v);
}
```
The crash output pasted from compiler explorer:
```
: In function 'f1':
:10:32: warning: implicit declaration of function 'f2'; did you mean
'f1'? [-Wimplicit-function-declaration]
10 | void f1(volatile struct T v) { f2(v); }
|^~
|f1
: At top level:
:11:6: warning: conflicting types for 'f2'; have 'void(volatile struct
T * const)'
11 | void f2(volatile struct T *const v) { }
| ^~
:10:32: note: previous implicit declaration of 'f2' with type
'void(volatile struct T * const)'
10 | void f1(volatile struct T v) { f2(v); }
|^~
during IPA pass: inline
: In function 'f1':
:10:32: internal compiler error: in setup_one_parameter, at
tree-inline.cc:3565
10 | void f1(volatile struct T v) { f2(v); }
|^
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0x11c5051 optimize_inline_calls(tree_node*)
???:0
0xe69aeb inline_transform(cgraph_node*)
???:0
0xfec7fb execute_all_ipa_transforms(bool)
???:0
0xbfe2d9 cgraph_node::expand()
???:0
0xc027bb symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug ipa/112486] GCC: 14: hangs with always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112486 wierton <141242068 at smail dot nju.edu.cn> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from wierton <141242068 at smail dot nju.edu.cn> --- Thank you for your reply! I will close this issue.
[Bug c/112488] New: GCC: 14: internal compiler error: in make_ssa_name_fn, at tree-ssanames.cc:354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488
Bug ID: 112488
Summary: GCC: 14: internal compiler error: in make_ssa_name_fn,
at tree-ssanames.cc:354
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Compiler explorer: https://gcc.godbolt.org/z/h9aen36q7
When compile this program with `gcc-14 -O1`, gcc ICEs:
```
extern void abort(void);
int test(int *n) {
struct T { char a[*n], b[*n]; };
return sizeof(struct T) - sizeof(struct T);
}
void f1(int *p) {
if (test(p)) abort();
}
```
The crash output:
```
during IPA pass: inline
In function 'test':
cc1: internal compiler error: in make_ssa_name_fn, at tree-ssanames.cc:354
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0x11bd6ff copy_tree_body_r(tree_node**, int*, void*)
???:0
0x147a55c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x147a8c4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x147a8c4 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x11b8ac9 remap_type(tree_node*, copy_body_data*)
???:0
0x11b8bdf remap_decl(tree_node*, copy_body_data*)
???:0
0x11c5b59 tree_function_versioning(tree_node*, tree_node*,
vec*, ipa_param_adjustments*, bool,
bitmap_head*, basic_block_def*)
???:0
0xe698db inline_transform(cgraph_node*)
???:0
0xfec7fb execute_all_ipa_transforms(bool)
???:0
0xbfe2d9 cgraph_node::expand()
???:0
0xc027bb symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/112489] New: GCC: 14: internal compiler error: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112489
Bug ID: 112489
Summary: GCC: 14: internal compiler error: in
check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/89rPW14fv
When compile this program with `gcc-14 -O3 -fno-tree-dominator-opts`, gcc-14
crashes.
```
#define M 3000
static double a[M][M], b[M][M], c[M][M];
int N;
struct T {
int k;
double a[M][M];
} v;
void f() {
for (int i = 0; i < N; i) {
for (int j = 0; j < N; j++) {
for (v.k = j; +v.k < N; v.k++) {
c[j][v.k] += v.a[i][j] * b[i][v.k] +
b[i][-j] * v.a[i - i][+v.k];
c[j][v.k] += v.a[i][j] * b[i][v.k] +
b[i][-j] * v.a[i - i][-v.k];
}
}
}
}
```
The crash output:
```
during GIMPLE pass: ch_vect
: In function 'f':
:9:6: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
9 | void f() {
| ^
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0x12c17de verify_loop_closed_ssa(bool, loop*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug ipa/112486] GCC: 14: hangs with always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112486 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- FWIW you can use "-fmax-error=256" to limit the amount of error messages. But generally if you want to compile some potentially malicious source code, you still need to run GCC in a sandbox with an output limit (along with other resource limits) as GCC security policy explicitly notes.
[Bug ipa/112487] [14 Regression] internal compiler error: in setup_one_parameter, at tree-inline.cc:3565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112487 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |14.0
[Bug c++/112490] New: infinite meta error in reverse_iterator::iterator>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490 Bug ID: 112490 Summary: infinite meta error in reverse_iterator::ite rator>> Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- #include #include using I = std::vector::iterator; using CI = std::basic_const_iterator; using RCI = std::reverse_iterator; static_assert(std::totally_ordered); https://godbolt.org/z/14zsETc4d The fact that libc++ does not generate an error suggests that this may be a language bug. Not sure where the real issue here, I will reduce it when I have time.
[Bug rtl-optimization/110390] ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Seems to be fixed on current trunk as of r14-5226-g0b94e9cc060906.
[Bug libstdc++/112491] New: std::deque::size xmethod output is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112491
Bug ID: 112491
Summary: std::deque::size xmethod output is wrong
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ks1322 at gmail dot com
Target Milestone: ---
For this code:
```
#include
int main()
{
std::deque d;
d.push_front(0);
return 0;
}
```
deque size xmethod produces wrong result
```
$ gdb -batch -ex "b 8" -ex r -ex "p d.size()" a.out
Breakpoint 1 at 0x4011f5: file /tmp/t.cpp, line 8.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, main () at /tmp/t.cpp:8
8 return 0;
$1 = 128
```
Expected result is 1 while actual result is 128.
As a workaround xmethods can be disabled with `disable xmethod`
```
$ gdb -batch -ex "b 8" -ex r -ex "disable xmethod" -ex "p d.size()" a.out
Breakpoint 1 at 0x4011f5: file /tmp/t.cpp, line 8.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, main () at /tmp/t.cpp:8
8 return 0;
$1 = 1
```
[Bug target/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Xi Ruoyao changed: What|Removed |Added CC||tamar.christina at arm dot com Last reconfirmed||2023-11-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Xi Ruoyao --- First bad commit is r14-5284: middle-end: optimize fneg (fabs (x)) to copysign (x, -1) [PR109154] This patch transforms fneg (fabs (x)) into copysign (x, -1) which is more canonical and allows a target to expand this sequence efficiently. Such sequences are common in scientific code working with gradients. There is an existing canonicalization of copysign (x, -1) to fneg (fabs (x)) which I remove since this is a less efficient form. The testsuite is also updated in light of this. gcc/ChangeLog: PR tree-optimization/109154 * match.pd: Add new neg+abs rule, remove inverse copysign rule. gcc/testsuite/ChangeLog: PR tree-optimization/109154 * gcc.dg/fold-copysign-1.c: Updated. * gcc.dg/pr55152-2.c: Updated. * gcc.dg/tree-ssa/abs-4.c: Updated. * gcc.dg/tree-ssa/backprop-6.c: Updated. * gcc.dg/tree-ssa/copy-sign-2.c: Updated. * gcc.dg/tree-ssa/mult-abs-2.c: Updated. * gcc.target/aarch64/fneg-abs_1.c: New test. * gcc.target/aarch64/fneg-abs_2.c: New test. * gcc.target/aarch64/fneg-abs_3.c: New test. * gcc.target/aarch64/fneg-abs_4.c: New test. * gcc.target/aarch64/sve/fneg-abs_1.c: New test. * gcc.target/aarch64/sve/fneg-abs_2.c: New test. * gcc.target/aarch64/sve/fneg-abs_3.c: New test. * gcc.target/aarch64/sve/fneg-abs_4.c: New test.
[Bug target/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 --- Comment #2 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #1) > gcc/ChangeLog: > > PR tree-optimization/109154 > * match.pd: Add new neg+abs rule, remove inverse copysign rule. I guess the inverse copysign rule removal caused a hidden issue to show up...
[Bug target/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483
--- Comment #3 from Xi Ruoyao ---
Minimized test case:
! { dg-do run }
use, intrinsic :: ieee_arithmetic
implicit none
real :: sx1, sx2, sx3
double precision :: dx1, dx2, dx3
type(ieee_round_type) :: mode
! Test IEEE_COPY_SIGN
sx1 = -tiny(sx1)
sx1 = sx1 / 101
if (ieee_copy_sign(sx1, sx1) /= sx1) STOP 37
end
[Bug target/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483
--- Comment #4 from Xi Ruoyao ---
In 268r.cse1:
(insn 26 25 27 2 (set (reg:SF 93)
(mem/u/c:SF (reg/f:DI 94) [0 S4 A32])) "ieee_2.f90":13:6 discrim 4 146
{*movsf_hardfloat}
(expr_list:REG_EQUAL (const_double:SF -1.0e+0 [-0x0.8p+1])
(nil)))
(insn 27 26 28 2 (set (reg:SF 81 [ _8 ])
(copysign:SF (reg/v:SF 80 [ sx1 ])
(reg:SF 93))) "ieee_2.f90":13:6 discrim 4 63 {copysignsf3}
(nil))
But in 269r.fwprop1:
(insn 27 24 28 2 (set (reg:SF 81 [ _8 ])
(neg:SF (reg/v:SF 80 [ sx1 ]))) "ieee_2.f90":13:6 discrim 4 89 {negsf2}
(expr_list:REG_DEAD (reg:SF 93)
(nil)))
???
[Bug other/112492] New: Add LLVM BOLT support to the GCC build scripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112492 Bug ID: 112492 Summary: Add LLVM BOLT support to the GCC build scripts Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: zamazan4ik at tut dot by Target Milestone: --- Hi! According to the Facebook Research Paper (https://research.facebook.com/publications/bolt-a-practical-binary-optimizer-for-data-centers-and-beyond/), LLVM BOLT (https://github.com/llvm/llvm-project/blob/main/bolt/README.md) helps with achieving better performance for GCC even after PGO-optimized GCC build. I think will be a good idea to add support for building GCC with BOLT as it's already for PGO-optimized GCC build with "make profiledbootstrap" target. Integrating LLVM BOLT to the build scripts allows maintainers in a much easier way to enable LLVM BOLT for GCC in their .spec files. Here I got some examples of how LLVM BOLT is already integrated into other projects: * Rustc: https://github.com/rust-lang/rust/pull/116352 * CPython: https://github.com/python/cpython/pull/95908 * Pyston: - https://github.com/pyston/pyston#building - https://github.com/pyston/pyston/blob/pyston_main/Makefile#L200 * Clang: https://github.com/llvm/llvm-project/blob/main/clang/cmake/caches/BOLT.cmake More about LLVM BOLT results for other projects can be found in: * Rustc: - https://github.com/rust-lang/rust/pull/116352 - https://www.reddit.com/r/rust/comments/y4w2kr/llvm_used_by_rustc_is_now_optimized_with_bolt_on/ * CPython: https://github.com/python/cpython/pull/95908 * YDB: https://github.com/ydb-platform/ydb/issues/140 * Clang: - [Slides](https://llvm.org/devmtg/2022-11/slides/Lightning15-OptimizingClangWithBOLTUsingCMake.pdf) - [Results on building Clang](https://github.com/ptr1337/llvm-bolt-scripts/blob/master/results.md) - [Linaro results](https://android-review.linaro.org/plugins/gitiles/toolchain/llvm_android/+/f36c64eeddf531b7b1a144c40f61d6c9a78eee7a) - [on AMD 7950X3D](https://github.com/llvm/llvm-project/issues/65010#issuecomment-1701255347) * LDC: https://github.com/ldc-developers/ldc/issues/4228#issuecomment-1334499428 * NodeJS: https://aaupov.github.io/blog/2020/10/08/bolt-nodejs * Chromium: https://aaupov.github.io/blog/2022/11/12/bolt-chromium * MySQL, MongoDB, memcached, Verilator: https://people.ucsc.edu/~hlitz/papers/ocolos.pdf More information can be found here: https://github.com/zamazan4ik/awesome-pgo
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483
Xi Ruoyao changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #5 from Xi Ruoyao ---
In simplify_binary_operation_1, simplify-rtx.cc:
case COPYSIGN:
if (rtx_equal_p (trueop0, trueop1) && ! side_effects_p (op0))
return op0;
if (CONST_DOUBLE_AS_FLOAT_P (trueop1))
{
REAL_VALUE_TYPE f1;
real_convert (&f1, mode, CONST_DOUBLE_REAL_VALUE (trueop1));
rtx tmp = simplify_gen_unary (ABS, mode, op0, mode);
if (REAL_VALUE_NEGATIVE (f1))
tmp = simplify_gen_unary (NEG, mode, op0, mode);
^^^
return tmp;
}
shouldn't the "op0" with caret be "tmp" instead??
[Bug c/112493] New: GCC: 14: internal compiler error: in verify_sra_access_forest, at tree-sra.cc:2421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112493
Bug ID: 112493
Summary: GCC: 14: internal compiler error: in
verify_sra_access_forest, at tree-sra.cc:2421
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/971ccPba8
When tries to compile this program with `gcc-14 -O1`, gcc throws internal
compiler error:
```
#define BIG_ENDIAN \
__attribute__((scalar_storage_order("big-endian")))
typedef struct {
union {
char addr8[16];
} u;
} ip6_addr_t;
typedef struct {
char is_v4;
union {
int addr;
ip6_addr_t addr6;
} u;
} net_addr_t;
typedef struct {
union {
char addr8[16];
} u;
} be_ip6_addr_t;
typedef struct {
char is_v4;
union {
be_ip6_addr_t addr6;
char addr;
} BIG_ENDIAN u;
} BIG_ENDIAN be_net_addr_t;
struct T {
const net_addr_t ip;
be_ip6_addr_t rc;
} v;
be_ip6_addr_t be_ip6_addr(const ip6_addr_t ip6) {
return v.rc;
}
be_net_addr_t be_net_addr(const net_addr_t ip) {
be_net_addr_t rc;
if (v.ip.is_v4) {
rc.u.addr = v.ip.u.addr;
} else {
rc.u.addr6 = be_ip6_addr(v.ip.u.addr6);
}
return rc;
}
```
The crash output:
```
:27:19: warning: type punning toggles scalar storage order
[-Wscalar-storage-order]
27 | be_ip6_addr_t addr6;
| ^
during GIMPLE pass: sra
: In function 'be_net_addr':
:41:15: internal compiler error: in verify_sra_access_forest, at
tree-sra.cc:2421
41 | be_net_addr_t be_net_addr(const net_addr_t ip) {
| ^~~
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0x1226f82 verify_all_sra_access_forests()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/112494] New: GCC: 14: internal compiler error: in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
Bug ID: 112494
Summary: GCC: 14: internal compiler error: in ix86_cc_mode, at
config/i386/i386.cc:16477
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/cPPxenx7q
When compile this program with `-Og -fno-tree-copy-prop -fno-tree-fre
-fno-tree-ccp -fno-tree-forwprop`, gcc crashes:
```
#include
#ifdef __x86_64__
# define EFLAGS_TYPE unsigned long long int
#else
# define EFLAGS_TYPE unsigned int
#endif
int main() {
EFLAGS_TYPE flags = 0xD7;
__writeeflags(0xD7);
flags && !__readeflags();
if ((flags && (!__readeflags())) != 0xD7);
return 0;
}
```
There are some intriguing observations about this crash.
1. Removing the `flags &&` portion at the point of the first __readeflags()
call eliminates the crash, even though it appears that `flags &&` has no
effect.
2. Removing the `!= 0xD7` portion at the point of the second __readeflags()
call also eliminates the crash.
The crash output:
```
during RTL pass: combine
: In function 'main':
:15:1: internal compiler error: in ix86_cc_mode, at
config/i386/i386.cc:16477
15 | }
| ^
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/112495] New: GCC: 14: internal compiler error: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112495
Bug ID: 112495
Summary: GCC: 14: internal compiler error: verify_gimple failed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/7sM17Pfbb
When compile this program with `gcc-14 -O1`, gcc ICEs:
```
typedef struct { int v; } T1;
typedef struct { T1 v[32]; } T2;
T1 s;
T1 f1() { return s; }
void f2(__seg_gs T2 *p, int n) {
for (int i = 0; i < n; ++i) p->v[i] = f1();
}
```
Interestingly, if replacing the call of `f1`() by `s` (manual inline f1), this
crash disappears.
The crash output:
```
: In function 'f2':
:7:6: error: mismatching comparison operand types
7 | void f2(__seg_gs T2 *p, int n) {
| ^~
struct T2 *
struct T1 *
_22 = p_6(D) >= _21;
:7:6: error: mismatching comparison operand types
struct T2 *
struct T1 *
_27 = _26 <= &s;
during GIMPLE pass: vect
:7:6: internal compiler error: verify_gimple failed
0x238b15e internal_error(char const*, ...)
???:0
0x117b6c9 verify_gimple_in_cfg(function*, bool, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/112495] GCC: 14: internal compiler error: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112495 --- Comment #1 from wierton <141242068 at smail dot nju.edu.cn> --- Correction: It should be -O3.
[Bug c/112496] New: GCC: 14: internal compiler error: in vectorizable_nonlinear_induction, at tree-vect-loop.cc:9573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112496
Bug ID: 112496
Summary: GCC: 14: internal compiler error: in
vectorizable_nonlinear_induction, at
tree-vect-loop.cc:9573
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/7aq3hjbjK
When compile this program with `gcc-14 -O2`, gcc ICEs:
```
struct T { int x : 24; } v;
void f1(int x) {
while (v.x - ((v.x <<= 1) - v.x)) ;
}
```
The crash output:
```
during GIMPLE pass: vect
: In function 'f1':
:2:6: internal compiler error: in vectorizable_nonlinear_induction, at
tree-vect-loop.cc:9573
2 | void f1(int x) {
| ^~
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0x13ec547 vectorizable_induction(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, vec*)
???:0
0x13fe290 vect_analyze_loop(loop*, vec_info_shared*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #40 from John David Anglin ---
Jeff,
I don't think these split instructions make a lot of sense on PA-RISC.
(insn 280 277 281 30 (set (reg/f:SI 20 %r20 [480])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
(const_int 396 [0x18c]))) "../Python/compile.c":5970:20 120
{addsi3}
(nil))
(insn 281 280 284 30 (set (mem:SI (reg/f:SI 20 %r20 [480]) [4 MEM[(int *)_107 +
396B]+0 S4 A32])
(reg:SI 12 %r12 [orig:134 vect_pretmp_36.2452 ] [134]))
"../Python/compile.c":5970:20 42 {*pa.md:2193}
(nil))
They increase code size and register pressure. That may lead to unnecessary
spills and longer branches. They increase probability of problems like the
one in this PR.
I suspect the two instructions generated are actually slower than one with a
nonzero memory offset. It's not clear that memory accesses with a zero offset
are faster than ones with nonzero offsets.
Integer loads and stores on pa support fairly large offsets.
I think we need to look at why this happens frequently.
Thoughts?
[Bug rtl-optimization/91865] Combine misses opportunity to remove (sign_extend (zero_extend)) before searching for insn patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91865 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Roger Sayle --- This should now be fixed on mainline.
[Bug target/110551] [11/12/13 Regression] an extra mov when doing 128bit multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551 Roger Sayle changed: What|Removed |Added Target Milestone|11.5|14.0 Resolution|--- |FIXED Summary|[11/12/13/14 Regression] an |[11/12/13 Regression] an |extra mov when doing 128bit |extra mov when doing 128bit |multiply|multiply Status|NEW |RESOLVED --- Comment #10 from Roger Sayle --- This should now be fixed on mainline.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #41 from Jeffrey A. Law --- I would agree. In fact,the whole point of the f-m-o pass is to bring those immediates into the memory reference. It'd be really useful to know why that isn't happening. The only thing I can think of would be if multiple instructions needed the %r20 in the RTL you attached. Which might point to a refinement we should make in f-m-o, specifically the transformation isn't likely profitable if we aren't able to fold away a term or fold a constant term into the actual memory reference.
[Bug bootstrap/112497] New: Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 Bug ID: 112497 Summary: Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- A very recent regression. Will bisect.
[Bug target/112413] Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413 --- Comment #6 from Vincent Riviere --- (In reply to Mikael Pettersson from comment #4) > Does the `.balignw` filler disappear if you drop `-malign-int`? No, it stays, but its value becomes 2, so it doesn't cause trouble.
[Bug tree-optimization/112495] [11/12/13/14 Regression] internal compiler error: verify_gimple failed with named address space (__seg_gs )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112495 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5
[Bug tree-optimization/112496] [13/14 Regression] ICE: in vectorizable_nonlinear_induction, at tree-vect-loop.cc with bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112496 Andrew Pinski changed: What|Removed |Added Known to fail||13.1.0, 13.2.0 Target Milestone|--- |13.3 Summary|GCC: 14: internal compiler |[13/14 Regression] ICE: in |error: in |vectorizable_nonlinear_indu |vectorizable_nonlinear_indu |ction, at tree-vect-loop.cc |ction, at |with bit fields |tree-vect-loop.cc:9573 | Known to work||12.3.0
[Bug tree-optimization/112496] [13/14 Regression] ICE: in vectorizable_nonlinear_induction, at tree-vect-loop.cc with bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112496 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||needs-bisection Last reconfirmed||2023-11-12 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug bootstrap/112492] Add LLVM BOLT support to the GCC build scripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112492 Andrew Pinski changed: What|Removed |Added Component|other |bootstrap Severity|normal |enhancement
[Bug tree-optimization/112495] [11/12/13/14 Regression] internal compiler error: verify_gimple failed with named address space (__seg_gs )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112495 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-11-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/112493] [11/12/13/14 Regression] ICE in verify_sra_access_forest with scalar_storage_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112493 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Keywords||ice-on-valid-code, ||needs-bisection Summary|GCC: 14: internal compiler |[11/12/13/14 Regression] |error: in |ICE in |verify_sra_access_forest, |verify_sra_access_forest |at tree-sra.cc:2421 |with scalar_storage_order Last reconfirmed||2023-11-12 Known to fail||10.1.0, 12.1.0 Target Milestone|--- |11.5 Known to work||9.5.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 Xi Ruoyao changed: What|Removed |Added Last reconfirmed||2023-11-12 Summary|Bootstrap comparison|[14 Regression] Bootstrap |failure:|comparison failure: |gcc/analyzer/constraint-man |gcc/analyzer/constraint-man |ager.o differs on |ager.o differs on |loongarch64-linux-gnu |loongarch64-linux-gnu Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||chenglulu at loongson dot cn, ||jeffreyalaw at gmail dot com, ||xen0n at gentoo dot org --- Comment #1 from Xi Ruoyao --- Starts from r14-5367: Author: Jin Ma Date: Sat Nov 11 13:11:45 2023 -0700 [PATCH v2] In the pipeline, USE or CLOBBER should delay execution if it star ts a new live range.
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 --- Comment #2 from Xi Ruoyao --- FWIW, GCC configured with: --with-system-zlib --disable-fixincludes --enable-default-ssp --enable-default-pie --disable-werror --disable-multilib
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- If at all possible, cc Jin Ma in this since it's his change, I just reviewed and committed the bits on Jin's behalf.
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 --- Comment #4 from Xi Ruoyao --- (In reply to Jeffrey A. Law from comment #3) > If at all possible, cc Jin Ma in this since it's his change, I just reviewed > and committed the bits on Jin's behalf. I've replied the gcc-patch thread. It seems Jin Ma does not have a Bugzilla account. Generally how do we debug a comparison failure? I've not seen it before.
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 --- Comment #5 from Jeffrey A. Law --- This failure means the stage1 and stage2 compilers generated different code for the same input. So when I need to debug this I usually start by first getting that source code. Based in the title of this bugzilla you're going to want the .ii file for constraint-manager as built by either the stage1 or stage2 compiler. Then I feed that into the stage1 and stage2 compiler with the same optimization options to verify that they indeed generate different code. Sometimes that doesn't work when the issue is debug insns, but that's where I start. Once I have confirmed the two compilers generate different code, then I try to isolate where/why. This can often be done by looking a debug dumps to narrow things down to a pass that's behaving differently. Alternately you can replace objects in the stage2 compiler with those from the stage1 compiler to narrow it down to a single .o that causes the compiler's behavior to diverge. Then it's usually a matter going into the debugger and understanding why the given pass is behaving differently. It's a long, painful process. *Sometimes* you can just build the stage1 compiler and run the testsuite and see if there are new failures on your target. It doesn't always generate something useful, but when it does it's often faster than the process I mentioned above.
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 Xi Ruoyao changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Xi Ruoyao --- The problematic commit reverted at r14-5371. I've tested the reversion locally, so marking this fixed.
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |14.0
[Bug rtl-optimization/110390] ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390 --- Comment #3 from Thomas Koenig --- Fixed by r14-3414-g0cfc9c953d0221: 0cfc9c953d0221ec3971a25e6509ebe1041f142e is the first new commit commit 0cfc9c953d0221ec3971a25e6509ebe1041f142e Author: Andrew MacLeod Date: Thu Aug 17 12:34:59 2023 -0400 Phi analyzer - Initialize with range instead of a tree. Rangers PHI analyzer currently only allows a single initializer to a group. This patch changes that to use an inialization range, which is cumulative of all integer constants, plus a single symbolic value. There is no other change to group functionality. This patch also changes the way PHI groups are printed so they show up in the listing as they are encountered, rather than as a list at the end. It was more difficult to see what was going on previously.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483
Thomas Schwinge changed:
What|Removed |Added
Target|loongarch64-linux-gnu |loongarch64-linux-gnu
||powerpc64le-linux-gnu
CC||tschwinge at gcc dot gnu.org
--- Comment #6 from Thomas Schwinge ---
(In reply to Xi Ruoyao from comment #5)
> In simplify_binary_operation_1, simplify-rtx.cc:
>
> case COPYSIGN:
> if (rtx_equal_p (trueop0, trueop1) && ! side_effects_p (op0))
> return op0;
> if (CONST_DOUBLE_AS_FLOAT_P (trueop1))
> {
> REAL_VALUE_TYPE f1;
> real_convert (&f1, mode, CONST_DOUBLE_REAL_VALUE (trueop1));
> rtx tmp = simplify_gen_unary (ABS, mode, op0, mode);
> if (REAL_VALUE_NEGATIVE (f1))
> tmp = simplify_gen_unary (NEG, mode, op0, mode);
> ^^^
> return tmp;
> }
>
> shouldn't the "op0" with caret be "tmp" instead??
I have no knowledge at all about that code, but your suggested change appears
legit, and I do confirm that it does fix the following powerpc64le-linux-gnu
regressions:
@@ -169421,7 +169467,7 @@ PASS: gcc.target/powerpc/p8vector-fp.c
scan-assembler xsdivdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsdivsp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsmuldp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsmulsp
[-PASS:-]{+FAIL:+} gcc.target/powerpc/p8vector-fp.c scan-assembler xsnabsdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsnegdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xssqrtdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xssqrtsp
PASS: gfortran.dg/ieee/ieee_2.f90 -O0 (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90 -O0 execution test
PASS: gfortran.dg/ieee/ieee_2.f90 -O1 (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/ieee/ieee_2.f90 -O1 execution test
PASS: gfortran.dg/ieee/ieee_2.f90 -O2 (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90 -O2 execution test
PASS: gfortran.dg/ieee/ieee_2.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (test for excess errors)
@@ -63715,7 +63751,7 @@ PASS: gfortran.dg/ieee/ieee_2.f90 -O3
-fomit-frame-pointer -funroll-loops -fpe
PASS: gfortran.dg/ieee/ieee_2.f90 -O3 -g (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90 -O3 -g execution test
PASS: gfortran.dg/ieee/ieee_2.f90 -Os (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/ieee/ieee_2.f90 -Os execution test
[Bug rtl-optimization/110390] ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390 --- Comment #4 from Andrew Pinski --- (In reply to Thomas Koenig from comment #3) > Fixed by r14-3414-g0cfc9c953d0221: That almost definitely just made the issue go latent.
[Bug tree-optimization/109689] [14 Regression] ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r14-301-gf2d6beb7a4ddf1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689 Andrew Pinski changed: What|Removed |Added CC||141242068 at smail dot nju.edu.cn --- Comment #12 from Andrew Pinski --- *** Bug 112489 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/112489] GCC: 14: internal compiler error: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112489 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 109689. *** This bug has been marked as a duplicate of bug 109689 ***
[Bug ipa/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 Andrew Pinski changed: What|Removed |Added Known to work||13.2.0 Summary|GCC: 14: internal compiler |[14 Regression] ICE in |error: in make_ssa_name_fn, |make_ssa_name_fn with VLA |at tree-ssanames.cc:354 |inside type and inlining Known to fail||14.0 Target Milestone|--- |14.0
[Bug ipa/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #7 from Tamar Christina --- Yeah, that fold-rtx code is bogus. It's a latent bug. Optimizing copysign(x, -y) to neg(x) is just wrong. Will you be sending a patch Xi or do you want me to?
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 --- Comment #8 from Xi Ruoyao --- (In reply to Tamar Christina from comment #7) > Yeah, that fold-rtx code is bogus. It's a latent bug. > > Optimizing copysign(x, -y) to neg(x) is just wrong. > > Will you be sending a patch Xi or do you want me to? Yes, I'm running a regression test now and I'll send the patch after it finishes.
[Bug ipa/112487] [11/12/13/14 Regression] ICE in setup_one_parameter with conflicting types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112487 Andrew Pinski changed: What|Removed |Added Known to work||9.5.0 Summary|[14 Regression] internal|[11/12/13/14 Regression] |compiler error: in |ICE in setup_one_parameter |setup_one_parameter, at |with conflicting types |tree-inline.cc:3565 | Status|UNCONFIRMED |NEW Target Milestone|14.0|11.5 Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Known to fail||10.1.0, 11.1.0, 13.2.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110790 --- Comment #8 from Andrew Pinski --- I need some code generation help for gcc.target/i386/pr110790-2.c, I have a patch where we now generate: ``` movq(%rdi,%rax,8), %rax shrq%cl, %rax andl$1, %eax ``` instead of previously: ``` movq(%rdi,%rax,8), %rax btq %rsi, %rax setc%al movzbl %al, %eax ``` I suspect the sequence that contains shrq/and is better but I am 100% sure. We still get btq when used with a conditional too.
[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110790 --- Comment #9 from Uroš Bizjak --- (In reply to Andrew Pinski from comment #8) > I need some code generation help for gcc.target/i386/pr110790-2.c, I have a > patch where we now generate: > ``` > movq(%rdi,%rax,8), %rax > shrq%cl, %rax > andl$1, %eax > ``` > > instead of previously: > ``` > movq(%rdi,%rax,8), %rax > btq %rsi, %rax > setc%al > movzbl %al, %eax > ``` > > I suspect the sequence that contains shrq/and is better but I am 100% sure. > We still get btq when used with a conditional too. The new sequence is better. It does not create a partial reg write (setc needs a clearing XOR in fron of CC-setting instruction).
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 --- Comment #9 from Xi Ruoyao --- *** Bug 112484 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/112484] [14 Regression] 26_numerics/random/{poisson_distribution,negative_binomial_distribution}/operators/values.cc fails on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112484 Xi Ruoyao changed: What|Removed |Added Resolution|--- |DUPLICATE Component|target |rtl-optimization Status|UNCONFIRMED |RESOLVED --- Comment #1 from Xi Ruoyao --- The fix for PR112483 also fixes this. I didn't expect that... *** This bug has been marked as a duplicate of bug 112483 ***
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Xi Ruoyao changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Novembe ||r/636200.html --- Comment #10 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #8) > (In reply to Tamar Christina from comment #7) > > Yeah, that fold-rtx code is bogus. It's a latent bug. > > > > Optimizing copysign(x, -y) to neg(x) is just wrong. > > > > Will you be sending a patch Xi or do you want me to? > > Yes, I'm running a regression test now and I'll send the patch after it > finishes. https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636200.html
[Bug rtl-optimization/112494] GCC: 14: internal compiler error: in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-11-12
Ever confirmed|0 |1
Component|target |rtl-optimization
Status|UNCONFIRMED |NEW
--- Comment #1 from Uroš Bizjak ---
Combine pass is trying to combine:
Trying 5 -> 8:
5: r98:DI=0xd7
8: flags:CCZ=cmp(r98:DI,0)
REG_EQUAL cmp(0xd7,0)
where:
(insn 5 2 6 2 (set (reg/v:DI 98 [ flags ])
(const_int 215 [0xd7])) "pr112494.c":10:26 84 {*movdi_internal}
(nil))
(insn 8 7 11 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 98 [ flags ])
(const_int 0 [0]))) "pr112494.c":12:9 8 {*cmpdi_ccno_1}
(expr_list:REG_EQUAL (compare:CCZ (const_int 215 [0xd7])
(const_int 0 [0]))
(nil)))
and calls ix86_cc_mode with:
Breakpoint 1, ix86_cc_mode (code=code@entry=SET, op0=0x7fffe3e37680,
op1=0x7fffea209490)
code = SET will trigger gcc_unreachable() at the end of the ix86_cc_mode
function.
Confirmed as a generic RTL optimization problem.
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 --- Comment #5 from anlauf at gcc dot gnu.org --- Created attachment 56563 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56563&action=edit Partial testsuite fixes This patch contains obvious fixes to 3 testcases, except for assumed_rank_9.f90, which is more severe, as it violates ! F2018:15.5.2.5 Allocatable and pointer dummy variables ! ! The actual argument shall be polymorphic if and only if the associated ! dummy argument is polymorphic, and either both the actual and dummy ! arguments shall be unlimited polymorphic, or the declared type of the ! actual argument shall be the same as the declared type of the dummy ! argument. ! ! F2023:15.5.2.6 has the same text which is detected (mostly) by NAG and Intel. We need to detect and diagnose violations of the above.
[Bug rtl-optimization/112494] ICE in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494 --- Comment #2 from Andrew Pinski --- It has failed since __writeeflags/__readeflags was added in 4.9.0.
[Bug target/112433] RISC-V GCC-15 feature: Split register allocation into RVV and non-RVV, and make vsetvl PASS run between them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/112450] RVV vectorization ICE in vect_get_loop_mask, at tree-vect-loop.cc:11037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||wrong-code
[Bug target/112399] RISC-V: Missed AVL propagation for complicate reduction case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112399 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0
[Bug middle-end/112403] `s+ (a?-1:1)` and `a?s-1:s+1` produce two different code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112403 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165 --- Comment #2 from Andrew Pinski --- Created attachment 56564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56564&action=edit Full testcase
[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-12 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Currently the trunk produces: ``` foo: ins v0.d[1], xzr ret foo1: moviv31.4s, 0 zip1v0.2d, v0.2d, v31.2d ret foo2: ins v0.d[1], xzr ret ``` Which is better than 10.x but still not using fmov.
[Bug libstdc++/111638] GLIBCXX_MAYBE_UNDERSCORED_FUNCS autoconf macro doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111638 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed for gcc 14.
[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- Mine, I will handle this. Most likely for GCC 15 though.
[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/110262] `t < 0 ? 1 : min(t, 1)` is not simplified down to just `t != 0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110262 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104296 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-11-12 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- So basically: min(t, 1) -> `t != 0` if we know at this point t is nonnegative ... and that is how it gets simplified.
[Bug tree-optimization/110405] missing nonzerobits on branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110405
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-12
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Another testcase:
```
void h(unsigned long);
void
f (unsigned long i)
{
if ((i & 7) != 6) __builtin_unreachable();
if(i & 1)
h(0);
}
```
Note LLVM is able to optimize both cases.
Note for the above testcase we get for the range:
# RANGE [irange] long unsigned int [6, 18446744073709551614]
Notice how the value/mask is not there even though we should be able to get it
from the IR.
[Bug target/103959] float64x1_t not using fmov to generate some float values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103959 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine.
[Bug tree-optimization/112472] (trunc)copysign((extend)x, CST) is not optimized to just copysign(x, CST')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112472 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2023-11-12 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine.
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-11-12
Summary|ICE with vector float |[14 Regression] ICE with
|bitfield after error|vector float bitfield after
||error
CC||pinskia at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Target Milestone|--- |14.0
--- Comment #1 from Andrew Pinski ---
Confirmed.
if (TREE_CODE (field) == FIELD_DECL
&& DECL_INITIAL (field)
&& TREE_TYPE (field) != error_mark_node)
{
unsigned HOST_WIDE_INT width
= tree_to_uhwi (DECL_INITIAL (field));
tree type = TREE_TYPE (field);
if (width != TYPE_PRECISION (type)) <--- Crash
{
Obvious introduced by the TYPE_PRECISION change to ICE on vector types:
r14-2150-gfe48f2651334bc
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #2 from Andrew Pinski ---
But we should also be rejecting:
```
struct A {
__attribute__((__vector_size__(4))) int d : 1;
};
struct A b = {0};
```
Which we currently accepts before and ICE now.
Note for the float case, we could in theory change:
```
/* Detect invalid bit-field type. */
if (TREE_CODE (*type) != INTEGER_TYPE
&& TREE_CODE (*type) != BOOLEAN_TYPE
&& TREE_CODE (*type) != ENUMERAL_TYPE
&& TREE_CODE (*type) != BITINT_TYPE)
{
error_at (loc, "bit-field %qs has invalid type", name);
*type = unsigned_type_node;
}
```
to use error_mark_node instead of unsigned_type_node here and that would fix
the ICE for the original testcase but not the above testcase.
[Bug libstdc++/112498] New: std::is_convertible::value returns false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112498
Bug ID: 112498
Summary: std::is_convertible::value returns
false
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: josopait at goopax dot com
Target Milestone: ---
If I am not mistaken, this should succeed:
#include
int main()
{
static_assert(std::is_convertible::value); // ok
static_assert(std::is_convertible::value); // fails
}
[Bug c++/112498] std::is_convertible::value returns false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112498
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
Component|libstdc++ |c++
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=111842
--- Comment #1 from Andrew Pinski ---
No.
```
_Float16 f(float a)
{
return a;
}
```
is invalid C++23 code.
:3:10: warning: converting to '_Float16' from 'float' with greater
conversion rank
Maybe we should add this to the FAQ because we get a question about implicit
conversion from _Float16 to float a few times now.
See
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1467r4.html#implicit
Which is the C++ paper which adds the extended floating point types and GCC
implements it full. Just as an extension allows the conversion (with a warning)
but since we cannot have different behavior for sfinae and concepts with
-pedantic/-pedantic-errors std::is_convertible needs to return false.
[Bug tree-optimization/112385] `(2 >> a) ^ (5 >> a)` is not optimized to `7 >> a` is 2 and 5 differ in signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112385 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Mine, I will handle this.
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-2526-g8911879415d6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #11 from Sam James --- (In reply to Roger Sayle from comment #10) > > I'm testing a patch. Did you get anywhere in the end?
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |NEW --- Comment #6 from Andrew Pinski --- Confirmed. bt32_setb2, bt32v_setb, bt32v_setb2 are the only ones done for 64bit.
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #2 from Sam James --- You may want to pick up the patches we use in Gentoo: * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=5c1d751f03ddca21442fc782da0fb21dd178c372 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=711d93ef417796e29586dee53135a049f79f84a1 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=fb1b1c796b1fb13ab52bb4ff45952598c7e2ca03 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=6a60bc33530f416429d09a47fbcc565a0e20ff93 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=abfbdfc45c71af6a14bcc4cd5354044cfca14add * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=51ae055728e7c266e8d192c8bfd836af17eda288 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=3b91727edf3a546f3407d37f4ce5859e8e5609bc * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=87914943d5b70a9623e06f9a615d4e974ffa5764 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=ca51ed9196a30be1a2b03b8b650a28c5f2479c9c * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=f6eaf5c9752dc8beaf0329e235a36b6d24324467 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=96f022bb6218b164f38a0a01764a9aee17e36154 This adds a bunch of common bug trackers and code review sites like phabricator, gerrit, gitlab, etc.
[Bug middle-end/111817] ICE in expand_asm_stmt with invalid characters in inline-asm output operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111817 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |NEW Summary|GCC: 14: internal compiler |ICE in expand_asm_stmt with |error: in expand_asm_stmt, |invalid characters in |at cfgexpand.cc:3389|inline-asm output operands --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-2526-g8911879415d6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #12 from Roger Sayle --- Patch proposed (actually two alternatives proposed) at https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636203.html
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 Andrew Pinski changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 111859 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/111859] 521.wrf_r build failure with -O2 -march=cascadelake --param vect-partial-vector-usage=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111859 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 112404 ***
[Bug target/111874] Missed mask_fold_left_plus with AVX512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111874 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-11-12 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- .
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 --- Comment #4 from Andrew Pinski --- This is interesting, I cannot reproduce it locally with r14-5371-g93e92b2e5d6866 . but with the version in godbolt I could (r14-5368-ge0787da263322f).
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 --- Comment #5 from Andrew Pinski --- I tried `--param ggc-min-expand=0 --param ggc-min-heapsize=0` and it still does not ICE. The exact command line I tried: ``` [apinski@xeond2 upstream-gcc-match]$ ~/upstream-gcc-match/bin/gcc t.cc -DICE -g -g0 -Wall -pthread -O3 --param ggc-min-expand=0 --param ggc-min-heapsize=0 ``` One difference between my build and godbolt is I don't use `--enable-libstdcxx-debug ` .
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 --- Comment #6 from Andrew Pinski --- Created attachment 56565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56565&action=edit unreduced testcase Ok, with this preprocessed source I am able to reproduce it locally. I have not looked into what is the difference on why I could reproduce it with the headers I have.
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 --- Comment #7 from Andrew Pinski --- Created attachment 56566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56566&action=edit Reduced testcase
[Bug c++/112498] std::is_convertible::value returns false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112498 --- Comment #2 from Ingo Josopait --- Yes, you are right. It is confusing, though. Maybe the warning message should mention that it is actually invalid code. It looked more like a suggestion to me.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #42 from John David Anglin --- The problem is we are limiting displacements to five bits in pa_legitimate_address_p. The comment is somewhat confusing but we may have reload issues if we allow 14-bit displacements before reload completes. Testing a patch to see if we can allow 14-bit displacements before reload.
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |NEW Keywords|needs-reduction | --- Comment #8 from Andrew Pinski --- Confirmed. Note the difference between my build and the others is due to: # if __GLIBC_PREREQ(2, 34) // Since glibc 2.34 all pthreads functions are usable without linking to // libpthread. # define _GLIBCXX_GTHREAD_USE_WEAK 0 # endif That is I have a newer glibc which causes __weakref__ not to be needed/used here. So next time please attach the preprocessed source when running into a bug in the front-end, because different versions of glibc might produce different preprocessed sources and not able to reproduce the issue.
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity after undefined decl defining a `thread_local auto` and weakref/alias attribute had been used before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 Andrew Pinski changed: What|Removed |Added Summary|ICE internal compiler |ICE internal compiler |error: in |error: in |discriminator_for_local_ent |discriminator_for_local_ent |ity, at cp/mangle.cc:2065 |ity after undefined decl ||defining a `thread_local ||auto` and weakref/alias ||attribute had been used ||before --- Comment #9 from Andrew Pinski --- note alias attribute also causes the ICE.
[Bug target/111926] RISC-V: Use vsetvl insn replace csrr vlenb insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/112490] infinite meta error in reverse_iterator::iterator>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490 --- Comment #1 from Andrew Pinski --- Well clang does not implement CWG2369 resolution. Which GCC implemented in r11-2774 . So it might be that is the reason why GCC rejects it and clang does not.
