From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
To: Jakub Jelinek <jakub@redhat.com>
Cc: Andy Isaacson <adi@hexapodia.org>,
James Morris <jmorris@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4
Date: Sun, 01 Feb 2004 16:17:47 -0500 [thread overview]
Message-ID: <401D6CFB.2090501@tmr.com> (raw)
In-Reply-To: <20040130194921.GO31589@devserv.devel.redhat.com>
Jakub Jelinek wrote:
> On Fri, Jan 30, 2004 at 11:14:07AM -0600, Andy Isaacson wrote:
>
>>On Fri, Jan 30, 2004 at 11:35:20AM -0500, James Morris wrote:
>>
>>>- const u8 padding[64] = { 0x80, };
>>>+ static u8 padding[64] = { 0x80, };
>>
>>The RedHat bug suggests 'static const' as the appropriate replacement.
>>
>>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114610#c4
>>
>>Unfortunately that probably means an extra 64 bytes of text, rather than
>>the 10 or so bytes of instructions to do the memset and store. Ideally
>>padding[] would be allocated in BSS rather than text or the stack (and
>>initialized with { 0x80, } at runtime), but I guess you can't have
>>everything.
>
>
> Or you can use
> u8 padding[64] = { 0x80 };
> if you really want to initialize it at runtime and want to work around the
> compiler bug. It shouldn't be any less efficient than
> const u8 padding[64] = { 0x80 };
> since it is used just once, passed to non-inlined function.
I like this, as it avoids bloating the 64 bytes into the kernel.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2004-02-01 21:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-30 3:21 [CRYPTO]: Miscompiling sha256.c by gcc 3.2.3 and arch pentium3,4 R CHAN
2004-01-30 14:39 ` James Morris
2004-01-30 15:04 ` Dave Paris
2004-01-30 15:24 ` R Chan
2004-01-30 15:28 ` Jakub Jelinek
2004-01-30 16:35 ` James Morris
2004-01-30 17:14 ` Andy Isaacson
2004-01-30 19:49 ` Jakub Jelinek
2004-02-01 21:17 ` Bill Davidsen [this message]
2004-01-30 21:14 ` David S. Miller
2004-02-01 21:18 ` Bill Davidsen
2004-02-01 23:22 ` David S. Miller
2004-02-02 1:00 ` Linus Torvalds
2004-02-02 18:55 ` Bill Davidsen
2004-01-30 17:26 ` Jean-Luc Cooke
-- strict thread matches above, loose matches on Subject: below --
2004-01-30 15:43 Arnd Bergmann
2004-01-30 16:57 ` James Morris
2004-01-30 18:02 ` Randy.Dunlap
2004-01-30 18:35 ` James Morris
2004-01-30 18:53 ` James Morris
2004-02-02 4:08 linux
2004-02-05 19:40 ` Jean-Luc Cooke
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=401D6CFB.2090501@tmr.com \
--to=davidsen@tmr.com \
--cc=adi@hexapodia.org \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.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