[Bug math/23822] New: ia64 static libm.a is missing exp2f, log2f and powf symbols

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] New: ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

            Bug ID: 23822
           Summary: ia64 static libm.a is missing exp2f, log2f and powf
                    symbols
           Product: glibc
           Version: 2.27
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: nszabolcs at gmail dot com
  Target Milestone: ---

the following commits which introduced symbol versions
for exp2f, log2f and powf accidentally removed the
symbols in the !SHARED case on itanium:

f5f0f5265162fe6f4f238abcd3086985f7c38d6d
New expf and exp2f version without SVID compat wrapper

72d3d281080be9f674982067d72874fd6cdb4b64
New symbol version for logf, log2f and powf without SVID compat

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

Szabolcs Nagy <nszabolcs at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |ia64

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

Andreas Schwab <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|ia64                        |
               Host|                            |ia64-*-*

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

Szabolcs Nagy <nsz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nsz at gcc dot gnu.org
           Assignee|unassigned at sourceware dot org   |nsz at gcc dot gnu.org

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  ba5b14c7613980dfefcad6b6e88f913e5f596c59 (commit)
      from  fe61f17cfc18f17befca3280e828bb40e8c772b0 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ba5b14c7613980dfefcad6b6e88f913e5f596c59

commit ba5b14c7613980dfefcad6b6e88f913e5f596c59
Author: Szabolcs Nagy <[hidden email]>
Date:   Fri Oct 26 14:39:42 2018 +0100

    i64: fix missing exp2f, log2f and powf symbols in libm.a [BZ #23822]

    When new symbol versions were introduced without SVID compatible
    error handling the exp2f, log2f and powf symbols were accidentally
    removed from the ia64 lim.a.  The regression was introduced by
    the commits

    f5f0f5265162fe6f4f238abcd3086985f7c38d6d
    New expf and exp2f version without SVID compat wrapper

    72d3d281080be9f674982067d72874fd6cdb4b64
    New symbol version for logf, log2f and powf without SVID compat

    With WEAK_LIBM_ENTRY(foo), there is a hidden __foo and weak foo
    symbol definition in both SHARED and !SHARED build.

        [BZ #23822]
        * sysdeps/ia64/fpu/e_exp2f.S (exp2f): Use WEAK_LIBM_ENTRY.
        * sysdeps/ia64/fpu/e_log2f.S (log2f): Likewise.
        * sysdeps/ia64/fpu/e_exp2f.S (powf): Likewise.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                  |    7 +++++++
 sysdeps/ia64/fpu/e_exp2f.S |    6 +++---
 sysdeps/ia64/fpu/e_log2f.S |    6 +++---
 sysdeps/ia64/fpu/e_powf.S  |    6 +++---
 4 files changed, 16 insertions(+), 9 deletions(-)

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.28/master has been created
        at  5256ffc51e4188a70fa0173cb6b6c94adde03fcb (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5256ffc51e4188a70fa0173cb6b6c94adde03fcb

commit 5256ffc51e4188a70fa0173cb6b6c94adde03fcb
Author: Szabolcs Nagy <[hidden email]>
Date:   Fri Oct 26 14:39:42 2018 +0100

    i64: fix missing exp2f, log2f and powf symbols in libm.a [BZ #23822]

    When new symbol versions were introduced without SVID compatible
    error handling the exp2f, log2f and powf symbols were accidentally
    removed from the ia64 lim.a.  The regression was introduced by
    the commits

    f5f0f5265162fe6f4f238abcd3086985f7c38d6d
    New expf and exp2f version without SVID compat wrapper

    72d3d281080be9f674982067d72874fd6cdb4b64
    New symbol version for logf, log2f and powf without SVID compat

    With WEAK_LIBM_ENTRY(foo), there is a hidden __foo and weak foo
    symbol definition in both SHARED and !SHARED build.

        [BZ #23822]
        * sysdeps/ia64/fpu/e_exp2f.S (exp2f): Use WEAK_LIBM_ENTRY.
        * sysdeps/ia64/fpu/e_log2f.S (log2f): Likewise.
        * sysdeps/ia64/fpu/e_exp2f.S (powf): Likewise.

    (cherry picked from commit ba5b14c7613980dfefcad6b6e88f913e5f596c59)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=aff9b377121f9cfabe5d45f3226acf99c73928a7

commit aff9b377121f9cfabe5d45f3226acf99c73928a7
Author: Florian Weimer <[hidden email]>
Date:   Fri Oct 26 09:19:40 2018 +0200

    conform: XFAIL siginfo_t si_band test on sparc64

    We can use long int on sparcv9, but on sparc64, we must match the int
    type used by the kernel (and not long int, as in POSIX).

    (cherry picked from commit 7c5e34d7f1b8f8f5acd94c2b885ae13b85414dcd)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=69d1e73d99c6ad3f65fc16b6325d6ae289950d03

commit 69d1e73d99c6ad3f65fc16b6325d6ae289950d03
Author: Ilya Yu. Malakhov <[hidden email]>
Date:   Mon Oct 22 13:03:57 2018 +0200

    signal: Use correct type for si_band in siginfo_t [BZ #23562]

    (cherry picked from commit f997b4be18f7e57d757d39e42f7715db26528aa0)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=314e181dc90cb290942d8b2b57823306ae956696

commit 314e181dc90cb290942d8b2b57823306ae956696
Author: Stefan Liebler <[hidden email]>
Date:   Wed Oct 17 12:23:04 2018 +0200

    Fix race in pthread_mutex_lock while promoting to PTHREAD_MUTEX_ELISION_NP
[BZ #23275]

    The race leads either to pthread_mutex_destroy returning EBUSY
    or triggering an assertion (See description in bugzilla).

    This patch is fixing the race by ensuring that the elision path is
    used in all cases if elision is enabled by the GLIBC_TUNABLES framework.

    The __kind variable in struct __pthread_mutex_s is accessed concurrently.
    Therefore we are now using the atomic macros.

    The new testcase tst-mutex10 is triggering the race on s390x and intel.
    Presumably also on power, but I don't have access to a power machine
    with lock-elision. At least the code for power is the same as on the other
    two architectures.

    ChangeLog:

        [BZ #23275]
        * nptl/tst-mutex10.c: New File.
        * nptl/Makefile (tests): Add tst-mutex10.
        (tst-mutex10-ENV): New variable.
        * sysdeps/unix/sysv/linux/s390/force-elision.h: (FORCE_ELISION):
        Ensure that elision path is used if elision is available.
        * sysdeps/unix/sysv/linux/powerpc/force-elision.h (FORCE_ELISION):
        Likewise.
        * sysdeps/unix/sysv/linux/x86/force-elision.h: (FORCE_ELISION):
        Likewise.
        * nptl/pthreadP.h (PTHREAD_MUTEX_TYPE, PTHREAD_MUTEX_TYPE_ELISION)
        (PTHREAD_MUTEX_PSHARED): Use atomic_load_relaxed.
        * nptl/pthread_mutex_consistent.c (pthread_mutex_consistent): Likewise.
        * nptl/pthread_mutex_getprioceiling.c (pthread_mutex_getprioceiling):
        Likewise.
        * nptl/pthread_mutex_lock.c (__pthread_mutex_lock_full)
        (__pthread_mutex_cond_lock_adjust): Likewise.
        * nptl/pthread_mutex_setprioceiling.c (pthread_mutex_setprioceiling):
        Likewise.
        * nptl/pthread_mutex_timedlock.c (__pthread_mutex_timedlock): Likewise.
        * nptl/pthread_mutex_trylock.c (__pthread_mutex_trylock): Likewise.
        * nptl/pthread_mutex_unlock.c (__pthread_mutex_unlock_full): Likewise.
        * sysdeps/nptl/bits/thread-shared-types.h (struct __pthread_mutex_s):
        Add comments.
        * nptl/pthread_mutex_destroy.c (__pthread_mutex_destroy):
        Use atomic_load_relaxed and atomic_store_relaxed.
        * nptl/pthread_mutex_init.c (__pthread_mutex_init):
        Use atomic_store_relaxed.

    (cherry picked from commit 403b4feb22dcbc85ace72a361d2a951380372471)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5a74abda201907cafbdabd1debf98890313ff71e

commit 5a74abda201907cafbdabd1debf98890313ff71e
Author: H.J. Lu <[hidden email]>
Date:   Fri Sep 28 13:31:19 2018 -0700

    i386: Use _dl_runtime_[resolve|profile]_shstk for SHSTK [BZ #23716]

    When elf_machine_runtime_setup is called to set up resolver, it should
    use _dl_runtime_resolve_shstk or _dl_runtime_profile_shstk if SHSTK is
    enabled by kernel.

    Tested on i686 with and without --enable-cet as well as on CET emulator
    with --enable-cet.

        [BZ #23716]
        * sysdeps/i386/dl-cet.c: Removed.
        * sysdeps/i386/dl-machine.h (_dl_runtime_resolve_shstk): New
        prototype.
        (_dl_runtime_profile_shstk): Likewise.
        (elf_machine_runtime_setup): Use _dl_runtime_profile_shstk or
        _dl_runtime_resolve_shstk if SHSTK is enabled by kernel.

    Signed-off-by: H.J. Lu <[hidden email]>

    (cherry picked from commit 7b1f9406761331cf35fe521fbdb592beecf68a2c)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5473739a7b44f27965b70d1acf480f5f72603e78

commit 5473739a7b44f27965b70d1acf480f5f72603e78
Author: Rafal Luzynski <[hidden email]>
Date:   Tue Oct 2 23:34:18 2018 +0200

    kl_GL: Fix spelling of Sunday, should be "sapaat" (bug 20209).

    Although CLDR says otherwise, it is confirmed by Oqaasileriffik, the
    official Greenlandic language regulator, that this change is correct.

        [BZ #20209]
        * localedata/locales/kl_GL: (abday): Fix spelling of Sun (Sunday),
        should be "sap" rather than "sab".
        (day): Fix spelling of Sunday, should be "sapaat" rather than
        "sabaat".

    (cherry picked from commit dae3ed958c3d0090838e49ff4f78c201262b1cf0)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=044c96f0d5595aeb0bb4e79355081c5a7f4faca5

commit 044c96f0d5595aeb0bb4e79355081c5a7f4faca5
Author: Adhemerval Zanella <[hidden email]>
Date:   Wed Aug 29 16:36:44 2018 -0300

    Fix misreported errno on preadv2/pwritev2 (BZ#23579)

    The fallback code of Linux wrapper for preadv2/pwritev2 executes
    regardless of the errno code for preadv2, instead of the case where
    the syscall is not supported.

    This fixes it by calling the fallback code iff errno is ENOSYS. The
    patch also adds tests for both invalid file descriptor and invalid
    iov_len and vector count.

    The only discrepancy between preadv2 and fallback code regarding
    error reporting is when an invalid flags are used.  The fallback code
    bails out earlier with ENOTSUP instead of EINVAL/EBADF when the syscall
    is used.

    Checked on x86_64-linux-gnu on a 4.4.0 and 4.15.0 kernel.

        [BZ #23579]
        * misc/tst-preadvwritev2-common.c (do_test_with_invalid_fd): New
        test.
        * misc/tst-preadvwritev2.c, misc/tst-preadvwritev64v2.c (do_test):
        Call do_test_with_invalid_fd.
        * sysdeps/unix/sysv/linux/preadv2.c (preadv2): Use fallback code iff
        errno is ENOSYS.
        * sysdeps/unix/sysv/linux/preadv64v2.c (preadv64v2): Likewise.
        * sysdeps/unix/sysv/linux/pwritev2.c (pwritev2): Likewise.
        * sysdeps/unix/sysv/linux/pwritev64v2.c (pwritev64v2): Likewise.

    (cherry picked from commit 7a16bdbb9ff4122af0a28dc20996c95352011fdd)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=3a67c72c1512f778304a5644dea2fcf5bdece274

commit 3a67c72c1512f778304a5644dea2fcf5bdece274
Author: Andreas Schwab <[hidden email]>
Date:   Thu Sep 27 12:37:06 2018 +0200

    Fix stack overflow in tst-setcontext9 (bug 23717)

    The function f1a, executed on a stack of size 32k, allocates an object of
    size 32k on the stack.  Make the stack variables static to reduce
    excessive stack usage.

    (cherry picked from commit f841c97e515a1673485a2b12b3c280073d737890)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2339d6a55eb7a7e040ae888e906adc49eeb59eab

commit 2339d6a55eb7a7e040ae888e906adc49eeb59eab
Author: H.J. Lu <[hidden email]>
Date:   Wed Sep 12 08:40:59 2018 -0700

    i386: Use ENTRY and END in start.S [BZ #23606]

    Wrapping the _start function with ENTRY and END to insert ENDBR32 at
    function entry when CET is enabled.  Since _start now includes CFI,
    without "cfi_undefined (eip)", unwinder may not terminate at _start
    and we will get

    Program received signal SIGSEGV, Segmentation fault.
    0xf7dc661e in ?? () from /lib/libgcc_s.so.1
    Missing separate debuginfos, use: dnf debuginfo-install
libgcc-8.2.1-3.0.fc28.i686
    (gdb) bt
     #0  0xf7dc661e in ?? () from /lib/libgcc_s.so.1
     #1  0xf7dc7c18 in _Unwind_Backtrace () from /lib/libgcc_s.so.1
     #2  0xf7f0d809 in __GI___backtrace (array=array@entry=0xffffc7d0,
        size=size@entry=20) at ../sysdeps/i386/backtrace.c:127
     #3  0x08049254 in compare (p1=p1@entry=0xffffcad0, p2=p2@entry=0xffffcad4)
        at backtrace-tst.c:12
     #4  0xf7e2a28c in msort_with_tmp (p=p@entry=0xffffca5c,
b=b@entry=0xffffcad0,
        n=n@entry=2) at msort.c:65
     #5  0xf7e29f64 in msort_with_tmp (n=2, b=0xffffcad0, p=0xffffca5c)
        at msort.c:53
     #6  msort_with_tmp (p=p@entry=0xffffca5c, b=b@entry=0xffffcad0,
n=n@entry=5)
        at msort.c:53
     #7  0xf7e29f64 in msort_with_tmp (n=5, b=0xffffcad0, p=0xffffca5c)
        at msort.c:53
     #8  msort_with_tmp (p=p@entry=0xffffca5c, b=b@entry=0xffffcad0,
n=n@entry=10)
        at msort.c:53
     #9  0xf7e29f64 in msort_with_tmp (n=10, b=0xffffcad0, p=0xffffca5c)
        at msort.c:53
     #10 msort_with_tmp (p=p@entry=0xffffca5c, b=b@entry=0xffffcad0,
n=n@entry=20)
        at msort.c:53
     #11 0xf7e2a5b6 in msort_with_tmp (n=20, b=0xffffcad0, p=0xffffca5c)
        at msort.c:297
     #12 __GI___qsort_r (b=b@entry=0xffffcad0, n=n@entry=20, s=s@entry=4,
        cmp=cmp@entry=0x8049230 <compare>, arg=arg@entry=0x0) at msort.c:297
     #13 0xf7e2a84d in __GI_qsort (b=b@entry=0xffffcad0, n=n@entry=20,
s=s@entry=4,
        cmp=cmp@entry=0x8049230 <compare>) at msort.c:308
     #14 0x080490f6 in main (argc=2, argv=0xffffcbd4) at backtrace-tst.c:39

    FAIL: debug/backtrace-tst

        [BZ #23606]
        * sysdeps/i386/start.S: Include <sysdep.h>
        (_start): Use ENTRY/END to insert ENDBR32 at entry when CET is
        enabled.  Add cfi_undefined (eip).

    Signed-off-by: H.J. Lu <[hidden email]>

    (cherry picked from commit 5a274db4ea363d6b0b92933f085a92daaf1be2f2)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0ef2f4400c06927af34c515555f68840a70ba409

commit 0ef2f4400c06927af34c515555f68840a70ba409
Author: Wilco Dijkstra <[hidden email]>
Date:   Wed Sep 19 16:50:18 2018 +0100

    Fix strstr bug with huge needles (bug 23637)

    The generic strstr in GLIBC 2.28 fails to match huge needles.  The
optimized
    AVAILABLE macro reads ahead a large fixed amount to reduce the overhead of
    repeatedly checking for the end of the string.  However if the needle
length
    is larger than this, two_way_long_needle may confuse this as meaning the
end
    of the string and return NULL.  This is fixed by adding the needle length
to
    the amount to read ahead.

        [BZ #23637]
        * string/test-strstr.c (pr23637): New function.
        (test_main): Add tests with longer needles.
        * string/strcasestr.c (AVAILABLE): Fix readahead distance.
        * string/strstr.c (AVAILABLE): Likewise.

        (cherry picked from commit 83a552b0bb9fc2a5e80a0ab3723c0a80ce1db9f2)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a55e109709af55e6ed67d3f9536cac5d929c982e

commit a55e109709af55e6ed67d3f9536cac5d929c982e
Author: Carlos O'Donell <[hidden email]>
Date:   Wed Sep 5 01:16:42 2018 -0400

    Fix tst-setcontext9 for optimized small stacks.

    If the compiler reduces the stack usage in function f1 before calling
    into function f2, then when we swapcontext back to f1 and continue
    execution we may overwrite registers that were spilled to the stack
    while f2 was executing.  Later when we return to f2 the corrupt
    registers will be reloaded from the stack and the test will crash.  This
    was most commonly observed on i686 with __x86.get_pc_thunk.dx and
    needing to save and restore $edx.  Overall i686 has few registers and
    the spilling to the stack is bound to happen, therefore the solution to
    making this test robust is to split function f1 into two parts f1a and
    f1b, and allocate f1b it's own stack such that subsequent execution does
    not overwrite the stack in use by function f2.

    Tested on i686 and x86_64.

    Signed-off-by: Carlos O'Donell <[hidden email]>
    (cherry picked from commit 791b350dc725545e3f9b5db0f97ebdbc60c9735f)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=307d04334d516bb180f484a2b283f97310bfee66

commit 307d04334d516bb180f484a2b283f97310bfee66
Author: Florian Weimer <[hidden email]>
Date:   Thu Sep 20 12:03:01 2018 +0200

    misc: New test misc/tst-gethostid

    The empty /etc/hosts file used to trigger bug 23679.

    (cherry picked from commit db9a8ad4ff3fc58e3773a9a4d0cabe3c1bc9c94c)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e7d22db29cfdd2f1fb97a70a76fa53d151569945

commit e7d22db29cfdd2f1fb97a70a76fa53d151569945
Author: Mingli Yu <[hidden email]>
Date:   Thu Sep 20 12:41:13 2018 +0200

    Linux gethostid: Check for NULL value from gethostbyname_r [BZ #23679]

    A NULL value can happen with certain gethostbyname_r failures.

    (cherry picked from commit 1214ba06e6771acb953a190091b0f6055c64fd25)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1fe2b9ca8a50aaa789d72944b5a91f1d35337adc

commit 1fe2b9ca8a50aaa789d72944b5a91f1d35337adc
Author: Stefan Liebler <[hidden email]>
Date:   Thu Sep 6 14:27:03 2018 +0200

    Fix segfault in maybe_script_execute.

    If glibc is built with gcc 8 and -march=z900,
    the testcase posix/tst-spawn4-compat crashes with a segfault.

    In function maybe_script_execute, the new_argv array is dynamically
    initialized on stack with (argc + 1) elements.
    The function wants to add _PATH_BSHELL as the first argument
    and writes out of bounds of new_argv.
    There is an off-by-one because maybe_script_execute fails to count
    the terminating NULL when sizing new_argv.

    ChangeLog:

        * sysdeps/unix/sysv/linux/spawni.c (maybe_script_execute):
        Increment size of new_argv by one.

    (cherry picked from commit 28669f86f6780a18daca264f32d66b1428c9c6f1)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0b79004569e5ce1669136b8c41564c3809730f15

commit 0b79004569e5ce1669136b8c41564c3809730f15
Author: Florian Weimer <[hidden email]>
Date:   Tue Aug 28 12:57:46 2018 +0200

    regex: Add test tst-regcomp-truncated [BZ #23578]

    (cherry picked from commit 761404b74d9853ce1608195e24f25b78a910591a)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=58559f14437d2aa71753a29fed435efa06aa4576

commit 58559f14437d2aa71753a29fed435efa06aa4576
Author: Paul Eggert <[hidden email]>
Date:   Tue Aug 28 21:54:28 2018 +0200

    regex: fix uninitialized memory access

    I introduced this bug into gnulib in commit
    8335a4d6c7b4448cd0bcb6d0bebf1d456bcfdb17 dated 2006-04-10;
    eventually it was merged into glibc.  The bug was found by
    project-repo <[hidden email]> and reported here:
    https://lists.gnu.org/r/sed-devel/2018-08/msg00017.html
    Diagnosis and draft fix reported by Assaf Gordon here:
    https://lists.gnu.org/r/bug-gnulib/2018-08/msg00071.html
    https://lists.gnu.org/r/bug-gnulib/2018-08/msg00142.html
    * posix/regex_internal.c (build_wcs_upper_buffer):
    Fix bug when mbrtowc returns 0.

    (cherry picked from commit bc680b336971305cb39896b30d72dc7101b62242)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=aa8a3e4cdef20c50cb20f008864fff05cbfbdf29

commit aa8a3e4cdef20c50cb20f008864fff05cbfbdf29
Author: Martin Kuchta <[hidden email]>
Date:   Mon Aug 27 18:54:46 2018 +0200

    pthread_cond_broadcast: Fix waiters-after-spinning case [BZ #23538]

    (cherry picked from commit 99ea93ca31795469d2a1f1570f17a5c39c2eb7e2)

-----------------------------------------------------------------------

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, b2.27 has been created
        at  5cd5309d910b0fcdeb5d7e734afb535d0231ba2c (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5cd5309d910b0fcdeb5d7e734afb535d0231ba2c

commit 5cd5309d910b0fcdeb5d7e734afb535d0231ba2c
Author: Szabolcs Nagy <[hidden email]>
Date:   Fri Oct 26 14:39:42 2018 +0100

    i64: fix missing exp2f, log2f and powf symbols in libm.a [BZ #23822]

    When new symbol versions were introduced without SVID compatible
    error handling the exp2f, log2f and powf symbols were accidentally
    removed from the ia64 lim.a.  The regression was introduced by
    the commits

    f5f0f5265162fe6f4f238abcd3086985f7c38d6d
    New expf and exp2f version without SVID compat wrapper

    72d3d281080be9f674982067d72874fd6cdb4b64
    New symbol version for logf, log2f and powf without SVID compat

    With WEAK_LIBM_ENTRY(foo), there is a hidden __foo and weak foo
    symbol definition in both SHARED and !SHARED build.

        [BZ #23822]
        * sysdeps/ia64/fpu/e_exp2f.S (exp2f): Use WEAK_LIBM_ENTRY.
        * sysdeps/ia64/fpu/e_log2f.S (log2f): Likewise.
        * sysdeps/ia64/fpu/e_exp2f.S (powf): Likewise.

    (cherry picked from commit ba5b14c7613980dfefcad6b6e88f913e5f596c59)

-----------------------------------------------------------------------

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, b2.27 has been deleted
       was  5cd5309d910b0fcdeb5d7e734afb535d0231ba2c

- Log -----------------------------------------------------------------
5cd5309d910b0fcdeb5d7e734afb535d0231ba2c i64: fix missing exp2f, log2f and powf
symbols in libm.a [BZ #23822]
-----------------------------------------------------------------------

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug math/23822] ia64 static libm.a is missing exp2f, log2f and powf symbols

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23822

Szabolcs Nagy <nsz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.29

--- Comment #5 from Szabolcs Nagy <nsz at gcc dot gnu.org> ---
fixed for 2.29 (and on 2.27, 2.28 release branches)

--
You are receiving this mail because:
You are on the CC list for the bug.