[gentoo-user] gcc 4.2 and Core 2 Duo

[gentoo-user] gcc 4.2 and Core 2 Duo

[Andrew Gaydenko]

I have noticed, the official portage tree has included gcc 4.2. Now for 
Core 2 Duo CPU (amd64 Gentoo arch) I use in make.conf file:

CFLAGS="-O2 -march=nocona -pipe"

gcc' changelog has this note:

--------------------
...
IA-32/x86-64

    * -mtune=generic can now be used to generate code running well on common x86 chips. 
      This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel
      Core 2.
    * -mtune=native and -march=native will produce code optimized for the host 
      architecture as detected using the cpuid instruction.
...
--------------------

The question is: must I replace '-march=nocona' with '-mtune=native and -march=native'?
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Kenneth Prugh]

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

Andrew Gaydenko wrote:
> I have noticed, the official portage tree has included gcc 4.2. Now for 
> Core 2 Duo CPU (amd64 Gentoo arch) I use in make.conf file:
> 
> CFLAGS="-O2 -march=nocona -pipe"
> 
> gcc' changelog has this note:
> 
> --------------------
> ...
> IA-32/x86-64
> 
>     * -mtune=generic can now be used to generate code running well on common x86 chips. 
>       This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel
>       Core 2.
>     * -mtune=native and -march=native will produce code optimized for the host 
>       architecture as detected using the cpuid instruction.
> ...
> --------------------
> 
> The question is: must I replace '-march=nocona' with '-mtune=native and -march=native'?

I have a Core2 Duo E6600 and use these CFLAGS with GCC 4.2:

CFLAGS="-Os -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx
-msse2 -msse3"

Native works fine here.
-- 
Kenneth Prugh - Ken69267
Gentoo AMD64 Arch Tester


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Andrew Gaydenko]

> > 
> > The question is: must I replace '-march=nocona' with '-mtune=native and -march=native'?
> 
> I have a Core2 Duo E6600 and use these CFLAGS with GCC 4.2:
> 
> CFLAGS="-Os -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx
> -msse2 -msse3"
> 
> Native works fine here.

Kenneth, thanks! I'll try your flags-string. I hope, there aren't any
resons to rebuld anything else after switching form 4.1.2 with curennt
flags to 4.2.0 with youe flags. Is it true?
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Kenneth Prugh]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

Andrew Gaydenko wrote:
>>> The question is: must I replace '-march=nocona' with '-mtune=native and -march=native'?
>> I have a Core2 Duo E6600 and use these CFLAGS with GCC 4.2:
>>
>> CFLAGS="-Os -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx
>> -msse2 -msse3"
>>
>> Native works fine here.
> 
> Kenneth, thanks! I'll try your flags-string. I hope, there aren't any
> resons to rebuld anything else after switching form 4.1.2 with curennt
> flags to 4.2.0 with youe flags. Is it true?

Personally I rebuilt everything on my system because I wanted everything
to be compiled under my shiny new toolchain. I accomplished it via this:

# emerge -eav system
# emerge -eav world

However, I don't believe you _have_ to rebuild. GCC 4.1 and 4.2 should
be binary compatible. I know that my GCC 4.1 LibTorrent works fine with
a GCC 4.2 built rtorrent, so I would like to say it should work fine.

-- 
Kenneth Prugh - Ken69267
Gentoo AMD64 Arch Tester


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

Kenneth Prugh wrote:
> Andrew Gaydenko wrote:
>   
>>>> The question is: must I replace '-march=nocona' with '-mtune=native and -march=native'?
>>>>         
>>> I have a Core2 Duo E6600 and use these CFLAGS with GCC 4.2:
>>>
>>> CFLAGS="-Os -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx
>>> -msse2 -msse3"
>>>
>>> Native works fine here.
>>>       
>> Kenneth, thanks! I'll try your flags-string. I hope, there aren't any
>> resons to rebuld anything else after switching form 4.1.2 with curennt
>> flags to 4.2.0 with youe flags. Is it true?
>>     
>
> Personally I rebuilt everything on my system because I wanted everything
> to be compiled under my shiny new toolchain. I accomplished it via this:
>
> # emerge -eav system
> # emerge -eav world
>
> However, I don't believe you _have_ to rebuild. GCC 4.1 and 4.2 should
> be binary compatible. I know that my GCC 4.1 LibTorrent works fine with
> a GCC 4.2 built rtorrent, so I would like to say it should work fine.
>
>   

