https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #18 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:be70bb5e4babdf9d3d33e8f4658452038407fa8e
commit r11-7807-gbe70bb5e4babdf9d3d33e8f4658452038407fa8e
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #16 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:02f2dc441b1954736cc61e3f97687cd23d5586c5
commit r11-7768-g02f2dc441b1954736cc61e3f97687cd23d5586c5
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #15 from Vladimir Makarov ---
I've submitted the patch defining a new memory constraint:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566976.html
The patch itself:
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #14 from Segher Boessenkool ---
Well, V=m-o (not the same thing, these are sets) -- but, it is clear that "o"
should be a subset of "m":
(define_memory_constraint "TARGET_MEM_CONSTRAINT"
"Matches any valid memory."
(define_memory_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #13 from rsandifo at gcc dot gnu.org
---
Sorry for not responding until now, but would it work to make
the "o" constraint check memory_address_addr_space_p too,
like the other memory constraints do? IMO it's wrong for "o"
to accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #12 from Vladimir Makarov ---
(In reply to Vladimir Makarov from comment #11)
> Introducing a new memory constraint can take some time.
>
> I guess we could switch off the offending code meanwhile because it is
> compiler crash vs un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #11 from Vladimir Makarov ---
Introducing a new memory constraint can take some time.
I guess we could switch off the offending code meanwhile because it is compiler
crash vs unoptimal generated code choice.
I'll investigate how swi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #10 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #7)
> The addition of those extra args makes clear that the function is no
> longer just testing if it is a valid address. It should be renamed.
>
I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #9 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #8)
> Rather than a target hook, isn't it a property of a particular constraint?
> This constraint implies "m", this one doesn't?
> Make the implies "m" behavior the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #8 from Jakub Jelinek ---
Rather than a target hook, isn't it a property of a particular constraint?
This constraint implies "m", this one doesn't?
Make the implies "m" behavior the default one and add some syntax in the *.md
files to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #7 from Segher Boessenkool ---
>From the offending patch:
-/* Return true if the eliminated form of AD is a legitimate target address.
*/
+/* Return true if the eliminated form of AD is a legitimate target address.
+ If OP is a ME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #6 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #5)
> Thanks Vladimir. It is indeed a problem in LRA (or triggered by it).
> We have
> 8: {[r121:DI+low(unspec[`*.LANCHOR0',%2:DI]
> 47+0x92a4)]=asm_operan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #5 from Segher Boessenkool ---
Thanks Vladimir. It is indeed a problem in LRA (or triggered by it).
We have
8: {[r121:DI+low(unspec[`*.LANCHOR0',%2:DI]
47+0x92a4)]=asm_operands;clobber
so this is an offset that is too big for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #4 from Vladimir Makarov ---
I've reproduced it too and started to work on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #3 from Jakub Jelinek ---
C test (for -O2 too):
char e[37540];
struct A { int c; } d;
void
bar (int n)
{
__asm__("" : : "r" (e));
}
void
foo (void)
{
__asm__("stw %1, %0" : "=o" (d.c) : "r" (0));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
Jakub Jelinek changed:
What|Removed |Added
Summary|[11 Regression] internal|[11 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Summary|internal compil
19 matches
Mail list logo
