This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Deprecating basic asm in a function - What now?
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Andrew Haley <aph at redhat dot com>, Jeff Law <law at redhat dot com>, Michael Matz <matz at suse dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 22 Jun 2016 12:28:14 -0700
- Subject: Re: Deprecating basic asm in a function - What now?
- Authentication-results: sourceware.org; auth=none
- References: <dc3ca16c-3521-757f-fcf0-50061f510f75 at LimeGreenSocks dot com> <alpine dot LSU dot 2 dot 20 dot 1606201931460 dot 13156 at wotan dot suse dot de> <57682A85 dot 4060803 at redhat dot com> <alpine dot LSU dot 2 dot 20 dot 1606201941340 dot 13156 at wotan dot suse dot de> <57690227 dot 2050501 at redhat dot com> <alpine dot LSU dot 2 dot 20 dot 1606211401150 dot 13156 at wotan dot suse dot de> <57696C45 dot 5000309 at redhat dot com> <c23d921a-5546-ea81-0367-cfc1a18de876 at redhat dot com> <576970ED dot 30507 at redhat dot com> <f666086e-8c64-c6c8-b1a2-eaa18572a685 at redhat dot com> <576AD20F dot 90208 at gmail dot com> <CA+=Sn1miUKQkJ9zSNWBMeH0-JaRdCB80gdzi7NttvBkZ0_+=+A at mail dot gmail dot com> <CAESRpQAyQ_fAguDCKt3jqbySNcChmvfXJzgNTY_rEZuwoXNprA at mail dot gmail dot com>
On Wed, Jun 22, 2016 at 12:26 PM, Manuel LÃpez-IbÃÃez
<lopezibanez@gmail.com> wrote:
> On 22 June 2016 at 19:05, Andrew Pinski <pinskia@gmail.com> wrote:
>> On Wed, Jun 22, 2016 at 10:59 AM, Manuel LÃpez-IbÃÃez
>> <lopezibanez@gmail.com> wrote:
>>> On 22/06/16 10:02, Florian Weimer wrote:
>>>> GCC could parse the assembly instructions and figure out the clobbers.
>>>
>>>
>>> Which is also needed for various things, such as providing better
>>> diagnostics:
>>>
>>> http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/70335
>>
>> Actually GCC outputs markers that modern gas understands and you get
>> much better diagnostic already compared to what was reported above.
>
> We get better diagnostics than in the past, but not as good as
> Clang's. And there are many limitations of the "markers" approach: Not
> only there is no column info, line info is often wrong:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57950
>
> And there remains a lot of work to get GAS to output diagnostics like
> GCC does nowadays (colors, caret, fix-it hints, etc.). And additional
> work to make GAS obey GCC settings (if GCC disables colors, then GAS
> should not output colors). Most of that work will be duplication of
> what GCC already does.
>
> Besides diagnostics, the integrated assembler is faster (as proven by
> David Malcom's experiments) and it provides additional info to GCC
> (the point raised by Florian).
>
>> Note each target in gas has its own way of parsing assembly code which
>> is one of the reason why it is so hard todo the above and also each
>> target has its own wording which can confuse people. I think if you
>
> I didn't say it was easy. Yet, Clang/LLVM did it.
That is because there are less targets on the Clang/LLVM side of things.
>
>> want better diagnostic from assembly code, then working on binutils to
>> unify things including error messages (and subtarget support) would be
>> a much better use of time than integrating binutils into gcc.
>
> Unifying error messages does not seem to be a feature used to
> advertise Clang as a replacement for GCC. It doesn't seem to be what
> users discuss in various forums (including the reddit thread I quoted
> above). It won't help with the issues discussed in this thread.
>
> Cheers,
>
> Manuel.