[Clfs-dev] EGLIBC x86 is special?

[Martin Ward]

On 12/07/13 18:14, Andrew Bradford wrote:
> On Fri, Jul 12, 2013, at 12:43 PM, William Harrington wrote:
>> On Jul 12, 2013, at 6:35 AM, Andrew Bradford wrote:
>>
>>> For x86 32 bit and x86 32 bit portion of multilib but not for any
>>> other
>>> arch including x86_64 there's the addition of:
>>>
>>> CFLAGS="-march=$(cut -d- -f1 <<< $CLFS_TARGET32) -mtune=generic -g -
>>> O2"
>> I can't find an archive of Greg's original post and the LFS mailing
>> list archive is still not available. But I'm sure it stemmed from this:
>>
>> http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg10910.html
> OK, but when setting -march= to i386, i486, or i686 isn't the goal to
> not support a processor that's older?  Isn't that the point of choosing
> your target?  If I'm choosing my triplet to be i686-pc-linux-gnu then
> don't I implicitly choose to not support running the code generated on
> an i386 machine?  Passing the -mtune=generic may not even do anything
> useful for 32 bit x86 any more, Linux doesn't even support i386 as an
> arch these days, since 3.8 (which is in the main book).  If you want to
> run on any processor newer than i386 you pick your triplet as
> i386-pc-linux-gnu and go from there.
>
> Plus, why is 32 bit x86 the only place that -g and -O2 are passed?  Do
> we really need those defined here?
> I know there's mention that -O3 causes issues sometimes but that was
> like 6+ years ago on much older gcc and glibc, let alone other software
> that would crash.
>
> I guess the true test is to just try and see what happens.  They just
> don't seem necessary to me.
> Thanks,
> Andrew
> _______________________________________________
> Clfs-dev mailing list
> Clfs-dev at lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
>
Hi

I've been running eglibc with -O3 for quite a while now and suffered no 
problems, however i'm a little more cautious with other packages usually 
-O2 -march=athlon64 -mtune=generic -fomit-frame-pointer -pipe, although 
-pipe causes a fair amount of test failures in the gcc test suite

the last build i did was -O2 -march=athlon64 -mtune=native 
-fomit-frame-pointer -pipe, again no problems on a full KDE desktop


Cheers

Martin