public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Gabriel F.T.Gomes <gftg@sourceware.org>
To: glibc-cvs@sourceware.org
Subject: [glibc] Deleted branch gabriel/powerpc-ieee128-printscan
Date: Fri, 13 Dec 2019 22:28:00 -0000	[thread overview]
Message-ID: <20191213222803.112032.qmail@sourceware.org> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 14162 bytes --]

The branch 'gabriel/powerpc-ieee128-printscan' was deleted.
It previously pointed to:

 5b7fcf2... RFC: powerpc64le: Enable support for IEEE long double

Diff:

!!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE (LOST):
-------------------------------------------------------------------

  5b7fcf2... RFC: powerpc64le: Enable support for IEEE long double
  b9d9986... powerpc64le: Require a compiler with -mno-gnu-attribute
  4625bdf... ldbl-128ibm-compat: Do not mix -mabi=*longdouble and -mlong
  9dcbdd5... Avoid compat symbols for totalorder in powerpc64le IEEE lon
  675a15e... ldbl-128ibm-compat: Compiler flags for stdio functions
  cf48802... Do not redirect calls to __GI_* symbols, when redirecting t
  d00ba66... ldbl-128ibm-compat: Add *cvt functions
  e470a3f... Refactor *cvt functions implementation (5/5)
  fc90741... Refactor *cvt functions implementation (1-4/5)
  8a9f338... ldbl-128ibm-compat: Add ISO C99 versions of scanf functions
  48630fa... ldbl-128ibm-compat: Fix selection of GNU and ISO C99 scanf

commit 5b7fcf2e8104411e4fe41f2847b717abf31d2433
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Thu Jul 11 11:48:28 2019 -0300

    RFC: powerpc64le: Enable support for IEEE long double
    
    DO NOT COMMIT!
    
    Changes since v2:
    
      - Added definition of LDBL_IBM128_COMPAT_VERSION and
        LDBL_IBM128_VERSION (moved from a previous commit).
    
    Changes since v1:
    
      - Use __LONG_DOUBLE_USES_FLOAT128 directly.
    
    -- 8< --
    On platforms where long double may have two different formats, i.e.: the
    same format as double (64-bits) or something else (128-bits), building
    with -mlong-double-128 is the default and function calls in the user
    program match the name of the function in Glibc.  When building with
    -mlong-double-64, Glibc installed headers redirect such calls to the
    appropriate function.
    
    This patch adds similar redirections to be used by user code builds in
    IEEE long double mode (-mabi=ieeelongdouble).  It also skips some uses
    of libc_hidden_proto in internal headers, because they also produce
    redirections, causing a redirection conflict.
    
    PS: Missing NEWS entry.

commit b9d9986c6619d94750e5879df7f15190d9c85140
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Fri Oct 11 15:20:05 2019 -0300

    powerpc64le: Require a compiler with -mno-gnu-attribute
    
    No changes since v2.
    
    Changes since v1:
    
      - Added mentions to the build requirement in manual/install.texi,
        INSTALL (regenerated) and NEWS.
    
    -- 8< --
    On powerpc64le, a few files are built on IEEE long double mode
    (-mabi=ieeelongdouble), whereas most are built on IBM long double mode
    (-mabi=ibmlongdouble, the default for -mlong-double-128). Since binutils
    2.31, linking object files with different long double modes causes
    errors similar to:
    
      ld: libc_pic.a(s_isinfl.os) uses IBM long double,
          libc_pic.a(ieee128-qefgcvt.os) uses IEEE long double.
      collect2: error: ld returned 1 exit status
      make[2]: *** [../Makerules:649: libc_pic.os] Error 1
    
    The warnings are fair and correct, but in order for glibc to have
    support for both long double modes on powerpc64le, they have to be
    ignored.  This can be accomplished with the use of -mno-gnu-attribute
    option when building the few files that require IEEE long double mode.
    
    However, -mno-gnu-attribute is not available in GCC 6, the minimum
    version required to build glibc, so this patch adds a test for this
    feature in powerpc64le builds, and fails early if it's not available.
    
    Tested, on powerpc64le, that the build fails early with GCC 6 and that
    it succeeds with GCC 7 or greater.
    
    Reviewed-by: Joseph Myers <joseph@codesourcery.com>

commit 4625bdf4d3edb21b437c0a84cfe80562b92a066a
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Tue Sep 10 08:05:03 2019 -0500

    ldbl-128ibm-compat: Do not mix -mabi=*longdouble and -mlong-double-128
    
    No changes since v2.
    
    Changes since v1:
    
      - Do not try to remove -mabi=ieeelongdouble, since it hasn't been
        added.  The removal is a residue from our initial development.
    
    -- 8< --
    Some compiler versions, e.g. GCC 7, complain when -mlong-double-128 is
    used together with -mabi=ibmlongdouble or -mabi=ieeelongdouble,
    producing the following error message:
    
      cc1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’
    
    This patch removes -mlong-double-128 from the compilation lines that
    explicitly request -mabi=*longdouble.
    
    Tested for powerpc64le.

