From: Peter Allworth <linsol@zeta.org.au>
To: Pavel Roskin <pavel_roskin@geocities.com>
Cc: Graham Stoney <greyham@research.canon.com.au>,
linuxppc-embedded@lists.linuxppc.org
Subject: Re: Best compiler/flags combination
Date: Tue, 01 Feb 2000 10:10:02 +1100 [thread overview]
Message-ID: <3896164A.16417EC2@zeta.org.au> (raw)
In-Reply-To: Pine.LNX.4.21.0001302322580.774-100000@localhost.localdomain
Pavel Roskin wrote:
>
<snip>
> You did not mention flags. Maybe my results will be of some interest. I'm
> using egcs-1.1.2 native for PowerMAC
>
> -O2 bad code almost everywhere (libcrypt, depmod, bash)
> -Os bad code in tinylogin
> -Os -fno-inline good code (not extensively tested),
> but it doesn't look like a clean solution
> -O2 -mcpu=860 -mmultiple -mstrings -mhard-float
> good code so far, but libm cannot be compiled
> (internal error in the compiler)
Pavel,
I believe I have found the cause of the "internal error" in the compiler.
The source code of the compiler includes a file:
egcs-1.1.2/gcc/config/rs6000/rs6000.c
that defines a routine called "rs6000_override_options" which for -mcpu=860
will FORCE soft-float, irrespective of your command line flags.
(I think it's particularly thoughtful the way it doesn't tell you it's
doing this. ;)
By looking through the available list of cpu types, I've found an old
one that results in the compiler using the correct set of internal flags
to generate code for an MPC core with hardware (or emulated) floating point.
It's: -mcpu=505
With this flag I've been able to successfully compile and use glibc-2.1.1
on my Rev C iMac. I think the same code should run native on the iMac but
I haven't tried it.
> Probably I'll still have to use
> -O2 -mcpu=860 -mmultiple -mstrings -mhard-float
>
> Or should I understand your recommendation so that you don't specify -mcpu
> and gcc still produces code running on embedded systems?
As far as I can tell, the only problem with using the compiler "as-is"
would be that the compiler's idea of how long each instruction takes
would be wrong in some cases and so the resulting code would be suboptimal.
'Hope that all helps,
PeterA.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
prev parent reply other threads:[~2000-01-31 23:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-01-28 20:06 Best compiler/flags combination Pavel Roskin
2000-01-30 23:21 ` Graham Stoney
2000-01-31 4:55 ` Pavel Roskin
2000-01-31 12:58 ` Marcus Sundberg
2000-01-31 23:10 ` Peter Allworth [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=3896164A.16417EC2@zeta.org.au \
--to=linsol@zeta.org.au \
--cc=greyham@research.canon.com.au \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=pavel_roskin@geocities.com \
/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).