[Bug c++/67739] New: name clash between builtin functions and local variables when optimization is on

[Bug c++/67739] New: name clash between builtin functions and local variables when optimization is on

[milan.durovic at ali dot com.au]

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

            Bug ID: 67739
           Summary: name clash between builtin functions and local
                    variables when optimization is on
           Product: gcc
           Version: 4.9.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: milan.durovic at ali dot com.au
  Target Milestone: ---

Created attachment 36404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36404&action=edit
simple test program illustrating the problem with gcc 4.8.1

This bug also appears in 4.8.1 version.

We have a local static array called 'sincos'. The code is calculating sin() and
cos() of the same value.

Compiler generates a call to 'sincos' method. However, the address of 'sincos'
method is resolved to be the address of the local static variable of the same
name, leading to an error. Compiler hasn't generated ANY warnings about this
name clash.

Identical problem exists in 4.8.1 compiler, except that here the function name
is 'sincosf'. It seems like this is a long standing error.


Compiler invocation:

gcc -O1 -lm test.c -Wall -Wextra -save-temps

Then:

./a.out

does segmentation fault.

[Bug c++/67739] name clash between builtin functions and local variables when optimization is on

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
You are using -std=gnu89 by default and thus adhering to GNU extensions where
sincos is a known identifier.  We're missing to warn about this maybe(?).
Using -std=c89 should fix this as well (not verified).

[Bug c++/67739] name clash between builtin functions and local variables when optimization is on

[milan.durovic at ali dot com.au]

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

--- Comment #3 from Milan Durovic <milan.durovic at ali dot com.au> ---
I think a warning is the right answer. You can't expect people to be aware of
all built-in functions. I wasn't aware that there was such a function called
'sincos'.

And even more importantly, the name clash is not really obvious for the simple
reason that the function that the compiler invokes is not even explicitly
exposed, ie. it doesn't appear in the source code. And these change: in one
version, compiler invokes sincosf and in another, sincos. So code that compiles
and works fine with one compiler version would fail with another compiler
version.

Warning is the minimum that should happen, although I think if the compiler
wants to invoke a particular, hidden function, and its name clashes with a
program variable, then it's something compiler should automatically resolve.

[Bug c++/67739] name clash between builtin functions and local variables when optimization is on

[milan.durovic at ali dot com.au]

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

--- Comment #4 from Milan Durovic <milan.durovic at ali dot com.au> ---
Richard Biener:

I've tried your suggestion. The problem is still there, although it does help
with 4.8.1, when local variable is called sincosf.

But the core problem is still there: the compiler generates a call to a method
whose name clashes with a local variable and no indication of this happening is
given at all.

[Bug middle-end/67739] name clash between builtin functions and local variables when optimization is on

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57664&action=edit
Better testcase

With the original testcase, the stores to sincosf were optimized away and no
longer did the sin->sinf transformation so do it manually.