Lint-style comments, more generally

[Eric Gallager]

Seeing how long the thread on gcc-patches on what comments
-Wimplicit-fallthrough should recognize has gotten, I thought it might
be a good idea to start a discussion on lint-style comments more
generally. Instead of just limiting the use of lint-style comments to
-Wimplicit-fallthrough, why not split the recognition of it off into a
separate switch (-flint-style-comments or -Wlint-style-comments) that
can be taken advantage of by other warnings? Here are some examples
I've seen in actual code:
/*NOTREACHED*/ to tell the compiler that code is unreachable; could be
useful if the -Wunreachable-code warning were to be revived. I
suggested making this equivalent to __builtin_unreachable() on a bug
on bugzilla, but apparently that also affects codegen, so instead of
making the two exactly equivalent, how about if the comment just
silences the warning and leaves the codegen the same?
/*ARGSUSED*/ which is pretty similar to __attribute__((unused)) or
#pragma unused; could also be used to silence -Wunused-parameter
/*VARARGS*/ for functions with a variable number of arguments; I'm not
aware of any GCC warnings that this one would currently silence.

Further links I found by Googling:
http://csweb.cs.wfu.edu/~torgerse/Kokua/More_SGI/007-0701-150/sgi_html/apb.html
(lists some other ones I hadn't seen)
http://www.splint.org/manual/manual.html#annotations (scroll down to
the "Traditional Lint Comments" section)
https://docs.freebsd.org/info/cpp/cpp.info.Invocation.html (The
FreeBSD cpp seems to have a '-lint' flag; apparently their GCC
supports a #pragma lint)
http://www.fnal.gov/docs/products/gcc/v2_95_2/cpp.info,.Invocation.html
(seems to be the same as the previous, but with some further
commentary about option naming)

Anyways, what do people think?

Calling convention for "Routines for floating point emulation"

[Yichao Yu]

Hi,

I'd like to ask what should be the calling convention/ABI for these
routines on platforms with hardware floating point support (but
somehow still want to generate a libcall for whatever reasons).