I have a script that you can run that rebuilds everything only once and
it is a complete bottom to top rebuild.  No need to do a system then
world this way.  I got it off the forums and I have used it a few times
and it works very well for me so far.  If you want it, I can send it to
you off list or post it here for everybody that wants to save a copy.  I
have not used it in a while so I'm not sure if portage changes may have
made it not work anymore.

Let me know.

Dale

:-)  :-)

[-- Attachment #2: Type: text/html, Size: 2057 bytes --]

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Kenneth Prugh]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

Vladimir G. Ivanovic wrote:
<snip>
> You, of course, remembered to change your default compiler with
> 
>    # gcc-config <CHOST>-gnu-4.2.0
> 
> before recompiling everything. (Run 'gcc-config' with no arguments for
> more info.)
> 
> --- Vladimir

Yep. I've also seen that with march/mtune set to native, GCC 4.1.2 fails
to compile anything (here at least), so it's a bit hard to make that
mistake.

-- 
Kenneth Prugh - Ken69267
Gentoo AMD64 Arch Tester


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Vladimir G. Ivanovic]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kenneth Prugh wrote:
> Vladimir G. Ivanovic wrote:
> <snip>
>> You, of course, remembered to change your default compiler with
>>
>>    # gcc-config <CHOST>-gnu-4.2.0
>>
>> before recompiling everything. (Run 'gcc-config' with no arguments for
>> more info.)
>>
>> --- Vladimir
> 
> Yep. I've also seen that with march/mtune set to native, GCC 4.1.2 fails
> to compile anything (here at least), so it's a bit hard to make that
> mistake.
> 

Duh. I should have realized that native had no chance of working on
any version prior to 4.2.0 and so my reminder wasn't needed.

- --- Vladimir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)

iD8DBQFGoX4FEo/yvZUwubMRAgkFAJ9wHxdGjV5Adstc91/V+Kp0PuuPOACfaLO1
E7yfaY4cgD6tQ5hVklrFU44=
=hN1b
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Daniel Pielmeier]

> march and mtune together? stupid.
> native when you know your CPU? Does your CHOST say 'x86_64' or nocona?
> mmmx, msse2, mss3 stupid. Its all part of nocona (maybe not msse3 but 
> everything else). And fomit-frame-pointer? AFAIK superfluos on the amd64 
> architecture, which was copied by intel - so it should be superfluos on 
> nocona.

I think nocona is not a valid CHOST. For 32bit use
CHOST="i686-pc-linux-gnu" and for 64bit use CHOST="x86_64-pc-linux-gnu"


@ Andrew Gaydenko

Take a look here
http://gentoo-wiki.com/Safe_Cflags#Intel_Core_2_Duo.2FQuad_.2F_Xeon_51xx.2F53xx
i think this settings should be used until gcc-4.3 is out! So your
current settings should do it until that happens!

Regards,

Daniel
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Tobias Heinlein]

Volker Armin Hemmann wrote:
> On Freitag, 20. Juli 2007, Andrew Gaydenko wrote:
> march and mtune together? stupid.
> mmmx, msse2, mss3 stupid. Its all part of nocona (maybe not msse3 but 
> everything else). 

