https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61740
Bug ID: 61740
Summary: Fixes for minor problems in asm_fprintf and
output_asm_insn
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at limegreensocks dot com
Created attachment 33087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33087&action=edit
Proposed patch
The attached patch fixes 4 inline asm issues in asm_fprintf and
output_asm_insn. They vary in importance from minor to trivial.
1) Compiling this inline asm statement (correctly) reports "unterminated
assembly dialect alternative":
asm("{" :);
But this one does not:
asm("{stuff" :);
This patch reports all unterminated dialects (for both att & intel) in both
output_asm_insn & asm_fprintf:
asm("{" :);
asm("{nop" :);
asm("{|" :);
asm("{nop|" :);
asm("{nop|nop" :);
asm("{||" :);
asm("{nop||" :);
asm("{nop|nop|" :);
asm("{nop||nop" :);
asm("{nop|nop|nop" :);
2) In r198641, output_asm_insn was modified to add support for escaping the
dialect characters: {|}. This feature was not added to asm_fprintf (which also
supports dialects). This patch updates asm_fprintf to support escaping dialect
characters, so that it truly will "handle alternate assembler dialects here,
just like output_asm_insn."
3) There are two format strings (%@ %r) defined for asm_fprintf in c-format.c
that are only available for arm. Any attempt to use them from other platforms
results in an ICE. Since the entire purpose of these tables is to validate
format strings, these entries should only be defined when building arm.
While I could have simply wrapped the offending table entries in an #ifdef
__arm__, that does not appear to be consistent with the standard used by the
rest of gcc. Following the example of the related macro
(ASM_FPRINTF_EXTENSIONS), I created a macro named ASM_FPRINTF_TABLE that can be
created on a per-platform basis to define platform-specific formats. Like
ASM_FPRINTF_EXTENSIONS, this is (currently) only implemented on arm.
4) asm_fprintf uses a fixed size buffer (buf[10]) that it copies data into, but
it never checks to see if it is overrunning the buffer. While 10 bytes is
almost certainly sufficient for most valid uses, not checking at all seems bad.
There are legal (if unlikely) printf modifiers that require more than 10
bytes. Rather than depend upon people to not violate this restriction, this
patch performs a simple check for overruns.
An 11 byte example: asm_fprintf(asm_out_file, "%-160.140x", 12);
