[Bug inline-asm/57950] New: wrong line numbers in error messages for inline assembler statements

[Bug inline-asm/57950] New: wrong line numbers in error messages for inline assembler statements

[f.heckenbach@fh-soft.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

            Bug ID: 57950
           Summary: wrong line numbers in error messages for inline
                    assembler statements
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
          Assignee: unassigned at gcc dot gnu.org
          Reporter: f.heckenbach@fh-soft.de

This was reported as Debian bug #588087 several years ago ...

For error messages concerning inline assembler statements, gcc
counts embedded "\n" characters towards the line number, instead of
actual newlines in the source file, so the error messages refer to
the wrong lines.

Compiling the test program below with "gcc asm-line-number.c" gives
this output:

asm-line-number.c: Assembler messages:
asm-line-number.c:3: Error: no such instruction: `foo'
asm-line-number.c:4: Error: no such instruction: `foo'
asm-line-number.c:8: Error: no such instruction: `foo'

In f1(), both asm errors are in the same source line (3), but gcc
counts them as different because of the "\n" between them.

In f2(), the line number refers to the line (8) which contains
"__asm__" instead of the line (10) with the actual asm code.

static void f1 ()
{
  __asm__ ("foo\nfoo");
}

static void f2 ()
{
  __asm__
    (
      "foo"
    );
}

[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It is not GCC which is reporting this error message but rather gas (binutils)
though GCC is reporting to binutils the line info for the start of the
inline-asm.

[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
GCC uses the line number of the start of the asm statement, so line 8 is
correct.

[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #2)
> GCC uses the line number of the start of the asm statement, so line 8 is
> correct.

"Correct" as "expected" but not as "desired".

This is what Clang prints by comparison:

asm-line-number.c:3:12: error: invalid instruction mnemonic 'foo'
  __asm__ ("foo\nfoo");
           ^
<inline asm>:1:2: note: instantiated into assembly here
        foo
        ^~~
asm-line-number.c:3:18: error: invalid instruction mnemonic 'foo'
  __asm__ ("foo\nfoo");
                 ^
<inline asm>:2:1: note: instantiated into assembly here
foo
^~~
asm-line-number.c:10:7: error: invalid instruction mnemonic 'foo'
      "foo"
      ^
<inline asm>:1:2: note: instantiated into assembly here
        foo
        ^~~
3 errors generated.

It seems difficult to get there without an integrated assembler, but GCC could
at least provide better locations to GAS (and GAS understand and print column
numbers), so we could get:

asm-line-number.c: Assembler messages:
asm-line-number.c:3:12: Error: no such instruction: `foo'
asm-line-number.c:3:18: Error: no such instruction: `foo'
asm-line-number.c:10:7: Error: no such instruction: `foo'

Any editor worth its salt would jump to the correct line and column in the
sources.
>From gcc-bugs-return-426489-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 22 11:44:12 2013
Return-Path: <gcc-bugs-return-426489-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29899 invoked by alias); 22 Jul 2013 11:44:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26889 invoked by uid 48); 22 Jul 2013 11:42:10 -0000
From: "f.heckenbach@fh-soft.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
Date: Mon, 22 Jul 2013 11:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: inline-asm
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: f.heckenbach@fh-soft.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57950-4-QAk4BTHyFv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57950-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57950-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00996.txt.bz2
Content-length: 1788

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