Yes, that's right. These flags don't need to be set again. But there are
some ebuilds that filter certain flags like march. By this filtering the
package would be compiled without mmx and msse2 if the flags aren't set
again. If they are, the package will still be compiled *with* mmx and
msse2 even though march is filtered.. Yes, the filtering in the ebuild
isn't done just for fun but some people still prefer to have mmx and
msse2 enabled (when march is filtered).
In short, settings these flags is not completley stupid but has a reason
(even though it's not a very good one). :)

> And then Os. That is a big nono.

Why? I have a complete system running with -Os here and it's working fine.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Volker Armin Hemmann]

On Freitag, 20. Juli 2007, Tobias Heinlein wrote:
> Volker Armin Hemmann wrote:
> > On Freitag, 20. Juli 2007, Andrew Gaydenko wrote:
> > march and mtune together? stupid.
> > mmmx, msse2, mss3 stupid. Its all part of nocona (maybe not msse3 but
> > everything else).
>
> Yes, that's right. These flags don't need to be set again. But there are
> some ebuilds that filter certain flags like march. By this filtering the
> package would be compiled without mmx and msse2 if the flags aren't set
> again. If they are, the package will still be compiled *with* mmx and
> msse2 even though march is filtered.. Yes, the filtering in the ebuild
> isn't done just for fun but some people still prefer to have mmx and
> msse2 enabled (when march is filtered).
> In short, settings these flags is not completley stupid but has a reason
> (even though it's not a very good one). :)


stupid is meant as 'uninformed' not imbecile in that case. But yes, choice of 
words was not good in my part.

>
> > And then Os. That is a big nono.
>
> Why? I have a complete system running with -Os here and it's working fine.

because Os is known for miscompilations and it makes stuff slower a lot.

For example picture resizing in gwenview. Fast with O2, unbearable slow with 
Os. Last tried with gcc 4.1 ;)
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] -Os = Nono? (was: gcc 4.2 and Core 2 Duo)

[Alexander Skwar]

Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> wrote:

> And then Os. That is a big nono.

Why's that?

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] -Os = Nono? (was: gcc 4.2 and Core 2 Duo)

[Volker Armin Hemmann]

On Montag, 23. Juli 2007, Alexander Skwar wrote:
> Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> wrote:
> > And then Os. That is a big nono.
>
> Why's that?
>
> Alexander Skwar

because several gcc have compiled crap with that flag in the past?


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] -Os = Nono?

[Kenneth Prugh]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

Volker Armin Hemmann wrote:
> On Montag, 23. Juli 2007, Alexander Skwar wrote:
>> Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> wrote:
>>> And then Os. That is a big nono.
>> Why's that?
>>
>> Alexander Skwar
> 
> because several gcc have compiled crap with that flag in the past?
> 
> 

That was the past, -Os generally works fine on AMD64 now. That can be
evidenced by my fully -Os built system that works fine.
-- 
Kenneth Prugh - Ken69267
Gentoo AMD64 Arch Tester


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-user] -Os = Nono?

[Mike Edenfield]

Kenneth Prugh wrote:
> Volker Armin Hemmann wrote:
>> On Montag, 23. Juli 2007, Alexander Skwar wrote:
>>> Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> wrote:
>>>> And then Os. That is a big nono.
>>> Why's that?
>>>
>>> Alexander Skwar
>> because several gcc have compiled crap with that flag in the past?
>>
>>
> 
> That was the past, -Os generally works fine on AMD64 now. That can be
> evidenced by my fully -Os built system that works fine.

 From my experience, the main "problem" with -Os is that it's rarely 
used, and not all that useful.  It's essentially the same as -O2 with 
some optimizations turned off, to save space.  The difference in binary 
size between -O2 and -Os has no, in my experience, been very 
significant.  And -Os produces slower code than -O2.

More importantly, -O2 seems to be the "typical" optimization setting, 
and almost all free software packages are built and tested and generally 
"supported", for whatever that means in an open-source world, under -O2. 
  If you report a bug in a package and you use -Os, the first thing the 
devs will ask is "recompile it using normal CFLAGS and try again."

So yes, recent gcc versions have been much better at not breaking code 
under -Os.  At least, it's no more broken under -Os than under -O2.  But 
  given that disk space is dirt cheap and modern OS don't need to read 
an entire binary into memory to execute it, the actual, tangible 
benefits of using -Os over -O2 are minimal compared against the possible 
problems it might cause.

--Mike
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] -Os = Nono?

