public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu
@ 2023-06-04 20:10 shaohua.li at inf dot ethz.ch
2023-06-04 20:33 ` [Bug c/110115] " pinskia at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: shaohua.li at inf dot ethz.ch @ 2023-06-04 20:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
Bug ID: 110115
Summary: Wrong code at -O1 on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
gcc at -O1 emits the wrong code. This seems to be a long latent bug.
Compiler explorer: https://godbolt.org/z/3h4TYEYjW
$ cat a.c
int a;
char b;
static int c(char *e, int f) {
int d = 0;
for (; d < f; d++)
e[d] = 0;
return d;
}
int g(char e, int f) {
char h[20];
int i = c(h, f);
return i;
}
int j() {
switch (a) {
case 'f':
return 0;
default:
return ~0;
}
}
int main() {
{
char *k[3];
int d = 0;
for (; g(8, 15) - 15 + d < 1; d++)
k[j()+1] = &b;
*k[0] = -*k[0];
}
}
$
$ gcc-tk -O0 a.c && ./a.out
$
$ gcc-tk -O1 a.c && ./a.out
Segmentation fault
$
$ gcc-tk -fsanitize=address,undefined a.c && ./a.out
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-8d5f050dabbf6dd3b992c3b46661848dbcf30d9e/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-8d5f050dabbf6dd3b992c3b46661848dbcf30d9e
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230523 (experimental) (GCC)
$
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/110115] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
@ 2023-06-04 20:33 ` pinskia at gcc dot gnu.org
2023-06-04 20:34 ` [Bug middle-end/110115] " pinskia at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-04 20:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Partition 0: size 24 align 16
k h
That is definitely wrong.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/110115] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
2023-06-04 20:33 ` [Bug c/110115] " pinskia at gcc dot gnu.org
@ 2023-06-04 20:34 ` pinskia at gcc dot gnu.org
2023-06-04 20:35 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-04 20:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Component|c |middle-end
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=103006
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Most likely another dup of bug 103006.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/110115] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
2023-06-04 20:33 ` [Bug c/110115] " pinskia at gcc dot gnu.org
2023-06-04 20:34 ` [Bug middle-end/110115] " pinskia at gcc dot gnu.org
@ 2023-06-04 20:35 ` pinskia at gcc dot gnu.org
2023-06-04 20:37 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-04 20:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=90348
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Most likely another dup of bug 103006.
Or rather PR 90348.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/110115] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
` (2 preceding siblings ...)
2023-06-04 20:35 ` pinskia at gcc dot gnu.org
@ 2023-06-04 20:37 ` pinskia at gcc dot gnu.org
2023-07-30 14:23 ` shaohua.li at inf dot ethz.ch
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-04 20:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
And yes -fstack-reuse=none fixes the issue.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/110115] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
` (3 preceding siblings ...)
2023-06-04 20:37 ` pinskia at gcc dot gnu.org
@ 2023-07-30 14:23 ` shaohua.li at inf dot ethz.ch
2023-12-18 1:19 ` [Bug middle-end/110115] [11/12/13/14 Regression] " pinskia at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: shaohua.li at inf dot ethz.ch @ 2023-07-30 14:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
--- Comment #5 from Shaohua Li <shaohua.li at inf dot ethz.ch> ---
I tried to bisect this case and I bisected it to r0-2686-gd119f34c952
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/110115] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
` (4 preceding siblings ...)
2023-07-30 14:23 ` shaohua.li at inf dot ethz.ch
@ 2023-12-18 1:19 ` pinskia at gcc dot gnu.org
2024-01-16 10:51 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-18 1:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-12-18
Known to fail| |11.1.0
Summary|Wrong code at -O1 on |[11/12/13/14 Regression]
|x86_64-linux-gnu |Wrong code at -O1 on
| |x86_64-linux-gnu
Target Milestone|--- |11.5
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to work| |10.1.0
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/110115] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
` (5 preceding siblings ...)
2023-12-18 1:19 ` [Bug middle-end/110115] [11/12/13/14 Regression] " pinskia at gcc dot gnu.org
@ 2024-01-16 10:51 ` cvs-commit at gcc dot gnu.org
2024-03-02 0:38 ` cvs-commit at gcc dot gnu.org
2024-03-04 12:12 ` [Bug middle-end/110115] [11/12 " jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-01-16 10:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:1251d3957de04dc9b023a23c09400217e13deadb
commit r14-7274-g1251d3957de04dc9b023a23c09400217e13deadb
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Jan 16 11:49:34 2024 +0100
cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]
The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
ivtmp.40_3 = (unsigned long) &MEM <unsigned long[100]> [(void *)&bitint.6
+ 8B];
...
uses of ivtmp.40_3
...
bitint.6 ={v} {CLOBBER(eos)};
...
ivtmp.28_43 = (unsigned long) &MEM <unsigned long[100]> [(void
*)&bitint.6 + 8B];
...
uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.
The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.
In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers). The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXXXXXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.
2024-01-16 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.
* gcc.dg/torture/bitint-49.c: New test.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/110115] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
` (6 preceding siblings ...)
2024-01-16 10:51 ` cvs-commit at gcc dot gnu.org
@ 2024-03-02 0:38 ` cvs-commit at gcc dot gnu.org
2024-03-04 12:12 ` [Bug middle-end/110115] [11/12 " jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-02 0:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:432708c306838fe1444da0df7d629a60468c0c73
commit r13-8383-g432708c306838fe1444da0df7d629a60468c0c73
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Jan 16 11:49:34 2024 +0100
cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]
The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
ivtmp.40_3 = (unsigned long) &MEM <unsigned long[100]> [(void *)&bitint.6
+ 8B];
...
uses of ivtmp.40_3
...
bitint.6 ={v} {CLOBBER(eos)};
...
ivtmp.28_43 = (unsigned long) &MEM <unsigned long[100]> [(void
*)&bitint.6 + 8B];
...
uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.
The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.
In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers). The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXXXXXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.
2024-01-16 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.
(cherry picked from commit 1251d3957de04dc9b023a23c09400217e13deadb)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/110115] [11/12 Regression] Wrong code at -O1 on x86_64-linux-gnu
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
` (7 preceding siblings ...)
2024-03-02 0:38 ` cvs-commit at gcc dot gnu.org
@ 2024-03-04 12:12 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-03-04 12:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110115
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
Summary|[11/12/13/14 Regression] |[11/12 Regression] Wrong
|Wrong code at -O1 on |code at -O1 on
|x86_64-linux-gnu |x86_64-linux-gnu
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Worked around for GCC 13.3+ and 14+.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-03-04 12:12 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-04 20:10 [Bug c/110115] New: Wrong code at -O1 on x86_64-linux-gnu shaohua.li at inf dot ethz.ch
2023-06-04 20:33 ` [Bug c/110115] " pinskia at gcc dot gnu.org
2023-06-04 20:34 ` [Bug middle-end/110115] " pinskia at gcc dot gnu.org
2023-06-04 20:35 ` pinskia at gcc dot gnu.org
2023-06-04 20:37 ` pinskia at gcc dot gnu.org
2023-07-30 14:23 ` shaohua.li at inf dot ethz.ch
2023-12-18 1:19 ` [Bug middle-end/110115] [11/12/13/14 Regression] " pinskia at gcc dot gnu.org
2024-01-16 10:51 ` cvs-commit at gcc dot gnu.org
2024-03-02 0:38 ` cvs-commit at gcc dot gnu.org
2024-03-04 12:12 ` [Bug middle-end/110115] [11/12 " jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).