--- Comment #4 from Frank Heckenbach <f.heckenbach@fh-soft.de> ---
(In reply to Manuel López-Ibáñez from comment #3)
> (In reply to Andreas Schwab from comment #2)
> > GCC uses the line number of the start of the asm statement, so line 8 is
> > correct.
> 
> "Correct" as "expected" but not as "desired".

And it would only explain the latter messages, not the former ones
reported as lines 3 and 4.

> This is what Clang prints by comparison:
> 
> asm-line-number.c:3:12: error: invalid instruction mnemonic 'foo'
>   __asm__ ("foo\nfoo");
>            ^
> <inline asm>:1:2: note: instantiated into assembly here
>         foo
>         ^~~
> asm-line-number.c:3:18: error: invalid instruction mnemonic 'foo'
>   __asm__ ("foo\nfoo");
>                  ^
> <inline asm>:2:1: note: instantiated into assembly here
> foo
> ^~~
> asm-line-number.c:10:7: error: invalid instruction mnemonic 'foo'
>       "foo"
>       ^
> <inline asm>:1:2: note: instantiated into assembly here
>         foo
>         ^~~
> 3 errors generated.
> 
> It seems difficult to get there without an integrated assembler, but GCC
> could at least provide better locations to GAS (and GAS understand and print
> column numbers), so we could get:
> 
> asm-line-number.c: Assembler messages:
> asm-line-number.c:3:12: Error: no such instruction: `foo'
> asm-line-number.c:3:18: Error: no such instruction: `foo'
> asm-line-number.c:10:7: Error: no such instruction: `foo'
> 
> Any editor worth its salt would jump to the correct line and column in the
> sources.

The clang output is indeed very nice, though to me, the wrong line
numbers (at least in the presence of "\n") are the more serious
problem than the lack of column numbers.
>From gcc-bugs-return-426490-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 22 12:07:48 2013
Return-Path: <gcc-bugs-return-426490-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30374 invoked by alias); 22 Jul 2013 12:07:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27993 invoked by uid 48); 22 Jul 2013 12:05:46 -0000
From: "acrux at linuxmail dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/57591] gcc-4.8 libbacktrace btest failure on Linux ppc64
Date: Mon, 22 Jul 2013 12:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: acrux at linuxmail dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57591-4-DsCkRFUI2y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57591-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57591-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00997.txt.bz2
Content-length: 147

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW591

--- Comment #4 from acrux <acrux at linuxmail dot org> ---
same failure with  gcc-4.8-20130718

[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
The error messages are all generated by the assembler which knows nothing about
the source file.

[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #5)
> The error messages are all generated by the assembler which knows nothing
> about the source file.

It knows the locations passed by GCC. (And it could know the column also, if
gas supported that). GCC seem to be passing wrong line numbers.
>From gcc-bugs-return-426496-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 22 13:28:58 2013
Return-Path: <gcc-bugs-return-426496-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26331 invoked by alias); 22 Jul 2013 13:28:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23956 invoked by uid 48); 22 Jul 2013 13:26:56 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
Date: Mon, 22 Jul 2013 13:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: inline-asm
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57950-4-qxvM0I6DEv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57950-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57950-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg01003.txt.bz2
Content-length: 168

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW950

--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> ---
There is no way to know how the newline was written.

[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #7)
> There is no way to know how the newline was written.

Sorry I don't get this. Could you elaborate?

There are some technical limitations of GCC:

* string constants don't have their own location:
* asm expressions only have one location (starting at the "asm" keyword)
* GCC currently doesn't look at all into the string constant given to an asm
expression.

First, it is not clear that the location given to asm expressions needs to be
the location of the asm keyword. It could be the location of the string and it
would be already an improvement.

Second, when printing the assembler, GCC can check for newlines and simply
print the line directive after each newline. I see one potential problem:

 static void f1 ()
{
  __asm__ ("foo\n"
           "foo");
}

This works OK now by pure chance but it will be broken by the above trick. To
reliably fix this, GCC must learn to track locations of multi-line strings.
Interestingly, the same problem we face when improving the diagnostics for
-Wformat: PR52952
>From gcc-bugs-return-426533-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 22 19:36:29 2013
Return-Path: <gcc-bugs-return-426533-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6258 invoked by alias); 22 Jul 2013 19:36:29 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 878 invoked by uid 48); 22 Jul 2013 19:34:27 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements
Date: Mon, 22 Jul 2013 19:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: inline-asm
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57950-4-N0GWO1sONB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57950-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57950-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg01040.txt.bz2
Content-length: 416

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW950

--- Comment #9 from Andreas Schwab <schwab@linux-m68k.org> ---
The assembler only sees literal newlines, it does not know how they were
written in the source.

The compiler cannot put line directives in the middle of an assembler string by
itself because it cannot know how the assembler will interpret the text around
the newline.  This will surely break things.

[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #9)
> The assembler only sees literal newlines, it does not know how they were
> written in the source.

Is there other way to generate literal newlines apart from printing a literal
newline? And why it matters how they were written in the source code? The point
is that GCC should see that it is a literal newline and hint GAS that it was
actually in the same line (or not) in the original source code. GAS does not
need to know anything.

> The compiler cannot put line directives in the middle of an assembler string
> by itself because it cannot know how the assembler will interpret the text
> around the newline.  This will surely break things.

If there are restrictions on the lines where the location directives can appear
in an assembler file, then it is a problem, yes. I wasn't aware of such
restrictions, I was assuming that they were basically like preprocessor
directives.

Oh, well, another reason why an integrated assembler is such a good idea...
>From gcc-bugs-return-426536-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 22 20:46:38 2013
Return-Path: <gcc-bugs-return-426536-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 922 invoked by alias); 22 Jul 2013 20:46:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29596 invoked by uid 48); 22 Jul 2013 20:44:36 -0000
From: "wschmidt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57949] [powerpc64] Structure parameter alignment issue with vector extensions
Date: Mon, 22 Jul 2013 20:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ABI, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wschmidt at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57949-4-8PiOT78tWi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57949-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57949-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg01043.txt.bz2
Content-length: 1166

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW949

--- Comment #3 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
The problem is target-specific, in config/rs6000/rs6000.c:
rs6000_function_arg_boundary().

static unsigned int
rs6000_function_arg_boundary (enum machine_mode mode, const_tree type)
{
  if (DEFAULT_ABI == ABI_V4
      && (GET_MODE_SIZE (mode) == 8
      || (TARGET_HARD_FLOAT
          && TARGET_FPRS
          && (mode == TFmode || mode == TDmode))))
    return 64;
  else if (SPE_VECTOR_MODE (mode)
       || (type && TREE_CODE (type) == VECTOR_TYPE
           && int_size_in_bytes (type) >= 8
           && int_size_in_bytes (type) < 16))
    return 64;
  else if (ALTIVEC_OR_VSX_VECTOR_MODE (mode)
       || (type && TREE_CODE (type) == VECTOR_TYPE
           && int_size_in_bytes (type) >= 16))
    return 128;
  else if (TARGET_MACHO
        && rs6000_darwin64_abi
        && mode == BLKmode
       && type && TYPE_ALIGN (type) > 64)
    return 128;
  else
    return PARM_BOUNDARY;
}

Note that the TARGET_MACHO + Darwin ABI case does what the 64-bit PowerPC ELF
ABI implies should be done.  It's not clear to me why that ABI is excluded.

[Bug inline-asm/57950] wrong line numbers in error messages for inline assembler statements

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

--- Comment #11 from Andreas Schwab <schwab@linux-m68k.org> ---
See the example in the original description.

[Bug c/57950] wrong line numbers in error messages for inline assembler statements

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|inline-asm                  |c
           Severity|normal                      |enhancement