[Benno Schulenberg]

Mike Edenfield wrote:
> More importantly, -O2 seems to be the "typical" optimization
> setting, and almost all free software packages are built and
> tested and generally "supported", for whatever that means in an
> open-source world, under -O2. If you report a bug in a package
> and you use -Os, the first thing the devs will ask is "recompile
> it using normal CFLAGS and try again."

Although I agree with your reasoning above, you are contradicting 
yourself in the following two statements:

> At least, it's no more broken under -Os than under -O2.
> [...]  benefits of using -Os over -O2 are minimal 
> compared against the possible problems it might cause.

If -Os is no more broken than -O2, then it shouldn't cause any extra 
problems.  :)

> But given that disk space is dirt cheap

It's not about disk space, it's about the amount that needs to be 
loaded from disk upon first run.

> and modern OS  
> don't need to read an entire binary into memory to execute it,

But if the entire binary is larger, each coherent subsection will be 
larger too, so more will have to be loaded with -O2 than with -Os.  
Processors are fast enough and getting faster all the time, it is 
only those disks that don't get any quicker -- not until we drop 
all those spinning platters and go solid state.

Benno
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] -Os = Nono?

[Zsitvai János]

Hi, 

Have you actually measured the gain? Emerge some thing with Os, qsize the package, emerge it with O2, qsize again? I went back to O2 from Os when it became apparent that the resulting binaries were actually _larger_. On every single package I tried.

Zsitvai János
--
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: -Os = Nono?

[Grant Edwards]

On 2007-07-23, Zsitvai János <zsitvaij@gmail.com> wrote:

> Have you actually measured the gain? Emerge some thing with
> Os, qsize the package, emerge it with O2, qsize again? I went
> back to O2 from Os when it became apparent that the resulting
> binaries were actually _larger_. On every single package I
> tried.

I haven't measured it for IA32, but for a couple other 
architectures I have, and -Os generated consistently larger
code than -O2.  Using -O3 ballooned up to be quite a bit larger
than both -Os and -O2, but if you're worried about size, -O2
usually seems to be the best choice.

-- 
Grant Edwards                   grante             Yow! ... this must be what
                                  at               it's like to be a COLLEGE
                               visi.com            GRADUATE!!

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: -Os = Nono?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Mon, 23 Jul 2007 19:57:06 +0000 (UTC), Grant Edwards wrote:

> I haven't measured it for IA32, but for a couple other 
> architectures I have, and -Os generated consistently larger
> code than -O2.  Using -O3 ballooned up to be quite a bit larger
> than both -Os and -O2, but if you're worried about size, -O2
> usually seems to be the best choice.

I've just tried it on a few PPC packages and, on balance, there was a
small space saving, although it was hardly enough to get excited about.


-- 
Neil Bothwick

There is absolutely no substitute for a genuine lack of preparation.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] -Os = Nono?

[Mike Edenfield]

Benno Schulenberg wrote:

> Although I agree with your reasoning above, you are contradicting 
> yourself in the following two statements:
> 
>> At least, it's no more broken under -Os than under -O2.
>> [...]  benefits of using -Os over -O2 are minimal 
>> compared against the possible problems it might cause.
> 
> If -Os is no more broken than -O2, then it shouldn't cause any extra 
> problems.  :)

True, this is a contradiction, but only in the sense that I failed to 
distinguish between the general case of "most things" that used to break 
under -Os don't break anymore, vs. the specific cases where the two 
settings actually do differ.  Obviously, O2 and Os are using a different 
set of optimizations.  In most cases the code is the same, so if there's 
a problem with the resulting code, it's probably not the compiler's 
fault.  But there are always going to be corner cases where some extra 
space-saving optimization does something unintended, or exposes some 
bug, that O2 does not.

--K

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] -Os = Nono?

[Volker Armin Hemmann]

