built-in function 'exp' declared as non-function

built-in function 'exp' declared as non-function

[phi gcc]

Hi All,

I try to find a way to locally (in a compile unit) disable this
annoying warning.

built-in function 'exp' declared as non-function

exp is a symbol of mine (An array of struct), not a function.

I can't change the Makefile CFLAGS  that are setup tight (-Wall etc....)
I am reluctant to #define exp MyExp has it render symbolic debuging of
it tedious.
I know I am not including <math.h> in anyway in this compile unit
I can't find a #pragma or _Pragma suitable for this.
I can't make my exp[] array  static (easily).

I guess I have exhausted my gcc knowledge. Any ideas/tricks  to let
gcc know that I don't want to use exp() builtin,  that kinda step in
my name space.
Thanx in advance,
Cheers
Phi

Re: built-in function 'exp' declared as non-function

[Segher Boessenkool]

Hi phi,

On Wed, Apr 10, 2019 at 09:46:45AM +0200, phi gcc wrote:
> built-in function 'exp' declared as non-function
> 
> exp is a symbol of mine (An array of struct), not a function.
> 
> I can't change the Makefile CFLAGS  that are setup tight (-Wall etc....)

Preferably you should add --no-builtin-exp.  But you can also add a line

#pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"


Segher

Re: built-in function 'exp' declared as non-function

[Segher Boessenkool]

[ Please keep replies on the list.  Thanks. ]

On Wed, Apr 10, 2019 at 06:04:30PM +0200, phi gcc wrote:
> I can't really change the Makefile so the --no-builtin is not too easy for me.
> 
> The pragma seems not work on my gcc
> 
> TC$ gcc --version
> gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
> 
> TC$ echo "#pragma GCC diagnostic ignored \"-Wbuiltin-declaration-mismatch\"
> int exp;" | cc -c -x c -
> <stdin>:2:5: warning: built-in function 'exp' declared as non-function

Yeah, this is a separately controllable warning since GCC 8 (it couldn't
be disabled before, other than with -w).


Segher

Re: built-in function 'exp' declared as non-function

[Martin Sebor]

On 4/10/19 4:51 PM, Segher Boessenkool wrote:
> [ Please keep replies on the list.  Thanks. ]
> 
> On Wed, Apr 10, 2019 at 06:04:30PM +0200, phi gcc wrote:
>> I can't really change the Makefile so the --no-builtin is not too easy for me.
>>
>> The pragma seems not work on my gcc
>>
>> TC$ gcc --version
>> gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
>>
>> TC$ echo "#pragma GCC diagnostic ignored \"-Wbuiltin-declaration-mismatch\"
>> int exp;" | cc -c -x c -
>> <stdin>:2:5: warning: built-in function 'exp' declared as non-function

Disabling the built-in is far safer than disabling these warnings.
Some optimizations transform calls to library functions made by
the program and recognized as built-ins to those to other functions
that the program never explicitly calls.  When an incompatible symbol
with the same name as one of the other built-in functions is defined
in a program, calls to the other built-in will very likely crash.

It ought to be possible to disable built-ins using an attribute
or #pragma, like #pragma GCC optimize, but it doesn't work.  If
there isn't a way to do it, filing an enhancement request might
help.

Martin

Re: built-in function 'exp' declared as non-function

[Martin Sebor]

[putting gcc-help back]

On 4/10/19 10:23 PM, phi gcc wrote:
> Hi Martin,
> 
> I agry that crossing out all builtin warning when only a few need to
> be isolated is not safe.
> 
> However the compiler have all the informations it needs to decide if
> one is using a symbol in a builtin context or not, in my case I am
> using exp() in a file where <math.h> is not included, so the waring
> should not be emiited, if I decide later to include <math.h> for
> whatever reason, the warning will be more that appreciated :)

You're right that GCC knows enough to disable treating the symbol
as a built-in in the file where the symbol is defined.  In most
cases it does do that.  But defining such a symbol "infects" all
translation units in the program.  If the program dynamically
links with shared libraries it also affects those.  References
to the symbol from there will resolve to the "rogue" definition
in the file that disables the built-in (either implicitly or
explicitly, using -fno-builtin-).

> So my preference choice would be, the compiler decide  if I am using
> exp() in my own right, and emit warning appropriatly.
> 
> If that is too hard to achieve, the allowing #pragma or _Pragma is acceptable.