commit 9dcbdd544768e71ce2b0a8e127f6095d24ce8d15
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Mon Sep 9 12:59:46 2019 -0500

    Avoid compat symbols for totalorder in powerpc64le IEEE long double
    
    No changes since v2.
    
    Changes since v1:
    
      - Added comment on the redefinition of libm_alias_float128_other_r_ldbl.
    
    -- 8< --
    On powerpc64le, the libm_alias_float128_other_r_ldbl macro is
    used to create an alias between totalorderf128 and __totalorderlieee128,
    as well as between the totalordermagf128 and __totalordermaglieee128.
    
    However, the totalorder* and totalordermag* functions changed their
    parameter type since commit ID 42760d764649 and got compat symbols for
    their old versions.  With this change, the aforementioned macro would
    create two conflicting aliases for __totalorderlieee128 and
    __totalordermaglieee128.
    
    This patch avoids the creation of the alias between the IEEE long double
    symbols (__totalorderl*ieee128) and the compat symbols, because the IEEE
    long double functions have never been exported thus don't need such
    compat symbol.
    
    Tested for powerpc64le.
    
    Reviewed-by: Joseph Myers <joseph@codesourcery.com>

commit 675a15ed1e980c8473d843ae1de0e2d0be8e53b3
Author: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Date:   Mon Jul 30 12:04:40 2018 -0300

    ldbl-128ibm-compat: Compiler flags for stdio functions
    
    No changes since v2.
    
    No changes since v1.
    
    -- 8< --
    Some of the files that provide stdio.h and wchar.h functions have a
    filename prefixed with 'io', such as 'iovsprintf.c'.  On platforms that
    imply ldbl-128ibm-compat, these files must be compiled with the flag
    -mabi=ibmlongdouble.  This patch adds this flag to their compilation.
    
    Notice that this is not required for the other files that provide
    similar functions, because filenames that are not prefixed with 'io'
    have ldbl-128ibm-compat counterparts in the Makefile, which already adds
    -mabi=ibmlongdouble to them.

commit cf488028e0e656b700652d5d87dff494ad37bd5a
Author: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Date:   Sun Oct 20 16:00:30 2019 -0500

    Do not redirect calls to __GI_* symbols, when redirecting to *ieee128
    
    No changes since v2.
    
    Changes since v1:
    
      - Reduced the number of changes to the minimum required to build *cvt
        files in -mabi=ieeelongdouble mode.
      - Added __LONG_DOUBLE_USES_FLOAT128 to all long-double.h files.
    
    -- 8< --
    On platforms where long double has IEEE binary128 format as a third
    option (initially, only powerpc64le), many exported functions are
    redirected to their __*ieee128 equivalents.  This redirection is
    provided by installed headers such as stdio-ldbl.h, and is supposed to
    work correctly with user code.
    
    However, during the build of glibc, similar redirections are employed,
    in internal headers, such as include/stdio.h, in order to avoid extra
    PLT entries.  These redirections conflict with the redirections to
    __*ieee128, and must be avoided during the build.  This patch protects
    the second redirections with a test for __LONG_DOUBLE_USES_FLOAT128, a
    new macro that is defined to 1 when functions that deal with long double
    typed values reuses the _Float128 implementation (this is currently only
    true for powerpc64le).
    
    Tested for powerpc64le, x86_64, and with build-many-glibcs.py.
    
    Co-authored-by: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
    Reviewed-by: Florian Weimer <fweimer@redhat.com>

commit d00ba6675d9c07e7a1336793336a13e8a75b98d6
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Thu Jul 11 11:48:24 2019 -0300

    ldbl-128ibm-compat: Add *cvt functions
    
    Changes since v2:
    
      - Fix http URLs.
    
    No changes since v1.
    
    -- 8< --
    This patch adds IEEE long double versions of q*cvt* functions for
    powerpc64le.  Unlike all other long double to/from string conversion
    functions, these do not rely on internal functions that can take
    floating-point numbers with different formats and act on them
    accordingly, instead, the related files are rebuilt with the
    -mabi=ieeelongdouble compiler flag set.
    
    Having -mabi=ieeelongdouble passed to the compiler causes the object
    files to be marked with a .gnu_attribute that is incompatible with the
    .gnu_attribute in files built with -mabi=ibmlongdouble (the default).
    The difference causes error messages similar to the following:
    
      ld: libc_pic.a(s_isinfl.os) uses IBM long double,
          libc_pic.a(ieee128-qefgcvt_r.os) uses IEEE long double.
      collect2: error: ld returned 1 exit status
      make[2]: *** [../Makerules:649: libc_pic.os] Error 1
    
    Although this warning is useful in other situations, the library
    actually needs to have functions with different long double formats, so
    .gnu_attribute generation is explicitly disabled for these files with
    the use of -mno-gnu-attribute.
    
    Tested for powerpc64le on the branch that actually enables the
    sysdeps/ieee754/ldbl-128ibm-compat for powerpc64le.