On Montag, 23. Juli 2007, Kenneth Prugh wrote:
> Volker Armin Hemmann wrote:
> > On Montag, 23. Juli 2007, Alexander Skwar wrote:
> >> Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> wrote:
> >>> And then Os. That is a big nono.
> >>
> >> Why's that?
> >>
> >> Alexander Skwar
> >
> > because several gcc have compiled crap with that flag in the past?
>
> That was the past, -Os generally works fine on AMD64 now. That can be
> evidenced by my fully -Os built system that works fine.

no, it does not 'works fine'.

a) grep -R Os /usr/portage and have an unpleasant surprise.

b) I compiled a couple of stuff with Os and the result: picture resizing and  
browsing with kuickshow and gwenview was  a lot slower.

The only thing I compile with Os is the kernel - after I played a lot of 
ut2004 to make sure that it is not slower...
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

Am Freitag 20 Juli 2007 20:16 schrieb Kenneth Prugh:
> Andrew Gaydenko wrote:
> > I have noticed, the official portage tree has included gcc 4.2. Now for
> > Core 2 Duo CPU (amd64 Gentoo arch) I use in make.conf file:
> >
> > CFLAGS="-O2 -march=nocona -pipe"
> >
> > gcc' changelog has this note:
> >
> > --------------------
> > ...
> > IA-32/x86-64
> >
> >     * -mtune=generic can now be used to generate code running well on
> > common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M,
> > Intel Pentium 4 and Intel Core 2.
> >     * -mtune=native and -march=native will produce code optimized for the
> > host architecture as detected using the cpuid instruction.
> > ...
> > --------------------
> >
> > The question is: must I replace '-march=nocona' with '-mtune=native and
> > -march=native'?
>
> I have a Core2 Duo E6600 and use these CFLAGS with GCC 4.2:
>
> CFLAGS="-Os -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx
> -msse2 -msse3"
>
> Native works fine here.

I don't think that you need -msse3 -msse2 and -mmmx because -march takes care 
of that (refer to "man gcc", one notable exeption: -march=athlon64 does not 
pull -msse3 in because not all Athlons support it). 
-fomit-frame-pointer is unneccessary on AMD64 (refer to "man gcc", again).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Kenneth Prugh]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

Florian Philipp wrote:
> Am Freitag 20 Juli 2007 20:16 schrieb Kenneth Prugh:
>> Andrew Gaydenko wrote:
>>> I have noticed, the official portage tree has included gcc 4.2. Now for
>>> Core 2 Duo CPU (amd64 Gentoo arch) I use in make.conf file:
>>>
>>> CFLAGS="-O2 -march=nocona -pipe"
>>>
>>> gcc' changelog has this note:
>>>
>>> --------------------
>>> ...
>>> IA-32/x86-64
>>>
>>>     * -mtune=generic can now be used to generate code running well on
>>> common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M,
>>> Intel Pentium 4 and Intel Core 2.
>>>     * -mtune=native and -march=native will produce code optimized for the
>>> host architecture as detected using the cpuid instruction.
>>> ...
>>> --------------------
>>>
>>> The question is: must I replace '-march=nocona' with '-mtune=native and
>>> -march=native'?
>> I have a Core2 Duo E6600 and use these CFLAGS with GCC 4.2:
>>
>> CFLAGS="-Os -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx
>> -msse2 -msse3"
>>
>> Native works fine here.
> 
> I don't think that you need -msse3 -msse2 and -mmmx because -march takes care 
> of that (refer to "man gcc", one notable exeption: -march=athlon64 does not 
> pull -msse3 in because not all Athlons support it). 
> -fomit-frame-pointer is unneccessary on AMD64 (refer to "man gcc", again).

Yeah I wasn't exactly positive if it did pull everything in, and
specifying specifically can't really hurt at all as long as you know
it's supported with your cpu.

-- 
Kenneth Prugh - Ken69267
Gentoo AMD64 Arch Tester


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[gentoo-user] Re: gcc 4.2 and Core 2 Duo

[Alexander Skwar]

Kenneth Prugh <ken69267@gmail.com> wrote:

> Yeah I wasn't exactly positive if it did pull everything in, and
> specifying specifically can't really hurt at all as long as you know
> it's supported with your cpu.