The pragma solution I suggested is also limited, just as
the option.  But after thinking about it some more, the pragma
to disable the symbol from being treated as a built-in shouldn't
be necessary.  GCC should do that (and in most cases does) on
its own in response to the incompatible declaration of the symbol.
It still issues a warning (which is important).  In recent GCC
version the warning can be disabled via #pragma GCC diagnostic
(but as I said, that's ill-advised),  In a future GCC version,
perhaps even 10, redefining a built-in symbol will likely
become an error (same way as it is an error with Clang).

Martin


> 
> The actual solution is not too good.
> 
> Cheers,
> 
> 
> On Thu, Apr 11, 2019 at 4:26 AM Martin Sebor <msebor@gmail.com> wrote:
>>
>> On 4/10/19 4:51 PM, Segher Boessenkool wrote:
>>> [ Please keep replies on the list.  Thanks. ]
>>>
>>> On Wed, Apr 10, 2019 at 06:04:30PM +0200, phi gcc wrote:
>>>> I can't really change the Makefile so the --no-builtin is not too easy for me.
>>>>
>>>> The pragma seems not work on my gcc
>>>>
>>>> TC$ gcc --version
>>>> gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
>>>>
>>>> TC$ echo "#pragma GCC diagnostic ignored \"-Wbuiltin-declaration-mismatch\"
>>>> int exp;" | cc -c -x c -
>>>> <stdin>:2:5: warning: built-in function 'exp' declared as non-function
>>
>> Disabling the built-in is far safer than disabling these warnings.
>> Some optimizations transform calls to library functions made by
>> the program and recognized as built-ins to those to other functions
>> that the program never explicitly calls.  When an incompatible symbol
>> with the same name as one of the other built-in functions is defined
>> in a program, calls to the other built-in will very likely crash.
>>
>> It ought to be possible to disable built-ins using an attribute
>> or #pragma, like #pragma GCC optimize, but it doesn't work.  If
>> there isn't a way to do it, filing an enhancement request might
>> help.
>>
>> Martin

Re: built-in function 'exp' declared as non-function

[phi gcc]

Builtin symbols should be namespaced
__exp()

and he one who want the builtin short named could (and I guess the
include math.h) can do that.

#define exp __exp

There is no problem of renaming it because as a user you will never
set a BP into the builtin.

With the reversed logic, compilers (or normalisation I guess)
despotically pick a stdlib function name, decide it become a builtin,
and the one who never used it, but may colide with the symbol, are now
directed toward their rename

#define exp my_exp

That is a pitty because now, some debugger don't know this macro name
so setting BP is a problem (you got to remember the macro expanded
name)

I am not to happy with that.

On this occurence I can manage by declaring my int exp as static, with
some tricks to pass the addr of it to other CU consumers, the beauty
of external static..

How well...

Re: built-in function 'exp' declared as non-function

[Jonathan Wakely]

On Thu, 11 Apr 2019 at 18:01, phi gcc <phi.gcc@gmail.com> wrote:
>
> Builtin symbols should be namespaced
> __exp()
>
> and he one who want the builtin short named could (and I guess the
> include math.h) can do that.
>
> #define exp __exp
>
> There is no problem of renaming it because as a user you will never
> set a BP into the builtin.
>
> With the reversed logic, compilers (or normalisation I guess)
> despotically pick a stdlib function name, decide it become a builtin,

No, the language standard picked the name, and reserves "exp" as an
identifier with external linkage if you use any stdlib entity. So
defining another entity with that name and external linkage has
undefined behaviour.

Re: built-in function 'exp' declared as non-function

[phi gcc]

Yes I got it. Now what will be the standard next move, what  set of
idents will become unavailable. ...

On Thu, Apr 11, 2019 at 7:06 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Thu, 11 Apr 2019 at 18:01, phi gcc <phi.gcc@gmail.com> wrote:
> >
> > Builtin symbols should be namespaced
> > __exp()
> >
> > and he one who want the builtin short named could (and I guess the
> > include math.h) can do that.
> >
> > #define exp __exp
> >
> > There is no problem of renaming it because as a user you will never
> > set a BP into the builtin.
> >
> > With the reversed logic, compilers (or normalisation I guess)
> > despotically pick a stdlib function name, decide it become a builtin,
>
> No, the language standard picked the name, and reserves "exp" as an
> identifier with external linkage if you use any stdlib entity. So
> defining another entity with that name and external linkage has
> undefined behaviour.

Re: built-in function 'exp' declared as non-function

[phi gcc]

Exp when used requires both math.h and -lm
Does it make it an stdlib ?

I am new to this vocable sounds like stdlib is the sum of a bunch of .h and
may .a .so, with bunch meaning the list can grow at will.

I must have missed something .... 😀

Re: built-in function 'exp' declared as non-function

[Jonathan Wakely]

On Thu, 11 Apr 2019 at 18:34, phi gcc <phi.gcc@gmail.com> wrote:

> Exp when used requires both math.h and -lm
> Does it make it an stdlib ?
>
> I am new to this vocable sounds like stdlib is the sum of a bunch of .h
> and may .a .so, with bunch meaning the list can grow at will.
>

The standard library is what's defined in the standard, nothing to do with
a bunch of headers and library files on disk.


> I must have missed something .... 😀
>

Re: built-in function 'exp' declared as non-function

[graham stott via gcc-help]

    


-------- Original message --------
From: phi gcc <phi.gcc@gmail.com> 
Date: 11/04/2019  18:34  (GMT+00:00) 
To: Jonathan Wakely <jwakely.gcc@gmail.com> 
Cc: Martin Sebor <msebor@gmail.com>, gcc-help <gcc-help@gcc.gnu.org> 
Subject: Re: built-in function 'exp' declared as non-function 

Exp when used requires both math.h and -lmDoes it make it an stdlib ?I am new to this vocable sounds like stdlib is the sum of a bunch of .h andmay .a .so, with bunch meaning the list can grow at will.I must have missed something .... 😀