[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows

2013-12-30 Thread solomon.gibbs.lists at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066

Solomon Gibbs solomon.gibbs.lists at gmail dot com changed:

   What|Removed |Added

  Attachment #29236|0   |1
is obsolete||

--- Comment #4 from Solomon Gibbs solomon.gibbs.lists at gmail dot com ---
Created attachment 31545
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31545action=edit
Shared header, C99 and C++ units. With workaround.


[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows

2013-12-30 Thread solomon.gibbs.lists at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066

Solomon Gibbs solomon.gibbs.lists at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Solomon Gibbs solomon.gibbs.lists at gmail dot com ---
Sorry, I missed the request for more information.

This is still broken for me under 4.8.1. 

In a nutshell, I think that differing assumptions about inline functions made
by g++ and gcc are carrying over into object file output and preventing
linking. 

Working from a shared header with a non-static inline function, gcc explicitly
creates an implementation at the location of an extern inline  On the
other hand, g++ creates an implementation in every unit where the header was
included, intending to throw away redundant definitions at link time. 

This gives us a definition in the C unit and the C++ unit. However, for some
reason, possibly related to the difference in COFF data, the linker is unable
to determine that the definitions are truly identical as it would if they both
came from a non-static C++ inline.

One workaround is to prevent the C++ definition from being created using the
gnu_inline function attribute.


I updated the original attachment to show the workaround and added a Makefile.
Since this requires a shared header, C and C++ units to manifest, I did not
paste all three files into the comment, but left them in the attachment
archive. Please let me know if you still need something else to reproduce the
issue.

The relevant output is obtained from objdump as:

$ objdump -x app-broken.o |grep -B1 -e 'COMDAT _problem_function'
  3 .text$problem_function 000c      0180  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE, LINK_ONCE_DISCARD
(COMDAT _problem_function 4)


$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\opt\MinGW-w64\x86-posix-dwarf\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/opt/mingw-w64/x86-posix-dwarf/bin/../libexec/gcc/i686-w64-mingw32/4.8.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-4.8.1/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32
--with-sysroot=/tmp/x32-481-posix-dwarf-r5/mingw32 --enable-shared
--enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp
--enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check
--disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686
--with-tune=generic --with-libiconv --with-system-zlib
--with-gmp=/tmp/mingw-prereq/i686-w64-mingw32-static
--with-mpfr=/tmp/mingw-prereq/i686-w64-mingw32-static
--with-mpc=/tmp/mingw-prereq/i686-w64-mingw32-static
--with-isl=/tmp/mingw-prereq/i686-w64-mingw32-static
--with-cloog=/tmp/mingw-prereq/i686-w64-mingw32-static
--enable-cloog-backend=isl --with-pkgversion='rev5, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/tmp/x32-481-posix-dwarf-r5/libs/include -I/tmp/mingw-prereq/x32-zlib/include
-I/tmp/mingw-prereq/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe
-I/tmp/x32-481-posix-dwarf-r5/libs/include -I/tmp/mingw-prereq/x32-zlib/include
-I/tmp/mingw-prereq/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe
-L/tmp/x32-481-posix-dwarf-r5/libs/lib -L/tmp/mingw-prereq/x32-zlib/lib
-L/tmp/mingw-prereq/i686-w64-mingw32-static/lib
-L/tmp/x32-481-posix-dwarf-r5/mingw32/opt/lib -Wl,--large-address-aware'
Thread model: posix
gcc version 4.8.1 (rev5, Built by MinGW-W64 project)


$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\opt\MinGW-w64\x86-posix-dwarf\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/opt/mingw-w64/x86-posix-dwarf/bin/../libexec/gcc/i686-w64-mingw32/4.8.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-4.8.1/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32
--with-sysroot=/tmp/x32-481-posix-dwarf-r5/mingw32 --enable-shared
--enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp
--enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check
--disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls

[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows

2013-12-27 Thread ktietz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
No reply.  So I assume bug was fixed already.  Please don't hesitate to reopen
this bug (with small testcase for reproducing it) again, if it re-appears.


[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows

2013-11-26 Thread ktietz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-11-26
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org ---
I can't reproduce your problem with 4.7.  At least not with given sample.

Could you please provide more detailed, short, and compilable testcase.


[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows

2013-01-24 Thread solomon.gibbs.lists at gmail dot com

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

--- Comment #1 from Solomon Gibbs solomon.gibbs.lists at gmail dot com 
2013-01-24 19:42:15 UTC ---

I'm looking at the objdump -x output for the c++ object and I note that there's
a separate section for the inlined function. It appears to be annotated with a
COMDAT field value of 4. According to skyfree.org/linux/references/coff.pdf a
value of 4 corresponds to IMAGE_COMDAT_SELECT_EXACT_MATCH: The linker chooses
an arbitrary section among the definitions for this symbol. A multiply defined
symbol error is issued if all definitions don’t match exactly. The C99 symbol
has no COMDAT selection field.