https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
--- Comment #6 from Alex Bradbury ---
(In reply to Jim Wilson from comment #4)
> I think the intent of the second rule is that float values are passed in the
> same regs as an integer value, and that it wasn't the intent that the
> promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
--- Comment #2 from Alex Bradbury ---
Better example demonstrating the problem exists for returns too:
$ cat foo.c
struct float_struct { float v; };
struct char_struct { char v; };
struct float_struct callee(float, char);
float caller(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87690
--- Comment #1 from Alex Bradbury ---
It's clear from the example but I made a typo in the explanation due to a last
minute change in my example. char is unsigned, so the value in char_struct is
zero-extended as we expect.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
The RISC-V PSABI documentation specifies the following for the base/integer
calling convention:
1) When passed in registers, scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391
--- Comment #4 from Alex Bradbury ---
(In reply to Jim Wilson from comment #2)
> One can specify an architecture with FP registers, and an ABI that does not
> use the FP registers. By the same token, it is reasonable to expect that
> one should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87391
--- Comment #1 from Alex Bradbury ---
Apologies I pasted the wrong command output in the original report. The
invocation demonstrating the bug is below:
$ ./riscv32-unknown-elf-gcc -march=rv32i -mabi=ilp32e foo.c -S -o -
.file "foo.c"
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
The current ABI docs state that the RV32E calling convention (-mabi=ilp32e) may
only be used with the RV32E ISA (-march=rv32e). GCC does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86387
Alex Bradbury changed:
What|Removed |Added
Summary|[RISCV][ABI] GCC fails to |[RISCV][ABI] GCC fails to
: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
The psABI is documented here:
https://github.com/riscv/riscv-elf-psabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
--- Comment #3 from Alex Bradbury ---
(In reply to Andrew Waterman from comment #2)
> I realize the documentation doesn't concur with me, but as long as gcc
> and libgcc agree on the lock-freeness of the routines, I don't see the
> harm. (wrt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
Alex Bradbury changed:
What|Removed |Added
CC||asb at lowrisc dot org
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
When targeting -march=rv32i or -march=rv64i (i.e. a RISC-V target without the A
extension), GCC will produce a fence-based mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #5 from Alex Bradbury ---
(In reply to palmer from comment #4)
> """
> @item -mabi=@var{ABI-string}
> @opindex mabi
> Specify integer and floating-point calling convention. @var{ABI-string}
> contains two parts: the size of integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #2 from Alex Bradbury ---
(In reply to palmer from comment #1)
> Thanks Alex -- you're correct that this is a documentation/code mismatch. I
> just talked to Andrew and we think it's best to change the documentation.
> How does
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
The documentation for the -mabi command-line option for RISC-V states:
"""
@item -mabi=@var{ABI-string}
@opindex mabi
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
The RISC-V 2.2 user-level ISA specification renamed fmv.s.x and fmv.x.s to
fmv.w.x and fmv.x.w respectively. gas doesn't recognise these mnemonics.
Additionally, objdump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82106
--- Comment #2 from Alex Bradbury ---
Same problem with `-mstrict-align`, which as you say makes this worse.
I'm actually not sure if this is an ABI-visible issue. The vararg save area and
it's location is basically required by the ABI due to
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asb at lowrisc dot org
Target Milestone: ---
Created attachment 42127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42127=edit
Simple program to reprod
18 matches
Mail list logo
