From: Jim Wilson <wilson@specifixinc.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: chris@scary.beasts.org, akpm@osdl.org,
linux-kernel@vger.kernel.org, gcc@gcc.gnu.org
Subject: Re: [PATCH] Add 64-bit get_user and __get_user for i386
Date: Tue, 20 Apr 2004 16:21:13 -0700 [thread overview]
Message-ID: <4085B069.5070709@specifixinc.com> (raw)
In-Reply-To: 20040420020922.GA18348@mail.shareable.org
Jamie Lokier wrote:
> However that doesn't seem to be a problem. Experiments show that an
> __asm__ which outputs to a char or short type is _always_
> sign-extended or zero-extended if needed by the compiler, on various
> i386 subtargets. The compiler doesn't assume anything about the
> output higher bits from an __asm__.
>
> --> GCC experts, can you confirm the above property please?
expand_asm_operands in stmt.c checks for promoted variables, and if it
sees one, it will generate a temporary with the unpromoted size to
replace it in the asm, and then copy the temporary to the promoted
variable after the asm, ensuring that the extension happens after the asm.
> (Function calls are similar: GCC won't assume anything about the
> higher bits of the result received from a function, although it always
> promotes the result before returning a value. Odd combination).
I think this is a minor gcc bug. We have been promoting char/short
return values since the gcc-1.x days. This promotion occurs regardless
of whether the target asks for return values to be promoted. This
promotion happens in start_function in c-decl.c. Perhaps this is a left
over from the K&R C days, as I don't see anything in the C89 standard
that requires this. Changing this now might break ports that require
the promotion, but were not explicitly asking for it, so changing this
might be tricky. I'd suggest opening a gcc bugzilla bug report if we
really care about this.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
prev parent reply other threads:[~2004-04-20 23:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-18 0:28 Nasty 2.6 sendfile() bug / regression; affects vsftpd chris
2004-04-18 3:12 ` Linus Torvalds
2004-04-18 13:49 ` chris
2004-04-19 0:46 ` Jamie Lokier
2004-04-19 5:28 ` Linus Torvalds
2004-04-19 9:44 ` [PATCH] Add 64-bit get_user and __get_user for i386 Jamie Lokier
2004-04-19 10:14 ` Jamie Lokier
2004-04-19 10:17 ` [PATCH] Use get_user for 64-bit read in sendfile64 Jamie Lokier
2004-04-19 10:36 ` Jamie Lokier
2004-04-19 14:56 ` [PATCH] Add 64-bit get_user and __get_user for i386 Linus Torvalds
[not found] ` <20040420020922.GA18348@mail.shareable.org>
[not found] ` <Pine.LNX.4.58.0404191945490.29941@ppc970.osdl.org>
2004-04-20 17:41 ` Jamie Lokier
2004-04-21 1:15 ` Linus Torvalds
2004-04-20 23:21 ` Jim Wilson [this message]
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=4085B069.5070709@specifixinc.com \
--to=wilson@specifixinc.com \
--cc=akpm@osdl.org \
--cc=chris@scary.beasts.org \
--cc=gcc@gcc.gnu.org \
--cc=jamie@shareable.org \
--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