Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: christopher.leonard at abaco dot com
Target Milestone: ---
When giving a C expression as input to an extended asm statement the wrong
value is loaded if the type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #2 from Christopher Leonard
---
Surely then in the example if r9 is loaded with high and r10 with low then %0
should be r10, not r9?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #3 from Christopher Leonard
---
I understand it has to split it, the problem is that %0 defaults to the
register holding the most-significant part of the integer. Is this really the
desired behavior?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #5 from Christopher Leonard
---
Is the order at least consistant with x86-32? i.e. if you give a 64-bit input
operand to inline assembly the order is hi:lo? I'm worried this is a bizarre
convention imposed on high endian architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #9 from Christopher Leonard
---
(In reply to Andrew Pinski from comment #6)
> Yes the order is always hi:lo (reg:reg+1) on all targets I know of
This is definitely not the natural choice (on any platform: I agree, endianness
is irre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #10 from Christopher Leonard
---
Getting contradictory statements now:
>reg:reg+1 maps to lo:hi on x86.
>On x86, we don't allow register pairs in asm at all.
Not allowing, or printing a warning, is much better behavior than what I h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
--- Comment #13 from Christopher Leonard
---
(In reply to Segher Boessenkool from comment #12)
> the oldest GCC still supported is GCC 7.
Apologies if it was not clear, but I am just reporting the issue for posterity
and it was not easy for me
