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

Martin Sebor msebor@gmail.com
Thu Apr 11 15:12:00 GMT 2019


[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



More information about the Gcc-help mailing list