In particular, it seems that on all the platforms with a
arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h,
debian armhf, fedora armv7hl) the __powidf2 function (and possibly
many others) are compiled with the AAPCS VFP calling convention, which
is also how it is used by gcc. However, LLVM dev (CC'd) claims that
these routines are meant to be always using soft floating point
calling convention even on platforms using hard floating point ABI.

A breif google search doesn't show document supporting either so what
exactly should be used? Is it documented anywhere or what's the
default rule to decide the calling conventions for these functions? In
either case I think it's be nice if the document is a little more
explicit about this.

Yichao Yu

Re: Calling convention for "Routines for floating point emulation"

[Yichao Yu]

On Wed, Sep 28, 2016 at 5:23 PM, Yichao Yu  wrote:
> Hi,
>
> I'd like to ask what should be the calling convention/ABI for these
> routines on platforms with hardware floating point support (but
> somehow still want to generate a libcall for whatever reasons).
>
> In particular, it seems that on all the platforms with a
> arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h,
> debian armhf, fedora armv7hl) the __powidf2 function (and possibly
> many others) are compiled with the AAPCS VFP calling convention, which
> is also how it is used by gcc. However, LLVM dev (CC'd) claims that
> these routines are meant to be always using soft floating point
> calling convention even on platforms using hard floating point ABI.
>
> A breif google search doesn't show document supporting either so what
> exactly should be used? Is it documented anywhere or what's the
> default rule to decide the calling conventions for these functions? In
> either case I think it's be nice if the document is a little more
> explicit about this.

And see https://llvm.org/bugs/show_bug.cgi?id=30543 for some context.

>
> Yichao Yu

Re: Calling convention for "Routines for floating point emulation"

[Joseph Myers]

On Wed, 28 Sep 2016, Yichao Yu wrote:

> In particular, it seems that on all the platforms with a
> arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h,
> debian armhf, fedora armv7hl) the __powidf2 function (and possibly
> many others) are compiled with the AAPCS VFP calling convention, which
> is also how it is used by gcc. However, LLVM dev (CC'd) claims that
> these routines are meant to be always using soft floating point
> calling convention even on platforms using hard floating point ABI.

The RTABI functions should use the base AAPCS calling conventions.  That 
was something I dealt with when working on the implementation of the VFP 
ABI variant .

Except where an external ABI defines things like that, the normal 
expectation for libgcc functions is that they have the same ABI as for an 
ordinary C function with the same prototype.  That is, since libgcc.texi 
gives a prototype for __powidf2 without saying anything special about its 
ABI, and since it is not a function defined in RTABI, it can be taken to 
use the VFP ABI when compiling for that ABI.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Calling convention for "Routines for floating point emulation"

[Yichao Yu]

On Wed, Sep 28, 2016 at 7:39 PM, Joseph Myers  wrote:
> On Wed, 28 Sep 2016, Yichao Yu wrote:
>
>> In particular, it seems that on all the platforms with a
>> arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h,
>> debian armhf, fedora armv7hl) the __powidf2 function (and possibly
>> many others) are compiled with the AAPCS VFP calling convention, which
>> is also how it is used by gcc. However, LLVM dev (CC'd) claims that
>> these routines are meant to be always using soft floating point
>> calling convention even on platforms using hard floating point ABI.
>
> The RTABI functions should use the base AAPCS calling conventions.  That
> was something I dealt with when working on the implementation of the VFP
> ABI variant .
>
> Except where an external ABI defines things like that, the normal
> expectation for libgcc functions is that they have the same ABI as for an
> ordinary C function with the same prototype.  That is, since libgcc.texi
> gives a prototype for __powidf2 without saying anything special about its
> ABI, and since it is not a function defined in RTABI, it can be taken to

I guess other ppl on the list probably know this but what's the list
of function in RTABI?

Thanks.

> use the VFP ABI when compiling for that ABI.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: Calling convention for "Routines for floating point emulation"

[Yichao Yu]

On Wed, Sep 28, 2016 at 7:45 PM, Yichao Yu  wrote:
> On Wed, Sep 28, 2016 at 7:39 PM, Joseph Myers  wrote:
>> On Wed, 28 Sep 2016, Yichao Yu wrote:
>>
>>> In particular, it seems that on all the platforms with a
>>> arm*-*-gnueabihf triple I've checked (alarm armv7h, alarm armv6h,
>>> debian armhf, fedora armv7hl) the __powidf2 function (and possibly
>>> many others) are compiled with the AAPCS VFP calling convention, which
>>> is also how it is used by gcc. However, LLVM dev (CC'd) claims that
>>> these routines are meant to be always using soft floating point
>>> calling convention even on platforms using hard floating point ABI.
>>
>> The RTABI functions should use the base AAPCS calling conventions.  That
>> was something I dealt with when working on the implementation of the VFP
>> ABI variant .
>>
>> Except where an external ABI defines things like that, the normal
>> expectation for libgcc functions is that they have the same ABI as for an
>> ordinary C function with the same prototype.  That is, since libgcc.texi
>> gives a prototype for __powidf2 without saying anything special about its
>> ABI, and since it is not a function defined in RTABI, it can be taken to
>
> I guess other ppl on the list probably know this but what's the list
> of function in RTABI?

Is it 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
?

>
> Thanks.
>
>> use the VFP ABI when compiling for that ABI.
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com

Re: Calling convention for "Routines for floating point emulation"

[Joseph Myers]

On Wed, 28 Sep 2016, Yichao Yu wrote:

> >> Except where an external ABI defines things like that, the normal
> >> expectation for libgcc functions is that they have the same ABI as for an
> >> ordinary C function with the same prototype.  That is, since libgcc.texi
> >> gives a prototype for __powidf2 without saying anything special about its
> >> ABI, and since it is not a function defined in RTABI, it can be taken to
> >
> > I guess other ppl on the list probably know this but what's the list
> > of function in RTABI?
> 
> Is it 
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> ?

Yes, that's the right document.  Specifically, section 4.1.2, which 
defines the floating-point functions that always use the base ABI.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Calling convention for "Routines for floating point emulation"

[Yichao Yu]

On Wed, Sep 28, 2016 at 8:07 PM, Joseph Myers  wrote:
> On Wed, 28 Sep 2016, Yichao Yu wrote:
>
>> >> Except where an external ABI defines things like that, the normal
>> >> expectation for libgcc functions is that they have the same ABI as for an
>> >> ordinary C function with the same prototype.  That is, since libgcc.texi
>> >> gives a prototype for __powidf2 without saying anything special about its
>> >> ABI, and since it is not a function defined in RTABI, it can be taken to
>> >
>> > I guess other ppl on the list probably know this but what's the list
>> > of function in RTABI?
>>
>> Is it 
>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
>> ?
>
> Yes, that's the right document.  Specifically, section 4.1.2, which
> defines the floating-point functions that always use the base ABI.

I've just started reading 4.1.1 =)

Got it. Thanks very much for the fast answer!

Yichao Yu

>
> --
> Joseph S. Myers
> jos...@codesourcery.com