public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/114399] New: [14] RISC-V rv32i miscompile
@ 2024-03-20 0:27 patrick at rivosinc dot com
2024-03-20 0:34 ` [Bug target/114399] " pinskia at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: patrick at rivosinc dot com @ 2024-03-20 0:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
Bug ID: 114399
Summary: [14] RISC-V rv32i miscompile
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Testcase:
int a;
struct b {
long long c;
};
struct d {
short e;
long long f;
};
union {
struct b g;
struct d h;
} i;
int main() {
i.h.f++;
a = i.g.c >> 1;
__builtin_printf("%X\n", a);
}
Commands:
> gcc red.c -o red.out -m32 -fno-strict-aliasing -static
> ./red.out
80000000
> riscv64-unknown-linux-gnu-gcc -mabi=ilp32 -march=rv32i red.c -o red.out -fno-strict-aliasing -static
> /scratch/tc-testing/tc-mar-19/build-rv32-64-gcv/bin/qemu-riscv32 red.out
0
Discovered/tested with r14-9544-gc7a774edbf8 (not bisected)
Found via fuzzer.
I don't think this has any undefined behavior but the combo of union/struct has
me a bit wary.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/114399] [14] RISC-V rv32i miscompile
2024-03-20 0:27 [Bug target/114399] New: [14] RISC-V rv32i miscompile patrick at rivosinc dot com
@ 2024-03-20 0:34 ` pinskia at gcc dot gnu.org
2024-03-20 0:39 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-20 0:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
32bit i686 long long has an alignment of 4 while most other targets have an
alignment of 8.
Which you could see via sizeof.
```
int tt = sizeof(struct b);
int tt1 = sizeof(struct d);
```
i?86:
```
tt:
.long 8
...
tt1:
.long 12
```
RISCV32:
```
tt:
.word 8
...
tt1:
.word 16
```
Basically in the i?86 case, i.h.f++ will modify byte 4 of the union while on
most other targets, it will modify byte 8.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/114399] [14] RISC-V rv32i miscompile
2024-03-20 0:27 [Bug target/114399] New: [14] RISC-V rv32i miscompile patrick at rivosinc dot com
2024-03-20 0:34 ` [Bug target/114399] " pinskia at gcc dot gnu.org
@ 2024-03-20 0:39 ` pinskia at gcc dot gnu.org
2024-03-20 0:41 ` patrick at rivosinc dot com
2024-03-20 0:45 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-20 0:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
That is doing:
long long f __attribute__((packed,aligned(4)));
Will produce the same result between the 2 targets.
Likewise:
long long f __attribute__((packed,aligned(8)));
With -Wpadded you can see the padding between e and f is added.
<source>:7:13: warning: padding struct to align 'd::f' [-Wpadded]
Just the padding is different between the 2 targets due to the alignment of
long long being 4 bytes (it is an old ABI where 4 bytes was the only alignment
at the time when long long was added, double have a similar thing too).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/114399] [14] RISC-V rv32i miscompile
2024-03-20 0:27 [Bug target/114399] New: [14] RISC-V rv32i miscompile patrick at rivosinc dot com
2024-03-20 0:34 ` [Bug target/114399] " pinskia at gcc dot gnu.org
2024-03-20 0:39 ` pinskia at gcc dot gnu.org
@ 2024-03-20 0:41 ` patrick at rivosinc dot com
2024-03-20 0:45 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: patrick at rivosinc dot com @ 2024-03-20 0:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
Patrick O'Neill <patrick at rivosinc dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |FIXED
--- Comment #3 from Patrick O'Neill <patrick at rivosinc dot com> ---
Ah thank you - that makes sense.
IIUC -malign-double is the option I'm looking for to set the padding to be the
same between x86/risc-v.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug target/114399] [14] RISC-V rv32i miscompile
2024-03-20 0:27 [Bug target/114399] New: [14] RISC-V rv32i miscompile patrick at rivosinc dot com
` (2 preceding siblings ...)
2024-03-20 0:41 ` patrick at rivosinc dot com
@ 2024-03-20 0:45 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-20 0:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114399
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |INVALID
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-03-20 0:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-20 0:27 [Bug target/114399] New: [14] RISC-V rv32i miscompile patrick at rivosinc dot com
2024-03-20 0:34 ` [Bug target/114399] " pinskia at gcc dot gnu.org
2024-03-20 0:39 ` pinskia at gcc dot gnu.org
2024-03-20 0:41 ` patrick at rivosinc dot com
2024-03-20 0:45 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).