[Bug c/110696] New: RISC-V: -march doesn't imply correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110696
Bug ID: 110696
Summary: RISC-V: -march doesn't imply correctly
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
test:
#include "riscv_vector.h"
void foo () {vint32m1_t v;}
1. -march=rv64gcv_zvl4096:
.attribute arch,
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl1024b1p0_zvl128b1p0_zvl2048b1p0_zvl32b1p0_zvl4096b1p0_zvl64b1p0"
Missing: zvl256b and zvl512b
2. -march=rv64gcv_zvl8192:
.attribute arch,
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl2048b1p0_zvl32b1p0_zvl4096b1p0_zvl64b1p0_zvl8192b1p0"
Missing: zvl256b and zvl512b and zvl1024b
[Bug other/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 Andrew Pinski changed: What|Removed |Added CC||zhendong.su at inf dot ethz.ch --- Comment #5 from Andrew Pinski --- *** Bug 110671 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/110671] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in gimple_phi_arg_def_from_edge, at gimple.h:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110671 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 110669 ***
[Bug tree-optimization/105132] ICE in in operator[], at vec.h:889 with -march=skylake-avx512 -O3 since r12-7246-g4963079769c99c40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105132 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug middle-end/110673] [14 regression] ICE when buliding opus (internal compiler error: in gimple_phi_arg_def_from_edge, at gimple.h:4699)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Reduced is the same as PR 110669 . *** This bug has been marked as a duplicate of bug 110669 ***
[Bug other/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 --- Comment #4 from Andrew Pinski --- *** Bug 110673 has been marked as a duplicate of this bug. ***
[Bug other/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 Andrew Pinski changed: What|Removed |Added CC||lehua.ding at rivai dot ai --- Comment #3 from Andrew Pinski --- *** Bug 110695 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/110695] RISC-V: compile gcc.dg/torture/pr105132.c crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110695 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 110669 ***
[Bug tree-optimization/110695] New: RISC-V: compile gcc.dg/torture/pr105132.c crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110695
Bug ID: 110695
Summary: RISC-V: compile gcc.dg/torture/pr105132.c crash
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lehua.ding at rivai dot ai
Target Milestone: ---
The trunk compiler will crash when compiling the testcase
gcc.dg/torture/pr105132.c with -O1 option and only -O1 option will crash.
13.1.0 is ok.
during GIMPLE pass: sccp
dump file: /app/output.c.156t.sccp
: In function 'd':
:4:6: internal compiler error: in gimple_phi_arg_def_from_edge, at
gimple.h:4699
4 | void d(long f[][5][5][17], int g[][5][5][17]) {
| ^
0x7ff51b931082 __libc_start_main
???: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 tree-optimization/95923] Failure to optimize bool checks into and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-July/62 ||4594.html --- Comment #8 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624594.html
[Bug testsuite/109880] [14 regression] gcc.target/powerpc/fold-vec-extract-int.p8.c fails after r14-916-g9417b30499ce09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109880 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Kewen Lin --- (In reply to Andrew Pinski from comment #4) > Has this been fixed with the commit? Yeah, marking it resolved, thanks for reminding.
[Bug target/109971] [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Kewen Lin --- (In reply to Andrew Pinski from comment #12) > Has this been fixed? Yes, those failures should be fixed then. Thanks for reminding.
[Bug middle-end/110694] [11/12/13/14 Regression] False Positive -Werror=free-nonheap-object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110694 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |11.5 Known to fail||11.1.0 Status|UNCONFIRMED |NEW Known to work||10.5.0 Last reconfirmed||2023-07-17 Summary|False Positive |[11/12/13/14 Regression] |-Werror=free-nonheap-object |False Positive ||-Werror=free-nonheap-object --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/110694] New: False Positive -Werror=free-nonheap-object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110694
Bug ID: 110694
Summary: False Positive -Werror=free-nonheap-object
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: biggs at biggs dot xyz
Target Milestone: ---
Created attachment 9
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=9=edit
Source File
Observed on Trunk and 13.1.1
Consider:
```c
#include
typedef struct S S;
struct S {
int* i;
};
static S* s_constructor(void) {
S* s = malloc(sizeof(*s));
if (s) s->i = calloc(1, sizeof(*(s->i)));
return s;
}
static void s_destructor(S* s) {
if (!s) return;
free(s->i);
free(s);
}
static void s_destructor2(S s[static 1]) {
free(s->i);
free(s);
}
int main(void) {
S* s = s_constructor();
s_destructor(s);
s = s_constructor();
if (s) s_destructor2(s);
s = (void*) 0;
return EXIT_SUCCESS;
}
```
Compiling with gcc -Wall -Werror produces the error:
: In function 's_destructor2':
:23:5: error: 'free' called on unallocated object 's'
[-Werror=free-nonheap-object]
23 | free(s);
| ^~~
:21:29: note: declared here
21 | static void s_destructor2(S s[static 1]) {
| ~~^~~
cc1: all warnings being treated as errors
However, there is no error when compiled with -O1 or higher optimization flag.
I don't think s_destructor2(S s[static 1]) should emit an error in the first
place though. The function definition should be compatible with s_destructor(S*
s).
[Bug c/110693] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110693 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-07-17 Known to fail||10.1.0 Status|UNCONFIRMED |NEW Severity|normal |minor --- Comment #1 from Andrew Pinski --- Confirmed. Not a regression.
[Bug c/110693] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110693
Bug ID: 110693
Summary: internal compiler error: Segmentation fault
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: ---
When compiling below program using gcc-14 with option `gcc-14 a.c`, gcc-14
crashes:
```
char global;
void bar (void);
void __GIMPLE (ssa)
foo (char * p)
{
__BB(2):
if (p_2(D) == _Literal (char *)[2])
goto __BB3;
else
goto __BB4;
__BB(3):
bar ();
goto __BB4;
__BB(4):
return;
}
```
GCC's output is pasted below:
```
:5:6: error: '__GIMPLE' only valid with '-fgimple'
5 | void __GIMPLE (ssa)
| ^~~~
: In function 'foo':
:9:41: error: subscripted value is neither array nor pointer nor vector
9 | if (p_2(D) == _Literal (char *)[2])
| ^
:9:44: error: invalid _Literal before ')' token
9 | if (p_2(D) == _Literal (char *)[2])
|^
:20:1: internal compiler error: Segmentation fault
20 | }
| ^
0x2150dee internal_error(char const*, ...)
???:0
0xb510f3 unchecked_make_edge(basic_block_def*, basic_block_def*, int)
???:0
0xa7d754 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
???:0
0xa7477d c_parse_file()
???:0
0xae3e59 c_common_parse_file()
???: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 tree-optimization/95923] Failure to optimize bool checks into and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923 --- Comment #7 from Andrew Pinski --- I will fix the phiopt issue later ...
[Bug tree-optimization/95923] Failure to optimize bool checks into and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923 --- Comment #6 from Andrew Pinski --- Created attachment 8 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=8=edit Patch which I am testing
[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 --- Comment #11 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:061f74c06735e1fa35b910ae0bcf01b61a74ec23 commit r14-2546-g061f74c06735e1fa35b910ae0bcf01b61a74ec23 Author: Jan Hubicka Date: Sun Jul 16 23:56:59 2023 +0200 Fix profile update in scale_profile_for_vect_loop When vectorizing 4 times, we sometimes do for <4x vectorized body> for <2x vectorized body> for <1x vectorized body> Here the second two fors handling epilogue never iterates. Currently vecotrizer thinks that the middle for itrates twice. This turns out to be scale_profile_for_vect_loop that uses niter_for_unrolled_loop. At that time we know epilogue will iterate at most 2 times but niter_for_unrolled_loop does not know that the last iteration will be taken by the epilogue-of-epilogue and thus it think that the loop may iterate once and exit in middle of second iteration. We already do correct job updating niter bounds and this is just ordering issue. This patch makes us to first update the bounds and then do updating of the loop. I re-implemented the function more correctly and precisely. The loop reducing iteration factor for overly flat profiles is bit funny, but only other method I can think of is to compute sreal scale that would have similar overhead I think. Bootstrapped/regtested x86_64-linux, will commit it shortly. gcc/ChangeLog: PR middle-end/110649 * tree-vect-loop.cc (scale_profile_for_vect_loop): Rewrite. (vect_transform_loop): Move scale_profile_for_vect_loop after upper bound updates.
[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 --- Comment #10 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:c62791fa413a49fc6476ce186b324250f8ae6d40 commit r14-2545-gc62791fa413a49fc6476ce186b324250f8ae6d40 Author: Jan Hubicka Date: Sun Jul 16 23:55:14 2023 +0200 Fix optimize_mask_stores profile update While looking into sphinx3 regression I noticed that vectorizer produces BBs with overall probability count 120%. This patch fixes it. Richi, I don't know how to create a testcase, but having one would be nice. Bootstrapped/regtested x86_64-linux, will commit it shortly. gcc/ChangeLog: PR tree-optimization/110649 * tree-vect-loop.cc (optimize_mask_stores): Set correctly probability of the if-then-else construct.
[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 --- Comment #9 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:1d203d4c90adb064edfa9680768d1f83a41f17e0 commit r14-2544-g1d203d4c90adb064edfa9680768d1f83a41f17e0 Author: Jan Hubicka Date: Sun Jul 16 23:53:56 2023 +0200 Avoid double profile udpate in try_peel_loop try_peel_loop uses gimple_duplicate_loop_body_to_header_edge which subtracts the profile from the original loop. However then it tries to scale the profile in a wrong way (it forces header count to be entry count). This eliminates to profile misupdates in the internal loop of sphinx3. gcc/ChangeLog: PR middle-end/110649 * tree-ssa-loop-ivcanon.cc (try_peel_loop): Avoid double profile update.
[Bug fortran/110658] MINVAL/MAXVAL and deferred-length character arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110658 --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-July/059620.html
[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 Jan Hubicka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110692 --- Comment #8 from Jan Hubicka --- So in mgau_eval the inner loop is vectorized and peeled, epilogues are vectorized and fully unrolled. The resulting code seems bit more complicated then it needs to be. I do not think the problems in profile updates are very iportant and actually should affect overall performance much. vector_gautbl_eval_logs3 seems similar but we run out of registers, so there profile may be more relevant I added to PR110692 oversimplified example of this pattern. I think we could get overall codegen better...
[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 --- Comment #7 from Jan Hubicka --- I found the problem why vectorizer gets vectorized epilogue profile scales wrong. It is scale_profile_for_vect_loop that uses niter_for_unrolled_loop which does not understand the fact that if iteration count is not divisible, the epilogue (unless loop is masked) will use the count. THe upper bound compuation is actually right in update of loop_info, so we can just use it directly instead of relying on niter_for_unrolled_loop. Wrong profile in: ;; basic block 14, loop depth 2, count 13764235 (guessed, freq 1.9247), maybe hot ;; Invalid sum of incoming counts 25234431 (guessed, freq 3.5286), should be 13764235 (guessed, freq 1.9247) Is caused by loop peeling. The unrolled loop is peeled 4 times which seems like a reasonable idea, but I am not sure why profile is not updated correctly here.
[Bug fortran/110658] MINVAL/MAXVAL and deferred-length character arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110658 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-07-16 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from anlauf at gcc dot gnu.org --- I am testing the following patch: diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc index dbb04f8c434..e783dbb64b1 100644 --- a/gcc/fortran/trans-expr.cc +++ b/gcc/fortran/trans-expr.cc @@ -7654,7 +7654,12 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, (and other intrinsics?) and dummy functions. In the case of SPREAD, we take the character length of the first argument for the result. For dummies, we have to look through the formal argument list for -this function and use the character length found there.*/ +this function and use the character length found there. +Likewise, we handle the case of deferred-length character dummy +arguments to intrinsics that determine the characteristics of +the result, which cannot be deferred-length. */ + if (expr->value.function.isym) + ts.deferred = false; if (ts.deferred) cl.backend_decl = gfc_create_var (gfc_charlen_type_node, "slen"); else if (!sym->attr.dummy)
[Bug middle-end/110692] New: epilogues for loop which can be also vectorized with half size can be improved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110692
Bug ID: 110692
Summary: epilogues for loop which can be also vectorized with
half size can be improved.
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: ---
for:
int a[99];
test()
{
for (int i = 0 ; i < 99; i++)
a[i]++;
}
we produce:
0: 66 0f 6f 0d 00 00 00movdqa 0x0(%rip),%xmm1# 8
7: 00
8: b8 00 00 00 00 mov$0x0,%eax
d: ba 00 00 00 00 mov$0x0,%edx
12: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
18: 66 0f 6f 00 movdqa (%rax),%xmm0
1c: 48 83 c0 10 add$0x10,%rax
20: 66 0f fe c1 paddd %xmm1,%xmm0
24: 0f 29 40 f0 movaps %xmm0,-0x10(%rax)
28: 48 39 c2cmp%rax,%rdx
2b: 75 eb jne18
2d: f3 0f 7e 05 00 00 00movq 0x0(%rip),%xmm0# 35
34: 00
35: 83 05 00 00 00 00 01addl $0x1,0x0(%rip)# 3c
3c: f3 0f 7e 0d 00 00 00movq 0x0(%rip),%xmm1# 44
43: 00
44: 66 0f fe c1 paddd %xmm1,%xmm0
48: 66 0f d6 05 00 00 00movq %xmm0,0x0(%rip)# 50
4f: 00
50: c3 ret
which does the 4x vectorized loop followed by 2x vectorized loopless epilogue
and copy of remaining byte.
When bound is unknow we do:
int a[99];
test(int n)
{
for (int i = 0 ; i < n; i++)
a[i]++;
}
0: 85 ff test %edi,%edi
2: 7e 70 jle74
4: 8d 47 fflea-0x1(%rdi),%eax
7: 83 f8 02cmp$0x2,%eax
a: 76 6d jbe79
c: 89 fa mov%edi,%edx
e: 66 0f 6f 0d 00 00 00movdqa 0x0(%rip),%xmm1# 16
15: 00
16: 31 c0 xor%eax,%eax
18: c1 ea 02shr$0x2,%edx
1b: 48 c1 e2 04 shl$0x4,%rdx
1f: 66 0f 6f 80 00 00 00movdqa 0x0(%rax),%xmm0
26: 00
27: 48 83 c0 10 add$0x10,%rax
2b: 66 0f fe c1 paddd %xmm1,%xmm0
2f: 0f 29 80 00 00 00 00movaps %xmm0,0x0(%rax)
36: 48 39 d0cmp%rdx,%rax
39: 75 e4 jne1f
3b: 89 f8 mov%edi,%eax
3d: 83 e0 fcand$0xfffc,%eax
40: 40 f6 c7 03 test $0x3,%dil
44: 74 32 je 78
46: 48 63 d0movslq %eax,%rdx
49: 83 04 95 00 00 00 00addl $0x1,0x0(,%rdx,4)
50: 01
51: 8d 50 01lea0x1(%rax),%edx
54: 39 d7 cmp%edx,%edi
56: 7e 1c jle74
58: 48 63 d2movslq %edx,%rdx
5b: 83 c0 02add$0x2,%eax
5e: 83 04 95 00 00 00 00addl $0x1,0x0(,%rdx,4)
65: 01
66: 39 c7 cmp%eax,%edi
68: 7e 0a jle74
6a: 48 98 cltq
6c: 83 04 85 00 00 00 00addl $0x1,0x0(,%rax,4)
73: 01
74: c3 ret
75: 0f 1f 00nopl (%rax)
78: c3 ret
79: 31 c0 xor%eax,%eax
7b: eb c9 jmp46
the profitability threshold is 4.
Producing the loopless epilogue just as in the first case with additional tests
for block size would work better. The code looks quite bad for small trip
counts since there is extra jump down to 79.
[Bug fortran/110691] New: Segmentation fault on valid F2018 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110691 Bug ID: 110691 Summary: Segmentation fault on valid F2018 code Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Created attachment 7 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=7=edit Reproducer The attached code (which I believe to be valid F2018) leads to a segmentation violation with gfortran at least since version 11. (it also seg faults, probably with a different root case) in Intel oneAPI 21.9 (2023 v1), but works with nagfor. This is the backtrace of the segfault: Program received signal SIGSEGV, Segmentation fault. 0xd841 in __qn_containers_MOD_qn_array_copy () (gdb) bt #0 0xd841 in __qn_containers_MOD_qn_array_copy () #1 0xe3f3 in __qn_containers_MOD_qn_container_grow () #2 0xd2a5 in __qn_containers_MOD_qn_array_append () #3 0x55560742 in __qn_containers_uti_MOD_qn_containers_2 () #4 0x55563fb0 in __qn_containers_ut_MOD_qn_containers_test () #5 0x55563fc6 in MAIN__ () The reproducer of ca 1200 lines is attached.
[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
--- Comment #6 from Jan Hubicka ---
I tried zen3 with -march=native -Ofast
Samples: 1M of event 'cycles:u', Event count (approx.): 2309002237334, DSO: s
Overhead Command Symbol
42.51% sphinx_livepret [.] mgau_eval◆
24.36% sphinx_livepret [.] vector_gautbl_eval_logs3 ▒
6.81% sphinx_livepret [.] subvq_mgau_shortlist ▒
6.43% sphinx_livepret [.] logs3_add▒
4.91% sphinx_livepret [.] approx_cont_mgau_frame_eval ▒
4.32% sphinx_livepret [.] mdef_sseq2sen_active ▒
2.62% sphinx_livepret [.] dict2pid_comsenscr ▒
1.50% sphinx_livepret [.] hmm_vit_eval_3st ▒
0.84% sphinx_livepret [.] lextree_hmm_eval ▒
0.67% sphinx_livepret [.] lextree_hmm_propagate▒
0.64% sphinx_livepret [.] lextree_enter▒
0.61% sphinx_livepret [.] fe_fft ▒
0.45% sphinx_livepret [.] dict2pid_comsseq2sen_active ▒
0.32% sphinx_livepret [.] lextree_ssid_active ▒
0.18% sphinx_livepret [.] vithist_rescore ▒
0.14% sphinx_livepret [.] utt_decode_block ▒
0.12% sphinx_livepret [.] fe_mel_cep ▒
Prior vectorizing there is no invalid profile in mgau_eval.
Loop is
for (c = 0; c < mgau->n_comp-1; c += 2) { /* Interleave 2
components for speed */
m1 = mgau->mean[c];
m2 = mgau->mean[c+1];
v1 = mgau->var[c];
v2 = mgau->var[c+1];
dval1 = mgau->lrd[c];
dval2 = mgau->lrd[c+1];
for (i = 0; i < veclen; i++) {
diff1 = x[i] - m1[i];
dval1 -= diff1 * diff1 * v1[i];
diff2 = x[i] - m2[i];
dval2 -= diff2 * diff2 * v2[i];
/* E_INFO("x %10f m1 %10f m2 %10f v1 %10f, v2
%10f\n",x[i],m1[i],m2[i],v1[i],v2[i]);
E_INFO("diff1 %10f,dval1 %10f, diff2 %10f,
dval2 %10f\n",diff1,dval1,diff2,dval2);*/
}
if (dval1 < g->distfloor) /* Floor */
dval1 = g->distfloor;
if (dval2 < g->distfloor)
dval2 = g->distfloor;
score = logs3_add (score, (int32)(f * dval1) + mgau->mixw[c]);
score = logs3_add (score, (int32)(f * dval2) + mgau->mixw[c+1]);
}
and the inner loop iterates 47 times on average. Vectorizer has profitaiblity
threshold 8 and vectorizes to 32bit vectors.
Epilogue has threshold 4 and is vectorized with 16bit vector.
There is second similar loop nest in the function:
for (j = 0; active[j] >= 0; j++) {
#ifdef SPEC_CPU
considered++;
#endif
c = active[j];
m1 = mgau->mean[c];
v1 = mgau->var[c];
dval1 = mgau->lrd[c];
for (i = 0; i < veclen; i++) {
diff1 = x[i] - m1[i];
dval1 -= diff1 * diff1 * v1[i];
}
if (dval1 < g->distfloor)
dval1 = g->distfloor;
score = logs3_add (score, (int32)(f * dval1) + mgau->mixw[c]);
}
which is executed 10% of time and also vectorized twice.
We then believe that the inner loop iterates 5 times (I would expect 47/4
times).
In cunroll pass we then see:
Loop 4 iterates at most 2147483647 times.
Loop 4 likely iterates at most 2147483647 times.
Not unrolling loop 4 (--param max-completely-peel-times limit reached).
This is the outer loop
Loop 7 iterates at most 2 times.
Loop 7 likely iterates at most 2 times.
Loop size: 22
Estimated size after unrolling: 42
cont_mgau.c:604:20: optimized: loop with 2 iterations completely unrolled
(header execution count 1065258)
this is the scalar epilogue loop.
Loop 6 iterates at most 0 times.
Loop 6 likely iterates at most 0 times.
cont_mgau.c:575:7: optimized: loop turned into non-loop; it never loops
This is the vectorized epilogue loop (really non-loop).
So this looks OK, but introduced one mismatch in profile. Before the pass we
had:
;; basic block 14, loop depth 2, count 171249098 (guessed, freq 23.9461),
maybe hot
;;prev block 51, next block 66, flags: (NEW, VISITED)
;;pred: 24 [always] count:142707582 (guessed, freq 19.9550)
(FALLTHRU,DFS_BACK,EXECUTABLE)
;;51 [always] count:28541516 (guessed, freq 3.9910)
(FALLTHRU,EXECUTABLE)
and now we get:
;; basic block 14, loop depth 2, count 13764235 (guessed, freq 1.9247), maybe
hot
;; Invalid sum of incoming counts 25234431 (guessed, freq 3.5286), should be
13764235
[Bug target/104871] macosx-version-min wrong for macOS >= Big Sur (darwin20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104871 Francois-Xavier Coudert changed: What|Removed |Added Target Milestone|--- |10.5 CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Francois-Xavier Coudert --- Fixed on all open branches.
[Bug middle-end/68360] GCC bitfield processing code is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107601 --- Comment #8 from Andrew Pinski --- (In reply to Thomas Koenig from comment #7) > Using an indexed load byte/store byte would be an advantage for foo, at > least. That would be more related to PR 107601 and less to do with this issue. Since for riscv SLOW_BYTE_ACCESS is set, then all bitfields accesses are widen. But then you want to have them widen normally; otherwise you get other bad code generation ... Note riscv with zbs in the testcase in comment #7 will be one bseti: ld a5,0(a0) bseti a5,a5,42 sd a5,0(a0) So it is less of an issue ...
[Bug target/91520] AVX512 target assembler fails for x86_64 Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91520 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #9 from Francois-Xavier Coudert --- I've not seen these issues for a long time, and according to testresults from July 2022 they are not seen on any of the darwin targets tested by Iain (and that's a long list!): https://gcc.gnu.org/pipermail/gcc-testresults/2022-July/thread.html I'd suggest closing.
[Bug other/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #5 from Andrew Pinski --- >--enable-host-shared Why are you using that option?
[Bug c/110683] wrong code with '-O2 -fpack-struct'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110683 --- Comment #5 from Andrew Pinski --- ms.c:299:24: warning: taking address of packed member of 'union U1' may result in an unaligned pointer value [-Waddress-of-packed-member]
[Bug c++/41518] copy initialization of volatile objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41518 Andrew Pinski changed: What|Removed |Added CC||irip at qq dot com --- Comment #7 from Andrew Pinski --- *** Bug 110685 has been marked as a duplicate of this bug. ***
[Bug c++/110685] problem with volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110685 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Been fixed since GCC 4.9.1. *** This bug has been marked as a duplicate of bug 41518 ***
[Bug c++/110690] invalid use of member 'S::m' in static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110690 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 68604. *** This bug has been marked as a duplicate of bug 68604 ***
[Bug c++/68604] [DR613] [C++11+] typeid does not allow an id-expression that denotes a non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68604 Andrew Pinski changed: What|Removed |Added CC||irip at qq dot com --- Comment #4 from Andrew Pinski --- *** Bug 110690 has been marked as a duplicate of this bug. ***
[Bug c++/110690] invalid use of member 'S::m' in static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110690
--- Comment #1 from Andrew Pinski ---
Here is the proper testcase:
```
#include
struct S {
int m;
static void f_sizeof() { (void) sizeof(m); }
static void f_typeid() { (void) typeid(decltype(m)); }
struct N {
int m;
static void f_sizeof() { (void) sizeof(m); }
static void f_typeid() { (void) typeid(decltype(m)); }
};
template class C {
public:
int m;
static void f_sizeof() { (void) sizeof(m); }
static void f_typeid() { (void) typeid(decltype(m)); }
};
} s;
static void f_typeid() { (void) typeid(S::m); }
```
[Bug c++/110689] problem of initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110689
--- Comment #1 from Andrew Pinski ---
Testcase that is complete:
```
#include
struct M {
operator char() { return 'a'; }
} m;
int flag;
struct S {
S(std::initializer_list) { flag = 1; }
S(std::initializer_list) { flag = 2; }
};
S s = { m };
```
[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 Jan Hubicka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill |a/show_bug.cgi?id=10647 |a/show_bug.cgi?id=110647 --- Comment #5 from Jan Hubicka --- In comment 3 I got wrong PR number. It is PR110647
[Bug c/110683] wrong code with '-O2 -fpack-struct'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110683
--- Comment #4 from Andrew Pinski ---
(In reply to CTC from comment #3)
> The reduced program is
>
> # cat mss.i
> struct a {
> char b;
> int c;
> };
> union {
> struct a b;
> short c;
> } d = {8, 1};
> void main() { printf("%d\n", d.c); }
This reduced case shows that -fpacked-struct will change the layout of struct a
and nothing more. Without the option there is some padding bytes which are
zero. Also also this reduced testcase depends on the endian of the target.
Maybe the original testcase has similar issues with the unions.
[Bug c/110683] wrong code with '-O2 -fpack-struct'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110683
--- Comment #3 from CTC <19373742 at buaa dot edu.cn> ---
The reduced program is
# cat mss.i
struct a {
char b;
int c;
};
union {
struct a b;
short c;
} d = {8, 1};
void main() { printf("%d\n", d.c); }
[Bug c++/110690] New: invalid use of member 'S::m' in static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110690
Bug ID: 110690
Summary: invalid use of member 'S::m' in static member function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: irip at qq dot com
Target Milestone: ---
Test Code:
struct S {
int m;
static void f_sizeof() { (void) sizeof(m); }
static void f_typeid() { (void) typeid(decltype(m)); }
struct N {
int m;
static void f_sizeof() { (void) sizeof(m); }
static void f_typeid() { (void) typeid(decltype(m)); }
};
template class C {
public:
int m;
static void f_sizeof() { (void) sizeof(m); }
static void f_typeid() { (void) typeid(decltype(m)); }
};
} s;
static void f_typeid() { (void) typeid(m); }
Compiler error:invalid use of member 'S::m' in static member function
The reason is that typeid's operand may or may not be an unevaluated operand,
so it is not known which one it is at parsing time
[Bug c++/110689] New: problem of initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110689
Bug ID: 110689
Summary: problem of initializer list
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: irip at qq dot com
Target Milestone: ---
In the code, declare a struct/class and define multiple types of list
initializers, then use list initializers, such as:
struct M {
operator char() { return 'a'; }
} m;
struct S {
S(std::initializer_list) { flag = 1; }
S(std::initializer_list) { flag = 2; }
};
……
S s = { m };
Compiler error:
conversion from '' to 'S' is ambiguous
This is allowed in the C++ standard and requires overloaded parsing when the
list is initialized.
[Bug c++/110688] New: problem with templates typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110688
Bug ID: 110688
Summary: problem with templates typename
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: irip at qq dot com
Target Milestone: ---
Test cases such as:
template struct S01 {
struct P::template T<1> m;
};
Compiler error:
declaration does not declare anything [-fpermissive]
The C++ standard allows class templates to be declared without the need for
typename to refer to the type of an unknown materialized member
[Bug c++/110687] New: problem with class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110687
Bug ID: 110687
Summary: problem with class template
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: irip at qq dot com
Target Milestone: ---
Testcase as:
namespace N {
template struct S01 {
template struct T {};
N::S01::template T<1> m;
};
}
Compiler error:
'T<1>' in 'struct N::S01' does not name a type
The C++ standard allows you to declare a class template without adding typename
when referring to a previously defined type
[Bug c++/110686] New: problem with explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110686
Bug ID: 110686
Summary: problem with explicit
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: irip at qq dot com
Target Milestone: ---
Test template name resolution, such as:
template struct N {
template struct S23{
typedef long X;
void g(void) { try {} catch (typename ::N::S::S23::X) {} }
};
};
Compiler error:
'typename N::S' names 'template template struct N::S', which is not a type
expected unqualified-id before '<' token
expected ')' before '<' token
expected '{' before '<' token
expected primary-expression before '<' token
'::X' has not been declared
expected '; ' before ')' token
Error occurs when using typename and nested namespace templates.
The C++ standard describes that the typename prefix should be used when a
nested form such as ::N::S::S23::X represents a type rather than a
member of the currently instantiated template.
[Bug other/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #4 from AlexK --- where in Makefile gcc copies compiled libs from prev-* stage1 to lib* in stage2 ?
[Bug c++/110685] New: problem with volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110685
Bug ID: 110685
Summary: problem with volatile
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: irip at qq dot com
Target Milestone: ---
The test case code is initialized using user-defined conversion functions, such
as:
struct S
{
int m;
S(int i = 0) : m(i) { counter++; }
};
...
volatile S s02 = 1;
const volatile S s03 = 1;
Compiler error:no matching function for call to 'S::S(volatile S)'、no matching
function for call to 'S::S(const volatile S)'
Cannot be converted correctly after adding volatile
[Bug other/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #3 from AlexK --- Created attachment 6 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=6=edit My system - Linux Mint
[Bug other/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #2 from AlexK --- Created attachment 5 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=5=edit C cannot find libraries from stage1 (they are in prev- folders)
[Bug c/110683] wrong code with '-O2' and specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110683 --- Comment #2 from CTC <19373742 at buaa dot edu.cn> --- The reduced optimizations is -O2 -fpack-struct
[Bug other/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #1 from AlexK --- Created attachment 4 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4=edit stage1 success config.log mybuild/config.log at successful stage1
[Bug other/110684] New: unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 Bug ID: 110684 Summary: unknown spec function ‘dumps’ error, C compiler cannot create executables Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: alexei_sylver1 at mail dot ru Target Milestone: --- Created attachment 3 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3=edit dumps error description In short: install -v -d mybuild && cd mybuild ../configure --prefix=/tools/gcc-12.2.0 --without-build-config LD=ld --enable-libssp --enable-bootstrap --enable-lto --with-isl=/usr/local --with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local --with-system-zlib --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gcov --enable-languages=c,c++,fortran,objc,obj-c++,jit,go --enable-host-shared --disable-multilib --enable-shared after some time I have got error g++: fatal error: unknown spec function ‘dumps’ compilation terminated. (file 1 attached) I have found nothing about fixing 'dumps' err After that I found at stackoverflow, that if to unset global variables, it can help to continue (https://stackoverflow.com/questions/75548412/without-unset-compiling-gcc-on-crostini-fails-with-unknown-spec-function-dumps) so I ran unset LIBRARY_PATH CPATH C_INCLUDE_PATH PKG_CONFIG_PATH CPLUS_INCLUDE_PATH INCLUDE LD_LIBRARY_PATH make and compilation was going sufficient time, stage was completed mybuild/config.log attached), but suddenly I have got error configure:2630: error: in `/home/alexei/build/gcc-12.2.0/mybuild/intl': configure:2632: error: C compiler cannot create executables config.log from mybuild/intl attached also very many variables in this file are empty How to help compiler fine xgcc and continue?
[Bug c/110683] wrong code with '-O2' and specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110683 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 2 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=2=edit The compiler output
[Bug c/110683] New: wrong code with '-O2' and specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110683 Bug ID: 110683 Summary: wrong code with '-O2' and specific optimizations Product: gcc Version: 12.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 19373742 at buaa dot edu.cn Target Milestone: --- Created attachment 1 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=1=edit The preprocessed file *** OS and Platform: CentOS Linux release 7.9.2009 (Core), x86_64 GNU/Linux *** gcc version: /home/gcc-releases/gcc-12-0707/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/gcc-releases/gcc-12-0707/bin/gcc COLLECT_LTO_WRAPPER=/home/gcc-releases/gcc-12-0707/libexec/gcc/x86_64-pc-linux-gnu/12.3.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/gcc-releases/gcc-12-0707/ --disable-multilib --enable-language=c,c++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.3.1 20230707 (GCC) *** Command Lines: # /home/gcc-releases/gcc-12-0707/bin/gcc -I /home/csmith_record/include/csmith-2.3.0/ -O2 -fno-aggressive-loop-optimizations -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fno-allocation-dce -fno-asynchronous-unwind-tables -fno-auto-inc-dec -fno-bit-tests -fno-branch-count-reg -fno-caller-saves -fno-code-hoisting -fno-combine-stack-adjustments -fno-compare-elim -fno-cprop-registers -fno-crossjumping -fno-cse-follow-jumps -fno-dce -fno-defer-pop -fno-devirtualize -fno-devirtualize-speculatively -fno-dse -fno-early-inlining -fno-expensive-optimizations -fno-forward-propagate -fno-fp-int-builtin-inexact -fno-function-cse -fno-gcse -fno-gcse-after-reload -fno-gcse-lm -fno-guess-branch-probability -fno-hoist-adjacent-loads -fno-if-conversion -fno-if-conversion2 -fno-indirect-inlining -fno-inline -fno-inline-atomics -fno-inline-functions -fno-inline-functions-called-once -fno-inline-small-functions -fno-ipa-bit-cp -fno-ipa-cp -fno-ipa-cp-clone -fno-ipa-icf -fno-ipa-icf-functions -fno-ipa-icf-variables -fno-ipa-modref -fno-ipa-profile -fno-ipa-pure-const -fno-ipa-ra -fno-ipa-reference -fno-ipa-reference-addressable -fno-ipa-sra -fno-ipa-stack-alignment -fno-ipa-strict-aliasing -fno-ipa-vrp -fno-ira-hoist-pressure -fno-ira-share-save-slots -fno-ira-share-spill-slots -fno-isolate-erroneous-paths-dereference -fno-ivopts -fno-jump-tables -fno-lifetime-dse -fno-loop-interchange -fno-loop-unroll-and-jam -fno-lra-remat -fno-math-errno -fno-move-loop-invariants -fno-move-loop-stores -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-optimize-strlen -fno-partial-inlining -fno-peel-loops -fno-peephole -fno-peephole2 -fno-plt -fno-predictive-commoning -fno-printf-return-value -fno-ree -fno-reg-struct-return -fno-reorder-blocks -fno-reorder-blocks-and-partition -fno-reorder-functions -fno-rerun-cse-after-loop -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic -fno-sched-group-heuristic -fno-sched-interblock -fno-sched-last-insn-heuristic -fno-sched-rank-heuristic -fno-sched-spec -fno-sched-spec-insn-heuristic -fno-sched-stalled-insns-dep -fno-schedule-fusion -fno-schedule-insns2 -fno-semantic-interposition -fno-short-enums -fno-shrink-wrap -fno-shrink-wrap-separate -fno-signed-zeros -fno-split-ivs-in-unroller -fno-split-loops -fno-split-paths -fno-split-wide-types -fno-ssa-backprop -fno-ssa-phiopt -fno-stdarg-opt -fno-store-merging -fno-strict-aliasing -fno-thread-jumps -fno-toplevel-reorder -fno-trapping-math -fno-tree-bit-ccp -fno-tree-builtin-call-dce -fno-tree-ccp -fno-tree-ch -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-forwprop -fno-tree-fre -fno-tree-loop-distribute-patterns -fno-tree-loop-distribution -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-loop-vectorize -fno-tree-partial-pre -fno-tree-phiprop -fno-tree-pre -fno-tree-pta -fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-sink -fno-tree-slp-vectorize -fno-tree-slsr -fno-tree-sra -fno-tree-switch-conversion -fno-tree-tail-merge -fno-tree-ter -fno-tree-vrp -fno-unroll-completely-grow-size -fno-unswitch-loops -fno-unwind-tables -fno-version-loops-for-strides -fno-allow-store-data-races -fno-associative-math -fno-branch-probabilities -fno-conserve-stack -fno-cx-fortran-rules -fno-cx-limited-range -fno-delayed-branch -fno-delete-dead-exceptions -fno-exceptions -fno-finite-loops -fno-finite-math-only -fno-float-store -fno-gcse-las -fno-gcse-sm -fno-graphite -fno-graphite-identity -fno-harden-compares -fno-harden-conditional-branches -fno-ipa-pta -fno-ira-loop-pressure -fno-isolate-erroneous-paths-attribute
[Bug middle-end/68360] GCC bitfield processing code is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2015-11-16 00:00:00 |2023-7-16
CC||tkoenig at gcc dot gnu.org
--- Comment #7 from Thomas Koenig ---
Just stumbled across this.
A maybe simpler testcase:
typedef struct
{
unsigned long x: 42;
unsigned b: 1;
unsigned long y: 42;
} myfield;
typedef struct
{
unsigned long x: 7;
unsigned b: 1;
unsigned long y: 42;
} yourfield;
void foo(myfield *x)
{
x->b = 1;
}
void bar (yourfield *x)
{
x->b = 1;
}
gets, on RISC-V,
foo:
ld a5,0(a0)
li a4,1
sllia4,a4,42
or a5,a5,a4
sd a5,0(a0)
ret
bar:
ld a5,0(a0)
ori a5,a5,128
sd a5,0(a0)
ret
Using an indexed load byte/store byte would be an advantage for foo, at least.
[Bug rtl-optimization/97756] [11/12/13/14 Regression] Inefficient handling of 128-bit arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756 --- Comment #12 from Thomas Koenig --- (In reply to Andrew Pinski from comment #11) > This seems to be improved on trunk ... gcc is down to 37 instructions now for the original test case with -O3. icc, which appears to be best, has 33, see https://godbolt.org/z/461jeozs9 .
[Bug c/110682] New: GCC, ICE: internal compiler error: in gimplify_expr, at gimplify.cc:16771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110682
Bug ID: 110682
Summary: GCC, ICE: internal compiler error: in gimplify_expr,
at gimplify.cc:16771
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: ---
When compiling below program using gcc-14 with option `gcc-14 -Ofast a.c`,
gcc-14 crashes:
```
struct a {
const signed char b;
};
void f(volatile struct a *c) {
c - 0 % c->b;
struct a c = {1};
}
```
GCC's output is pasted below:
```
: In function 'f':
:7:12: error: 'c' redeclared as different kind of symbol
7 | struct a c = {1};
|^
:5:27: note: previous definition of 'c' with type 'volatile struct a *'
5 | void f(volatile struct a *c) {
|~~~^
:6:5: internal compiler error: in gimplify_expr, at gimplify.cc:16771
6 | c - 0 % c->b;
| ~~^~
0x2150dee internal_error(char const*, ...)
???:0
0x9ce06c fancy_abort(char const*, int, char const*)
???:0
0xd7057a gimplify_stmt(tree_node**, gimple**)
???:0
0xd6d9ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd7057a gimplify_stmt(tree_node**, gimple**)
???:0
0xd6e4eb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd7057a gimplify_stmt(tree_node**, gimple**)
???:0
0xd6d954 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd7057a gimplify_stmt(tree_node**, gimple**)
???:0
0xd71a13 gimplify_body(tree_node*, bool)
???:0
0xd71e6f gimplify_function_tree(tree_node*)
???:0
0xbaebe7 cgraph_node::analyze()
???:0
0xbb2731 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
