[Bug libc/15605] New: gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[Bug libc/15605] New: gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[azanella at linux dot vnet.ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15605

            Bug ID: 15605
           Summary: gcc-4.8 + tree-loop-distribute-patterns breaks is
                    unsafe for GLIBC
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: azanella at linux dot vnet.ibm.com
                CC: drepper.fsp at gmail dot com

GCC 4.8 now enables -ftree-loop-distribute-patterns at -O3 by default. This
optimization option may transform loops into memset/memmove call
(http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Optimize-Options.html#Optimize-Options)
and without proper handling this may generate unexpected PLT calls on GLIBC
builds.

Carlos O'Donell raised his concerns
(http://sourceware.org/ml/libc-alpha/2013-02/msg00299.html), there is also
reports on recursive calls building the default memset/memmove implementations
(http://sourceware.org/ml/libc-alpha/2013-05/msg00731.html), and tt was
observed some PLT issues on PPC32/PPC64 builds as well
(http://sourceware.org/ml/libc-alpha/2013-04/msg00131.html).

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[azanella at linux dot vnet.ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15605

Adhemerval Zanella Netto <azanella at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |azanella at linux dot vnet.ibm.com

--- Comment #1 from Adhemerval Zanella Netto <azanella at linux dot vnet.ibm.com> ---
The spurious memset/memmove PLT generations was fixed by commit
6a97b62a5b4f18aea849d6f4d8de58d1469d2521.

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[tschwinge at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15605

Thomas Schwinge <tschwinge at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tschwinge at sourceware dot org
           Assignee|unassigned at sourceware dot org   |azanella at linux dot vnet.ibm.com

--- Comment #2 from Thomas Schwinge <tschwinge at sourceware dot org> ---
This commit breaks the build in --disable-hidden-plt configurations, where
there are no __GI_memmove and __GI_memset symbols.  What to do in this case?

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15605

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 10 Oct 2013, tschwinge at sourceware dot org wrote:

> This commit breaks the build in --disable-hidden-plt configurations, where
> there are no __GI_memmove and __GI_memset symbols.  What to do in this case?

Remove the undocumented --disable-hidden-plt configure option?  What 
purpose does it serve?

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[tschwinge at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15605

Thomas Schwinge <tschwinge at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roland at gnu dot org,
                   |                            |samuel.thibault@ens-lyon.or
                   |                            |g

--- Comment #4 from Thomas Schwinge <tschwinge at sourceware dot org> ---
In sysdeps/mach/hurd/configure (configure.in), the Hurd hard-codes NO_HIDDEN
citing »the need for PLT calls in ld.so«.  I think I have some rough idea what
this is about (as soon as available, use the "full" implementations of
functions in libc when invoked from ld.so instead of the "reduced"
implementations residing in ld.so itself?), but will have to look into it in
more detail, or perhaps Roland can clarify?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19738-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Oct 10 16:45:47 2013
Return-Path: <glibc-bugs-return-19738-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 7300 invoked by alias); 10 Oct 2013 16:45:47 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 7266 invoked by uid 48); 10 Oct 2013 16:45:44 -0000
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/13140] no-break space as thousands_sep causes inconsistent output
Date: Thu, 10 Oct 2013 16:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.18
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bugdal at aerifal dot cx
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-13140-131-eyrAW3rnRk@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13140-131@http.sourceware.org/bugzilla/>
References: <bug-13140-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-10/txt/msg00097.txt.bz2
Content-length: 1425

https://sourceware.org/bugzilla/show_bug.cgi?id\x13140

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
The "legwork" needed is on the part of the application, not glibc. glibc is
doing exactly the right thing here; non-wide printf-family functions' field
widths are all in terms of bytes, not characters. Even if there were not a
standard (ISO C) dictating the current behavior, there is no flexibility to
change this, because for some uses of sprintf may rely on width being in bytes
to avoid buffer overflow.

If you want field widths in characters, you have to use the wide printf-family
functions. This is problematic of course because stdio streams have an
orientation (byte or wide) and you cannot mix byte and wide functions on them.
So, for practical purposes, you probably have to use swprintf or
open_wmemstream and fwprintf, then print the resulting string using fprintf
with the %ls specifier.

Simply avoiding thousands separators at the printf level is probably an easier
solution.

In any case, I don't think there's anything glibc can do to make this easier.

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[roland at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15605

--- Comment #5 from Roland McGrath <roland at gnu dot org> ---
Yes, in the Hurd it's crucial that calls like __mmap be the libc ones instead
of the rtld-local ones after the bootstrap phase, when the dynamic linker is
being used for dlopen and the like.  Probably the right thing to do is not to
disable PLT avoidance altogether, but to have the rtld_hidden_* macros disabled
in the Hurd configuration.  (Actually it would really be ideal just to select
the exact set that should use PLT calls for the Hurd.  But we could start with
disabling it for rtld altogether and then seeing how many PLT entries we get.)

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[cvs-commit at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15605

--- Comment #6 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  4959e284ca9c4ee749e1fe4b95ce682dee110a27 (commit)
      from  d98720e07f67fbeec00f9e1347840404240d3c48 (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=4959e284ca9c4ee749e1fe4b95ce682dee110a27

commit 4959e284ca9c4ee749e1fe4b95ce682dee110a27
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Jan 20 11:05:22 2014 -0800

    Include generic symbol-hacks.h for x32

    In BZ #15605 fix with addding memset/memmove alias in symbol-hacks.h,
    x32 symbol-hacks.h change was missing.  Fixed by including
    <sysdeps/generic/symbol-hacks.h> in x32 symbol-hacks.h.

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

Summary of changes:
 ChangeLog                         |    5 +++++
 sysdeps/x86_64/x32/symbol-hacks.h |    2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[cvs-commit at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15605

--- Comment #7 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.18/master has been updated
       via  2a8396b962b8c57a2581023b62766a3ac44c3ba4 (commit)
      from  0553c6642be2cdf6bac776fac5fd50164cb28709 (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=2a8396b962b8c57a2581023b62766a3ac44c3ba4

commit 2a8396b962b8c57a2581023b62766a3ac44c3ba4
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Jan 20 11:05:22 2014 -0800

    Include generic symbol-hacks.h for x32

    In BZ #15605 fix with addding memset/memmove alias in symbol-hacks.h,
    x32 symbol-hacks.h change was missing.  Fixed by including
    <sysdeps/generic/symbol-hacks.h> in x32 symbol-hacks.h.

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

Summary of changes:
 ChangeLog                         |    5 +++++
 sysdeps/x86_64/x32/symbol-hacks.h |    2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15605

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[philippe.gislard at morpho dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15605

philippe.gislard at morpho dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |philippe.gislard at morpho dot com

--- Comment #8 from philippe.gislard at morpho dot com ---
Hi,

I'm using gcc 4.9.1, and I have and issue when reimplementing memset that is
quite similar:
loop inside memset is transformed into recursive call to memset

I noticed that when compiling with -fno-tree-loop-distribute-patterns has no
impact but with -fno-tree-ch the issue disappear.
Can someone tell me if it is related to this bug and if possible, what's
happening exactly and if there is a better way to handle this ?

Thanks.

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

[Bug libc/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[philippe.gislard at morpho dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15605

--- Comment #9 from philippe.gislard at morpho dot com ---
(In reply to philippe.gislard from comment #8)
> Hi,
> 
> I'm using gcc 4.9.1, and I have and issue when reimplementing memset that is
> quite similar:
> loop inside memset is transformed into recursive call to memset
> 
> I noticed that when compiling with -fno-tree-loop-distribute-patterns has no
> impact but with -fno-tree-ch the issue disappear.
> Can someone tell me if it is related to this bug and if possible, what's
> happening exactly and if there is a better way to handle this ?
> 
> Thanks.

My bad: -fno-tree-loop-distribute-patterns DOES workaround this issue

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

[Bug build/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15605

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com
          Component|libc                        |build

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

[Bug hurd/15605] gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC

[rnewman at parasoft dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15605

Rich Newman <rnewman at parasoft dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rnewman at parasoft dot com

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