linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] [RFC] arm: fix memset-related crashes caused by recent GCC (4.7.2) optimizations
Date: Tue, 12 Feb 2013 15:58:01 +0000	[thread overview]
Message-ID: <20130212155801.GQ17833@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20130212140008.GB4123@mudshark.cambridge.arm.com>

On Tue, Feb 12, 2013 at 02:00:08PM +0000, Will Deacon wrote:
> On Mon, Feb 11, 2013 at 07:42:25PM +0000, Ivan Djelic wrote:
> > On Mon, Feb 11, 2013 at 06:41:14PM +0000, Will Deacon wrote:
> > > On Sat, Feb 02, 2013 at 08:33:08AM +0000, Ivan Djelic wrote:
> > > > Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
> > > > assumptions about the implementation of memset and similar functions.
> > > > The current ARM optimized memset code does not return the value of
> > > > its first argument, as is usually expected from standard implementations.
> > > 
> > > How does GCC do this? By strcmping the function name and assuming that
> > > memset is a libc implementation?
> > > 
> > > If so, maybe passing something like -ffreestanding would make sense to turn
> > > this behaviour off in the compiler (otherwise we should also vet the rest of
> > > the standard string functions).
> > 
> > In theory, yes; but there is actually a short list of libc functions that GCC
> > always requires from the environment, even when -ffreestanding is used: memcpy,
> > memmove, memset and memcmp (see [1] below).
> 
> Interesting... the GCC documentation also states that ffreestanding implies
> fno-builtin, so memset and co shouldn't be targetted for this sort of
> optimisation by GCC. Have you observed this problem even when passing this
> option?

Rather than wondering whether we should be using -ffreestanding or not
(which, x86 people have strongly resisted) I suggest that we just fix
our memset() implementation to be compliant.

The reason it's not compliant is that I saw no reason for it to be
compliant back in the gcc 2.7.x days, and it's persisted like that for
the last 19-ish years.  If GCC is now making use of the return value,
then we need to fix that and undo the "optimization" in our string.h.

So let's just bite the bullet, make the asm memset() compliant, and
clean up string.h.

  reply	other threads:[~2013-02-12 15:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-02  8:33 [PATCH] [RFC] arm: fix memset-related crashes caused by recent GCC (4.7.2) optimizations Ivan Djelic
2013-02-09 11:05 ` Ivan Djelic
2013-02-09 14:48 ` Nicolas Pitre
2013-02-11 12:35   ` Ivan Djelic
2013-02-11 18:17 ` Ben Dooks
2013-02-11 21:39   ` Ivan Djelic
2013-02-11 18:41 ` Will Deacon
2013-02-11 19:42   ` Ivan Djelic
2013-02-12 14:00     ` Will Deacon
2013-02-12 15:58       ` Russell King - ARM Linux [this message]
2013-02-12 16:36         ` Will Deacon
2013-02-12 16:37           ` Russell King - ARM Linux
2013-02-12 16:38             ` Will Deacon
2013-03-05 13:50           ` Dirk Behme
2013-03-06  1:42             ` Will Deacon
2013-03-06  7:05               ` Dirk Behme
2013-03-06 17:11             ` Russell King - ARM Linux
2013-03-06 17:38               ` Dirk Behme
2013-03-06 18:43                 ` Russell King - ARM Linux

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=20130212155801.GQ17833@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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 NNTP newsgroup(s).