Doesn't the doc say, that it actually CAN hurt, as it forces the use
of certain instructions, even if they would not be used automatically?

Because of that, I'd refrain from using stuff like -msse for each
and every package. There might be the odd package out there, where
something like this would help.

Conclusion: I'd use: CFLAGS="-Os -march=native"

Alexander Skwar

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Daniel Pielmeier]

Andrew Gaydenko schrieb:
> I have noticed, the official portage tree has included gcc 4.2. Now for 
> Core 2 Duo CPU (amd64 Gentoo arch) I use in make.conf file:
> 
> CFLAGS="-O2 -march=nocona -pipe"
> 
> gcc' changelog has this note:
> 
> --------------------
> ...
> IA-32/x86-64
> 
>     * -mtune=generic can now be used to generate code running well on common x86 chips. 
>       This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel
>       Core 2.
>     * -mtune=native and -march=native will produce code optimized for the host 
>       architecture as detected using the cpuid instruction.
> ...
> --------------------
> 
> The question is: must I replace '-march=nocona' with '-mtune=native and -march=native'?

Here you will find additional information http://tinyurl.com/2b6spk.
It is stated there that you can use either -march=cpu-type or
-mtune=cpu-type and that -march=cpu-type implies -mtune=cpu-type.

I think you can also use the nocona option for the cpu-type until gcc
4.3 is out which brings you -march=core2, see here http://tinyurl.com/ottvh.

Using mtune or march depends on where you want to use your compiled
software, if you only want to use it only on your own machine
-march=native is probably the best option and if you want to use it on
other machines too, you should choose -mtune=native. If you don't know
at all the weather the cpu is IA32 AMD64 or EM64T you should use
-mtune=generic.

Maybe someone could explain it better, but this is what i understand!

Regards,

Daniel
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

Hello Andrew Gaydenko,

> The question is: must I replace '-march=nocona' with '-mtune=native and
> -march=native'?

You CAN change them but there's no MUST about it. I've been running GCC
4.2 with -march=nocona for about ten days and it's working well.


-- 
Neil Bothwick

Linux like wigwam. No windows, no gates, Apache inside.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Volker Armin Hemmann]

On Freitag, 20. Juli 2007, Andrew Gaydenko wrote:
> I have noticed, the official portage tree has included gcc 4.2. Now for
> Core 2 Duo CPU (amd64 Gentoo arch) I use in make.conf file:
>
> CFLAGS="-O2 -march=nocona -pipe"
>
> gcc' changelog has this note:
>
> --------------------
> ...
> IA-32/x86-64
>
>     * -mtune=generic can now be used to generate code running well on
> common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M,
> Intel Pentium 4 and Intel Core 2.
>     * -mtune=native and -march=native will produce code optimized for the
> host architecture as detected using the cpuid instruction.
> ...
> --------------------
>
> The question is: must I replace '-march=nocona' with '-mtune=native and
> -march=native'?

first of all: using mtune AND march is stupid

Second, that 'feature' means that gcc looks at your CHOST and use that for the 
march/mtune setting.

So no, don't change anything at all. march=nocona is fine. Don't touch it.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Kenneth Prugh]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Volker Armin Hemmann wrote:
> Second, that 'feature' means that gcc looks at your CHOST and use that for the 
> march/mtune setting.
> 
> So no, don't change anything at all. march=nocona is fine. Don't touch it.

That's completely wrong. If you look at the old patch [1] that fixed
mtune for the Core2's you'd see it is MUCH more complicated than that.

[1] http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00061.html
-- 
Kenneth Prugh - Ken69267
Gentoo AMD64 Arch Tester


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-user] gcc 4.2 and Core 2 Duo

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Friday 20 July 2007, "Boyd Stephen Smith Jr." <bss03@volumehost.net> 
wrote about 'Re: [gentoo-user] gcc 4.2 and Core 2 Duo':
> If they have the same value, or -march is listed after -mtune, yes. 
> -march implies -mtune, but you might do something like

-march=686 -mtune=native

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]