commit e470a3f2e608ddfe4ce3ca1ce2cf8d3896750be3
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Tue Nov 26 14:48:49 2019 -0300

    Refactor *cvt functions implementation (5/5)
    
    Changes since v2:
    
      - Moved the removal of unused macros to a previous patch
    
    Changes since v1:
    
      - Adapted after patch v1 19/31 (remove hidden_* uses) was dropped.
      - Fixed unintended removal of cvt* symbols on alpha and s390x
        (now tested with build-many-glibcs.py).
    
    This patch is to be squashed with the other n/5 refactoring patches.
    
    This patch replaces the use of the APPEND macro with one new macro being
    defined for each of the cvt* functions.  This makes it easier to define
    functions names for IEEE long double on powerpc64le, e.g. __ecvtieee128.
    
    The commit message is on patch 1-4/5.

commit fc9074193ecb65c2b778497d43cbd90be3291c9f
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Thu Jul 11 11:48:08 2019 -0300

    Refactor *cvt functions implementation (1-4/5)
    
    Changes since v2:
    
      - Squashed patches 1-4 and trivial bits of patch 5.
      - Replaced http with https (like the rest of glibc).
      - Updated copyright years.
      - Removed refactoring noise reported by Paul Murphy.
    
    No changes since v1.
    
    This patch is to be squashed with the other n/5 refactoring patches.
    
    Below, the commit message to be used after the squashing...
    
    -- 8< --
    This patch refactors the *cvt functions implementation in a way that
    makes it easier to re-use them for implementing the IEEE long double on
    powerpc64le.  By splitting the implementation per se in one file
    (efgcvt-template.c) and the alias definitions in others (e.g. efgcvt.c),
    the new code makes it easier to define new function names, such as
    __qecvtieee128.
    
    Tested for powerpc64le and with build-many-glibcs.
    
    Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>

commit 8a9f338591e27a72b179fec6a42d7469c6a55eb5
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Thu Jul 11 11:47:43 2019 -0300

    ldbl-128ibm-compat: Add ISO C99 versions of scanf functions
    
    Changes since v2:
    
      - Removed ugly hacks after rebase against commit ID 93486ba583ec.
      - Updated copyright years.
      - Unified test case for GNU and ISO C99 versions (got rid of many
        files in the process, including the new test template for C99).
      - Fixed http URLs.
      - Updated commit message.
    
    No changes since v1.
    
    -- 8< --
    In the format string for *scanf functions, the '%as', '%aS', and '%a[]'
    modifiers behave differently depending on ISO C99 compatibility.  When
    _GNU_SOURCE is defined and -std=c89 is passed to the compiler, these
    functions behave like ascanf, and the modifiers allocate memory for the
    output.  Otherwise, the ISO C99 compliant version of these functions is
    used, and the modifiers consume a floating-point argument.  This patch
    adds the IEEE binary128 variant of ISO C99 compliant functions for the
    third long double format on powerpc64le.
    
    Tested for powerpc64le.
    
    Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>

commit 48630fa435cebdbf0b91ef0dbb1fe7be99a2d4ec
Author: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Date:   Wed Nov 27 10:06:50 2019 -0600

    ldbl-128ibm-compat: Fix selection of GNU and ISO C99 scanf
    
    New since v2.
    
    -- 8< --
    Since commit
    
    commit 03992356e6fedc5a5e9d32df96c1a2c79ea28a8f
    Author: Zack Weinberg <zackw@panix.com>
    Date:   Sat Feb 10 11:58:35 2018 -0500
    
        Use C99-compliant scanf under _GNU_SOURCE with modern compilers.
    
    the selection of the GNU versions of scanf functions requires both
    _GNU_SOURCE and -std=c89.  This patch changes the tests in
    ldbl-128ibm-compat so that they actually test the GNU versions (without
    this change, the redirection to the ISO C99 version always happens, so
    GNU versions of the new implementation (e.g. __scanfieee128) were left
    untested).
    
    Tested for powerpc64le.


             reply	other threads:[~2019-12-13 22:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 22:28 Gabriel F.T.Gomes [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-12-03 17:02 Gabriel F.T.Gomes
2019-10-25 15:31 Gabriel F.T.Gomes
2019-10-15 19:00 Gabriel F.T.Gomes
2019-08-09 18:34 Gabriel F.T.Gomes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191213222803.112032.qmail@sourceware.org \
    --to=gftg@sourceware.org \
    --cc=glibc-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).