https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #34 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #33)
> On Sat, 30 Mar 2019, segher at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
> >
> > --- Comment #32 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #33 from rguenther at suse dot de ---
On Sat, 30 Mar 2019, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
>
> --- Comment #32 from Segher Boessenkool ---
> Historically, a local register asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #32 from Segher Boessenkool ---
Historically, a local register asm variable *does* live in that variable
for its entire scope. This stopped working correctly, even with the many
caveats there were for it, and many years ago the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #31 from Segher Boessenkool ---
If an asm makes a function non-pure, that asm should be volatile in the
first place? Or are there any cases where that is not true?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #30 from rguenther at suse dot de ---
On Fri, 29 Mar 2019, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
>
> --- Comment #29 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #29 from Jakub Jelinek ---
(In reply to Richard Biener from comment #28)
> Any comments?
> --- gcc/gimple.c(revision 270012)
> +++ gcc/gimple.c(working copy)
> @@ -2727,11 +2738,16 @@ gimple_asm_clobbers_memory_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #28 from Richard Biener ---
I am considering the following as a fix for the GIMPLE issue, does that
look acceptable? I think a binary flag as suggested by Jakub results
in somewhat unpredictable behavior with regard to inlining I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #27 from rguenther at suse dot de ---
On February 8, 2019 6:35:29 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
>
>--- Comment #24 from Jakub Jelinek ---
>FRE doesn't, as that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #26 from Jakub Jelinek ---
(In reply to Alexander Monakov from comment #25)
> (In reply to Jakub Jelinek from comment #22)
> > A function call must be assumed to clobber any call used registers of
> > course.
> > But calls already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #25 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #22)
> A function call must be assumed to clobber any call used registers of course.
> But calls already do have vops (well, const/pure don't, and I don't think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #24 from Jakub Jelinek ---
FRE doesn't, as that breaks the #c9 testcase.
a = 1;
__asm__("add %1, %0" : "=r" o_12 : "r" a, "0" 0);
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
i_13 = 1;
a = 1;
__asm__("add %1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #23 from rguenther at suse dot de ---
On February 8, 2019 6:25:09 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
>
>--- Comment #22 from Jakub Jelinek ---
>(In reply to Alexander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #22 from Jakub Jelinek ---
(In reply to Alexander Monakov from comment #21)
> (In reply to Jakub Jelinek from comment #18)
> > We could cache a bool in struct function whether the function has any local
> > hard register vars and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #21 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #18)
> We could cache a bool in struct function whether the function has any local
> hard register vars and just propagate that info during inlining etc. and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #20 from Segher Boessenkool ---
(In reply to Richard Biener from comment #19)
> Not sure if it
> is generally advised/done to use scratch registers by simply clobbering
> them.
It is often done. Advised... I cannot think of a good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #19 from Richard Biener ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Richard Biener from comment #16)
> > /* Clobber all memory and addressable symbols for asm ("" : : : "memory");
> > */
> > if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #18 from Jakub Jelinek ---
(In reply to Richard Biener from comment #16)
> /* Clobber all memory and addressable symbols for asm ("" : : : "memory");
> */
> if (gimple_asm_clobbers_memory_p (stmt))
> add_virtual_operand (fn,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #17 from Alexander Monakov ---
Well, the asm with the xor was just to make the testcase more-obviously-broken,
it's still broken when %eax is clobbered in a more subtle way, like via a
libcall for integer division like in earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Richard Biener changed:
What|Removed |Added
Target Milestone|7.4 |7.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #15 from Alexander Monakov ---
Typo: PR 42491 should have said PR 43491.
Hopefully more obviously-broken testcase with an inline function:
static inline void
ff(int *o)
{
register int a asm("eax");
a = 1;
asm("add %1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #14 from Alexander Monakov ---
With -fno-tree-fre it's still broken.
How long will GCC play this sort of whack-a-mole with ad-hoc restrictions to
gimple optimizations (PR 29877, PR 42491, PR 61572)?
And this:
> for fixed registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #12 from Segher Boessenkool ---
The lifetime of "a" ends where the for block ends. It is also wholly
irrelevant here.
If LLVM implement other semantics than GCC here, report that bug to LLVM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Segher Boessenkool changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #9 from Alexander Monakov ---
Actually, no long division needed, broken with a plain move as well:
__attribute__((weak))
int f(void)
{
int o=0, i;
for (i=0; i<3; i++) {
register int a asm("eax");
a = 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #8 from Alexander Monakov ---
Executable testcase suitable for bisecting, aborts with -O2 -m32
__attribute__((weak))
int f(long long x[])
{
int o=0, i;
for (i=0; i<3; i++) {
register int a asm("eax");
a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #6 from Andrew Pinski ---
The old documentation had the following:
Stores into local register variables may be deleted when they appear to be dead
according to dataflow analysis. References to local register variables may be
deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #4 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #3)
> Reopening - please read the testcase in detail. Neither the 'a' nor the 'd'
> input are clobbered in the original code, which uses a temporary ('t') as
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #1 from Andrew Pinski ---
I dont think this is a bug. The warning in the manual talks about the call
case even.
37 matches
Mail list logo
