impossible constraint violation for value cast to unsigned char

Bug #1758992 reported by Peter A. Bigot on 2018-03-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
High
Thomas Preud'homme

Bug Description

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]

Changed in gcc-arm-embedded:
status: New → In Progress

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.

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?

Changed in gcc-arm-embedded:
assignee: nobody → Thomas Preud'homme (thomas-preudhomme)
importance: Undecided → High
Peter A. Bigot (pab-u) wrote :

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.

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) wrote :

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.)

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

Best regards.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.