https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Bug 105231 depends on bug 106082, which changed state.
Bug 106082 Summary: [13 Regression] Recent change broke m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106082
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #30 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4f77738c3b44cb6b7bfe2a7ef823a5d9d75c0e79
commit r12-8239-g4f77738c3b44cb6b7bfe2a7ef823a5d9d75c0e79
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #29 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #27 from rguenther at suse dot de ---
On Thu, 14 Apr 2022, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
>
> --- Comment #26 from Segher Boessenkool ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #26 from Segher Boessenkool ---
(In reply to Richard Biener from comment #25)
> (In reply to Segher Boessenkool from comment #24)
> > Wrt keeping REG_EQUAL notes... If you want to keep them you need to make
> > sure
> > they still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #25 from Richard Biener ---
(In reply to Segher Boessenkool from comment #24)
> Wrt keeping REG_EQUAL notes... If you want to keep them you need to make
> sure
> they still are valid. GCC keeps those on i3, it is much too hard in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #24 from Segher Boessenkool ---
Wrt keeping REG_EQUAL notes... If you want to keep them you need to make sure
they still are valid. GCC keeps those on i3, it is much too hard in general to
validate other such notes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #23 from Segher Boessenkool ---
i3 is not always the sole instruction that results from the combine: if a
single insn does not work, two are tried, and one of them is placed at i2.
It's something to consider, it has to be checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #22 from rguenther at suse dot de ---
On Wed, 13 Apr 2022, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
>
> --- Comment #21 from Eric Botcazou ---
> > I'm not sure that's a general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #21 from Eric Botcazou ---
> I'm not sure that's a general enough fix though since we seem to drop
> the REG_EQUAL note and as soon as we do that there's a disconnect
> between what CFG generation thinks throws and what combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #20 from rguenther at suse dot de ---
On Tue, 12 Apr 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
>
> --- Comment #19 from Jakub Jelinek ---
> It is true that float_extend from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #19 from Jakub Jelinek ---
It is true that float_extend from a constant or constant pool memory if the
constant isn't NaN should never raise any kind of exception or trap.
Shouldn't we handle that in may_trap_p_1 or whatever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #18 from rguenther at suse dot de ---
On Tue, 12 Apr 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
>
> --- Comment #16 from Jakub Jelinek ---
> i3 is always the last, that is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #17 from Jakub Jelinek ---
For the testcase, again no reason for -fsanitize=thread,
void baz (int *);
void bar (double, double, _Decimal64);
void
foo (void)
{
int s __attribute__((cleanup (baz)));
bar (0xfffe,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #16 from Jakub Jelinek ---
i3 is always the last, that is the ultimate insn into which the other insns are
combined into.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #15 from Richard Biener ---
But looking at all the distribute_notes calls I'm not sure that i2 and i3 are
passed in execution order or that i3 is always the last instruction in the
set of insns that are combined?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #14 from rguenther at suse dot de ---
On Tue, 12 Apr 2022, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
>
> --- Comment #13 from Eric Botcazou ---
> > Oh, and checking for REG_EQUAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #13 from Eric Botcazou ---
> Oh, and checking for REG_EQUAL notes on i2/i3 doesn't work since they do not
> exist there. Likewise REG_EQUAL notes can be simply dropped which would
> make the IL "invalid" so I think what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #12 from Richard Biener ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > (In reply to Eric Botcazou from comment #8)
> > > > Yes, but still the float_extend:XF would have made
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #10 from Richard Biener ---
(In reply to Eric Botcazou from comment #8)
> > Yes, but still the float_extend:XF would have made may_trap_p say
> > the insn possibly traps but there's no EH on it despite
> > -fnon-call-exceptions.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #9 from Richard Biener ---
Initially we generate
(insn 36 35 37 (set (reg:XF 95)
(float_extend:XF (reg:SF 96))) "t.c":6:3 -1
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(expr_list:REG_EQUAL (const_double:XF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #8 from Eric Botcazou ---
> Yes, but still the float_extend:XF would have made may_trap_p say
> the insn possibly traps but there's no EH on it despite
> -fnon-call-exceptions.
The REG_EH note is added by make_reg_eh_region_note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #7 from rguenther at suse dot de ---
On Tue, 12 Apr 2022, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
>
> --- Comment #6 from Eric Botcazou ---
> > So interestingly distribute_notes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #6 from Eric Botcazou ---
> So interestingly distribute_notes sees
>
> (gdb) p debug_rtx (i2)
> (insn 78 22 24 3 (set (reg:XF 99)
> (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2])
> [0 S4 A32]))) 166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #5 from Richard Biener ---
may_trap_p triggers on the (float_extend:XF ...) because
/* Any floating arithmetic may trap. */
if (FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math)
return 1;
with all that I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #3 from Richard Biener ---
Before combine we had
(insn 22 17 78 3 (set (reg:SF 92)
(mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S4 A32]))
"t.c":6:3 142 {*movsf_internal}
(expr_list:REG_EQUAL (const_double:SF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
31 matches
Mail list logo
