* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
@ 2022-10-07 20:18 ` pinskia at gcc dot gnu.org
2022-10-10 13:00 ` [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f marxin at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-07 20:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|debug |target
Summary|-fcompare-debug failure |[10/11/12/13 Regression]
|(length) with |-fcompare-debug failure
|-fsanitize=float-cast-overf |(length) with
|low |-fsanitize=float-cast-overf
| |low
Target Milestone|--- |10.5
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am 99% sure it is a bug in reg-stack.cc which makes this a target issue as
x86_64 is one of two targets which use reg-stack for their FP (m68k being the
other).
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
2022-10-07 20:18 ` [Bug target/107183] [10/11/12/13 Regression] " pinskia at gcc dot gnu.org
@ 2022-10-10 13:00 ` marxin at gcc dot gnu.org
2022-10-10 15:20 ` pinskia at gcc dot gnu.org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-10-10 13:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-10-10
Status|UNCONFIRMED |NEW
Summary|[10/11/12/13 Regression] |[10/11/12/13 Regression]
|-fcompare-debug failure |-fcompare-debug failure
|(length) with |(length) with
|-fsanitize=float-cast-overf |-fsanitize=float-cast-overf
|low |low since
| |r7-5708-gcfd719e7769fd43f
CC| |jakub at gcc dot gnu.org,
| |marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Likely started with r7-5708-gcfd719e7769fd43f.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
2022-10-07 20:18 ` [Bug target/107183] [10/11/12/13 Regression] " pinskia at gcc dot gnu.org
2022-10-10 13:00 ` [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f marxin at gcc dot gnu.org
@ 2022-10-10 15:20 ` pinskia at gcc dot gnu.org
2022-10-18 8:33 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-10 15:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #2)
> Likely started with r7-5708-gcfd719e7769fd43f.
Exposed by ....
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (2 preceding siblings ...)
2022-10-10 15:20 ` pinskia at gcc dot gnu.org
@ 2022-10-18 8:33 ` rguenth at gcc dot gnu.org
2022-11-18 14:29 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-10-18 8:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (3 preceding siblings ...)
2022-10-18 8:33 ` rguenth at gcc dot gnu.org
@ 2022-11-18 14:29 ` jakub at gcc dot gnu.org
2022-11-18 16:13 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-18 14:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the bug is in swap_rtx_condition.
It is called on:
(insn 10023 10021 10024 4 (set (reg:CCFP 17 flags)
(unspec:CCFP [
(compare:CCFP (reg:XF 9 st(1) [orig:84 _3 ] [84])
(reg:XF 8 st [107]))
] UNSPEC_NOTRAP)) "pr107183.c":6:18 discrim 1 45 {*cmpiuxf_i387}
(expr_list:REG_DEAD (reg:XF 9 st(1) [orig:84 _3 ] [84])
(expr_list:REG_DEAD (reg:XF 8 st [107])
(nil))))
on the first next_flags_user call in the function it sets insn to:
(insn 10110 10024 10111 4 (set (reg:QI 3 bx [105])
(unordered:QI (reg:CCFP 17 flags)
(const_int 0 [0]))) "pr107183.c":6:18 discrim 1 949 {*setcc_qi}
(nil))
(still the same between -g and -g0, but already that one could differ),
but then next_flags_user (the 3rd one in the function) finds
(debug_insn 4 10029 10030 4 (var_location:SI D#1 (if_then_else:SI (uneq
(reg:CCFP 17 flags)
(const_int 0 [0]))
(reg:SI 3 bx [105])
(reg:SI 0 ax [111]))) -1
(nil))
with -g and
(insn 10030 10029 10032 4 (set (reg:SI 3 bx [orig:90 iftmp.0_9 ] [90])
(if_then_else:SI (uneq (reg:CCFP 17 flags)
(const_int 0 [0]))
(reg:SI 3 bx [105])
(reg:SI 0 ax [111]))) "pr107183.c":6:18 discrim 1 1269
{*movsicc_noc}
(expr_list:REG_DEAD (reg:CCFP 17 flags)
(expr_list:REG_DEAD (reg:SI 0 ax [111])
(expr_list:REG_EQUAL (if_then_else:SI (uneq (reg:CCFP 17 flags)
(const_int 0 [0]))
(reg:SI 3 bx [105])
(const_int 1 [0x1]))
(nil)))))
with -g0.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (4 preceding siblings ...)
2022-11-18 14:29 ` jakub at gcc dot gnu.org
@ 2022-11-18 16:13 ` jakub at gcc dot gnu.org
2022-11-20 16:44 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-18 16:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53926
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53926&action=edit
gcc13-pr107183.patch
Untested fix.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (5 preceding siblings ...)
2022-11-18 16:13 ` jakub at gcc dot gnu.org
@ 2022-11-20 16:44 ` cvs-commit at gcc dot gnu.org
2022-11-20 23:11 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-20 16:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
--- Comment #6 from CVS 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:6b5c98c1c0003bd470a4428bede6c862637a94b8
commit r13-4175-g6b5c98c1c0003bd470a4428bede6c862637a94b8
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sun Nov 20 17:42:42 2022 +0100
reg-stack: Fix a -fcompare-debug bug in reg-stack [PR107183]
As the following testcase shows, the swap_rtx_condition function
in reg-stack can result in different code generation between -g and -g0.
The function is doing the changes as it goes, so does analysis and
changes together, which makes it harder to deal with DEBUG_INSNs,
where normally analysis phase ignores them and the later phase
doesn't.
swap_rtx_condition walks instructions two different ways, one is
using next_flags_user function which stops on non-call instructions
that mention the flags register, and the other is a loop on fnstsw
where it stops on instructions mentioning it and tries to find
sahf instruction that uses it (in both cases calls stop it and so
does end of basic block).
Now both of these currently stop on DEBUG_INSNs that mention
the flags register resp. the fnstsw result register.
On success the function recurses on next flags user instruction
if still live and if the recursion failed, reverts the changes
it did too and fails.
If it were just for the next_flags_user case, the fix could be
just not doing
INSN_CODE (insn) = -1;
if (recog_memoized (insn) == -1)
fail = 1;
on DEBUG_INSNs (assuming all changes to those are fine),
swap_rtx_condition_1 just changes one comparison to a different
one. But due to the possibility of fnstsw result being used
in theory before sahf in some DEBUG_INSNs, this patch takes
a different approach. swap_rtx_condition has now a new argument
and two modes. The first mode is when debug_seen is >= 0, in this
case both next_flags_user and the loop for fnstsw -> sahf will
ignore but note DEBUG_INSNs (that mention flags register or fnstsw
result). If no such DEBUG_INSN is found during the whole call
including recursive invocations (so e.g. for -g0 but probably most
often for -g as well), it behaves as before, if it returns true
all the changes are done and nothing further needs to be done later.
If any DEBUG_INSNs are seen along the way, even when returning success
all the changes are reverted, so it just reports that the function
would be successful if DEBUG_INSNs were ignored.
In this case, compare_for_stack_reg needs to call it again in
debug_seen = -1 mode, which tells the function to update everything
including DEBUG_INSNs. For the fnstsw -> sahf case which I hope
will be very rare I just reset the DEBUG_INSNs, I don't really
know how to express it easily otherwise. For the rest
swap_rtx_condition_1 is done even on the DEBUG_INSNs.
2022-11-20 Jakub Jelinek <jakub@redhat.com>
PR target/107183
* reg-stack.cc (next_flags_user): Add DEBUG_SEEN argument.
If >= 0 and a DEBUG_INSN would be otherwise returned, set
DEBUG_SEEN to 1 and ignore it.
(swap_rtx_condition): Add DEBUG_SEEN argument. In >= 0
mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs
were seen and revert all changes on success in that case.
Don't try to recog_memoized DEBUG_INSNs.
(compare_for_stack_reg): Adjust swap_rtx_condition caller.
If it returns true and debug_seen is 1, call swap_rtx_condition
again with debug_seen -1.
* gcc.dg/ubsan/pr107183.c: New test.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (6 preceding siblings ...)
2022-11-20 16:44 ` cvs-commit at gcc dot gnu.org
@ 2022-11-20 23:11 ` cvs-commit at gcc dot gnu.org
2022-11-21 9:23 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-20 23:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:196cb25ddbc6c4fae5e7b1c0a09f32f59bdabaa8
commit r12-8922-g196cb25ddbc6c4fae5e7b1c0a09f32f59bdabaa8
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sun Nov 20 17:42:42 2022 +0100
reg-stack: Fix a -fcompare-debug bug in reg-stack [PR107183]
As the following testcase shows, the swap_rtx_condition function
in reg-stack can result in different code generation between -g and -g0.
The function is doing the changes as it goes, so does analysis and
changes together, which makes it harder to deal with DEBUG_INSNs,
where normally analysis phase ignores them and the later phase
doesn't.
swap_rtx_condition walks instructions two different ways, one is
using next_flags_user function which stops on non-call instructions
that mention the flags register, and the other is a loop on fnstsw
where it stops on instructions mentioning it and tries to find
sahf instruction that uses it (in both cases calls stop it and so
does end of basic block).
Now both of these currently stop on DEBUG_INSNs that mention
the flags register resp. the fnstsw result register.
On success the function recurses on next flags user instruction
if still live and if the recursion failed, reverts the changes
it did too and fails.
If it were just for the next_flags_user case, the fix could be
just not doing
INSN_CODE (insn) = -1;
if (recog_memoized (insn) == -1)
fail = 1;
on DEBUG_INSNs (assuming all changes to those are fine),
swap_rtx_condition_1 just changes one comparison to a different
one. But due to the possibility of fnstsw result being used
in theory before sahf in some DEBUG_INSNs, this patch takes
a different approach. swap_rtx_condition has now a new argument
and two modes. The first mode is when debug_seen is >= 0, in this
case both next_flags_user and the loop for fnstsw -> sahf will
ignore but note DEBUG_INSNs (that mention flags register or fnstsw
result). If no such DEBUG_INSN is found during the whole call
including recursive invocations (so e.g. for -g0 but probably most
often for -g as well), it behaves as before, if it returns true
all the changes are done and nothing further needs to be done later.
If any DEBUG_INSNs are seen along the way, even when returning success
all the changes are reverted, so it just reports that the function
would be successful if DEBUG_INSNs were ignored.
In this case, compare_for_stack_reg needs to call it again in
debug_seen = -1 mode, which tells the function to update everything
including DEBUG_INSNs. For the fnstsw -> sahf case which I hope
will be very rare I just reset the DEBUG_INSNs, I don't really
know how to express it easily otherwise. For the rest
swap_rtx_condition_1 is done even on the DEBUG_INSNs.
2022-11-20 Jakub Jelinek <jakub@redhat.com>
PR target/107183
* reg-stack.cc (next_flags_user): Add DEBUG_SEEN argument.
If >= 0 and a DEBUG_INSN would be otherwise returned, set
DEBUG_SEEN to 1 and ignore it.
(swap_rtx_condition): Add DEBUG_SEEN argument. In >= 0
mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs
were seen and revert all changes on success in that case.
Don't try to recog_memoized DEBUG_INSNs.
(compare_for_stack_reg): Adjust swap_rtx_condition caller.
If it returns true and debug_seen is 1, call swap_rtx_condition
again with debug_seen -1.
* gcc.dg/ubsan/pr107183.c: New test.
(cherry picked from commit 6b5c98c1c0003bd470a4428bede6c862637a94b8)
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (7 preceding siblings ...)
2022-11-20 23:11 ` cvs-commit at gcc dot gnu.org
@ 2022-11-21 9:23 ` cvs-commit at gcc dot gnu.org
2022-11-21 9:31 ` [Bug target/107183] [10 " jakub at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-21 9:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:d92cbc49eac263e32ff5eaabffd3efe2324502d2
commit r11-10386-gd92cbc49eac263e32ff5eaabffd3efe2324502d2
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sun Nov 20 17:42:42 2022 +0100
reg-stack: Fix a -fcompare-debug bug in reg-stack [PR107183]
As the following testcase shows, the swap_rtx_condition function
in reg-stack can result in different code generation between -g and -g0.
The function is doing the changes as it goes, so does analysis and
changes together, which makes it harder to deal with DEBUG_INSNs,
where normally analysis phase ignores them and the later phase
doesn't.
swap_rtx_condition walks instructions two different ways, one is
using next_flags_user function which stops on non-call instructions
that mention the flags register, and the other is a loop on fnstsw
where it stops on instructions mentioning it and tries to find
sahf instruction that uses it (in both cases calls stop it and so
does end of basic block).
Now both of these currently stop on DEBUG_INSNs that mention
the flags register resp. the fnstsw result register.
On success the function recurses on next flags user instruction
if still live and if the recursion failed, reverts the changes
it did too and fails.
If it were just for the next_flags_user case, the fix could be
just not doing
INSN_CODE (insn) = -1;
if (recog_memoized (insn) == -1)
fail = 1;
on DEBUG_INSNs (assuming all changes to those are fine),
swap_rtx_condition_1 just changes one comparison to a different
one. But due to the possibility of fnstsw result being used
in theory before sahf in some DEBUG_INSNs, this patch takes
a different approach. swap_rtx_condition has now a new argument
and two modes. The first mode is when debug_seen is >= 0, in this
case both next_flags_user and the loop for fnstsw -> sahf will
ignore but note DEBUG_INSNs (that mention flags register or fnstsw
result). If no such DEBUG_INSN is found during the whole call
including recursive invocations (so e.g. for -g0 but probably most
often for -g as well), it behaves as before, if it returns true
all the changes are done and nothing further needs to be done later.
If any DEBUG_INSNs are seen along the way, even when returning success
all the changes are reverted, so it just reports that the function
would be successful if DEBUG_INSNs were ignored.
In this case, compare_for_stack_reg needs to call it again in
debug_seen = -1 mode, which tells the function to update everything
including DEBUG_INSNs. For the fnstsw -> sahf case which I hope
will be very rare I just reset the DEBUG_INSNs, I don't really
know how to express it easily otherwise. For the rest
swap_rtx_condition_1 is done even on the DEBUG_INSNs.
2022-11-20 Jakub Jelinek <jakub@redhat.com>
PR target/107183
* reg-stack.c (next_flags_user): Add DEBUG_SEEN argument.
If >= 0 and a DEBUG_INSN would be otherwise returned, set
DEBUG_SEEN to 1 and ignore it.
(swap_rtx_condition): Add DEBUG_SEEN argument. In >= 0
mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs
were seen and revert all changes on success in that case.
Don't try to recog_memoized DEBUG_INSNs.
(compare_for_stack_reg): Adjust swap_rtx_condition caller.
If it returns true and debug_seen is 1, call swap_rtx_condition
again with debug_seen -1.
* gcc.dg/ubsan/pr107183.c: New test.
(cherry picked from commit 6b5c98c1c0003bd470a4428bede6c862637a94b8)
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (8 preceding siblings ...)
2022-11-21 9:23 ` cvs-commit at gcc dot gnu.org
@ 2022-11-21 9:31 ` jakub at gcc dot gnu.org
2023-05-03 15:19 ` cvs-commit at gcc dot gnu.org
2023-05-04 7:20 ` jakub at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-21 9:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[10/11/12/13 Regression] |[10 Regression]
|-fcompare-debug failure |-fcompare-debug failure
|(length) with |(length) with
|-fsanitize=float-cast-overf |-fsanitize=float-cast-overf
|low since |low since
|r7-5708-gcfd719e7769fd43f |r7-5708-gcfd719e7769fd43f
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.4+, 12.3+ and trunk so far.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (9 preceding siblings ...)
2022-11-21 9:31 ` [Bug target/107183] [10 " jakub at gcc dot gnu.org
@ 2023-05-03 15:19 ` cvs-commit at gcc dot gnu.org
2023-05-04 7:20 ` jakub at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-03 15:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:2c83256249624cdf6feae6814cc31ef2cd94c185
commit r10-11342-g2c83256249624cdf6feae6814cc31ef2cd94c185
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sun Nov 20 17:42:42 2022 +0100
reg-stack: Fix a -fcompare-debug bug in reg-stack [PR107183]
As the following testcase shows, the swap_rtx_condition function
in reg-stack can result in different code generation between -g and -g0.
The function is doing the changes as it goes, so does analysis and
changes together, which makes it harder to deal with DEBUG_INSNs,
where normally analysis phase ignores them and the later phase
doesn't.
swap_rtx_condition walks instructions two different ways, one is
using next_flags_user function which stops on non-call instructions
that mention the flags register, and the other is a loop on fnstsw
where it stops on instructions mentioning it and tries to find
sahf instruction that uses it (in both cases calls stop it and so
does end of basic block).
Now both of these currently stop on DEBUG_INSNs that mention
the flags register resp. the fnstsw result register.
On success the function recurses on next flags user instruction
if still live and if the recursion failed, reverts the changes
it did too and fails.
If it were just for the next_flags_user case, the fix could be
just not doing
INSN_CODE (insn) = -1;
if (recog_memoized (insn) == -1)
fail = 1;
on DEBUG_INSNs (assuming all changes to those are fine),
swap_rtx_condition_1 just changes one comparison to a different
one. But due to the possibility of fnstsw result being used
in theory before sahf in some DEBUG_INSNs, this patch takes
a different approach. swap_rtx_condition has now a new argument
and two modes. The first mode is when debug_seen is >= 0, in this
case both next_flags_user and the loop for fnstsw -> sahf will
ignore but note DEBUG_INSNs (that mention flags register or fnstsw
result). If no such DEBUG_INSN is found during the whole call
including recursive invocations (so e.g. for -g0 but probably most
often for -g as well), it behaves as before, if it returns true
all the changes are done and nothing further needs to be done later.
If any DEBUG_INSNs are seen along the way, even when returning success
all the changes are reverted, so it just reports that the function
would be successful if DEBUG_INSNs were ignored.
In this case, compare_for_stack_reg needs to call it again in
debug_seen = -1 mode, which tells the function to update everything
including DEBUG_INSNs. For the fnstsw -> sahf case which I hope
will be very rare I just reset the DEBUG_INSNs, I don't really
know how to express it easily otherwise. For the rest
swap_rtx_condition_1 is done even on the DEBUG_INSNs.
2022-11-20 Jakub Jelinek <jakub@redhat.com>
PR target/107183
* reg-stack.c (next_flags_user): Add DEBUG_SEEN argument.
If >= 0 and a DEBUG_INSN would be otherwise returned, set
DEBUG_SEEN to 1 and ignore it.
(swap_rtx_condition): Add DEBUG_SEEN argument. In >= 0
mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs
were seen and revert all changes on success in that case.
Don't try to recog_memoized DEBUG_INSNs.
(compare_for_stack_reg): Adjust swap_rtx_condition caller.
If it returns true and debug_seen is 1, call swap_rtx_condition
again with debug_seen -1.
* gcc.dg/ubsan/pr107183.c: New test.
(cherry picked from commit 6b5c98c1c0003bd470a4428bede6c862637a94b8)
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug target/107183] [10 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f
2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz
` (10 preceding siblings ...)
2023-05-03 15:19 ` cvs-commit at gcc dot gnu.org
@ 2023-05-04 7:20 ` jakub at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-04 7:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.5 too.
^ permalink raw reply [flat|nested] 13+ messages in thread