[Bug c/126552] const-qualified local register variable used as an asm operand is silently discarded
bernie at codewiz dot org via Gcc-bugs <[email protected]> Mon, 03 Aug 2026 10:42:34 +0000
| Newsgroups | gmane.comp.gcc.bugs |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D126552
--- Comment #8 from Bernie Innocenti <bernie at codewiz dot org> ---
To clarify the constraints we're working with, the repro code comes from the
expansion of type-generic macros like these:
#define LP7NR(offs, name, t1, v1, r1, t2, v2, r2, t3, v3, r3, t4, v4, r4, =
t5,
v5, r5, t6, v6, r6, t7, v7, r7, bt, bn) \
({ \
t1 _##name##_v1 =3D (v1); \
t2 _##name##_v2 =3D (v2); \
t3 _##name##_v3 =3D (v3); \
t4 _##name##_v4 =3D (v4); \
t5 _##name##_v5 =3D (v5); \
t6 _##name##_v6 =3D (v6); \
t7 _##name##_v7 =3D (v7); \
{ \
register int _d0 __asm("d0"); \
register int _d1 __asm("d1"); \
register int _a0 __asm("a0"); \
register int _a1 __asm("a1"); \
register t3 _n3 __asm(#r3) =3D _##name##_v3; \
register t4 _n4 __asm(#r4) =3D _##name##_v4; \
register t5 _n5 __asm(#r5) =3D _##name##_v5; \
register t6 _n6 __asm(#r6) =3D _##name##_v6; \
register t7 _n7 __asm(#r7) =3D _##name##_v7; \
register t1 _n1 __asm(#r1) =3D _##name##_v1; \
register t2 _n2 __asm(#r2) =3D _##name##_v2; \
register void *const _##name##_bn __asm("a6") =3D (bn); \
__asm volatile ("jsr a6@(-"#offs":W)" \
: "=3Dr" (_d0), "=3Dr" (_d1), "=3Dr" (_a0), "=3Dr" (_a1) \
: "r" (_##name##_bn), "rf"(_n1), "rf"(_n2), "rf"(_n3), "rf"(_n4),
"rf"(_n5), "rf"(_n6), "rf"(_n7) \
: "fp0", "fp1", "cc", "memory"); \
} \
})
The full set is here:
https://github.com/adtools/fd2pragma/blob/master/Include/inline/macros.h
Following Drea's and Jakub's recommendation, I experimented with using hard
register constraints on __GNUC__ >=3D 16:
=20
https://github.com/codewiz/sfdc/blob/inline-macros-amigaports/include/inlin=
e/macros.h
This works only for GCC 16 (*), and only with -mlra (and there might be good
reasons if it's not already the default on m68k).
Plus, we still need a solution for GCC 13 and GCC 15, which are still activ=
ely
used by Amiga projects.=