[Bug c++/58738] New: forward declaration of function inside function cause link problem with optimization

[Bug c++/58738] New: forward declaration of function inside function cause link problem with optimization

[dushistov at mail dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58738

            Bug ID: 58738
           Summary: forward declaration of function inside function cause
                    link problem with optimization
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dushistov at mail dot ru

Here source code of test case:
namespace {

int foo()
{
    int bar(void);
    return bar();
}

int bar() { return -1; }

}

int main(int argc, char* argv[])
{
    return foo();
}

With g++ -O0 -Wpedantic -ansi -Wall test.cpp it compiles fine, while
with the same options except s/-O0/-O2/g it gave:
undefined reference to `(anonymous namespace)::bar()'.

gcc 4.8.1/amd64

[Bug c++/58738] forward declaration of function inside function cause link problem with optimization

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58738

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The standard says:

The name of a function declared in block scope and the name of a variable
declared by a block scope extern declaration have linkage. If there is a
visible declaration of an entity with linkage having the same name and type,
ignoring entities declared outside the innermost enclosing namespace scope, the
block scope declaration declares that same entity and receives the linkage of
the previous declaration. If there is more than one such matching entity, the
program is ill-formed. Otherwise, if no matching entity is found, the block
scope entity
receives external linkage.

That means the first declaration of bar() has external linkage, but the later
definition has internal linkage because it's a member of an unnamed namespace,
so the declaration does not match the definition.

So I think your program is invalid.

[Bug c++/58738] forward declaration of function inside function cause link problem with optimization

[dushistov at mail dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58738

--- Comment #2 from Evgeniy Dushistov <dushistov at mail dot ru> ---
>That means the first declaration of bar() has external linkage, but the later >definition has internal linkage because it's a member of an unnamed namespace, >so the declaration does not match the definition.

But if gcc consider that bar() has external linkage,
(- When a name has external linkage, the enity it denotes can be referred to by
names from scopes of other translation uits or from other scopes of the same
translation unit.)

why it generate reference to  `(anonymous namespace)::bar()'?

According to error message it has anonymous namespace, in another words
internal linkage.

[Bug c++/58738] forward declaration of function inside function cause link problem with optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |10.1.0, 4.8.1, 9.1.0
      Known to work|                            |11.1.0, 12.0

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This seems to have been fixed in GCC 11+.

[Bug c++/58738] forward declaration of function inside function cause link problem with optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=95677

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect maybe r11-3699 fixed this.