[Bug libstdc++/59472] Many warnings "type of 'X' does not match original declaration" when linking with libstdc++ static library compiled with -flto

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I think it's worth keeping open for my suggestion in comment 3 (which I'd
forgotten about).

[Bug libstdc++/59472] Many warnings "type of 'X' does not match original declaration" when linking with libstdc++ static library compiled with -flto

[paul at scruby dot com]

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

--- Comment #7 from Paul Scruby  ---
Feel free to close this ticket.

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59472
>
> --- Comment #6 from Eric Gallager  ---
> (In reply to Paul Scruby from comment #5)
>> Is there a patch to fix or suppress the warnings when link-time
>> optimizing
>> to libstdc++.a ?  I'm using gcc4.8.2, but I'm happy to upgrade to gcc4.9
>> if
>> this release is more likely to get fixed first?
>
> Well both those branches are closed now; could you upgrade to something
> more
> recent instead?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug libstdc++/59472] Many warnings "type of 'X' does not match original declaration" when linking with libstdc++ static library compiled with -flto

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Paul Scruby from comment #5)
> Is there a patch to fix or suppress the warnings when link-time optimizing
> to libstdc++.a ?  I'm using gcc4.8.2, but I'm happy to upgrade to gcc4.9 if
> this release is more likely to get fixed first?

Well both those branches are closed now; could you upgrade to something more
recent instead?

[Bug libstdc++/59472] Many warnings type of 'X' does not match original declaration when linking with libstdc++ static library compiled with -flto

[paul at scruby dot com]

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

--- Comment #5 from Paul Scruby paul at scruby dot com ---
Is there a patch to fix or suppress the warnings when link-time optimizing to
libstdc++.a ?  I'm using gcc4.8.2, but I'm happy to upgrade to gcc4.9 if this
release is more likely to get fixed first?

[Bug libstdc++/59472] Many warnings type of 'X' does not match original declaration when linking with libstdc++ static library compiled with -flto

[paul at scruby dot com]

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

Paul Scruby paul at scruby dot com changed:

   What|Removed |Added

 CC||paul at scruby dot com

--- Comment #2 from Paul Scruby paul at scruby dot com ---
I have the same issue with my build of gcc4.8.2

I built libstdc++-v3 with '-flto -O3'.  Now when my makefiles link to libstdc++
statically eg '-static-libstdc++ -flto -O3 -fuse-linker-plugin', I see these
warnings too.

Thanks,

Paul

[Bug libstdc++/59472] Many warnings type of 'X' does not match original declaration when linking with libstdc++ static library compiled with -flto

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #1)
 Reassigning to libstdc++ because the warnings seem to say the truth.

They do tell the truth.

We use char arrays for good reason (see the comment in src/c++98/globals_io.cc)
but I'm not sure why we have to lie about the types in src/c++98/ios_init.cc, I
think it's only so we can call the destructors in ios::sync_with_stdio:

// Explicitly call dtors to free any memory that is
// dynamically allocated by filebuf ctor or member functions,
// but don't deallocate all memory by calling operator delete.
buf_cout_sync.~stdio_sync_filebufchar();
buf_cin_sync.~stdio_sync_filebufchar();
buf_cerr_sync.~stdio_sync_filebufchar();

But I think that could be done by casting the char array to stdio_sync_filebuf*
instead.

[Bug libstdc++/59472] Many warnings type of 'X' does not match original declaration when linking with libstdc++ static library compiled with -flto

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
That should work for the streambufs, it's not so simple for the standard stream
objects though, as they're user-visible and we declared their (pretend) types
in iostream.

[Bug libstdc++/59472] Many warnings type of 'X' does not match original declaration when linking with libstdc++ static library compiled with -flto

[glisse at gcc dot gnu.org]

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

Marc Glisse glisse at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-22
  Component|lto |libstdc++
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
Same here (CXXFLAGS_FOR_TARGET=-O2 -g -flto -ffat-lto-objects after a trivial
fix for PR 43538):

/data/repos/gcc/trunk/libstdc++-v3/src/c++98/ios_init.cc:56:33: warning: type
of 'buf_wcerr' does not match original declaration [enabled by default]
   extern stdio_filebufwchar_t buf_wcerr;
 ^
/data/repos/gcc/trunk/libstdc++-v3/src/c++98/globals_io.cc:105:17: note:
previously declared here
   fake_wfilebuf buf_wcerr;
 ^

etc.

Reassigning to libstdc++ because the warnings seem to say the truth.