impossible constraint violation for value cast to unsigned char

[Peter A. Bigot]

The reduced example below produces a diagnostic when a value in the I constraint range is explicitly cast to unsigned char. The diagnostic does not appear if the value is not cast. This is reduced from a case where 0x80 is an enumeration constant.

Work-around is to use "0xFF & value" rather than "(unsigned char)value".

lilith[1173]$ cat x.c
__attribute__((naked))
static void service(void) {
  __asm( "svc %0\n" "bx r14" : : "I" ((unsigned char)0x80) : "r0" );
}

int main() {
  service();
}
lilith[1174]$ arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 x.c
x.c: In function 'service':
x.c:3:3: warning: asm operand 0 probably doesn't match constraints
   __asm( "svc %0\n" "bx r14" : : "I" ((unsigned char)0x80) : "r0" );
   ^~~~~
x.c:3:3: error: impossible constraint in 'asm'

Present in following and several earlier releases on Linux.

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]

[Thomas Preud'homme (thomas-preudhomme)]

I've reported the bug in [1]. I have a patch that works for this testcase which I'm currently testing.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344

Best regards.

[Thomas Preud'homme (thomas-preudhomme)]

Hi Peter,

Upon investigation it turns out that the reverse can happen: a constant that should be refused because it doesn't match its constraint gets accepted and transformed along the way. Is there a chance the Linux kernel is impacted by that issue?

[Peter A. Bigot (pab-u)]

I don't know if the Linux kernel could be affected; my discovery was in a Nordic Cortex-M-based Bluetooth soft device (binary blob with SWI-based API defined in a header). I've patched their headers to work around it.

[Thomas Preud'homme (thomas-preudhomme)]

Oh my bad, I misunderstood the last sentence in your original comment. You meant that you get this bug with our Linux toolchain. Understood. Any chance you could change your app to use an int rather than unsigned char in the meantime?

[Peter A. Bigot (pab-u)]

Yes, I was referring to the platform of the pre-built toolchain, not the kernel.

I patched the vendor headers to use a uint16_t which is how they worked around it in later releases of a different soft device. (Apparently they didn't bother to report the bug.)

[Thomas Preud'homme (thomas-preudhomme)]

Thanks for reporting the bug then. It's being worked on.

Best regards.

[Joey Ye (jinyun-ye)]

Peter, It turns out nobody in community is sure of how to resolve it. Is this problem still blocking you? We may consider close it with won't fix.

[Peter A. Bigot (pab-u)]

I'm fine with closing this here as long as the upstream gcc bug remains open. I worked around this at the time I reported it so it's not blocking me.