[Bug target/52163] New: [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[Bug target/52163] New: [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[doko at gcc dot gnu.org]

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

             Bug #: 52163
           Summary: [4.7 regression] 64bit powerpc libgcc is missing
                    exported symbols
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: doko@gcc.gnu.org


a 20120205 trunk build on powerpc-linux-gnu, configured with
      --enable-targets=powerpc-linux,powerpc64-linux
     --with-cpu=default32
is missing some exported symbols in the 64bit libgcc_s.so.  The 32bit libgcc
looks fine.
I don't see the missing symbols with 20120121, but 20120129.

I'll do the next test build with r183491 reverted.


dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols
file: see diff output below
dpkg-gensymbols: warning: debian/lib64gcc1/DEBIAN/symbols doesn't match
completely debian/lib64gcc1.symbols.powerpc
--- debian/lib64gcc1.symbols.powerpc (lib64gcc1_1:4.7-20120205-1_powerpc)
+++ dpkg-gensymbolsDWJ2Yc    2012-02-05 22:14:13.000000000 +0000
@@ -1,7 +1,7 @@
 libgcc_s.so.1 lib64gcc1 #MINVER#
  GCC_3.0@GCC_3.0 1:4.1.1
  GCC_3.3.1@GCC_3.3.1 1:4.1.1
- GCC_3.3.4@GCC_3.3.4 1:4.1.1
+#MISSING: 1:4.7-20120205-1# GCC_3.3.4@GCC_3.3.4 1:4.1.1
  GCC_3.3@GCC_3.3 1:4.1.1
  GCC_3.4.2@GCC_3.4.2 1:4.1.1
  GCC_3.4.4@GCC_3.4.4 1:4.1.1
@@ -32,8 +32,8 @@
  __absvdi2@GCC_3.0 1:4.1.1
  __absvsi2@GCC_3.0 1:4.1.1
  __absvti2@GCC_3.4.4 1:4.1.1
- __adddf3@GCC_3.0 1:4.1.1
- __addsf3@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __adddf3@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __addsf3@GCC_3.0 1:4.1.1
  __addvdi3@GCC_3.0 1:4.1.1
  __addvsi3@GCC_3.0 1:4.1.1
  __addvti3@GCC_3.4.4 1:4.1.1
@@ -53,24 +53,24 @@
  __deregister_frame_info@GLIBC_2.0 1:4.1.1
  __deregister_frame_info_bases@GCC_3.0 1:4.1.1
  __divdc3@GCC_4.0.0 1:4.1.1
- __divdf3@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __divdf3@GCC_3.0 1:4.1.1
  __divsc3@GCC_4.0.0 1:4.1.1
- __divsf3@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __divsf3@GCC_3.0 1:4.1.1
  __divtc3@GCC_4.0.0 1:4.1.1
  __divti3@GCC_3.0 1:4.1.1
  __emutls_get_address@GCC_4.3.0 1:4.3
  __emutls_register_common@GCC_4.3.0 1:4.3
  __enable_execute_stack@GCC_3.4.2 1:4.1.1
- __eqdf2@GCC_3.0 1:4.1.1
- __eqsf2@GCC_3.0 1:4.1.1
- __extendsfdf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __eqdf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __eqsf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __extendsfdf2@GCC_3.0 1:4.1.1
  __ffsdi2@GCC_3.0 1:4.1.1
  __ffsti2@GCC_3.0 1:4.1.1
  __fixdfdi@GCC_3.0 1:4.1.1
- __fixdfsi@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __fixdfsi@GCC_3.0 1:4.1.1
  __fixdfti@GCC_3.0 1:4.1.1
  __fixsfdi@GCC_3.0 1:4.1.1
- __fixsfsi@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __fixsfsi@GCC_3.0 1:4.1.1
  __fixsfti@GCC_3.0 1:4.1.1
  __fixtfdi@GCC_3.0 1:4.1.1
  __fixtfti@GCC_3.0 1:4.1.1
@@ -85,16 +85,16 @@
  __floatdidf@GCC_3.0 1:4.1.1
  __floatdisf@GCC_3.0 1:4.1.1
  __floatditf@GCC_3.0 1:4.1.1
- __floatsidf@GCC_3.0 1:4.1.1
- __floatsisf@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __floatsidf@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __floatsisf@GCC_3.0 1:4.1.1
  __floattidf@GCC_3.0 1:4.1.1
  __floattisf@GCC_3.0 1:4.1.1
  __floattitf@GCC_3.0 1:4.1.1
  __floatundidf@GCC_4.2.0 1:4.2.1
  __floatundisf@GCC_4.2.0 1:4.2.1
  __floatunditf@GCC_4.2.0 1:4.2.1
- __floatunsidf@GCC_4.2.0 1:4.1.1
- __floatunsisf@GCC_4.2.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __floatunsidf@GCC_4.2.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __floatunsisf@GCC_4.2.0 1:4.1.1
  __floatuntidf@GCC_4.2.0 1:4.2.1
  __floatuntisf@GCC_4.2.0 1:4.2.1
  __floatuntitf@GCC_4.2.0 1:4.2.1
@@ -104,33 +104,33 @@
  __gcc_qdiv@GCC_3.4.4 1:4.1.1
  __gcc_qmul@GCC_3.4.4 1:4.1.1
  __gcc_qsub@GCC_3.4.4 1:4.1.1
- __gedf2@GCC_3.0 1:4.1.1
- __gesf2@GCC_3.0 1:4.1.1
- __gtdf2@GCC_3.0 1:4.1.1
- __gtsf2@GCC_3.0 1:4.1.1
- __ledf2@GCC_3.0 1:4.1.1
- __lesf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __gedf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __gesf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __gtdf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __gtsf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __ledf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __lesf2@GCC_3.0 1:4.1.1
  __lshrti3@GCC_3.0 1:4.1.1
- __ltdf2@GCC_3.0 1:4.1.1
- __ltsf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __ltdf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __ltsf2@GCC_3.0 1:4.1.1
  __modti3@GCC_3.0 1:4.1.1
  __muldc3@GCC_4.0.0 1:4.1.1
- __muldf3@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __muldf3@GCC_3.0 1:4.1.1
  __mulsc3@GCC_4.0.0 1:4.1.1
- __mulsf3@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __mulsf3@GCC_3.0 1:4.1.1
  __multc3@GCC_4.0.0 1:4.1.1
  __multi3@GCC_3.0 1:4.1.1
  __mulvdi3@GCC_3.0 1:4.1.1
  __mulvsi3@GCC_3.0 1:4.1.1
  __mulvti3@GCC_3.4.4 1:4.1.1
- __nedf2@GCC_3.0 1:4.1.1
- __negdf2@GCC_3.0 1:4.1.1
- __negsf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __nedf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __negdf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __negsf2@GCC_3.0 1:4.1.1
  __negti2@GCC_3.0 1:4.1.1
  __negvdi2@GCC_3.0 1:4.1.1
  __negvsi2@GCC_3.0 1:4.1.1
  __negvti2@GCC_3.4.4 1:4.1.1
- __nesf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __nesf2@GCC_3.0 1:4.1.1
  __paritydi2@GCC_3.4 1:4.1.1
  __parityti2@GCC_3.4 1:4.1.1
  __popcountdi2@GCC_3.4 1:4.1.1
@@ -144,18 +144,18 @@
  __register_frame_info_table@GLIBC_2.0 1:4.1.1
  __register_frame_info_table_bases@GCC_3.0 1:4.1.1
  __register_frame_table@GLIBC_2.0 1:4.1.1
- __subdf3@GCC_3.0 1:4.1.1
- __subsf3@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __subdf3@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __subsf3@GCC_3.0 1:4.1.1
  __subvdi3@GCC_3.0 1:4.1.1
  __subvsi3@GCC_3.0 1:4.1.1
  __subvti3@GCC_3.4.4 1:4.1.1
- __truncdfsf2@GCC_3.0 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __truncdfsf2@GCC_3.0 1:4.1.1
  __ucmpti2@GCC_3.0 1:4.1.1
  __udivmodti4@GCC_3.0 1:4.1.1
  __udivti3@GCC_3.0 1:4.1.1
  __umodti3@GCC_3.0 1:4.1.1
- __unorddf2@GCC_3.3.4 1:4.1.1
- __unordsf2@GCC_3.3.4 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __unorddf2@GCC_3.3.4 1:4.1.1
+#MISSING: 1:4.7-20120205-1# __unordsf2@GCC_3.3.4 1:4.1.1
  _xlqadd@GCC_3.4 1:4.1.1
  _xlqdiv@GCC_3.4 1:4.1.1
  _xlqmul@GCC_3.4 1:4.1.1

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-08 07:43:35 UTC ---
If those symbols were ever in some snapshot exported, it was by mistake.
Looking e.g. at gcc 4.4.6 ppc 64-bit libgcc_s.so, the only exported
*[sd]f[23]@@GCC* symbols there are
__powidf2@@GCC_4.0.0 FUNC GLOBAL DEFAULT
__powisf2@@GCC_4.0.0 FUNC GLOBAL DEFAULT
and nothing else.  ppc64 can always assume a FPU, so there is no point in
exporting the soft-fp stuff.

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #2 from Alan Modra <amodra at gmail dot com> 2012-02-08 09:37:12 UTC ---
Correct.  In fact, I think it's a waste of space to put the soft-float
functions in the normal ppc32 libgcc.  They really only belong in the nof
libgcc.

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-02-08
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-08 10:26:07 UTC ---
So ... not a bug?

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-08 10:27:32 UTC ---
Perhaps waste of space, but we have been including them there in the past, so
removing them would be an ABI change.  They could be made into @ as opposed to
@@ symbols, so that nobody links against them (when using GNU versioning).

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-08 10:28:05 UTC ---
Yeah.

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-02-08 15:34:32 UTC ---
On Wed, 8 Feb 2012, amodra at gmail dot com wrote:

> Correct.  In fact, I think it's a waste of space to put the soft-float
> functions in the normal ppc32 libgcc.  They really only belong in the nof
> libgcc.

My view is that while they may need to stay for ABI compatibility, it 
should be possible to build very small versions for that case from generic 
C code for all the functions where GCC will reliably generate the expected 
code (not a recursive call) from generic C - so they don't actually take 
up much space in libgcc.

SFtype __addsf3 (SFtype a, SFtype b) { return a + b; }

etc.

Doing this for Power is more complicated than for some architectures 
because of all the floating point variants including Xilinx and e500v1 
which do only single-precision in hardware - and some variants may do some 
operations in hardware but not others, for a given type (e.g. 
__builtin_isunordered may involve a libgcc function for e500).  But it's 
certainly feasible at the present state of the toplevel libgcc transition 
to control what functions are built from what sources on a per-multilib 
basis, testing the compiler used for that multilib to determine which 
floating-point configuration is applicable.  And similar issues of not 
needing certain functions in libgcc, other than for compatibility, apply 
to other targets as well (MIPS in particular) - the generic C versions 
referred to above will be of use for more targets than just Power.

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-08 15:52:18 UTC ---
Yeah, that might be a good idea.  As it would be just an optimization compared
to the present state, we might in the first step do it just for the ppc targets
that have full float/double support in hw.

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[doko at gcc dot gnu.org]

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

--- Comment #8 from Matthias Klose <doko at gcc dot gnu.org> 2012-02-08 19:24:42 UTC ---
it's not some snapshot, as it looks these were exported consistently since
4.1.1 releases.  Do you say that these symbols are not exported for e.g. Fedora
packages?

[Bug target/52163] [4.7 regression] 64bit powerpc libgcc is missing exported symbols

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-08 19:26:56 UTC ---
Yes, they are not exported in Fedora/RHEL packages.