[gentoo-dev] Replacing cpu-feature USE flags

[gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

So, I've been drafting this up in my blog[1], and it is a simple way to 
replace the CPU feature useflags. Let's try to summarise:

Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in 
the tree, almost never used to get new dependencies, but usually used to 
supply econf switches.

This works as long as the user enable the flags, but for AMD64 the story was, 
until now, that we simply enabled them when they worked, because we had some 
minimum support available. Unfortunately this became a problem with the 
introduction of nocona, because that is an amd64-like system but with no 
3dnow. And there is the problem that sse3 is supported only in later versions 
of Athlon64 and so on.

To try to clean up this mess, and to make it simpler to work in 
cross-compilation, I thought of using the definitions created by the C 
Preprocessor (CPP) by default for the given CFLAGS. Basically when 
using -march=athlon64, the preprocessor will enable a few definitions that 
tells the availability of MMX, 3dNOW, SSE and so on... if we wrap that 
around, we can use it to know if it's the case of enabling something or not.
This is customisable by the user by setting the CFLAGS themselves. If one does 
not want MMX instructions to be generated, but still want the rest of 
Athlon64 optimisations, it's simply the matter of 
using "-march=athlon64 -mno-mmx".

So, rather than the functions proposed in [1], I've sampled today the 
following function:

has_cpuset() {
    local def hasfeat

    while [[ -n $1 ]]; do
        case $1 in
            mmx)
                def="__MMX__" ;;
            3dnow)
                def="__3dNOW__" ;;
            3dnowex)
                def="__3dNOW_A__" ;;
            sse)
                def="__SSE__" ;;
            sse2)
                def="__SSE2__" ;;
            sse3)
                def="__SSE3__" ;;
            altivec)
                def="__ALTIVEC__" ;;
            *)
                ewarn "Instruction set $1 not supported."
                die "Instruction set not supported."
        esac

        echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null | grep -q ${def} || 
hasfeat="no"
        shift
    done

    if [[ ${hasfeat} == "no" ]]; then
        return 1
    else
        return 0
    fi
}

that can be tested easily with the following code:

yesno() {
    if "$@"; then
        echo "yes"
    else
        echo "no"
    fi
}

echo "Does it have 3dnow mmx sse2?"
yesno has_cpuset 3dnow mmx sse2
echo "Does it have mmx sse sse3?"
yesno has_cpuset mmx sse sse3
echo "Does it have altivec?"
yesno has_cpuset altivec


Note that you  need to set your CFLAGS corretly or it will, by default, tell 
you that everything is disabled.

Thoughts? Comments?

SPARC team: I'd like to know if VIS does a similar thing, would make simpler 
for instance its handling in xine-lib ebuild.

[1] 
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/24/crazy-idea-an-alternative-to-cpu-features-useflags
-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Stuart Herbert]

On 7/6/06, Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> wrote:
[Snip]
> Note that you  need to set your CFLAGS corretly or it will, by default, tell
> you that everything is disabled.
>
> Thoughts? Comments?

The one advantage of using USE flags for this is that the support can
be controlled very easily on a per-package basis.  CFLAGS is much more
of a system-wide setting.

Are there examples where we'd want to have these CPU feature flags
enabled for one package, but disabled for another (for performance or
stability reasons)?

If this is an ability we no longer need, then I like your idea.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 13:00, Stuart Herbert wrote:
> The one advantage of using USE flags for this is that the support can
> be controlled very easily on a per-package basis.  CFLAGS is much more
> of a system-wide setting.
There is always the bashrc to set CFLAGS on a per-package basis.

> Are there examples where we'd want to have these CPU feature flags
> enabled for one package, but disabled for another (for performance or
> stability reasons)?
I think the main issue would be with hardened, where mmx is already a problem 
on some packages, but I think this can be solved.
For any package where enabling mmx create stability problem, it's likely the 
support should be removed altogether anyway, as the flag is enabled for the 
majority of users already (the same goes for the other flags).

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Enrico Weigelt]

* Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> schrieb:
> On Thursday 06 July 2006 13:00, Stuart Herbert wrote:
> > The one advantage of using USE flags for this is that the support can
> > be controlled very easily on a per-package basis.  CFLAGS is much more
> > of a system-wide setting.
> There is always the bashrc to set CFLAGS on a per-package basis.

hmm, quite inconsitent. 
Would be better if we had something similar to package.use, but for
things like CFLAGS. (btw: evrything that can be controlled by environment
should be also available through such per-package tables in /etc/portage/)

> > Are there examples where we'd want to have these CPU feature flags
> > enabled for one package, but disabled for another (for performance or
> > stability reasons)?
> I think the main issue would be with hardened, where mmx is already a problem 
> on some packages, but I think this can be solved.

IMHO there was some "hardened" useflag. Is it the place where such 
things should go ?

> For any package where enabling mmx create stability problem, it's likely the 
> support should be removed altogether anyway, as the flag is enabled for the 
> majority of users already (the same goes for the other flags).

hmm, for most users this should be okay.
But what's w/ people who want to play around w/ this ?

BTW: is there a way for masking an useflag of some package ?
Lets say, we've got some package which has special mmx support. 
The package itself (w/o mmx) has been proven as stable, but the mmx
stuff hasn't. Is it then possible to mask only the MMX stuff ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ioannis Aslanidis]

Thought: I like it :)

On 7/6/06, Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> wrote:
> So, I've been drafting this up in my blog[1], and it is a simple way to
> replace the CPU feature useflags. Let's try to summarise:
>
> Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in
> the tree, almost never used to get new dependencies, but usually used to
> supply econf switches.
>
> This works as long as the user enable the flags, but for AMD64 the story was,
> until now, that we simply enabled them when they worked, because we had some
> minimum support available. Unfortunately this became a problem with the
> introduction of nocona, because that is an amd64-like system but with no
> 3dnow. And there is the problem that sse3 is supported only in later versions
> of Athlon64 and so on.
>
> To try to clean up this mess, and to make it simpler to work in
> cross-compilation, I thought of using the definitions created by the C
> Preprocessor (CPP) by default for the given CFLAGS. Basically when
> using -march=athlon64, the preprocessor will enable a few definitions that
> tells the availability of MMX, 3dNOW, SSE and so on... if we wrap that
> around, we can use it to know if it's the case of enabling something or not.
> This is customisable by the user by setting the CFLAGS themselves. If one does
> not want MMX instructions to be generated, but still want the rest of
> Athlon64 optimisations, it's simply the matter of
> using "-march=athlon64 -mno-mmx".
>
> So, rather than the functions proposed in [1], I've sampled today the
> following function:
>
> has_cpuset() {
>    local def hasfeat
>
>    while [[ -n $1 ]]; do
>        case $1 in
>            mmx)
>                def="__MMX__" ;;
>            3dnow)
>                def="__3dNOW__" ;;
>            3dnowex)
>                def="__3dNOW_A__" ;;
>            sse)
>                def="__SSE__" ;;
>            sse2)
>                def="__SSE2__" ;;
>            sse3)
>                def="__SSE3__" ;;
>            altivec)
>                def="__ALTIVEC__" ;;
>            *)
>                ewarn "Instruction set $1 not supported."
>                die "Instruction set not supported."
>        esac
>
>        echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null | grep -q ${def} ||
> hasfeat="no"
>        shift
>    done
>
>    if [[ ${hasfeat} == "no" ]]; then
>        return 1
>    else
>        return 0
>    fi
> }
>
> that can be tested easily with the following code:
>
> yesno() {
>    if "$@"; then
>        echo "yes"
>    else
>        echo "no"
>    fi
> }
>
> echo "Does it have 3dnow mmx sse2?"
> yesno has_cpuset 3dnow mmx sse2
> echo "Does it have mmx sse sse3?"
> yesno has_cpuset mmx sse sse3
> echo "Does it have altivec?"
> yesno has_cpuset altivec
>
>
> Note that you  need to set your CFLAGS corretly or it will, by default, tell
> you that everything is disabled.
>
> Thoughts? Comments?
>
> SPARC team: I'd like to know if VIS does a similar thing, would make simpler
> for instance its handling in xine-lib ebuild.
>
> [1]
> http://farragut.flameeyes.is-a-geek.org/articles/2006/06/24/crazy-idea-an-alternative-to-cpu-features-useflags
> --
> Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
> Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
>
>
>


-- 
Ioannis Aslanidis

<deathwing00[at]gentoo.org> 0xB9B11F4E

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Donnie Berkholz]

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

Diego 'Flameeyes' Pettenò wrote:
>         echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null

> Thoughts? Comments?

How will you handle non-gcc compilers?

Thanks,
Donnie


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 13:40, Donnie Berkholz wrote:
> How will you handle non-gcc compilers?
We don't support any, to start with.

But ICC I'm pretty sure behaves like GCC, and whatever else we'd go by 
supporting should likely do the same.

But again, we don't support any, so it's up to whoever wants to support them 
to find a solution, I'd say.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Donnie Berkholz]

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

Diego 'Flameeyes' Pettenò wrote:
> On Thursday 06 July 2006 13:40, Donnie Berkholz wrote:
>> How will you handle non-gcc compilers?
> We don't support any, to start with.
> 
> But ICC I'm pretty sure behaves like GCC, and whatever else we'd go by 
> supporting should likely do the same.
> 
> But again, we don't support any, so it's up to whoever wants to support them 
> to find a solution, I'd say.

Well, there are enough in the tree that you should at least make sure
they don't completely break and error out when passing them invalid
flags, even if you fail to auto-enable mmx/sse/whatever. You could do if
[[ $(tc-getCC) != *gcc* ]] or something...

Thanks,
Donnie


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 13:58, Donnie Berkholz wrote:
> Well, there are enough in the tree
There are ebuilds for non-gcc compilers. There's no support in using them for 
anything like building stuff. Let's think to all the append-flags there are 
in the tree. This is not going to make the support any less working. There's 
no project maintaining support for icc and the like.

> that you should at least make sure 
> they don't completely break and error out when passing them invalid
> flags, 
Uhm, If you look at the function itself you can see that I drop the stderr 
output and I just care about the other part. The flags used are the ones set 
by the user with the exclusion of -E -dM that are, afaik, standard unix 
compiler options like -c and -o.. if the compiler does not support those, 
it's unlikely it can actually do anything useful in Gentoo.
And anyway it cannot "break", it will just report that no extensions are 
available.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Harald van Dijk]

On Thu, Jul 06, 2006 at 02:21:43PM +0200, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 06 July 2006 13:58, Donnie Berkholz wrote:
> > Well, there are enough in the tree
> There are ebuilds for non-gcc compilers. There's no support in using them for 
> anything like building stuff. Let's think to all the append-flags there are 
> in the tree.

`append-flags $(test-flags ...)` can be used instead, if the options are
gcc-specific, and I have done that myself in a case where every
supported GCC version supported the specific option. (-fpermissive was
the one.)

> This is not going to make the support any less working. There's 
> no project maintaining support for icc and the like.

When the answer is "make icc not suck" even when it is capable of
compiling mostly any package if the portage tree would not assume gcc,
that's not going to happen. First, alternative compilers must be
accepted (even when not supported) by package maintainers, and only then
might they ever become supported.

> > that you should at least make sure 
> > they don't completely break and error out when passing them invalid
> > flags, 
> Uhm, If you look at the function itself you can see that I drop the stderr 
> output and I just care about the other part. The flags used are the ones set 
> by the user with the exclusion of -E -dM that are, afaik, standard unix 
> compiler options like -c and -o..

-E is a standard unix compiler option. -dM isn't. What you could do
instead is `$(tc-getCC) ${CFLAGS} -E - >/dev/null 2>&1 <<EOF
#if !($macro)
#error
#endif
EOF` and check $CC's return value. If $macro is not defined, or is
defined to something like 0, preprocessing won't succeed, and $CC will
return nonzero.

> if the compiler does not support those, 
> it's unlikely it can actually do anything useful in Gentoo.
> And anyway it cannot "break", it will just report that no extensions are 
> available.

That's sane behaviour regardless. :)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Mike Frysinger]

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

On Thursday 06 July 2006 07:48, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 06 July 2006 13:40, Donnie Berkholz wrote:
> > How will you handle non-gcc compilers?
>
> We don't support any, to start with.

this sort of closed mindedness isnt really encouraging ... plus it's kind of 
funny, this statement coming from you of all people ... especially after all 
the crap you had to go through to break the "we dont support anything other 
than linux / gnu" mentality you fought through for so long
-mike

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 02:46, Mike Frysinger wrote:
> this sort of closed mindedness isnt really encouraging ...
Err I actually thought if icc in the first place and tried to inform myself. 
I'm not the kind of person (and you should know) who likes breaking 
unsupported stuff. I think it's reasonable to find a solution that works with 
ICC, and actually Harald already gave one later in the thread.
It's just a matter of fact that we don't have anybody right now to follow what 
might and might not break this or that unsupported compiler. As soon as there 
is a single person ready to at least answer to questions about it, the 
situation changes.

I'm just saying that I wouldn't discard entirely a solution just because some 
unsupported software _might_ not work (note the conditional). I wouldn't 
discard a solution just because it _might_ not work on GNU/kFreeBSD; I would 
discard it if I _know for sure_ that it does not work on GNU/kFreeBSD (in 
which case, knowing it doesn't work, I would look for a working solution).

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Mike Frysinger]

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

On Thursday 06 July 2006 20:57, Diego 'Flameeyes' Pettenò wrote:
> I'm just saying that I wouldn't discard entirely a solution just because
> some unsupported software _might_ not work (note the conditional). I
> wouldn't discard a solution just because it _might_ not work on
> GNU/kFreeBSD; I would discard it if I _know for sure_ that it does not work
> on GNU/kFreeBSD (in which case, knowing it doesn't work, I would look for a
> working solution).

you missed the point of my reply ... flatly discarding anything because we 
dont currently support it is a bad place to be

what i was implying wasnt for you to discard an entire solution, just be more 
flexible

forward thinking is what has allowed Gentoo to be trivially ported to what was 
once considered unsupported (i know it's helped a ton in porting to obscure 
cpus :P)

now, put that in your pipe and smoke it
-mike

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ned Ludd]

On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
> Diego 'Flameeyes' Pettenò wrote:
> >         echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null
> 
> > Thoughts? Comments?
> 
> How will you handle non-gcc compilers?

Non gcc compilers have never been supported and probably never will be.

Gentoo uses the GNU Toolchain.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Donnie Berkholz]

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

Ned Ludd wrote:
> On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
>> Diego 'Flameeyes' Pettenò wrote:
>>>         echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null
>>> Thoughts? Comments?
>> How will you handle non-gcc compilers?
> 
> Non gcc compilers have never been supported and probably never will be.

Neither has USE=-*, but we don't actively try to break it. =) As long as
this doesn't cause all non-gcc compilers to immediately die, I don't
care if they miss out on auto-mmx or whatever.

Thanks,
Donnie


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Harald van Dijk]

On Thu, Jul 06, 2006 at 11:41:26AM -0400, Ned Ludd wrote:
> On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
> > Diego 'Flameeyes' Pettenò wrote:
> > >         echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null
> > 
> > > Thoughts? Comments?
> > 
> > How will you handle non-gcc compilers?
> 
> Non gcc compilers have never been supported and probably never will be.
> 
> Gentoo uses the GNU Toolchain.

The GNU toolchain is not supported by Gentoo, and in fact gets actively
broken with unsupported command-line options. Only the GNU toolchain as
modified by Gentoo's toolchain guys is supported, unfortunately.
-- 
gentoo-dev@gentoo.org mailing list

Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Kevin F. Quinn]

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

On Thu, 6 Jul 2006 21:06:18 +0200
Harald van Dijk <truedfx@gentoo.org> wrote:

> The GNU toolchain is not supported by Gentoo, and in fact gets
> actively broken with unsupported command-line options. Only the GNU
> toolchain as modified by Gentoo's toolchain guys is supported,
> unfortunately.

What exactly is it about the toolchain supplied with Gentoo that causes
you problems?

-- 
Kevin F. Quinn

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote:
> On Thu, 6 Jul 2006 21:06:18 +0200
> Harald van Dijk <truedfx@gentoo.org> wrote:
> 
> > The GNU toolchain is not supported by Gentoo, and in fact gets
> > actively broken with unsupported command-line options. Only the GNU
> > toolchain as modified by Gentoo's toolchain guys is supported,
> > unfortunately.
> 
> What exactly is it about the toolchain supplied with Gentoo that causes
> you problems?

I don't have a lot of trust in Gentoo's patches, as they have resulted
in completely and utterly unusable ld, and (minor) data loss due to a
miscompilation by Gentoo's gcc, in the past. Also, being able to check
whether your own software compiles with a GNU toolchain is to me a good
thing.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Stephen P. Becker]

Harald van Dijk wrote:
> On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote:
>> On Thu, 6 Jul 2006 21:06:18 +0200
>> Harald van Dijk <truedfx@gentoo.org> wrote:
>>
>>> The GNU toolchain is not supported by Gentoo, and in fact gets
>>> actively broken with unsupported command-line options. Only the GNU
>>> toolchain as modified by Gentoo's toolchain guys is supported,
>>> unfortunately.
>> What exactly is it about the toolchain supplied with Gentoo that causes
>> you problems?
> 
> I don't have a lot of trust in Gentoo's patches, as they have resulted
> in completely and utterly unusable ld, and (minor) data loss due to a
> miscompilation by Gentoo's gcc, in the past. Also, being able to check
> whether your own software compiles with a GNU toolchain is to me a good
> thing.

Isn't this why gcc et al support the "vanilla" USE flag?

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Thu, Jul 06, 2006 at 04:03:26PM -0400, Stephen P. Becker wrote:
> Harald van Dijk wrote:
> >On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote:
> >>On Thu, 6 Jul 2006 21:06:18 +0200
> >>Harald van Dijk <truedfx@gentoo.org> wrote:
> >>
> >>>The GNU toolchain is not supported by Gentoo, and in fact gets
> >>>actively broken with unsupported command-line options. Only the GNU
> >>>toolchain as modified by Gentoo's toolchain guys is supported,
> >>>unfortunately.
> >>What exactly is it about the toolchain supplied with Gentoo that causes
> >>you problems?
> >
> >I don't have a lot of trust in Gentoo's patches, as they have resulted
> >in completely and utterly unusable ld, and (minor) data loss due to a
> >miscompilation by Gentoo's gcc, in the past. Also, being able to check
> >whether your own software compiles with a GNU toolchain is to me a good
> >thing.
> 
> Isn't this why gcc et al support the "vanilla" USE flag?

Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
compiler in Gentoo.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

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

On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> compiler in Gentoo.

you're just griping because i forced ssp/pie regardless of USE=vanilla ... 
since gcc-4.0 and below are on the way out, i have no problem changing this 
behavior

besides, since both of these technologies are in mainline gcc now, i really 
dont see how you can continue to gripe with gcc-4.1.1+
-mike

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> > compiler in Gentoo.
> 
> you're just griping because i forced ssp/pie regardless of USE=vanilla ... 

I didn't mind that you applied ssp/pie patches regardless of
USE=vanilla, I did mind that you applied the stub patches with
USE="nossp vanilla", and I also didn't like that this was either done
accidentally but ignored when pointed out, or that this was done
deliberately with a misleading cvs log message.

> since gcc-4.0 and below are on the way out, i have no problem changing this 
> behavior
> 
> besides, since both of these technologies are in mainline gcc now, i really 
> dont see how you can continue to gripe with gcc-4.1.1+

I don't know how much gcc-spec-env.patch can be trusted, and even if it
is 100% safe, such patches don't belong in anything that would be called
"vanilla". (I have commented on that patch long before this thread
started, so don't think I'm just looking for something to complain about
now.)
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Kevin F. Quinn]

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

On Fri, 7 Jul 2006 07:46:16 +0200
Harald van Dijk <truedfx@gentoo.org> wrote:

> On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't
> > > a supported compiler in Gentoo.
> > 
> > you're just griping because i forced ssp/pie regardless of
> > USE=vanilla ... 
> 
> I didn't mind that you applied ssp/pie patches regardless of
> USE=vanilla, I did mind that you applied the stub patches with
> USE="nossp vanilla", and I also didn't like that this was either done
> accidentally but ignored when pointed out, or that this was done
> deliberately with a misleading cvs log message.

If you take out the stub patches (which incidentally have no impact on
code generation), many builds will simply fail because they expect the
additional flags from ssp, htb etc to be there.

Since they have no impact on code generation, their presence doesn't
impact comparisons with a pure upstream release.

> > since gcc-4.0 and below are on the way out, i have no problem
> > changing this behavior
> > 
> > besides, since both of these technologies are in mainline gcc now,
> > i really dont see how you can continue to gripe with gcc-4.1.1+
> 
> I don't know how much gcc-spec-env.patch can be trusted, and even if
> it is 100% safe, such patches don't belong in anything that would be
> called "vanilla". (I have commented on that patch long before this
> thread started, so don't think I'm just looking for something to
> complain about now.)

Again, if you don't gave GCC_SPECS defined in your environment then
that patch makes no difference to code generation.

-- 
Kevin F. Quinn

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
> On Fri, 7 Jul 2006 07:46:16 +0200
> Harald van Dijk <truedfx@gentoo.org> wrote:
> 
> > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't
> > > > a supported compiler in Gentoo.
> > > 
> > > you're just griping because i forced ssp/pie regardless of
> > > USE=vanilla ... 
> > 
> > I didn't mind that you applied ssp/pie patches regardless of
> > USE=vanilla, I did mind that you applied the stub patches with
> > USE="nossp vanilla", and I also didn't like that this was either done
> > accidentally but ignored when pointed out, or that this was done
> > deliberately with a misleading cvs log message.
> 
> If you take out the stub patches (which incidentally have no impact on
> code generation), many builds will simply fail because they expect the
> additional flags from ssp, htb etc to be there.

That's the point. I mentioned being able to test whether your own
software compiles with a pure GNU toolchain as a desire. Being able to
see whether unofficial compiler options are used is not just a nice
extra, but even necessary for that.

> Since they have no impact on code generation, their presence doesn't
> impact comparisons with a pure upstream release.
> 
> > > since gcc-4.0 and below are on the way out, i have no problem
> > > changing this behavior
> > > 
> > > besides, since both of these technologies are in mainline gcc now,
> > > i really dont see how you can continue to gripe with gcc-4.1.1+
> > 
> > I don't know how much gcc-spec-env.patch can be trusted, and even if
> > it is 100% safe, such patches don't belong in anything that would be
> > called "vanilla". (I have commented on that patch long before this
> > thread started, so don't think I'm just looking for something to
> > complain about now.)
> 
> Again, if you don't gave GCC_SPECS defined in your environment then
> that patch makes no difference to code generation.

Yes, but if GCC_SPECS is defined in the environment, I don't know enough
about it to be sure that it interacts properly with -specs command-line
options. Even if it works perfectly, though, the point remains that it
does not belong in a USE=vanilla build.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Ned Ludd]

On Fri, 2006-07-07 at 18:53 +0200, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
> > On Fri, 7 Jul 2006 07:46:16 +0200
> > Harald van Dijk <truedfx@gentoo.org> wrote:
> > 
> > > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't
> > > > > a supported compiler in Gentoo.
> > > > 
> > > > you're just griping because i forced ssp/pie regardless of
> > > > USE=vanilla ... 
> > > 
> > > I didn't mind that you applied ssp/pie patches regardless of
> > > USE=vanilla, I did mind that you applied the stub patches with
> > > USE="nossp vanilla", and I also didn't like that this was either done
> > > accidentally but ignored when pointed out, or that this was done
> > > deliberately with a misleading cvs log message.
> > 
> > If you take out the stub patches (which incidentally have no impact on
> > code generation), many builds will simply fail because they expect the
> > additional flags from ssp, htb etc to be there.
> 
> That's the point. I mentioned being able to test whether your own
> software compiles with a pure GNU toolchain as a desire. Being able to
> see whether unofficial compiler options are used is not just a nice
> extra, but even necessary for that.
> 
> > Since they have no impact on code generation, their presence doesn't
> > impact comparisons with a pure upstream release.
> > 
> > > > since gcc-4.0 and below are on the way out, i have no problem
> > > > changing this behavior
> > > > 
> > > > besides, since both of these technologies are in mainline gcc now,
> > > > i really dont see how you can continue to gripe with gcc-4.1.1+
> > > 
> > > I don't know how much gcc-spec-env.patch can be trusted, and even if
> > > it is 100% safe, such patches don't belong in anything that would be
> > > called "vanilla". (I have commented on that patch long before this
> > > thread started, so don't think I'm just looking for something to
> > > complain about now.)
> > 
> > Again, if you don't gave GCC_SPECS defined in your environment then
> > that patch makes no difference to code generation.
> 
> Yes, but if GCC_SPECS is defined in the environment, I don't know enough
> about it to be sure that it interacts properly with -specs command-line
> options. Even if it works perfectly, though, the point remains that it
> does not belong in a USE=vanilla build.


Keep pushing this and the only thing you will end up with is the 
vanilla flag being removed all together.. You want a pure 100% 
vanilla(POS) non working toolchain then go download it and 
compile it yourself. You will soon see why things exist the way 
they do..

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
> Keep pushing this and the only thing you will end up with is the 
> vanilla flag being removed all together..

Is that a threat? If not, is there a reason behind this?

> You want a pure 100% 
> vanilla(POS) non working toolchain then go download it and 
> compile it yourself. You will soon see why things exist the way 
> they do..

If you mean modifying the build system to actually work properly, then I
have no problem with that. USE=vanilla refers to runtime behaviour, not
the build system. (See use.desc.) Specifically, if patches are applied
that make sure GCC compiles, and those patches make sure GCC compiles to
the same program intended by the GCC devs at that release, those patches
are appropriate, IMO. None of the GCC patches I have problems with are
of this nature.

If you mean vanilla GCC + build fixes is unusable, then I'd appreciate
an explanation, because as far as I know, it can work just fine as a
system compiler, and plenty of people, at some times myself included,
use it as one.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Ned Ludd]

On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
> > Keep pushing this and the only thing you will end up with is the 
> > vanilla flag being removed all together..
> 
> Is that a threat? If not, is there a reason behind this?

Yes.. When users or devs complain non stop when they 
don't understand something it leaves us with a few choices.
1) put up with people not having a clue.
2) remove the option so they can't bitch about it.

Option #1 is not fun as it pushes the hand on #2

> > You want a pure 100% 
> > vanilla(POS) non working toolchain then go download it and 
> > compile it yourself. You will soon see why things exist the way 
> > they do..
> 
> If you mean modifying the build system to actually work properly, then I
> have no problem with that. USE=vanilla refers to runtime behaviour, not
> the build system. (See use.desc.) Specifically, if patches are applied
> that make sure GCC compiles, and those patches make sure GCC compiles to
> the same program intended by the GCC devs at that release, those patches
> are appropriate, IMO. None of the GCC patches I have problems with are
> of this nature.
> 
> If you mean vanilla GCC + build fixes is unusable, then I'd appreciate
> an explanation, because as far as I know, it can work just fine as a
> system compiler, and plenty of people, at some times myself included,
> use it as one.

You use the Gentoo modified one. Regardless of what USE= flags you have
enabled you are still getting Gentoo behaviors.

Think vanilla-sources are pure? They are not. 
They get patched as well with the minimal amount of patches required.
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote:
> On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote:
> > On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
> > > Keep pushing this and the only thing you will end up with is the 
> > > vanilla flag being removed all together..
> > 
> > Is that a threat? If not, is there a reason behind this?
> 
> Yes.. When users or devs complain non stop when they 
> don't understand something it leaves us with a few choices.
> 1) put up with people not having a clue.
> 2) remove the option so they can't bitch about it.
> 
> Option #1 is not fun as it pushes the hand on #2

Option 3: Enlighten me. I have explained why I feel the way I do, so if
there's some big flaw in my understanding, please do correct it.

> > > You want a pure 100% 
> > > vanilla(POS) non working toolchain then go download it and 
> > > compile it yourself. You will soon see why things exist the way 
> > > they do..
> > 
> > If you mean modifying the build system to actually work properly, then I
> > have no problem with that. USE=vanilla refers to runtime behaviour, not
> > the build system. (See use.desc.) Specifically, if patches are applied
> > that make sure GCC compiles, and those patches make sure GCC compiles to
> > the same program intended by the GCC devs at that release, those patches
> > are appropriate, IMO. None of the GCC patches I have problems with are
> > of this nature.
> > 
> > If you mean vanilla GCC + build fixes is unusable, then I'd appreciate
> > an explanation, because as far as I know, it can work just fine as a
> > system compiler, and plenty of people, at some times myself included,
> > use it as one.
> 
> You use the Gentoo modified one. Regardless of what USE= flags you have
> enabled you are still getting Gentoo behaviors.

Gentoo isn't the only system I use. I have used vanilla GCC + build
fixes, and I have been able to get a working system with it. So I'm
still waiting on your explanation of how it is unusable.

> Think vanilla-sources are pure? They are not. 
> They get patched as well with the minimal amount of patches required.

Interesting, and I did not know that, but looking at kernel-2.eclass
(which appears to be the only thing doing any modifying), the
modifications are all build system fixes, and won't affect the generated
kernel.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Ned Ludd]

On Fri, 2006-07-07 at 23:09 +0200, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote:
> > On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote:
> > > On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
> > > > Keep pushing this and the only thing you will end up with is the 
> > > > vanilla flag being removed all together..
> > > 
> > > Is that a threat? If not, is there a reason behind this?
> > 
> > Yes.. When users or devs complain non stop when they 
> > don't understand something it leaves us with a few choices.
> > 1) put up with people not having a clue.
> > 2) remove the option so they can't bitch about it.
> > 
> > Option #1 is not fun as it pushes the hand on #2
> 
> Option 3: Enlighten me. I have explained why I feel the way I do, so if
> there's some big flaw in my understanding, please do correct it.

Sigh... I'm not going to sit here and bicker with you.
At the end of the day here is what matters.. 
Your giving Mike a hard time on the most vital of all 
programs in this distro and that just sucks so please stop and 
just be happy that the toolchain works as well as it does.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Tushar Teredesai]

On 7/7/06, Ned Ludd <solar@gentoo.org> wrote:
> You want a pure 100%
> vanilla(POS) non working toolchain then go download it and
> compile it yourself. You will soon see why things exist the way
> they do..

LFS <http://www.linuxfromscratch.org/lfs> has always been based on a
"vanilla" toolchain. Never ran into issues. Of course, we do apply
upstream patches when needed.

-- 
Tushar Teredesai
   mailto:tushar@linuxfromscratch.org
   http://www.linuxfromscratch.org/~tushar/
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Ned Ludd]

On Fri, 2006-07-07 at 15:18 -0500, Tushar Teredesai wrote:
> On 7/7/06, Ned Ludd <solar@gentoo.org> wrote:
> > You want a pure 100%
> > vanilla(POS) non working toolchain then go download it and
> > compile it yourself. You will soon see why things exist the way
> > they do..
> 
> LFS <http://www.linuxfromscratch.org/lfs> has always been based on a
> "vanilla" toolchain. Never ran into issues. Of course, we do apply
> upstream patches when needed.

They patch gcc as needed also.

http://www.linuxfromscratch.org/hlfs/

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

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

On Friday 07 July 2006 12:53, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
> > If you take out the stub patches (which incidentally have no impact on
> > code generation), many builds will simply fail because they expect the
> > additional flags from ssp, htb etc to be there.
>
> That's the point. I mentioned being able to test whether your own
> software compiles with a pure GNU toolchain as a desire. Being able to
> see whether unofficial compiler options are used is not just a nice
> extra, but even necessary for that.

as i said, this really is a non-issue considering SSP has been integrated into 
mainline gcc

> > Again, if you don't gave GCC_SPECS defined in your environment then
> > that patch makes no difference to code generation.
>
> Yes, but if GCC_SPECS is defined in the environment

so what's stopping you from undefining it ?
-mike

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

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

On Friday 07 July 2006 01:46, Harald van Dijk wrote:
> On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> > > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> > > compiler in Gentoo.
> >
> > you're just griping because i forced ssp/pie regardless of USE=vanilla
> > ...
>
> I didn't mind that you applied ssp/pie patches regardless of
> USE=vanilla, I did mind that you applied the stub patches with
> USE="nossp vanilla", and I also didn't like that this was either done 
> accidentally but ignored when pointed out, or that this was done
> deliberately with a misleading cvs log message.

it was not ignored, i told you the answer was no ... i listened to your 
request and then i evaluated the situation and deemed at the time to go with 
what we have now.  see how your usage of "ignored" is incorrect here ?

as Kevin pointed out, the stubs do not affect code generation so i preferred 
to keep users from breaking themselves

also, at the time, i told you you could easily work around the stub situation 
by simply deleting them:
rm /usr/portage/sys-devel/gcc/files/stubs/*
and then add sys-devel/gcc/files/stubs/ to your rsync exclude list

once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply 
the stubs when USE=nossp as the majority of users will no longer be in the 
situation i referred to earlier

> > since gcc-4.0 and below are on the way out, i have no problem changing
> > this behavior
> >
> > besides, since both of these technologies are in mainline gcc now, i
> > really dont see how you can continue to gripe with gcc-4.1.1+
>
> I don't know how much gcc-spec-env.patch can be trusted, and even if it
> is 100% safe, such patches don't belong in anything that would be called
> "vanilla". (I have commented on that patch long before this thread
> started, so don't think I'm just looking for something to complain about
> now.)

you never pointed that patch out to me nor did i notice it, so i dont really 
see how you could have expected this to be fixed already

i'll update cvs when i get a chance
-mike

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote:
> On Friday 07 July 2006 01:46, Harald van Dijk wrote:
> > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> > > > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> > > > compiler in Gentoo.
> > >
> > > you're just griping because i forced ssp/pie regardless of USE=vanilla
> > > ...
> >
> > I didn't mind that you applied ssp/pie patches regardless of
> > USE=vanilla, I did mind that you applied the stub patches with
> > USE="nossp vanilla", and I also didn't like that this was either done 
> > accidentally but ignored when pointed out, or that this was done
> > deliberately with a misleading cvs log message.
> 
> it was not ignored, i told you the answer was no ... i listened to your 
> request and then i evaluated the situation and deemed at the time to go with 
> what we have now.  see how your usage of "ignored" is incorrect here ?

Actually, you did ignore. The below text refers to something older.

> as Kevin pointed out, the stubs do not affect code generation so i preferred 
> to keep users from breaking themselves
> 
> also, at the time, i told you you could easily work around the stub situation 
> by simply deleting them:
> rm /usr/portage/sys-devel/gcc/files/stubs/*
> and then add sys-devel/gcc/files/stubs/ to your rsync exclude list

Yes, you told me this, before USE=vanilla even existed for gcc. When
there's no implicit claim that installed GCC is official GCC, it's much
less of a problem that it's not. Back then, I never complained that the
installed GCC wasn't the official GCC, only that (a manually installed)
official GCC wasn't a supported compiler. And I did not ask for an
official way to disable the stub patches then, I only asked how I could
do it for my own system.

> once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply 
> the stubs when USE=nossp as the majority of users will no longer be in the 
> situation i referred to earlier

Thanks. I hope that if a similar situation comes up, ebuilds will use
test-flags instead of assuming the option is valid, though.

> > > since gcc-4.0 and below are on the way out, i have no problem changing
> > > this behavior
> > >
> > > besides, since both of these technologies are in mainline gcc now, i
> > > really dont see how you can continue to gripe with gcc-4.1.1+
> >
> > I don't know how much gcc-spec-env.patch can be trusted, and even if it
> > is 100% safe, such patches don't belong in anything that would be called
> > "vanilla". (I have commented on that patch long before this thread
> > started, so don't think I'm just looking for something to complain about
> > now.)
> 
> you never pointed that patch out to me nor did i notice it, so i dont really 
> see how you could have expected this to be fixed already

I didn't point that out to you, I pointed that out to another of the
toolchain guys. I'm not completely sure who, but I think it was
Halcy0n.

> i'll update cvs when i get a chance

Thanks again.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

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

On Friday 07 July 2006 17:53, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote:
> > On Friday 07 July 2006 01:46, Harald van Dijk wrote:
> > > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
> > > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
> > > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most
> > > > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a
> > > > > supported compiler in Gentoo.
> > > >
> > > > you're just griping because i forced ssp/pie regardless of
> > > > USE=vanilla ...
> > >
> > > I didn't mind that you applied ssp/pie patches regardless of
> > > USE=vanilla, I did mind that you applied the stub patches with
> > > USE="nossp vanilla", and I also didn't like that this was either done
> > > accidentally but ignored when pointed out, or that this was done
> > > deliberately with a misleading cvs log message.
> >
> > it was not ignored, i told you the answer was no ... i listened to your
> > request and then i evaluated the situation and deemed at the time to go
> > with what we have now.  see how your usage of "ignored" is incorrect here
> > ?
>
> Actually, you did ignore. The below text refers to something older.

ignored *what* then ?  you requested USE=vanilla control ssp, i said no and 
i'll add support for USE=nossp ... you requested USE/stub control, i said no, 
go delete the stubs

i dont see what else you're referring to ... be specific, vague claims only 
lead to wasting of both our times

> > > I don't know how much gcc-spec-env.patch can be trusted, and even if it
> > > is 100% safe, such patches don't belong in anything that would be
> > > called "vanilla". (I have commented on that patch long before this
> > > thread started, so don't think I'm just looking for something to
> > > complain about now.)
> >
> > you never pointed that patch out to me nor did i notice it, so i dont
> > really see how you could have expected this to be fixed already
>
> I didn't point that out to you, I pointed that out to another of the
> toolchain guys. I'm not completely sure who, but I think it was
> Halcy0n.

all bets are off now then ... with Halcy0n leaving us, that leaves me as the 
only person maintaining the toolchain (there are few devs who contribute 
fixes for their ports and it helps out a ton, but that doesnt really count as 
being fully responsible for the toolchain packages).  no more making 
retroactive claims when i wasnt involved ;P

i trust azarah to help out, but he's been busy in real life so i havent/wont 
ask him to contribute since i know he cannot (even if he wants to)
-mike

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 06:13:27PM -0400, Mike Frysinger wrote:
> ignored *what* then ?  you requested USE=vanilla control ssp, i said no and 
> i'll add support for USE=nossp ... you requested USE/stub control, i said no, 
> go delete the stubs

USE=nossp existed before USE=vanilla did. To be sure I'm remembering
right, I checked `cvs log toolchain.eclass`. In order, probably skipping
a few steps:

1- No SSP
2- Choice between SSP [USE=-nossp] and stub patches [USE=nossp].
   USE=vanilla didn't exist.
3- Choice between SSP [USE="-nossp -vanilla"], stub patches
    [USE="nossp -vanilla"], and nothing [USE="vanilla"]
4- Choice between SSP [USE=-nossp] and stub patches [USE=nossp]
   USE=vanilla exists but has no effect on SSP.

It was during 2 that I asked for a way to disable stub patches for
myself (and not as part of the official ebuild), and you said to delete
them. That was good enough for me during 2. We are now in 4.

> i dont see what else you're referring to ... be specific, vague claims only 
> lead to wasting of both our times

I hope this is specific enough: toolchain.eclass revision 1.234
(separating ssp/... from vanilla) log message:
"ssp/pie/htb have their own USE flags sep from vanilla, so people can 
 utilize those"
when in fact the old USE=vanilla behaviour is unavailable now. You have
never (as far as I know) answered whether it was intended to keep the
old behaviour as an option, and if it wasn't, why the log message is
what it is.

> all bets are off now then ... with Halcy0n leaving us, that leaves me as the 
> only person maintaining the toolchain (there are few devs who contribute 
> fixes for their ports and it helps out a ton, but that doesnt really count as 
> being fully responsible for the toolchain packages).

I'll keep that in mind, I wasn't aware that the other toolchain guys
handle specific parts of the toolchain packages only. Even if I disagree
with some specific decisions, nice job overall, then.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

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

On Friday 07 July 2006 19:04, Harald van Dijk wrote:
> I hope this is specific enough: toolchain.eclass revision 1.234
> (separating ssp/... from vanilla) log message:
> "ssp/pie/htb have their own USE flags sep from vanilla, so people can
>  utilize those"
> when in fact the old USE=vanilla behaviour is unavailable now. You have 
> never (as far as I know) answered whether it was intended to keep the
> old behaviour as an option, and if it wasn't, why the log message is
> what it is.

well i cant answer it if you havent asked it ... me not answering you on irc 
when i'm not around does not constitute being ignored and anyone who relies 
on irc in this respect really needs to learn more about irc

the log message looks pretty clear to me, i dont see this "hidden message" 
you're referring to

the ssp/pie/htb patches have their own USE flags so separating them from 
USE=vanilla makes perfect sense ... now you can do:
gentoo patches + ssp
gentoo patches + nossp
vanilla + ssp
vanilla + nossp

whereas before you only had the option of:
gentoo patches + ssp
vanilla + nossp

like i said in my previous e-mail, forcing stubs onto people even when 
USE=vanilla *is by design* because i got tired of people who had no clue 
about the consequences throwing USE=vanilla into their USE in make.conf and 
then complaining when the lack of SSP broke things ... this is also the 
reason i havent added USE=vanilla to glibc, too many users would simply break 
their boxes
-mike

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote:
> On Friday 07 July 2006 19:04, Harald van Dijk wrote:
> > I hope this is specific enough: toolchain.eclass revision 1.234
> > (separating ssp/... from vanilla) log message:
> > "ssp/pie/htb have their own USE flags sep from vanilla, so people can
> >  utilize those"
> > when in fact the old USE=vanilla behaviour is unavailable now. You have 
> > never (as far as I know) answered whether it was intended to keep the
> > old behaviour as an option, and if it wasn't, why the log message is
> > what it is.
> 
> well i cant answer it if you havent asked it ... me not answering you on irc 
> when i'm not around does not constitute being ignored and anyone who relies 
> on irc in this respect really needs to learn more about irc

I also mentioned it in a bugzilla comment, though admittedly not as a
question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to
assume read, right?

> the log message looks pretty clear to me, i dont see this "hidden message" 
> you're referring to
> 
> the ssp/pie/htb patches have their own USE flags so separating them from 
> USE=vanilla makes perfect sense ...

I'm not disagreeing with that, but removing an older option is not just
providing more choices.

>                                     now you can do:
> gentoo patches + ssp
> gentoo patches + nossp
> vanilla + ssp
> vanilla + nossp

gentoo patches + ssp
gentoo patches + stub
vanilla + ssp
vanilla + stub

> whereas before you only had the option of:
> gentoo patches + ssp
> vanilla + nossp

gentoo patches + ssp
gentoo patches + stub
vanilla

> like i said in my previous e-mail, forcing stubs onto people even when 
> USE=vanilla *is by design* because i got tired of people who had no clue 
> about the consequences throwing USE=vanilla into their USE in make.conf and 
> then complaining when the lack of SSP broke things ...

But I'm not asking for USE="vanilla" to disable SSP completely, I'm only
asking for USE="vanilla nossp" to disable it. "nossp" is already
explicitly documented as "NOT FOR GENERAL USE", too.

>                                                        this is also the 
> reason i havent added USE=vanilla to glibc, too many users would simply break 
> their boxes

No complaints there. :)
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Martin Schlemmer]

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

On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote:
> On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote:
> > On Friday 07 July 2006 19:04, Harald van Dijk wrote:

> > the ssp/pie/htb patches have their own USE flags so separating them from 
> > USE=vanilla makes perfect sense ...
> 
> I'm not disagreeing with that, but removing an older option is not just
> providing more choices.
> 
> >                                     now you can do:
> > gentoo patches + ssp
> > gentoo patches + nossp
> > vanilla + ssp
> > vanilla + nossp
> 
> gentoo patches + ssp
> gentoo patches + stub
> vanilla + ssp
> vanilla + stub
> 
> > whereas before you only had the option of:
> > gentoo patches + ssp
> > vanilla + nossp
> 
> gentoo patches + ssp
> gentoo patches + stub
> vanilla
> 
> > like i said in my previous e-mail, forcing stubs onto people even when 
> > USE=vanilla *is by design* because i got tired of people who had no clue 
> > about the consequences throwing USE=vanilla into their USE in make.conf and 
> > then complaining when the lack of SSP broke things ...
> 
> But I'm not asking for USE="vanilla" to disable SSP completely, I'm only
> asking for USE="vanilla nossp" to disable it. "nossp" is already
> explicitly documented as "NOT FOR GENERAL USE", too.
> 

No offence, but you are being very unreasonable in this thread.  The
fact that you can get what you are after, even though its not entirely
supported, should be enough for you, especially for the fact that you
are not clueless.

You should remember that somebody at the end of the day have to
sacrifice time and effort to fix bugs, and especially with something as
complex as gcc, the more variables, the more effort it is going to be.
And as Mike is relatively the only person currently who seems to
maintain gcc, it should be his prerogative to decided that he get too
much spam without the stubs.

And you should really know by now that being documented as "NOT FOR
GENERAL USE" will still not stop more than enough users to waste his
time in telling them not to disable SSP with vanilla if they don't know
what they are doing.


> Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> compiler in Gentoo.

For the fact that we do not support vanilla gcc - I assume this is a gcc
built by yourself - this truly is really unfair of you to expect it.
The 'contract' we usually have with upstream, is that if we apply
patches to their software, we will be the first tier in the support
chain.  Now you want to run gcc which was not modified by us to fix the
known hangups in how we do things - or save us time for that matter, and
you still want us to support it - or at least make life easier for us by
not leaving gaping holes that cost us maintenance time?

Am I the only one feeling that this is really selfish/absurd thinking
since you have such an hackle in what we do, to not research, debug, and
file thus your own bugs with http://gcc.gnu.org/bugzilla/ ?


The alternative to this that you seem to ignore, is that you can start
helping maintaining gcc (I am sure Mike will appreciate help with
Halcy0n gone as well, and me not having that much time currently).  And
of course promising so long as the stubs do not get applied with nossp,
that you will handle all breakage in that area.  Although I do not know
if its still really fair to expect Jakub et ell to sacrifice time to
process the bugs, and get them to you if its related to something
failing due to the missing stubs.



-- 
Martin Schlemmer


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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote:
> On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote:
> > On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote:
> > > On Friday 07 July 2006 19:04, Harald van Dijk wrote:
> 
> > > the ssp/pie/htb patches have their own USE flags so separating them from 
> > > USE=vanilla makes perfect sense ...
> > 
> > I'm not disagreeing with that, but removing an older option is not just
> > providing more choices.
> > 
> > >                                     now you can do:
> > > gentoo patches + ssp
> > > gentoo patches + nossp
> > > vanilla + ssp
> > > vanilla + nossp
> > 
> > gentoo patches + ssp
> > gentoo patches + stub
> > vanilla + ssp
> > vanilla + stub
> > 
> > > whereas before you only had the option of:
> > > gentoo patches + ssp
> > > vanilla + nossp
> > 
> > gentoo patches + ssp
> > gentoo patches + stub
> > vanilla
> > 
> > > like i said in my previous e-mail, forcing stubs onto people even when 
> > > USE=vanilla *is by design* because i got tired of people who had no clue 
> > > about the consequences throwing USE=vanilla into their USE in make.conf and 
> > > then complaining when the lack of SSP broke things ...
> > 
> > But I'm not asking for USE="vanilla" to disable SSP completely, I'm only
> > asking for USE="vanilla nossp" to disable it. "nossp" is already
> > explicitly documented as "NOT FOR GENERAL USE", too.
> > 
> 
> No offence, but you are being very unreasonable in this thread.  The
> fact that you can get what you are after, even though its not entirely
> supported, should be enough for you, especially for the fact that you
> are not clueless.
> 
> You should remember that somebody at the end of the day have to
> sacrifice time and effort to fix bugs, and especially with something as
> complex as gcc, the more variables, the more effort it is going to be.
> And as Mike is relatively the only person currently who seems to
> maintain gcc, it should be his prerogative to decided that he get too
> much spam without the stubs.

Sorry, but how much mail he gets does not affect one bit which behaviour
is better, it only helps understand why the lesser behaviour could be
chosen by reasonable people anyway. (Regardless of which behaviour is
the lesser one.) And I don't harass anyone about -- it's been a very
long time since I even mentioned any problems like this, and if nothing
is done after this thread dies, I'll likely be quiet about it for a long
time again -- so please don't act like I do.

> And you should really know by now that being documented as "NOT FOR
> GENERAL USE" will still not stop more than enough users to waste his
> time in telling them not to disable SSP with vanilla if they don't know
> what they are doing.

I guess that's a fair point.

> > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> > compiler in Gentoo.
> 
> For the fact that we do not support vanilla gcc - I assume this is a gcc
> built by yourself -

Actually, I meant gcc built with the vanilla flag here, as opposed to
pure official GCC, which I already stated is unsupported earlier.

>                     this truly is really unfair of you to expect it.
> The 'contract' we usually have with upstream, is that if we apply
> patches to their software, we will be the first tier in the support
> chain.  Now you want to run gcc which was not modified by us to fix the
> known hangups in how we do things - or save us time for that matter, and
> you still want us to support it - or at least make life easier for us by
> not leaving gaping holes that cost us maintenance time?

Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and
2) added features. (Assuming no patches are broken.) I think it's
reasonable to not rely on the existence of those added features. You
seem to think I think it's reasonable to not rely on bugs being
fixed. No problem there, I don't.

Besides, I said it's unfortunate that vanilla GCC (either one) is
unsupported, not that it must be. My other problem, that vanilla
GCC is different from Gentoo's GCC with the vanilla flag (plus maybe
nossp/nopie/...), can be handled without requiring support for it from
anyone.

> Am I the only one feeling that this is really selfish/absurd thinking
> since you have such an hackle in what we do, to not research, debug, and
> file thus your own bugs with http://gcc.gnu.org/bugzilla/ ?

I actually do file bugs there when I run into them.

> The alternative to this that you seem to ignore, is that you can start
> helping maintaining gcc (I am sure Mike will appreciate help with
> Halcy0n gone as well, and me not having that much time currently).

Since I'm more interested in vanilla GCC, I think there's little to help
maintain from Gentoo's side (support in ebuilds, and possibly the build
process, that's it). If that's something you think help would be good
for anyway, though, sure, if I can.

>                                                                    And
> of course promising so long as the stubs do not get applied with nossp,
> that you will handle all breakage in that area.

I have no problems modifying ebuilds / packages to autodetect flags
instead of assuming they exist myself, if it means vanilla GCC will be
supported feature-wise, for those versions of which the corresponding
Gentoo-patched version is supported.

>                                                 Although I do not know
> if its still really fair to expect Jakub et ell to sacrifice time to
> process the bugs, and get them to you if its related to something
> failing due to the missing stubs.

I /could/ read toolchain@ mail if I would help out with GCC, you know,
which is where such bugs should end up going to currently (those not
closed as dupes) if the package maintainer thinks it's a bug that some
GCC version doesn't support a particular flag. :) Or am I
misunderstanding?
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Martin Schlemmer]

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

On Sat, 2006-07-08 at 13:51 +0200, Harald van Dijk wrote:
> On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote:
> > On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote:
> > > On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote:
> > > > On Friday 07 July 2006 19:04, Harald van Dijk wrote:

> > > > like i said in my previous e-mail, forcing stubs onto people even when 
> > > > USE=vanilla *is by design* because i got tired of people who had no clue 
> > > > about the consequences throwing USE=vanilla into their USE in make.conf and 
> > > > then complaining when the lack of SSP broke things ...
> > > 
> > > But I'm not asking for USE="vanilla" to disable SSP completely, I'm only
> > > asking for USE="vanilla nossp" to disable it. "nossp" is already
> > > explicitly documented as "NOT FOR GENERAL USE", too.
> > > 
> > 
> > No offence, but you are being very unreasonable in this thread.  The
> > fact that you can get what you are after, even though its not entirely
> > supported, should be enough for you, especially for the fact that you
> > are not clueless.
> > 
> > You should remember that somebody at the end of the day have to
> > sacrifice time and effort to fix bugs, and especially with something as
> > complex as gcc, the more variables, the more effort it is going to be.
> > And as Mike is relatively the only person currently who seems to
> > maintain gcc, it should be his prerogative to decided that he get too
> > much spam without the stubs.
> 
> Sorry, but how much mail he gets does not affect one bit which behaviour
> is better, it only helps understand why the lesser behaviour could be
> chosen by reasonable people anyway. (Regardless of which behaviour is
> the lesser one.) And I don't harass anyone about -- it's been a very
> long time since I even mentioned any problems like this, and if nothing
> is done after this thread dies, I'll likely be quiet about it for a long
> time again -- so please don't act like I do.
> 

Actually it does if it cuts back his time by a very large percentage so
that he cannot do the other things he wants/needs to.  I assume this was
the case if he added that in the first place, and still refuse to change
it.

> > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
> > > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
> > > compiler in Gentoo.
> > 
> > For the fact that we do not support vanilla gcc - I assume this is a gcc
> > built by yourself -
> 
> Actually, I meant gcc built with the vanilla flag here, as opposed to
> pure official GCC, which I already stated is unsupported earlier.
> 

Hmm, thought I might have had it a tad wrong.  I still though do not
understand what the whole fuss is about stubs for some 5 flags.  (which
is what you are left with with USE="vanilla nossp" currently if my
memory is correct).  Maybe read down a bit before replying here.

> >                     this truly is really unfair of you to expect it.
> > The 'contract' we usually have with upstream, is that if we apply
> > patches to their software, we will be the first tier in the support
> > chain.  Now you want to run gcc which was not modified by us to fix the
> > known hangups in how we do things - or save us time for that matter, and
> > you still want us to support it - or at least make life easier for us by
> > not leaving gaping holes that cost us maintenance time?
> 
> Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and
> 2) added features. (Assuming no patches are broken.) I think it's
> reasonable to not rely on the existence of those added features.

I think its reasonable to no force the feature on you, but add the stubs
if it became a maintenance headache.  I am pretty sure it was not
toolchain who brought the whole situation about in the first place.

You can however fix the tree to make sure it will fully build without
those flags, and then talk to Mike again about removing them.  I am sure
he might be more willing if it will not steal his time again.

>  You
> seem to think I think it's reasonable to not rely on bugs being
> fixed. No problem there, I don't.
> 

Not at all.  I thought you think its reasonable to just keep loading
work on other people - or possible did not see that that would have been
the end result.  More about this to the end.

> Besides, I said it's unfortunate that vanilla GCC (either one) is
> unsupported, not that it must be. My other problem, that vanilla
> GCC is different from Gentoo's GCC with the vanilla flag (plus maybe
> nossp/nopie/...), can be handled without requiring support for it from
> anyone.
> 

From the length of this email, and you not wanting to see the reasoning,
or not having started to fix the tree so that your wish can be full
filled, It rather sounded like you did demand it.  Or this was at least
the impression I got.

Also once again I do not see what the big issue with the stubs is.  You
keep making a big issue out of it without giving concrete examples or
serious issues it is causing.  The problem was there before they were
added, and not due to them - its even possible that with test_flag() its
less of an issue now.  Still read down a bit before replying here.

> > The alternative to this that you seem to ignore, is that you can start
> > helping maintaining gcc (I am sure Mike will appreciate help with
> > Halcy0n gone as well, and me not having that much time currently).
> 
> Since I'm more interested in vanilla GCC, I think there's little to help
> maintain from Gentoo's side (support in ebuilds, and possibly the build
> process, that's it). If that's something you think help would be good
> for anyway, though, sure, if I can.
> 

Vanilla, Gentoo patched - they all have bugs which bugzilla have more
than enough of in.  And in the perfect world Gentoo patched gcc will
have less bugs than the Vanilla one.

> >                                                                    And
> > of course promising so long as the stubs do not get applied with nossp,
> > that you will handle all breakage in that area.
> 
> I have no problems modifying ebuilds / packages to autodetect flags
> instead of assuming they exist myself, if it means vanilla GCC will be
> supported feature-wise, for those versions of which the corresponding
> Gentoo-patched version is supported.
> 

OK, maybe I was just too dense to see it before, or maybe you kept
dancing around the issue.  To put it clear (or try at least), your whole
issue currently is that you cannot use a 'Vanilla' gcc (ie without the
stubs) to build everything in the tree ?  And not as much the stubs them
selfs ?

If this is the case, then I think you have been barking up the wrong
tree this whole time.  It was not toolchain who assumed flags are
present in some gcc to whatever packages - we just maintain the
toolchain.  And I am sure not all the blame will fall on hardened
either, as many package maintainers for packages that would not work
with SSP might have fixed it by just disabling it via CFLAGS.

So really, hitting the specific maintainers or upstream with a clue
stick would have been the logical solution that did not bog down
toolchain even more.

> >                                                 Although I do not know
> > if its still really fair to expect Jakub et ell to sacrifice time to
> > process the bugs, and get them to you if its related to something
> > failing due to the missing stubs.
> 
> I /could/ read toolchain@ mail if I would help out with GCC, you know,
> which is where such bugs should end up going to currently (those not
> closed as dupes) if the package maintainer thinks it's a bug that some
> GCC version doesn't support a particular flag. :) Or am I
> misunderstanding?

I think you understood wrongly.

If the stubs were to be just removed say tomorrow, and breakage in the
tree is still of such an extend that bugs starts to flood in again, its
not just you that will have to read the mail.  If the user is clueless,
then Jakub have to reassign the bug to either toolchain or the package
maintainer.  If he could not determine it was due to the missing CFLAG,
and it ended up with the package maintainer, then they would have had to
reassign it to toolchain.  Either case, if it was a very bad report,
they would first have to spend time and effort in getting the correct
information.  And besides all that, for each reassignment or comment to
the bug, it would have been extra mail that a few or possible a lot of
people had to have spend time on to read (except if they >/dev/null it,
but then they could miss possible need to check them selfs on it again).

So I really just wanted to make you think about how things could (and
probably did) cascade before the stubs was added.



-- 
Martin Schlemmer


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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Harald van Dijk]

(Not commenting on the whole message, just parts.)

On Sat, Jul 08, 2006 at 03:46:24PM +0200, Martin Schlemmer wrote:
> You can however fix the tree to make sure it will fully build without
> those flags, and then talk to Mike again about removing them.  I am sure
> he might be more willing if it will not steal his time again.

I ask again: would such patches be accepted? (Mike stated he would
remove stubs once GCC 4.1 is stable -- thanks -- so users wouldn't run
into problems often regardless.)

> Vanilla, Gentoo patched - they all have bugs which bugzilla have more
> than enough of in.

Ah yes, I see some that definitely apply to USE=vanilla builds. I'll see
if there's anything I can understand. :)

> OK, maybe I was just too dense to see it before, or maybe you kept
> dancing around the issue.  To put it clear (or try at least), your whole
> issue currently is that you cannot use a 'Vanilla' gcc (ie without the
> stubs) to build everything in the tree ?

No, being able to use vanilla GCC as Gentoo's system compiler would be a
nice addition, and if it's agreed as a good idea I don't mind helping
out with getting it working, but I can live without it.

> And not as much the stubs them selfs ?

Being able to check software for unofficial compiler flags is for some
cases a must.

I repeat: two separate issues. They keep getting mixed up here.

> I think you understood wrongly.
> 
> If the stubs were to be just removed say tomorrow, and breakage in the
> tree is still of such an extend that bugs starts to flood in again, its
> not just you that will have to read the mail.  If the user is clueless,
> then Jakub have to reassign the bug to either toolchain or the package
> maintainer.  If he could not determine it was due to the missing CFLAG,

The error is very clear:
 cc1: error: unrecognized command line option "-fno-stack-protector"

Maybe I have a little bit more confidence in people, sorry if that's
misplaced. :)
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Jakub Moc]

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

Harald van Dijk wrote:
>> If the stubs were to be just removed say tomorrow, and breakage in the
>> tree is still of such an extend that bugs starts to flood in again, its
>> not just you that will have to read the mail.  If the user is clueless,
>> then Jakub have to reassign the bug to either toolchain or the package
>> maintainer.  If he could not determine it was due to the missing CFLAG,
> 
> The error is very clear:
>  cc1: error: unrecognized command line option "-fno-stack-protector"
> 
> Maybe I have a little bit more confidence in people, sorry if that's
> misplaced. :)

Erm, yeah I can recognize the error, but it's really not very productive
to dupe the bugs over and over again. Killing the stubs breaks glibc
compile [1] and it breaks perl compile [2] as well.

[1] http://bugs.gentoo.org/show_bug.cgi?id=101471
[2] http://bugs.gentoo.org/show_bug.cgi?id=106965

I don't really see how is this a good idea to break two pretty critical
packages for users that have no clue what USE=vanilla does w/ gcc.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

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

On Saturday 08 July 2006 02:20, Harald van Dijk wrote:
> I also mentioned it in a bugzilla comment, though admittedly not as a
> question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to
> assume read, right?

the gcc2 bug has a lot of things in there i need to review/merge so it's in 
my "little" TODO box

> > like i said in my previous e-mail, forcing stubs onto people even when
> > USE=vanilla *is by design* because i got tired of people who had no clue
> > about the consequences throwing USE=vanilla into their USE in make.conf
> > and then complaining when the lack of SSP broke things ...
>
> But I'm not asking for USE="vanilla" to disable SSP completely, I'm only
> asking for USE="vanilla nossp" to disable it. "nossp" is already
> explicitly documented as "NOT FOR GENERAL USE", too.

well, vanilla is marked the same way, yet people use it ;)

but as i said, i'll add 'use vanilla || apply_stub' logic once 4.1.x goes 
stable, just no sooner
-mike

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

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

On Thursday 06 July 2006 15:55, Harald van Dijk wrote:
> I don't have a lot of trust in Gentoo's patches, as they have resulted
> in completely and utterly unusable ld, and (minor) data loss due to a
> miscompilation by Gentoo's gcc, in the past.

historically i'd agree with you but i'm pretty confident that this has gotten 
a ton better with 3.3.6 / 3.4.6 / 4.0.3 / 4.1.1

> Also, being able to check 
> whether your own software compiles with a GNU toolchain is to me a good
> thing.

USE=vanilla
-mike

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

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Ciaran McCreesh]

On Thu, 6 Jul 2006 21:42:20 +0200 "Kevin F. Quinn"
<kevquinn@gentoo.org> wrote:
| On Thu, 6 Jul 2006 21:06:18 +0200
| Harald van Dijk <truedfx@gentoo.org> wrote:
| > The GNU toolchain is not supported by Gentoo, and in fact gets
| > actively broken with unsupported command-line options. Only the GNU
| > toolchain as modified by Gentoo's toolchain guys is supported,
| > unfortunately.
| 
| What exactly is it about the toolchain supplied with Gentoo that
| causes you problems?

Selective and partial backporting of patches that leads to the C++
standard library code getting broken?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Stephen Bennett]

On Thu, 6 Jul 2006 20:56:31 +0100
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> Selective and partial backporting of patches that leads to the C++
> standard library code getting broken?

Obviously not an issue. Noone uses C++ anyway.
-- 
gentoo-dev@gentoo.org mailing list

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

[Mike Frysinger]

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

On Thursday 06 July 2006 15:56, Ciaran McCreesh wrote:
> Selective and partial backporting of patches that leads to the C++
> standard library code getting broken?

that patch was picked up by more than just Gentoo and then just as summarily 
punted
-mike

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Enrico Weigelt]

* Ned Ludd <solar@gentoo.org> schrieb:

<snip>

> Non gcc compilers have never been supported and probably never will be.

If someone decides to work on that topic, IMHO the best approach
would be providing an gcc-style frontend, so we actually get
an drop-in-replacement (at least from the command line view).

I've done something similar w/ my universal toolchain project,
which works compiler-independent (although I currently have only
an gcc backend ;-o) and also provides an drop-in-replacement for
libtool w/ gcc as an additional frontend.

    http://wiki.metux.de/public/Universal_Toolchain

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Harald van Dijk]

On Tue, Jul 25, 2006 at 02:14:46PM +0200, Enrico Weigelt wrote:
> * Ned Ludd <solar@gentoo.org> schrieb:
> 
> <snip>
> 
> > Non gcc compilers have never been supported and probably never will be.
> 
> If someone decides to work on that topic, IMHO the best approach
> would be providing an gcc-style frontend, so we actually get
> an drop-in-replacement (at least from the command line view).

What would it do if a gcc-specific option is used for which the real
compiler does not provide any option, even with a different name? If
it would ignore it, things would break horribly (just think of
-funsigned-char). If it would error out, are any options other than
those already specified by POSIX (`man 1p c99`) available on all
systems? (If not, no gcc-style frontend is necessary, because the
options are already the same for all compilers intended to be
usable as a (Unix-like-)system compiler.)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Enrico Weigelt]

* Harald van D??k <truedfx@gentoo.org> schrieb:

hi,

> What would it do if a gcc-specific option is used for which 
> the real compiler does not provide any option, even with a 
> different name? 

hmm, tricky. 

I've filed an bug in gcc-upstream for an similar issue, where
gcc/ld is missing some an flag allowing to filter exported 
symbols of shared libs. Hopefully this issue will be solved
soon by the gcc team. Until then I have to strip off that option,
hoping it does not break anything.

But nevertheless it would be a great step to adapt at least
those options which are supported. Completely unsupported 
options (which cannot be substituted somehow) are a major
problem anyways.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Enrico Weigelt]

* Donnie Berkholz <spyderous@gentoo.org> schrieb:
> Diego 'Flameeyes' Pettenò wrote:
> >         echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null
> 
> > Thoughts? Comments?
> 
> How will you handle non-gcc compilers?

Maybe it goes out of gentoo's scope, but I'm developing an 
universal toolchain wrapper which also supplies an gcc-style 
libtool frontend:

    http://wiki.metux.de/public/Universal_Toolchain
    
Perhaps someone likes to have a look at it.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 12:52:29 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags
| present in the tree, almost never used to get new dependencies, but
| usually used to supply econf switches.
| 
| This works as long as the user enable the flags, but for AMD64 the
| story was, until now, that we simply enabled them when they worked,
| because we had some minimum support available. Unfortunately this
| became a problem with the introduction of nocona, because that is an
| amd64-like system but with no 3dnow. And there is the problem that
| sse3 is supported only in later versions of Athlon64 and so on.

The other option here... Is to rename the x86 flags to x86_mmx,
x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not
really the same as the x86 flags.

There's probably some USE_EXPAND trickery that can be used here...
CPU_FEATURE_X86="mmx sse" -> cpu_feature_x86_mmx etc might be cleaner?

| To try to clean up this mess, and to make it simpler to work in 
| cross-compilation, I thought of using the definitions created by the
| C Preprocessor (CPP) by default for the given CFLAGS. Basically when 
| using -march=athlon64, the preprocessor will enable a few definitions
| that tells the availability of MMX, 3dNOW, SSE and so on... if we
| wrap that around, we can use it to know if it's the case of enabling
| something or not. This is customisable by the user by setting the
| CFLAGS themselves. If one does not want MMX instructions to be
| generated, but still want the rest of Athlon64 optimisations, it's
| simply the matter of using "-march=athlon64 -mno-mmx".

Sounds rather flaky and unreliable...

| SPARC team: I'd like to know if VIS does a similar thing, would make
| simpler for instance its handling in xine-lib ebuild.

VIS is present on all v9 CPUs. GCC's VIS support, however, sucks.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote:
> Sounds rather flaky and unreliable...
Sounds rather vague and without arguments.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 14:29:39 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote:
| > Sounds rather flaky and unreliable...
| Sounds rather vague and without arguments.

Well, you're assuming that a) everyone's using a C compiler, b) that
gcc has the slightest clue what it's doing, c) that the user has no
problem using nasty hacks to regain control, d) that this information
is only needed at compile time, e) that various gcc internal
definitions won't change... You're adding a lot of complexity, and thus
room for very weird breakages, to something that doesn't need it.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Olivier Crête]

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

On Thu, 2006-06-07 at 13:49 +0100, Ciaran McCreesh wrote:
> On Thu, 6 Jul 2006 14:29:39 +0200 "Diego 'Flameeyes' Pettenò"
> <flameeyes@gentoo.org> wrote:
> | On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote:
> | > Sounds rather flaky and unreliable...
> | Sounds rather vague and without arguments.
> 
> Well, you're assuming that
> a) everyone's using a C compiler,

If you're on Gentoo, I sure hope you have a C compiler

> b) that gcc has the slightest clue what it's doing,

Again, if you've compiled your whole system with gcc, I guess its a safe
bet

> c) that the user has no problem using nasty hacks to regain control,

Since when is setting your -march/-mnosse/-mnommx/-mno3dnow a nasty
hack?

> d) that this information is only needed at compile time,

I agree this is a problem..

> e) that various gcc internal definitions won't change... 

We can always change the eclass and check the GCC version if that
happens.

-- 
Olivier Crête
tester@gentoo.org

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Ciaran McCreesh wrote:
> Well, you're assuming that a) everyone's using a C compiler, b) that
> gcc has the slightest clue what it's doing, c) that the user has no
> problem using nasty hacks to regain control, d) that this information
> is only needed at compile time, e) that various gcc internal
> definitions won't change... You're adding a lot of complexity, and thus
> room for very weird breakages, to something that doesn't need it.

as for...

b) You kind of have to assume that when running a system that was 
compiled from ground up with gcc

c) This is not about "regaining" control. Currently, users who want to 
cross-compile are screwed and need nasty use.mask-hacks to not end up 
with broken binaries. The inability to provide per-package CFLAGS is a 
missing feature in portage, it's got nothing to do with this issue.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 06 Jul 2006 16:03:47 +0200 Simon Stelling <blubb@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > Well, you're assuming that a) everyone's using a C compiler, b) that
| > gcc has the slightest clue what it's doing, c) that the user has no
| > problem using nasty hacks to regain control, d) that this
| > information is only needed at compile time, e) that various gcc
| > internal definitions won't change... You're adding a lot of
| > complexity, and thus room for very weird breakages, to something
| > that doesn't need it.
| 
| as for...
| 
| b) You kind of have to assume that when running a system that was 
| compiled from ground up with gcc

Not really true. GCC can be quite happily wrong about what your CPU
could support, so long as it's not told to use it. This happens with
VIS, for example.

| c) This is not about "regaining" control. Currently, users who want
| to cross-compile are screwed and need nasty use.mask-hacks to not end
| up with broken binaries. The inability to provide per-package CFLAGS
| is a missing feature in portage, it's got nothing to do with this
| issue.

You can do it through bashrc. But then, if this is about working around
Portage's annoying lack of sane cross compile handling, why not put a
little effort into fixing it properly rather than a lot of effort into
making the tree more complicated?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Ciaran McCreesh wrote:
> You can do it through bashrc. But then, if this is about working around
> Portage's annoying lack of sane cross compile handling, why not put a
> little effort into fixing it properly rather than a lot of effort into
> making the tree more complicated?

Err, I think you're mixing up different things. How should portage be 
able to do sane cross compiling if you control the instruction sets 
through use flags which are blocked in profiles the build system is 
using? In fact, moving away from use flags over to the real(TM) solution 
is a step towards fixing the issue. Also, it doesn't make the tree more 
complicated. It is far more intuitive that supported instruction sets 
are used if the user doesn't explicitly wish not to than having some 
strange use flags that don't mean what they're named like.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 06 Jul 2006 17:09:42 +0200 Simon Stelling <blubb@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > You can do it through bashrc. But then, if this is about working
| > around Portage's annoying lack of sane cross compile handling, why
| > not put a little effort into fixing it properly rather than a lot
| > of effort into making the tree more complicated?
| 
| Err, I think you're mixing up different things. How should portage be 
| able to do sane cross compiling if you control the instruction sets 
| through use flags which are blocked in profiles the build system is 
| using?

That's just it. You shouldn't be using the wrong profile when compiling
things.

| In fact, moving away from use flags over to the real(TM)
| solution is a step towards fixing the issue. Also, it doesn't make
| the tree more complicated. It is far more intuitive that supported
| instruction sets are used if the user doesn't explicitly wish not to
| than having some strange use flags that don't mean what they're named
| like.

That's like saying "well we should just link against whatever's
available, it's far more intuitive than letting the user decide".

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ned Ludd]

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

On Thu, 2006-07-06 at 17:09 +0200, Simon Stelling wrote:
> Ciaran McCreesh wrote:
> > You can do it through bashrc. But then, if this is about working around
> > Portage's annoying lack of sane cross compile handling, why not put a
> > little effort into fixing it properly rather than a lot of effort into
> > making the tree more complicated?
> 
> Err, I think you're mixing up different things. 


> How should portage be 
> able to do sane cross compiling if you control the instruction sets 
> through use flags which are blocked in profiles the build system is 
> using? 

That is not the case anymore.. See PORTAGE_CONFIGROOT= and the
attachment as an example which solves this exact problem.

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

[-- Attachment #2: Type: text/plain, Size: 437 bytes --]

export PORTDIR=$(portageq envvar PORTDIR)
export ROOT=/dev/shm/blah
export PORTAGE_CONFIGROOT=${ROOT}
PROFILES="$(grep ^[a-z,0-9] ${PORTDIR}/profiles/profiles.desc | awk '{print $2}' | sort -u)"

mkdir -p ${PORTAGE_CONFIGROOT}/etc/
cd ${PORTAGE_CONFIGROOT}/etc/
for p in ${PROFILES}; do
	rm -f make.profile
	ln -s ../../../../${PORTDIR}/profiles/${p} make.profile
	touch make.conf
	ls -ld $(readlink -f make.profile)
	emerge --info
done

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Mike Frysinger]

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

On Thursday 06 July 2006 10:03, Simon Stelling wrote:
> c) This is not about "regaining" control. Currently, users who want to
> cross-compile are screwed and need nasty use.mask-hacks to not end up
> with broken binaries. The inability to provide per-package CFLAGS is a
> missing feature in portage, it's got nothing to do with this issue.

deficiency in portage that is being slowly resolved ... this is hardly 
specific to cpu-based USE flags and deserves nothing short of a real fix on 
the portage side

as for "broken binaries", i kind of doubt that statement ... when was the last 
time you saw a cross-toolchain accept assembly code written for a different 
architecture ?  now if you had said broken builds, i would have agreed with 
you slightly ... but again, refer to the "this is hardly specific to 
cpu-based USE flags" statement from earlier
-mike

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 02:50, Mike Frysinger wrote:
> as for "broken binaries", i kind of doubt that statement ... when was the
> last time you saw a cross-toolchain accept assembly code written for a
> different architecture ?
x86_64 toolchain accepting 3dnow on a nocona arch? :)

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Mike Frysinger]

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

On Thursday 06 July 2006 20:58, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 02:50, Mike Frysinger wrote:
> > as for "broken binaries", i kind of doubt that statement ... when was the
> > last time you saw a cross-toolchain accept assembly code written for a
> > different architecture ?
>
> x86_64 toolchain accepting 3dnow on a nocona arch? :)

that isnt a cross-compile nor a different architecture
-mike

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 03:15, Mike Frysinger wrote:
> > x86_64 toolchain accepting 3dnow on a nocona arch? :)
> that isnt a cross-compile nor a different architecture
This is the whole point of my solution.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

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

On Fri, 2006-07-07 at 04:28 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 03:15, Mike Frysinger wrote:
> > > x86_64 toolchain accepting 3dnow on a nocona arch? :)
> > that isnt a cross-compile nor a different architecture
> This is the whole point of my solution.
> 

From what you discussed above, it sounds more like a problem due to
short-sightedness on the amd64 team's part (no offence to amd64 team,
just stating things as I see them) because they just enabled 3dnow for
stuff that worked regardless.

Stupid question though ... does the gcc test thingy list __3dNOW__ on
nocona ?  I would think that it does, as there is no -march=nocona (or
whatever) yet.

So now you want to instead of fixing the amd64 profiles to be more
flexible, implement something that will give the green light to users on
x86 to use flag combinations, especially on older gcc's that causes
great pain for themselfs and developers ?

Sure, nocona should have had CFLAGS="-march=k8 -mno-3dnow", but it would
never have been an issue if the '3dnow' USE flag worked as expected on
amd64 ;)

Anyhow, just ranting - I understand the reasoning for doing it that way,
but you should also see it from the x86 side where -msse could really
mean a broken system, and maybe rethink your solution.


-- 
Martin Schlemmer


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Graham Murray]

Martin Schlemmer <azarah@nosferatu.za.org> writes:

> Stupid question though ... does the gcc test thingy list __3dNOW__ on
> nocona ?  I would think that it does, as there is no -march=nocona (or
> whatever) yet.

There is an -march=nocona (which I think was introduced in gcc 3.4)
which works for both 32bit (x86) and 64bit (amd64) systems. At least
on x86 it does NOT define __3dNOW__. Also, for x86 -march=prescott
defines __SSE3__ whereas -march=pentium4 does not.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Martin Schlemmer wrote:
> Stupid question though ... does the gcc test thingy list __3dNOW__ on
> nocona ?  I would think that it does, as there is no -march=nocona (or
> whatever) yet.

There is a -march=nocona, and it doesn't define __3dNOW__.

> So now you want to instead of fixing the amd64 profiles to be more
> flexible, implement something that will give the green light to users on
> x86 to use flag combinations, especially on older gcc's that causes
> great pain for themselfs and developers ?

I don't understand this. Why is '-march=i686 -m3dnow' bad if it results in the
same thing as '-march=athlon-xp'? I guess I'm just lacking facts here, so please
give me a hint :)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

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

On Fri, 2006-07-07 at 15:21 +0200, Simon Stelling wrote:
> Martin Schlemmer wrote:
> > Stupid question though ... does the gcc test thingy list __3dNOW__ on
> > nocona ?  I would think that it does, as there is no -march=nocona (or
> > whatever) yet.
> 
> There is a -march=nocona, and it doesn't define __3dNOW__.
> 

Missed that, sorry.

> > So now you want to instead of fixing the amd64 profiles to be more
> > flexible, implement something that will give the green light to users on
> > x86 to use flag combinations, especially on older gcc's that causes
> > great pain for themselfs and developers ?
> 
> I don't understand this. Why is '-march=i686 -m3dnow' bad if it results in the
> same thing as '-march=athlon-xp'? I guess I'm just lacking facts here, so please
> give me a hint :)
> 

Check Chris Gianelloni's mail just now.  For some compilers with some
-march's on x86 it did not explicitly turn on some features (or maybe
not to such a high extend).  So where say CFLAGS="-march=pentium3" would
work, CFLAGS="-march=pentium3 -msse" would fail to build, or generate
bad code (segfaulting binaries).


-- 
Martin Schlemmer


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 15:53, Martin Schlemmer wrote:
> Check Chris Gianelloni's mail just now.  For some compilers with some
> -march's on x86 it did not explicitly turn on some features (or maybe
> not to such a high extend).
Uh no, I think he meant that for some borderline processors there's not 
a -march value, like for Athlon64 Revision D, that has sse3 support. In those 
cases you have to use -msse3 or whatever else to tell the compiler what to 
generate.

> So where say CFLAGS="-march=pentium3" would 
> work, CFLAGS="-march=pentium3 -msse" would fail to build, or generate
> bad code (segfaulting binaries).
This might have been true with _older_ GCC, but all the series 3.3, 3.4, 4.0 
and 4.1 behaves correctly: -march=pentium3 implies -msse without doubt.

What you might incorrectly remember is -mfpmath=sse that is totally another 
thing, and dies usually on bad code anyway, and it's enabled by default on 
64-bit CPUs just because on there the 80-bit limit for doubles is not 
pertinent anymore.

I might seem an idiot, but I have enough experience to know what I'm talking 
about. Seems instead that other people confuse SEGFAULT with SIGILL and -msse 
with -mfpmath=sse (or simply remember just what happened with GCC 3.2).

A little note here: tools improve. GCC 2.95 was a joke, GCC 3.0, 3.1 were 
almost unusable, 3.2 started to be usable but full of problems, 3.3/3.4 
series improved, drastically.
Stuff like visibility is badly broken up to 4.0, but works fine on 4.1. You 
cannot think that a flag or a support will always be broken because a release 
had it broken, you have to watch what you're doing to do it correctly.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

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

On Fri, 2006-07-07 at 16:03 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 15:53, Martin Schlemmer wrote:
> > Check Chris Gianelloni's mail just now.  For some compilers with some
> > -march's on x86 it did not explicitly turn on some features (or maybe
> > not to such a high extend).
> Uh no, I think he meant that for some borderline processors there's not 
> a -march value, like for Athlon64 Revision D, that has sse3 support. In those 
> cases you have to use -msse3 or whatever else to tell the compiler what to 
> generate.
> 
> > So where say CFLAGS="-march=pentium3" would 
> > work, CFLAGS="-march=pentium3 -msse" would fail to build, or generate
> > bad code (segfaulting binaries).
> This might have been true with _older_ GCC, but all the series 3.3, 3.4, 4.0 
> and 4.1 behaves correctly: -march=pentium3 implies -msse without doubt.
> 
> What you might incorrectly remember is -mfpmath=sse that is totally another 
> thing, and dies usually on bad code anyway, and it's enabled by default on 
> 64-bit CPUs just because on there the 80-bit limit for doubles is not 
> pertinent anymore.
> 

As I pointed out on irc (to clarify), its still an issue even with
gcc-3.4.6.  Its just well enough filtered, and as Mike pointed out, they
'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from
4.0.1 I think.

> I might seem an idiot, but I have enough experience to know what I'm talking 
> about. Seems instead that other people confuse SEGFAULT with SIGILL and -msse 
> with -mfpmath=sse (or simply remember just what happened with GCC 3.2).
> 

I did not imply this as far I know, and if it seemed that way, I can
only say that I assumed that newer guys had the advantage of most
ebuilds filtering or -mno-sse/whatever for known broken stuff (I know
xorg was one with a few workarounds, also mozilla, etc at at some
stage), so would not have noticed if sse/whatever broke something.
That, and not being on the toolchain list you might not be familiar with
the extend of the issue, with the fact that its different issues with
different versions depending besides that on if its a i586, k6, p2, p3
or p4, etc.

> A little note here: tools improve. GCC 2.95 was a joke, GCC 3.0, 3.1 were 
> almost unusable, 3.2 started to be usable but full of problems, 3.3/3.4 
> series improved, drastically.
> Stuff like visibility is badly broken up to 4.0, but works fine on 4.1. You 
> cannot think that a flag or a support will always be broken because a release 
> had it broken, you have to watch what you're doing to do it correctly.
> 

I'd say only 4.0.1 and upwards really solved most of those issues,
especially the long comming sse one.


-- 
Martin Schlemmer


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 17:31, Martin Schlemmer wrote:
> As I pointed out on irc (to clarify), its still an issue even with
> gcc-3.4.6.  Its just well enough filtered, and as Mike pointed out, they
> 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from
> 4.0.1 I think.
For what I know, the last issue was fixed with 3.3/3.4, so this sounds new to 
me.
That said, I think this is up to now the only point that would make me rethink 
over this whole idea. For a pure simple and practical problem.

> I did not imply this as far I know, and if it seemed that way, I can
> only say that I assumed that newer guys had the advantage of most
> ebuilds filtering or -mno-sse/whatever for known broken stuff
Probably, but never assume that gentoo is the first experience for everyone ;) 
I had my own share of GCC problems way before, and I remember how much shit 
GCC 3.2 created, 3.3 compared to it was a different order of magnitude: it 
worked.

> I'd say only 4.0.1 and upwards really solved most of those issues,
> especially the long comming sse one.
Maybe because SSE wasn't that widespread in the past, I remember most issues 
to be related to MMX/3Dnow! extensions mainly, a part a big one with -msse 
that I thought dead with GCC 3.3, but I might be mistaken on that then, and I 
beg you pardon in that case.

Of course there's the usual -mfpmath=sse that do cause problems on 32-bit 
systems (although it's the default on 64-bit).

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Mike Frysinger]

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

On Friday 07 July 2006 13:22, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 17:31, Martin Schlemmer wrote:
> > As I pointed out on irc (to clarify), its still an issue even with
> > gcc-3.4.6.  Its just well enough filtered, and as Mike pointed out, they
> > 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from
> > 4.0.1 I think.
>
> For what I know, the last issue was fixed with 3.3/3.4, so this sounds new
> to me.

i dont think the segfaults applied to the 3.3 branch as the code was new to 
the 3.4 branch

the issues were worked around in 3.4.5 via specs filtering, 3.4.6 included one 
fix and i backported the other, 3.4.4 and older i dont know the status of 
(but i'd be inclined to push people to 3.4.6 anyways and cut 3.4.[0-4])

> That said, I think this is up to now the only point that would make me
> rethink over this whole idea. For a pure simple and practical problem.

doesnt seem like a valid roadblocker to me ... but i see the toolchain as 
something higher up guys shouldnt have to worry/think about; fix the gcc 
bugs, dont work around them in ebuilds
-mike

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Kevin F. Quinn]

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

On Thu, 6 Jul 2006 13:49:39 +0100
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Thu, 6 Jul 2006 14:29:39 +0200 "Diego 'Flameeyes' Pettenò"
> <flameeyes@gentoo.org> wrote:
> | On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote:
> | > Sounds rather flaky and unreliable...
> | Sounds rather vague and without arguments.
> 
> Well, you're assuming that a) everyone's using a C compiler,
> b) that gcc has the slightest clue what it's doing,

We're mostly talking about specially-written assembler code, not stuff
like vectorisation or the intrinsics (which very few packages use, if
any).

> c) that the user has no
> problem using nasty hacks to regain control,

Control is easy.  Specify the relevant -march in CFLAGS.

> d) that this information is only needed at compile time,

Where a package does run-time detection, there's no need for any
conditional compilation as they build for everything anyway, so such
packages wouldn't use mmx/sse/sse2 etc USE flags anyway.

> e) that various gcc internal definitions won't change...

Unlikely for these macros, as that would break a lot of existing code
regardless what we do.

> You're adding a lot of complexity, and
> thus room for very weird breakages, to something that doesn't need it.

I'd argue the current approach is the more complex approach, involving
the user having to discover the relationship between their processor
(which they've already set via -march in CFLAGS) and the various bits
that their processor has.


There are relatively few packages affected (<1%), so I think it's worth
a try.  In the end it may be that a few packages need to deal with
stuff manually like with the current USE flags, but they'd be local USE
flags at that point.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Enrico Weigelt]

* Kevin F. Quinn <kevquinn@gentoo.org> schrieb:

> Where a package does run-time detection, there's no need for any
> conditional compilation as they build for everything anyway, so such
> packages wouldn't use mmx/sse/sse2 etc USE flags anyway.

Well, there are still valid reasons: if you *know* you'll run the
binary only on non-mmx systems, you'd probably get rid of it to
make the binary smaller and reduce possible points of errors.

I'd consider the runtime-detection just as an extra failsafe check.

<snip>

> There are relatively few packages affected (<1%), so I think it's worth
> a try.  In the end it may be that a few packages need to deal with
> stuff manually like with the current USE flags, but they'd be local USE
> flags at that point.

ACK. Nobody forbids some packages having their own local useflags,
if really necessary.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
> Well, you're assuming that
Properly listing, what an arcane science.

> a) everyone's using a C compiler,
No, I assume that everyone is using a compiler. You cannot have a C++ compiler 
without a C compiler. The first person I see that sets CXXFLAGS but not 
CFLAGS I'm personally going to give him the "doesn't have a clue" prize.

> b) that gcc has the slightest clue what it's doing,
No, I assume that gcc has a big clue about which capabilities are available to 
the -march switch. I might be assuming that users have a clue on what they 
are doing, but that's an assumption I do have to do, or I shouldn't be 
working on Gentoo but on Debian, which seems pretty good at optimising for 
i386 still.

> c) that the user has no problem using nasty hacks to regain control,
Where "regain control" is "doing something that could have done before but 
made actually no sense to do before. And the bashrc thing is not a big nasty 
hack, works quite well for me.

> d) that this information is only needed at compile time,
Well of course use flags are available at runtime for the packages built to 
know, this is perfectly logic of you.

You really was getting out of arguments, don't you?

If I have to enable a configure switch I need it only at buildtime. If it has 
to be known at runtime there's the cpuid function!

> e) that various gcc internal definitions won't change... 
It's like assuming that gcc will always output the correct hello world for

int main() {
	printf("Hello, world!\n");
	return 0;
}

If it does change those values, it's going to be a killer for way more than 
just Portage.

> You're adding a lot of complexity, and thus 
> room for very weird breakages, to something that doesn't need it.
You're not exposing any of such breakages, I find it to reduce complexity to 
users that cannot try to enable SSE3 on an Athlon-TBird system.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 18:43:11 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
| > Well, you're assuming that
| Properly listing, what an arcane science.

Perhaps I should've written a Java + XML app that automatically formats
messages according to what the reader probably wants to see.
 
| > a) everyone's using a C compiler,
|
| No, I assume that everyone is using a compiler. You cannot have a C++
| compiler without a C compiler. The first person I see that sets
| CXXFLAGS but not CFLAGS I'm personally going to give him the "doesn't
| have a clue" prize.

And for a single compile?

| > b) that gcc has the slightest clue what it's doing,
|
| No, I assume that gcc has a big clue about which capabilities are
| available to the -march switch. I might be assuming that users have a
| clue on what they are doing, but that's an assumption I do have to
| do, or I shouldn't be working on Gentoo but on Debian, which seems
| pretty good at optimising for i386 still.

And your assumption would be wrong. I can assure you that relying upon
-march doing anything sensible with __MAGIC__ is entirely unsafe. Go
and look at the VIS handling if you want a perfect example.
 
| > c) that the user has no problem using nasty hacks to regain control,
|
| Where "regain control" is "doing something that could have done
| before but made actually no sense to do before. And the bashrc thing
| is not a big nasty hack, works quite well for me.

No no. Where "regain control" means the user has to screw around with
nasty hacks and pray, rather than setting a well defined, specific
variable.

| > d) that this information is only needed at compile time,
|
| Well of course use flags are available at runtime for the packages
| built to know, this is perfectly logic of you.

Uh. USE flags are available at DEPEND time.

| You really was getting out of arguments, don't you?

No, you're just not thinking this through.

| If I have to enable a configure switch I need it only at buildtime.
| If it has to be known at runtime there's the cpuid function!

And at the metadata phase?

| > e) that various gcc internal definitions won't change... 
| It's like assuming that gcc will always output the correct hello
| world for
| 
| int main() {
| 	printf("Hello, world!\n");
| 	return 0;
| }
| 
| If it does change those values, it's going to be a killer for way
| more than just Portage.

Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
It can and does change with different GCC releases. I know there've been
GCC changes on sparc to those kinds of defines to try to play nice with
certain other compilers...

| > You're adding a lot of complexity, and thus 
| > room for very weird breakages, to something that doesn't need it.
|
| You're not exposing any of such breakages, I find it to reduce
| complexity to users that cannot try to enable SSE3 on an Athlon-TBird
| system.
 
You're trying to guess what the user wants based upon hairy magic,
rather than doing what the user says (aren't you always yelling at
upstreams for doing that?), and all because you aren't aware
of how to cross compile correctly.

Now, please go back to justifying this thing on any merits it may have,
rather than playing the "Go and use Debian!!!1111! card.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
> And for a single compile?
I always leave the two of them in sync, even C++ apps might have parts 
building CFLAGS. In case you know you're going to use only C++ is not 
difficult to use

CFLAGS=${CXXFLAGS} has_cpuset 3dnow

don't you think?

> And your assumption would be wrong. I can assure you that relying upon
> -march doing anything sensible with __MAGIC__ is entirely unsafe. Go
> and look at the VIS handling if you want a perfect example.
Okay, maybe VIS handling is broken. But we can rely pretty safely on x86, 
amd64 and PPC gcc to know the table of arches and extensions supported. 
Remember that I asked to talk with SPARC team for VIS just because I only 
know about the other three arches.

> No no. Where "regain control" means the user has to screw around with
> nasty hacks and pray, rather than setting a well defined, specific
> variable.
Find me a reason to do that, a part for broken MMX code that should be 
disabled on the ebuild itself already.

> Uh. USE flags are available at DEPEND time.
If you talk about the nasm dependency, then it is rare, most of the MMX 
support is inline in C sources anyway.

> And at the metadata phase?
Should be already transparent or something is strange. nasm is simpler to add 
the dependency for x86, there is really few people not enabling mmx already. 
Yes it is a bit of regression, but for a small percentage of users, while 
there's more safety for many other people.

> Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
This ain't no magic. The magic is in the _CODE_ that GCC creates, but not in 
the _DEFINES_ that GCC emits.

> You're trying to guess what the user wants based upon hairy magic,
No, about their chosen architecture.

> rather than doing what the user says (aren't you always yelling at
> upstreams for doing that?)
The user asks for athlon64 support? They get athlon64 (mmx, 3dnow, 3dnowex, 
sse, sse2)
The user asks for G3 support? They get G3 (nothing)
The user asks for Pentium4 support? They get what they want (mmx, sse, sse2, 
sse3 in case)

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 20:07:00 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
| > And for a single compile?
|
| I always leave the two of them in sync, even C++ apps might have
| parts building CFLAGS. In case you know you're going to use only C++
| is not difficult to use
| 
| CFLAGS=${CXXFLAGS} has_cpuset 3dnow
| 
| don't you think?

Ah yes, yet more added complexity that's going to be forgotten and that
will lead to weird breakages.

Incidentally, syncing CFLAGS and CXXFLAGS really isn't a good idea if
you want your C compiler to work and produce vaguely sane code.

| > And your assumption would be wrong. I can assure you that relying
| > upon -march doing anything sensible with __MAGIC__ is entirely
| > unsafe. Go and look at the VIS handling if you want a perfect
| > example.
|
| Okay, maybe VIS handling is broken. But we can rely pretty safely on
| x86, amd64 and PPC gcc to know the table of arches and extensions
| supported. Remember that I asked to talk with SPARC team for VIS just
| because I only know about the other three arches.

Not really. The __MAGIC__ is subject to change whenever any GCC person
feels like it. It also doesn't work in cases where people have one of
those nasty corner case CPUs (such as the 4m, which is not an m and not
really a 4 either, or the USIV, or the r8k) that's best off with a weird
march.

| > No no. Where "regain control" means the user has to screw around
| > with nasty hacks and pray, rather than setting a well defined,
| > specific variable.
|
| Find me a reason to do that, a part for broken MMX code that should
| be disabled on the ebuild itself already.

Well that's kinda the point. Since ebuild developers don't have access
to every kind of CPU, relying upon the ebuilds getting it right isn't a
very good idea.

| > Uh. USE flags are available at DEPEND time.
|
| If you talk about the nasm dependency, then it is rare, most of the
| MMX support is inline in C sources anyway.

'most'?
 
| > And at the metadata phase?
|
| Should be already transparent or something is strange. nasm is
| simpler to add the dependency for x86, there is really few people not
| enabling mmx already. Yes it is a bit of regression, but for a small
| percentage of users, while there's more safety for many other people.

Since when was Gentoo about covering up for idiots who can't get their
ricing correct at the expense of those who know what they're doing?
 
| > Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the
| > contrary.
|
| This ain't no magic. The magic is in the _CODE_ that GCC creates, but
| not in the _DEFINES_ that GCC emits.

Sure it's magic. The __DEFINES__ aren't reliable. The GCC people change
them around now and again for compatibility with other compilers.
 
| > You're trying to guess what the user wants based upon hairy magic,
| No, about their chosen architecture.
| 
| > rather than doing what the user says (aren't you always yelling at
| > upstreams for doing that?)
|
| The user asks for athlon64 support? They get athlon64 (mmx, 3dnow,
| 3dnowex, sse, sse2)
| The user asks for G3 support? They get G3 (nothing)
| The user asks for Pentium4 support? They get what they want (mmx,
| sse, sse2, sse3 in case)
 
Setting CFLAGS and praying is not asking for something. Setting a
MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 20:29, Ciaran McCreesh wrote:
> Incidentally, syncing CFLAGS and CXXFLAGS really isn't a good idea if
> you want your C compiler to work and produce vaguely sane code.
I never said to keep them _identical_
I have a set of common flags (between which I have my arch flags) and a set of 
flags for C only and one for C++ only.

Again, it does not add more complexity than there is now to handle some 
situations.

> Not really. The __MAGIC__ is subject to change whenever any GCC person
> feels like it.
It's not magic. But if you think that going by that trick you can magically 
turn me in agreeing with you, good luck.

> It also doesn't work in cases where people have one of 
> those nasty corner case CPUs (such as the 4m, which is not an m and not
> really a 4 either, or the USIV, or the r8k) that's best off with a weird
> march.
That's what the -m{,no-}{mmx,sse,sse2,sse3,3dnow,3dnowex} flags are for.

> Well that's kinda the point. Since ebuild developers don't have access
> to every kind of CPU, relying upon the ebuilds getting it right isn't a
> very good idea.
The MMX code either works or don't. Not much to think about different CPUs.

> Since when was Gentoo about covering up for idiots who can't get their
> ricing correct at the expense of those who know what they're doing?
Again, I don't see any loss for who knows what he's doing.

> Sure it's magic. The __DEFINES__ aren't reliable. The GCC people change
> them around now and again for compatibility with other compilers.
Yeah _some_ of them are unreliable. Not those tho, as they are just the same 
on all the GCC we support. And I doubt that next week GCC 4.1.2 changes them 
around.

> Setting CFLAGS and praying is not asking for something. Setting a
> MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
And if you know what your CPU does, is it that difficult to tell the compiler 
to use them?

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 20:42:27 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| > Not really. The __MAGIC__ is subject to change whenever any GCC
| > person feels like it.
|
| It's not magic. But if you think that going by that trick you can
| magically turn me in agreeing with you, good luck.

They're a bunch of arbitrary somethings that may or may not be defined
based upon whatever upstream feels like doing to the compiler this
week. It's not like the behaviour of your hello world app, which is
defined by international standards.
 
| > It also doesn't work in cases where people have one of 
| > those nasty corner case CPUs (such as the 4m, which is not an m and
| > not really a 4 either, or the USIV, or the r8k) that's best off
| > with a weird march.
|
| That's what the -m{,no-}{mmx,sse,sse2,sse3,3dnow,3dnowex} flags are
| for.

Which is a horrible hack, and far less elegant than just having a
frickin' variable telling ebuilds what to do.
 
| > Well that's kinda the point. Since ebuild developers don't have
| > access to every kind of CPU, relying upon the ebuilds getting it
| > right isn't a very good idea.
|
| The MMX code either works or don't. Not much to think about different
| CPUs.

And in cases where the choice is "an SSE routine or an MMX routine or a
C routine"? It's not very likely that all possibilities will get tested
by ebuild devs.
 
| > Since when was Gentoo about covering up for idiots who can't get
| > their ricing correct at the expense of those who know what they're
| > doing?
|
| Again, I don't see any loss for who knows what he's doing.

Because you carefully snipped it out of your reply. You said yourself
that it's a regression.
 
| > Sure it's magic. The __DEFINES__ aren't reliable. The GCC people
| > change them around now and again for compatibility with other
| > compilers.
|
| Yeah _some_ of them are unreliable. Not those tho, as they are just
| the same on all the GCC we support. And I doubt that next week GCC
| 4.1.2 changes them around.

Oh, you doubt, do you? Very reassuring.
 
| > Setting CFLAGS and praying is not asking for something. Setting a
| > MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
|
| And if you know what your CPU does, is it that difficult to tell the
| compiler to use them?
 
Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one
remembers that for years we've been screaming at users for doing just
that.

CFLAGS is not a variable that should be used to control things. It has
a specific purpose, which is providing flags to the compiler that
should be used when compiling C programs. You're trying to give it a
new unrelated meaning. This is bad even if it were not for all the
nasty side cases and added complexity.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Curtis Napier]

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

Ciaran McCreesh wrote:
> On Thu, 6 Jul 2006 20:42:27 +0200 "Diego 'Flameeyes' Pettenò"
>  
> | > Setting CFLAGS and praying is not asking for something. Setting a
> | > MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
> |
> | And if you know what your CPU does, is it that difficult to tell the
> | compiler to use them?
>  
> Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one
> remembers that for years we've been screaming at users for doing just
> that.
> 

I could find a million threads in the forums supporting what Ciaran is
saying here. We have been told over and over and over until my head
feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT
IS WHAT USE FLAGS ARE FOR!!!!

Every developer who has ever commented on one of these threads has
always agreed with that. Put it in USE not CLFAGS.

To change this behavior now after all this time would be crazy IMHO.


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 22:02, Curtis Napier wrote:
> Every developer who has ever commented on one of these threads has
> always agreed with that. Put it in USE not CLFAGS.
Well it's not totally right.

Putting them in CFLAGS, when using -march, is redundant, pure and simple.

-march=athlon64 -msse -msse2 -mmmx -m3dnow -m3dnowex
would be equivalent of
-march=athlon64

If you have a new Athlon64 that supports SSE3, using
-march=athlon64 -msse3
is not only legit, but also (in my opinion at least) suggested. GCC can 
improve heavily if it knows what it has to do.

The problem is that people think that using
-march=pentium3 -mmmx
will bring them more acceleration, while this isn't true.

So I would suggest anybody wanting to comment on these issue to know the 
difference of using mmx in useflag and -mmmx in CFLAGS at the moment.
And then evaluate the change in behaviour.


Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most of the 
times, as it's not an i686 but at the same time it has MMX support.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 22:13:11 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| So I would suggest anybody wanting to comment on these issue to know
| the difference of using mmx in useflag and -mmmx in CFLAGS at the
| moment. And then evaluate the change in behaviour.

Well, if you're playing that game, I'd suggest that anybody wanting to
make proposals on this issue should know what CFLAGS is and understand
how it is nothing other than a set of flags that are passed to the
compiler when compiling a C program, and then evaluate the impact of
subverting such a variable for nefarious purposes.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote:
> Well, if you're playing that game, I'd suggest that anybody wanting to
> make proposals on this issue should know what CFLAGS is and understand
> how it is nothing other than a set of flags that are passed to the
> compiler when compiling a C program, and then evaluate the impact of
> subverting such a variable for nefarious purposes.
And I suggest that anybody willing to comment on user-side of things would 
know what an user is and understand how users feel about issues, instead of 
going on and on and on commenting without having a clue.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 22:46:31 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote:
| > Well, if you're playing that game, I'd suggest that anybody wanting
| > to make proposals on this issue should know what CFLAGS is and
| > understand how it is nothing other than a set of flags that are
| > passed to the compiler when compiling a C program, and then
| > evaluate the impact of subverting such a variable for nefarious
| > purposes.
|
| And I suggest that anybody willing to comment on user-side of things
| would know what an user is and understand how users feel about
| issues, instead of going on and on and on commenting without having a
| clue.

You're not going to give in gracefully, huh? Ok, I'd like to ask the
council to declare that abusing CFLAGS in the manner proposed in this
thread is a very bad idea.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote:
> You're not going to give in gracefully, huh? Ok, I'd like to ask the
> council to declare that abusing CFLAGS in the manner proposed in this
> thread is a very bad idea.
If you finished the proper arguments, the next one will be that it's all a 
cabal of infra against you, I suppose.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 23:12:51 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote:
| > You're not going to give in gracefully, huh? Ok, I'd like to ask the
| > council to declare that abusing CFLAGS in the manner proposed in
| > this thread is a very bad idea.
|
| If you finished the proper arguments, the next one will be that it's
| all a cabal of infra against you, I suppose.

No, Diego. The argument is that you're coming up with a horrible and
unnecessary hack where there are far cleaner alternatives, and that
you're blindly sticking to it and trying to throw off any objections by
devious means because you don't want to scrap said hack after all the
misguided effort you've spent on it. However, since you seem to be
incapable of admitting the gaping flaws in your own work, I'm asking for
someone else to point this out to you in a formal manner rather than
watch this thread go on for even longer.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Joshua Jackson]

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

Or instead of throwing a hissy fit yourself about diego not agreeing
with you..I don't know you could go and show the way that you feel it
should be done and show the technical merit.  Ciaran I will give you
that you are a capable programmer, and had valid arguments in this
thread. However, when interacting with people and proving points on
merits you seem to go out of your way to not prove anything and throw
examples out there without really backing them up.
>
> No, Diego. The argument is that you're coming up with a horrible
> and unnecessary hack where there are far cleaner alternatives, and
> that you're blindly sticking to it and trying to throw off any
> objections by devious means because you don't want to scrap said
> hack after all the misguided effort you've spent on it. However,
> since you seem to be incapable of admitting the gaping flaws in
> your own work, I'm asking for someone else to point this out to you
> in a formal manner rather than watch this thread go on for even
> longer.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFErYFLSENan+PfizARAjzzAJwIue9UDtwsANxaaqqnVJVr0jTz6ACglAL6
cO7O0Pw+CGDfFlVdY7z1N3o=
=6G6V
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson <tsunam@gentoo.org>
wrote:
| Or instead of throwing a hissy fit yourself about diego not agreeing
| with you..I don't know you could go and show the way that you feel it
| should be done and show the technical merit.  Ciaran I will give you
| that you are a capable programmer, and had valid arguments in this
| thread. However, when interacting with people and proving points on
| merits you seem to go out of your way to not prove anything and throw
| examples out there without really backing them up.

No, I go out of my way to avoid posting hundred page essays explaining
things that people already know. If there's really anyone reading this
discussion who doesn't understand any of the points being discussed,
they're more than welcome to ask for clarification. However, given how
basic an issue this is, is it really worth wasting everyone's time with
huge explanations of what CFLAGS is?

Come on, do you really think anyone will benefit from another
http://dev.gentoo.org/~blubb/duncan.pdf ?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Jory A. Pratt]

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

Ciaran McCreesh wrote:
> On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson <tsunam@gentoo.org>
> wrote:
> | Or instead of throwing a hissy fit yourself about diego not agreeing
> | with you..I don't know you could go and show the way that you feel it
> | should be done and show the technical merit.  Ciaran I will give you
> | that you are a capable programmer, and had valid arguments in this
> | thread. However, when interacting with people and proving points on
> | merits you seem to go out of your way to not prove anything and throw
> | examples out there without really backing them up.
> 
> No, I go out of my way to avoid posting hundred page essays explaining
> things that people already know. If there's really anyone reading this
> discussion who doesn't understand any of the points being discussed,
> they're more than welcome to ask for clarification. However, given how
> basic an issue this is, is it really worth wasting everyone's time with
> huge explanations of what CFLAGS is?
> 
> Come on, do you really think anyone will benefit from another
> http://dev.gentoo.org/~blubb/duncan.pdf ?
> 

Stephen Bennett wrote:
> On Thu, 06 Jul 2006 14:31:56 -0700
> Joshua Jackson <tsunam@gentoo.org> wrote:
>
>> Or instead of throwing a hissy fit yourself about diego not agreeing
>> with you..I don't know you could go and show the way that you feel it
>> should be done and show the technical merit.
>
> He already has done.


After reading this thread I can see this is just another one of ciaran's
b.s games that Stephen happens to back. My question is just how far up
ciaran's ass does stephen go. I am begining to think we will never get
to the end if ciaran and his bullshit around gentoo, nor will we ever
get rid of stephen's bullshit around gentoo. But the project continues
to allow such non-sence and wonders why devs are still walking away.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFErYoRo9V4dnAHxYwRAiq7AJ4+kLNig3h0Ra8k9CuLJynDFBuC+QCgiq/W
BFKmn9FzOXFhWgBt8rSbUdo=
=wTC0
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Stephen Bennett]

On Thu, 06 Jul 2006 17:09:22 -0500
"Jory A. Pratt" <anarchy@gentoo.org> wrote:

> <snip>

Leaving aside the incoherent ad-hominem attack, could you please point
out where the bullshit is? If you were referring to my post, I suggest
you re-read Ciaran's first mail to this thread. He outlined at least
two possible alternatives, but everyone seems to have ignored this.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Curtis Napier]

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

Jory A. Pratt wrote:
> Ciaran McCreesh wrote:
>>> On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson <tsunam@gentoo.org>
>>> wrote:
>>> | Or instead of throwing a hissy fit yourself about diego not agreeing
>>> | with you..I don't know you could go and show the way that you feel it
>>> | should be done and show the technical merit.  Ciaran I will give you
>>> | that you are a capable programmer, and had valid arguments in this
>>> | thread. However, when interacting with people and proving points on
>>> | merits you seem to go out of your way to not prove anything and throw
>>> | examples out there without really backing them up.
>>>
>>> No, I go out of my way to avoid posting hundred page essays explaining
>>> things that people already know. If there's really anyone reading this
>>> discussion who doesn't understand any of the points being discussed,
>>> they're more than welcome to ask for clarification. However, given how
>>> basic an issue this is, is it really worth wasting everyone's time with
>>> huge explanations of what CFLAGS is?
>>>
>>> Come on, do you really think anyone will benefit from another
>>> http://dev.gentoo.org/~blubb/duncan.pdf ?
>>>
> 
> Stephen Bennett wrote:
>>> On Thu, 06 Jul 2006 14:31:56 -0700
>>> Joshua Jackson <tsunam@gentoo.org> wrote:
>>>
>>>> Or instead of throwing a hissy fit yourself about diego not agreeing
>>>> with you..I don't know you could go and show the way that you feel it
>>>> should be done and show the technical merit.
>>> He already has done.
> 
> 
> After reading this thread I can see this is just another one of ciaran's
> b.s games that Stephen happens to back. My question is just how far up
> ciaran's ass does stephen go. I am begining to think we will never get
> to the end if ciaran and his bullshit around gentoo, nor will we ever
> get rid of stephen's bullshit around gentoo. But the project continues
> to allow such non-sence and wonders why devs are still walking away.
> 
> 
> 

I'm not sticking up for Ciaran, he already made his bed and now he's
laying in it. I'm sticking up for spb who is a damn good dev and doesn't
deserve this kind of bullshit dumped on him.

spb works his ass off for this project and is */ALWAYS/* very
professional. Just look at the past few threads that he has started
where he totally changed his approach based on feedback from everyone
(hell, look at ANY technical discussion that spb has ever had regarding
Gentoo - not just the last few mail threads). He was professional,
listened attentively and made changes based on the feedback that
satisfied everyone involved while still solving the problem at hand.
Sounds like a damn good developer to me. One I would like to see more of
in Gentoo.

spb != ciarnm

Just my two cents for what it's worth.


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Stephen Bennett]

On Thu, 06 Jul 2006 14:31:56 -0700
Joshua Jackson <tsunam@gentoo.org> wrote:

> Or instead of throwing a hissy fit yourself about diego not agreeing
> with you..I don't know you could go and show the way that you feel it
> should be done and show the technical merit.  

He already has done.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 23:23, Ciaran McCreesh wrote:
> No, Diego. The argument is that you're coming up with a horrible and
> unnecessary hack where there are far cleaner alternatives, and that
> you're blindly sticking to it and trying to throw off any objections by
> devious means because you don't want to scrap said hack after all the
> misguided effort you've spent on it. However, since you seem to be
> incapable of admitting the gaping flaws in your own work, I'm asking for
> someone else to point this out to you in a formal manner rather than
> watch this thread go on for even longer.

Wait, isn't that what _you_ usually do? Like climbing up on mirrors when you 
misunderstood something and blamed someone for an error that was never made, 
trying to find another glitch in the procedure to back it up?

Yeah that really sounds like you more than me.

I'm entirely ready to scrap what I have here if I find _valid reasons to_.
All you seem to be able to say is that you don't like this, you point to a 
control that users have not much for a valid reason than for the simple fact 
that the useflag was a good way to allow user to choose what it had without 
forcing it to use support that was not supported on their system. A solution 
that worked, but that is not the only one, and that I wouldn't consider a 
great choice that users really need to be able to use Gentoo.

The most interesting point shown up until now is the one about non-gcc 
compatibility, that I actually thought about for a while, but I thought -dM 
was unix standard option, Harald got me there, and I'll be checking for 
something in ICC.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Thu, 6 Jul 2006 23:45:21 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Thursday 06 July 2006 23:23, Ciaran McCreesh wrote:
| > No, Diego. The argument is that you're coming up with a horrible and
| > unnecessary hack where there are far cleaner alternatives, and that
| > you're blindly sticking to it and trying to throw off any
| > objections by devious means because you don't want to scrap said
| > hack after all the misguided effort you've spent on it. However,
| > since you seem to be incapable of admitting the gaping flaws in
| > your own work, I'm asking for someone else to point this out to you
| > in a formal manner rather than watch this thread go on for even
| > longer.
| 
| Wait, isn't that what _you_ usually do? Like climbing up on mirrors
| when you misunderstood something and blamed someone for an error that
| was never made, trying to find another glitch in the procedure to
| back it up?

Please try to keep this technical, even if your co-developers can't...

| I'm entirely ready to scrap what I have here if I find _valid reasons
| to_.

What's wrong with the ones you've been given so far? I'll summarise the
ones I consider important:

* it's relying upon non-guaranteed GCC internals.

* it's relying upon GCC knowing the state of the underlying system,
which fails at least for VIS.

* it's removing the ability to get access to the data at the metadata
phase, leading to what you yourself called a "regression".

* it's forcing users to use insane CFLAGS hacks, which we've spent years
telling them not to do and for good reason, to get back to previous
behaviour.

* a large part of the justification is based upon a misunderstanding of
how cross compilation should be done. The correct way around this
problem was already posted to the thread by solar.

* it's removing transparency and simplicity and replacing them with
obfuscation and complexity.

* it's taking a variable with a well defined purpose and abusing it for
something unrelated.

Will that lot do or would you like some more?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 01:16, Ciaran McCreesh wrote:
> Please try to keep this technical, even if your co-developers can't...
You started this.

> * it's relying upon non-guaranteed GCC internals.
Not that internals, that part is guaranteed to work, or we cannot consider 
guaranteed __PIC__ either, and we rely on that heavily.

> * it's relying upon GCC knowing the state of the underlying system,
> which fails at least for VIS.
Define "state of underlying system" because that is not a complete definition. 
This is not a state machine we're talking about, and we're not in science 
class.

> * it's removing the ability to get access to the data at the metadata
> phase, leading to what you yourself called a "regression".
Yes, a little regression. That's what pro&cons consideration are needed for 
after all.

> * it's forcing users to use insane CFLAGS hacks, which we've spent years
> telling them not to do and for good reason, to get back to previous
> behaviour.
No, we never spent years telling them not to use your so-called "CFLAGS hacks" 
that are rather a proper usage of what the compiler gives you.

I would _not_ ask someone why he's using -mno-mmx for instance, but I _will_ 
tell someone using

-march=athlon64 -mmmx -msse -msse2 -m3dnow -m3dnowex

that he's not doing anything useful.
Kinda like I do to people who uses -Wl,--enable-new-dtags [1]

> * a large part of the justification is based upon a misunderstanding of
> how cross compilation should be done. The correct way around this
> problem was already posted to the thread by solar.
No I'm not misunderstand how cross compilation should be done with a package 
manager. I'm saying that this will anyway give a hand to that. What I was 
referring to mostly comes down to the fact that, if I want to build a bin 
package for amd64 nocona arch, right now I am not guaranteed that setting 
CFLAGS to -march=nocona will produce the right result.

> * it's removing transparency and simplicity and replacing them with
> obfuscation and complexity.
It's removing green and yellow and adding black and white.
Your words are useless unless you explain them.

> * it's taking a variable with a well defined purpose and abusing it for
> something unrelated.
No it is not. Want to get the news? People at binutils were discussing about 
adding -march support to gas, so that it would refuse to build asm sources 
that contains instructions not supported by the -march value passed.
So using -march=i586 with mmx useflag wouldn't work anymore.

It does make sense to them and it does to me too.

> Will that lot do or would you like some more?
You have the innate ability to find more arguments when the ones you brought 
on are not accepted.

For what concerns me, I brought the idea, I find the single regression 
acceptable, I find it a proper usage of $CFLAGS variable, I find the 
internals guaranteed enough to work. My work is done here, I leave to anybody 
else to say what they think, as it seems I'm not the only one thinking this 
is a good idea.

[1] 
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/22/nonsensical-hacks-why-i-find-kdenewldflags-stupid
-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Fri, 7 Jul 2006 01:39:05 +0200 Diego 'Flameeyes' Pettenò
<flameeyes@gentoo.org> wrote:
| > * it's relying upon non-guaranteed GCC internals.
|
| Not that internals, that part is guaranteed to work, or we cannot
| consider guaranteed __PIC__ either, and we rely on that heavily.

With __PIC__ there's not much choice. Here there is.

| > * it's relying upon GCC knowing the state of the underlying system,
| > which fails at least for VIS.
|
| Define "state of underlying system" because that is not a complete
| definition. This is not a state machine we're talking about, and
| we're not in science class.

In the VIS case, there are plenty of situations where GCC will think
that the underlying system doesn't do VIS (because that's the only way
of stopping it from producing broken code), but where hand-crafted VIS
code is fine and desirable.
 
| > * it's forcing users to use insane CFLAGS hacks, which we've spent
| > years telling them not to do and for good reason, to get back to
| > previous behaviour.
|
| No, we never spent years telling them not to use your so-called
| "CFLAGS hacks" that are rather a proper usage of what the compiler
| gives you.

Wrong. We did.

| > * a large part of the justification is based upon a
| > misunderstanding of how cross compilation should be done. The
| > correct way around this problem was already posted to the thread by
| > solar.
|
| No I'm not misunderstand how cross compilation should be done with a
| package manager. I'm saying that this will anyway give a hand to
| that. What I was referring to mostly comes down to the fact that, if
| I want to build a bin package for amd64 nocona arch, right now I am
| not guaranteed that setting CFLAGS to -march=nocona will produce the
| right result.

Well no, if you're cross compiling you should be using an entirely
separate configuration setup.

| > * it's removing transparency and simplicity and replacing them with
| > obfuscation and complexity.
|
| It's removing green and yellow and adding black and white.
| Your words are useless unless you explain them.

Basic software engineering principles. Or basic English, if you prefer.

Transparency: what is happening is obvious. That is to say, the CFLAGS
variable affects flags that are passed when compiling C, and the
USE_THESE_FANCY_X86_EXTRAS variable affects the fancy x86 extras that
are used in cases where there are optional fancy x86 extras.

Simplicity: what is happening is happening without unnecessary extras
or complication.

Obfuscation: what is happening is not obvious, and is being hidden. For
example, the CFLAGS variable doesn't actually just alter CFLAGS, it
also triggers some unrelated code that turns on other unrelated
features. It's like having a function called display_person(person)
that as a side effect also deducts five percent of that person's salary.

Complexity: what is happening takes many steps and relies upon many
different systems, assumptions or code paths. Like, say, a scary hack
of a function where previously there was just a variable.

| > * it's taking a variable with a well defined purpose and abusing it
| > for something unrelated.
|
| No it is not. Want to get the news? People at binutils were
| discussing about adding -march support to gas, so that it would
| refuse to build asm sources that contains instructions not supported
| by the -march value passed. So using -march=i586 with mmx useflag
| wouldn't work anymore.

CFLAGS != ASFLAGS.

| > Will that lot do or would you like some more?
|
| You have the innate ability to find more arguments when the ones you
| brought on are not accepted.

Well yes. There're all sorts of things wrong with this proposal, and
some of them are more obvious than others. Still, it makes sense to
start with the easy ones and see whether they'll suffice before moving
onto more complex objections...

| I find it a proper usage of $CFLAGS variable

Ouch.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
> With __PIC__ there's not much choice. Here there is.
I would rather say that __PIC__ is guaranteed.

> In the VIS case, there are plenty of situations where GCC will think
> that the underlying system doesn't do VIS (because that's the only way
> of stopping it from producing broken code), but where hand-crafted VIS
> code is fine and desirable.
Okay, this is why i wanted to know that from SPARC team, as I have no 
knowledge of that architecture. I suppose then that VIS cannot be handled by 
this way.
> | No, we never spent years telling them not to use your so-called
> | "CFLAGS hacks" that are rather a proper usage of what the compiler
> | gives you.
> Wrong. We did.
Then you were wrong. I could have spent time explaining them when they make 
sense and why they don't in their usecases. If you did, well, then you really 
need to know better what you do because you seem to me pretty confused 
yourself, and I feel pity for you.

> Well no, if you're cross compiling you should be using an entirely
> separate configuration setup.
Same arch, slightly different setup, I find simpler to change CFLAGS.

> Basic software engineering principles. Or basic English, if you prefer.
Sorry I'm in the "Software engineering does not make real world usable" club. 
And find such terms opinable, subjective and vague.

> CFLAGS != ASFLAGS.
Point being? The idea would be that by default it passes the current 
GCC's -march.

> Well yes. There're all sorts of things wrong with this proposal, and
> some of them are more obvious than others. Still, it makes sense to
> start with the easy ones and see whether they'll suffice before moving
> onto more complex objections...
No it does not, as one would expect the big problems being hashed out first 
and then fine grained. But maybe I'm just a different kind of practical 
person than you are. Or you are not a practical person at all and just think 
of software engineering and theories and "this should work this way even if 
there is no real world way to make use of it".... oh wait...

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ciaran McCreesh]

On Fri, 7 Jul 2006 02:08:57 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> wrote:
| On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
| > With __PIC__ there's not much choice. Here there is.
|
| I would rather say that __PIC__ is guaranteed.

*shrug* if you like. The __MMX__ things, however, are not.
 
| > | No, we never spent years telling them not to use your so-called
| > | "CFLAGS hacks" that are rather a proper usage of what the compiler
| > | gives you.
| >
| > Wrong. We did.
|
| Then you were wrong. I could have spent time explaining them when
| they make sense and why they don't in their usecases. If you did,
| well, then you really need to know better what you do because you
| seem to me pretty confused yourself, and I feel pity for you.

Nope. We did it because a) it's unnecessary, b) some of the -m switches
lead to broken code with various gcc versions and c) the only people
doing it were those who didn't understand the implications.

| > Basic software engineering principles. Or basic English, if you
| > prefer.
|
| Sorry I'm in the "Software engineering does not make real world
| usable" club. And find such terms opinable, subjective and vague.

They're more than sufficient and entirely appropriate for the purpose at
hand. Dismissing arguments by arguing about the English isn't
dismissing the technical concerns.

| No it does not, as one would expect the big problems being hashed out
| first and then fine grained. But maybe I'm just a different kind of
| practical person than you are. Or you are not a practical person at
| all and just think of software engineering and theories and "this
| should work this way even if there is no real world way to make use
| of it".... oh wait...

Uh, so now you're claiming that "simplicity" and "transparency" are
just handwaving?

*sigh* This really isn't going to go anywhere. I hope someone else
manages to explain to you the issue with replacing a couple of aptly
named variables with a different misappropriated variable and a bunch
of nasty complicated code relying upon an external's internals, because
there's far too much mess out there already...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

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

On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
> > | No, we never spent years telling them not to use your so-called
> > | "CFLAGS hacks" that are rather a proper usage of what the compiler
> > | gives you.
> > Wrong. We did.
> Then you were wrong. I could have spent time explaining them when they make 
> sense and why they don't in their usecases. If you did, well, then you really 
> need to know better what you do because you seem to me pretty confused 
> yourself, and I feel pity for you.
> 

Yes, we did.  Were we wrong?  Out of a purest point of view ... maybe.
The problem was though that earlier gcc's was very bad at generating
sse/sse2, and sometimes mmx code.

Users being what they are though (ricers should say it all), they
enabled every flag that sounded like it could make their old box two
times faster.  This included -msse, -msse2, etc.  Which quite frankly
produced bad code in many cases.  So we told the users to not add any
-m* flags, and let gcc do its job with the proper -march.

So yeah, I can see that general use flags for cpu features might become
more tedious with the many new modules of processors out there, but to
say handle it by adding -msse, etc to CFLAGS, will surely if not on
gcc4, but then on gcc3 systems just ask for trouble.

And yes, I know you are saying that that is not exactly what you are
proposing, but the users will see it as a clear passport to stick all
those nice sounding flags just right back in, and then it will be too
late to tell them its not proper thing to do when the bugs start
flooding in.

Anyway, I tried to give some history and some what ifs, but as I
admitted many times in the past, I am no great writer.  You had to be
'there' I guess, *shrug*.


-- 
Martin Schlemmer


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Brian Harring]

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

On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote:
> On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
> > On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
> > > | No, we never spent years telling them not to use your so-called
> > > | "CFLAGS hacks" that are rather a proper usage of what the compiler
> > > | gives you.
> > > Wrong. We did.
> > Then you were wrong. I could have spent time explaining them when they make 
> > sense and why they don't in their usecases. If you did, well, then you really 
> > need to know better what you do because you seem to me pretty confused 
> > yourself, and I feel pity for you.
> > 
> 
> Yes, we did.  Were we wrong?  Out of a purest point of view ... maybe.
> The problem was though that earlier gcc's was very bad at generating
> sse/sse2, and sometimes mmx code.
> 
> Users being what they are though (ricers should say it all), they
> enabled every flag that sounded like it could make their old box two
> times faster.  This included -msse, -msse2, etc.  Which quite frankly
> produced bad code in many cases.  So we told the users to not add any
> -m* flags, and let gcc do its job with the proper -march.
> 
> So yeah, I can see that general use flags for cpu features might become
> more tedious with the many new modules of processors out there, but to
> say handle it by adding -msse, etc to CFLAGS, will surely if not on
> gcc4, but then on gcc3 systems just ask for trouble.
> 
> And yes, I know you are saying that that is not exactly what you are
> proposing, but the users will see it as a clear passport to stick all
> those nice sounding flags just right back in, and then it will be too
> late to tell them its not proper thing to do when the bugs start
> flooding in.

Dumb question, but what really blocks them from doing that now for 
x86 (for example)?

Yes, can't enable certain flags for non x86/x86_64 arches, but the con 
you're pointing at exists now for the most part.

~harring

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Martin Schlemmer]

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

On Fri, 2006-07-07 at 05:31 -0700, Brian Harring wrote:
> On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote:
> > On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
> > > On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
> > > > | No, we never spent years telling them not to use your so-called
> > > > | "CFLAGS hacks" that are rather a proper usage of what the compiler
> > > > | gives you.
> > > > Wrong. We did.
> > > Then you were wrong. I could have spent time explaining them when they make 
> > > sense and why they don't in their usecases. If you did, well, then you really 
> > > need to know better what you do because you seem to me pretty confused 
> > > yourself, and I feel pity for you.
> > > 
> > 
> > Yes, we did.  Were we wrong?  Out of a purest point of view ... maybe.
> > The problem was though that earlier gcc's was very bad at generating
> > sse/sse2, and sometimes mmx code.
> > 
> > Users being what they are though (ricers should say it all), they
> > enabled every flag that sounded like it could make their old box two
> > times faster.  This included -msse, -msse2, etc.  Which quite frankly
> > produced bad code in many cases.  So we told the users to not add any
> > -m* flags, and let gcc do its job with the proper -march.
> > 
> > So yeah, I can see that general use flags for cpu features might become
> > more tedious with the many new modules of processors out there, but to
> > say handle it by adding -msse, etc to CFLAGS, will surely if not on
> > gcc4, but then on gcc3 systems just ask for trouble.
> > 
> > And yes, I know you are saying that that is not exactly what you are
> > proposing, but the users will see it as a clear passport to stick all
> > those nice sounding flags just right back in, and then it will be too
> > late to tell them its not proper thing to do when the bugs start
> > flooding in.
> 
> Dumb question, but what really blocks them from doing that now for 
> x86 (for example)?
> 
> Yes, can't enable certain flags for non x86/x86_64 arches, but the con 
> you're pointing at exists now for the most part.
> 

I thought it was obvious, but apparently I overrated my writing
skills :/

Anyhow, because now we can say 'don't do that!', or just close the bug
as INVALID.  If not, you can still try it, but the user might say we
told him to enable sse/whatever like that.

Also, as Luca stated, USE=mmx/sse/sse2/etc means that you enable
tailored mmx/sse/whatever code, that should be working fine, as it was
not gcc doing some shot in the dark at optimising, where if its
enveloped with the CFLAGS, you cannot disable broken gcc optimisations,
but enabled mmx/sse/whatever that should work on those older gcc's.


-- 
Martin Schlemmer


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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:
>> * a large part of the justification is based upon a misunderstanding of
>> how cross compilation should be done. The correct way around this
>> problem was already posted to the thread by solar.
> No I'm not misunderstand how cross compilation should be done with a package 
> manager. I'm saying that this will anyway give a hand to that. What I was 
> referring to mostly comes down to the fact that, if I want to build a bin 
> package for amd64 nocona arch, right now I am not guaranteed that setting 
> CFLAGS to -march=nocona will produce the right result.

Using a proper profile and not hardwire useflags to use amd64 is a
solution too.

> No it is not. Want to get the news? People at binutils were discussing about 
> adding -march support to gas, so that it would refuse to build asm sources 
> that contains instructions not supported by the -march value passed.

That works this way already on ppc but...

> So using -march=i586 with mmx useflag wouldn't work anymore.

...I don't see why not since gas is supposed to accepth -m* flags
related  (see man as)

> 
> For what concerns me, I brought the idea, I find the single regression 
> acceptable, I find it a proper usage of $CFLAGS variable, I find the 
> internals guaranteed enough to work. My work is done here, I leave to anybody 
> else to say what they think, as it seems I'm not the only one thinking this 
> is a good idea.
> 

Amen
but isn't the only way and as I told you already I'd rather have stuff
properly set in profiles specific even if I like the idea of being able
to check for compiler support.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 02:01, Luca Barbato wrote:
> Using a proper profile and not hardwire useflags to use amd64 is a
> solution too.
Yes it is, I would more likely see that than adding even more useflags to 
profiles.

> > So using -march=i586 with mmx useflag wouldn't work anymore.
> ...I don't see why not since gas is supposed to accepth -m* flags
> related  (see man as)
Uh, -march=i586 will tell gas to accept only instructions present on i586, 
even if they come out of inline asm.
If the inline asm is MMX, gas refuses to produce code.

It would only work with nasm sources.

> but isn't the only way and as I told you already I'd rather have stuff
> properly set in profiles specific even if I like the idea of being able
> to check for compiler support.
Yes, you told me, and this is why we're not here discussing that. I told you 
want I think of the idea, I don't dislike it although I find it (thinking as 
it is now) a bit more complex.
I'm waiting to see a sample implementation tho, as that is what we should base 
on.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:

> I'm waiting to see a sample implementation tho, as that is what we should base 
> on.
> 

Assuming your cpuset it is just either ( use $1 && has_cpuset $1 ) or
the other way around, nothing much to write.

The more I think about the issue and the more I like the complete
profiles for amd64 more than the other solutions.

lu

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Chris Gianelloni]

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

On Fri, 2006-07-07 at 02:31 +0200, Luca Barbato wrote:
> The more I think about the issue and the more I like the complete
> profiles for amd64 more than the other solutions.

I don't even *want* to think of what this would be for x86.

These are what I can think of, so far, with regards to different support
on different chips.

x86 (everything)
i586 (everything i586-compatible)
i586 + mmx (pentium-mmx)
i686 (everything i686-compatible)
i686 + mmx (pentium2+, athlon+)
i686 + mmx + sse (pentium3+, athlon-xp+)
i686 + mmx + sse + sse2 (pentium4+, athlon64+, opteron+)
i686 + mmx + see + sse2 + sse3 (some pentium4, some athlon64, some
opteron)
i686 + mmx + 3dnow (athlon+)
i686 + mmx + 3dnow + sse (athlon-xp+)
i686 + mmx + 3dnow + sse + sse2 (athlon64+, opteron+)
i686 + mmx + 3dnow + sse + sse2 + sse3 (some athlon64, some opteron)

Now, some of those aren't able to be turned on solely via -march.

I'm not arguing for or against this, since I haven't bothered to read
the entire thread at the moment.  I just wanted to point out that we
would likely end up with 12 sub-profiles for all of our profiles to
accomplish this.  Even if we only started this going forward, x86 has a
few profiles considered "supported" by Release Engineering that would
need adjustment...

x86/2006.1/desktop
x86/no-nptl
x86/no-nptl/2.4

This means it is now 36 profiles to support, if we dropped support on
all profiles except for the new ones.  Without having any sort of
multiple inheritance available, this is really unmanageable.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Mike Doty]

Chris Gianelloni wrote:
[snip]

> This means it is now 36 profiles to support, if we dropped support on
> all profiles except for the new ones.  Without having any sort of
> multiple inheritance available, this is really unmanageable.
> 

This is exactly the same reason why amd64 won't move to a per CPU 
subprofile.  it might be a good idea for ppc, but not for us.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CPU subprofiles (was: Replacing cpu-feature USE flags)

[Ciaran McCreesh]

On Fri, 07 Jul 2006 08:36:32 -0500 Mike Doty <kingtaco@gentoo.org>
wrote:
| Chris Gianelloni wrote:
| [snip]
| > This means it is now 36 profiles to support, if we dropped support
| > on all profiles except for the new ones.  Without having any sort of
| > multiple inheritance available, this is really unmanageable.
| 
| This is exactly the same reason why amd64 won't move to a per CPU 
| subprofile.  it might be a good idea for ppc, but not for us.

I believe all discussion on CPU subprofiles has started with "if we had
multiple profile support then". Would the situation be any different if
it were just a case of telling Portage to use
base/default-linux/x86/2008.1 + extras/x86/cpu/pentium4?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] CPU subprofiles

[Mike Doty]

Ciaran McCreesh wrote:
> On Fri, 07 Jul 2006 08:36:32 -0500 Mike Doty <kingtaco@gentoo.org>
> wrote:
> | Chris Gianelloni wrote:
> | [snip]
> | > This means it is now 36 profiles to support, if we dropped support
> | > on all profiles except for the new ones.  Without having any sort of
> | > multiple inheritance available, this is really unmanageable.
> | 
> | This is exactly the same reason why amd64 won't move to a per CPU 
> | subprofile.  it might be a good idea for ppc, but not for us.
> 
> I believe all discussion on CPU subprofiles has started with "if we had
> multiple profile support then". Would the situation be any different if
> it were just a case of telling Portage to use
> base/default-linux/x86/2008.1 + extras/x86/cpu/pentium4?
> 
that would make it feasible, still not convinced it's the right way to go...
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Roy Bamford]

On 2006.07.07 14:27, Chris Gianelloni wrote:
> On Fri, 2006-07-07 at 02:31 +0200, Luca Barbato wrote:
> > The more I think about the issue and the more I like the complete
> > profiles for amd64 more than the other solutions.
> 
> I don't even *want* to think of what this would be for x86.
> 
> These are what I can think of, so far, with regards to different
> support
> on different chips.
> 
> x86 (everything)
> i586 (everything i586-compatible)
> i586 + mmx (pentium-mmx)
> i686 (everything i686-compatible)
> i686 + mmx (pentium2+, athlon+)
> i686 + mmx + sse (pentium3+, athlon-xp+)
> i686 + mmx + sse + sse2 (pentium4+, athlon64+, opteron+)
> i686 + mmx + see + sse2 + sse3 (some pentium4, some athlon64, some
> opteron)
> i686 + mmx + 3dnow (athlon+)
> i686 + mmx + 3dnow + sse (athlon-xp+)
> i686 + mmx + 3dnow + sse + sse2 (athlon64+, opteron+)
> i686 + mmx + 3dnow + sse + sse2 + sse3 (some athlon64, some opteron)
> 
[snip]
> 
> --
> Chris Gianelloni
> Release Engineering - Strategic Lead
> x86 Architecture Team
> Games - Developer
> Gentoo Linux
> 
Chris,

Its east to make worse too. There's mmxext and 3dnowext too.

Regards,

Roy Bamford

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Kevin F. Quinn]

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

On Thu, 6 Jul 2006 22:13:11 +0200
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most
> of the times, as it's not an i686 but at the same time it has MMX
> support.

There's -march=pentium-mmx for this.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 23:10, Kevin F. Quinn wrote:
> There's -march=pentium-mmx for this.
I forgot about it, thanks for pointing it out :)

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Curtis Napier wrote:
> I could find a million threads in the forums supporting what Ciaran is
> saying here. We have been told over and over and over until my head
> feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT
> IS WHAT USE FLAGS ARE FOR!!!!
> 
> Every developer who has ever commented on one of these threads has
> always agreed with that. Put it in USE not CLFAGS.

That's because CFLAGS="-msse" currently doesn't do what the user would think it
does. Which is the real problem, which we're solving with the change Diego
suggested.

> To change this behavior now after all this time would be crazy IMHO.

It might have become some sort of policy, but if the policy doesn't have a
god-like status. Sometimes it becomes obsolete and new (better) rules are put in
place.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Marius Mauch]

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

On Fri, 07 Jul 2006 13:13:09 +0200
Simon Stelling <blubb@gentoo.org> wrote:

> Curtis Napier wrote:
> > I could find a million threads in the forums supporting what Ciaran
> > is saying here. We have been told over and over and over until my
> > head feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN
> > CFLAGS!! THAT IS WHAT USE FLAGS ARE FOR!!!!
> > 
> > Every developer who has ever commented on one of these threads has
> > always agreed with that. Put it in USE not CLFAGS.
> 
> That's because CFLAGS="-msse" currently doesn't do what the user
> would think it does. Which is the real problem, which we're solving
> with the change Diego suggested.

Huh? What do you assume users think that CFLAGS=-msse does?
I know some people get confused by the mmx/sse/whatever use flags, but
I've never seen anybody assuming that CFLAGS determine if a patch
should be applied/configure switch enabled.
(I'm not arguing about the proposal itself here, just this argument is
bullshit)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Marius Mauch wrote:
>> That's because CFLAGS="-msse" currently doesn't do what the user
>> would think it does. Which is the real problem, which we're solving
>> with the change Diego suggested.
> 
> Huh? What do you assume users think that CFLAGS=-msse does?
> I know some people get confused by the mmx/sse/whatever use flags, but
> I've never seen anybody assuming that CFLAGS determine if a patch
> should be applied/configure switch enabled.
> (I'm not arguing about the proposal itself here, just this argument is
> bullshit)

Well, that was the best argument I could think of. I wasn't aware of the
breakage in old compilers like <gcc-3.3.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Richard Fish]

On 7/7/06, Simon Stelling <blubb@gentoo.org> wrote:
> That's because CFLAGS="-msse" currently doesn't do what the user would think it
> does. Which is the real problem, which we're solving with the change Diego
> suggested.

Well I certainly do *not* expect it to run configure with "--enable-sse".

-Richard
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Danny van Dyk]

Am Donnerstag, 6. Juli 2006 20:07 schrieb Diego 'Flameeyes' Pettenò:
>
> > rather than doing what the user says (aren't you always yelling at
> > upstreams for doing that?)
>
> The user asks for athlon64 support? They get athlon64 (mmx, 3dnow,
> 3dnowex, sse, sse2)
Ehm, no. Athlon64 can also optionally include: sse3 (for latest 
steppings) and xchg16 (which is a bit older already)
> The user asks for G3 support? They get G3 (nothing)
> The user asks for Pentium4 support? They get what they want (mmx,
> sse, sse2, sse3 in case)
Afaik Pentium4 has support for xchg16 since the very beginning.

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Friday 07 July 2006 02:20, Danny van Dyk wrote:
> Ehm, no. Athlon64 can also optionally include: sse3 (for latest
> steppings) and xchg16 (which is a bit older already)
That is the point, if they ask "-march=athlon64" they get the base athlon64.
If you add "-msse3" (as you should if you have an Athlon64 capable of SSE3) 
you get the whole stuff with sse3 support too. For free!

> Afaik Pentium4 has support for xchg16 since the very beginning.
I don't remember any useflag for that, and I don't seem to find that 
instruction reported in gcc's documentation, so I cannot comment on that.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ned Ludd]

On Thu, 2006-07-06 at 13:19 +0100, Ciaran McCreesh wrote:
> On Thu, 6 Jul 2006 12:52:29 +0200 "Diego 'Flameeyes' Pettenò"
> <flameeyes@gentoo.org> wrote:
> | Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags
> | present in the tree, almost never used to get new dependencies, but
> | usually used to supply econf switches.
> | 
> | This works as long as the user enable the flags, but for AMD64 the
> | story was, until now, that we simply enabled them when they worked,
> | because we had some minimum support available. Unfortunately this
> | became a problem with the introduction of nocona, because that is an
> | amd64-like system but with no 3dnow. And there is the problem that
> | sse3 is supported only in later versions of Athlon64 and so on.
> 
> The other option here... Is to rename the x86 flags to x86_mmx,
> x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not
> really the same as the x86 flags.
> 


> There's probably some USE_EXPAND trickery that can be used here...
> CPU_FEATURE_X86="mmx sse" -> cpu_feature_x86_mmx etc might be cleaner?

I tend to agree this might be a cleaner approach vs having to edit &
redit CFLAGS all over the place.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 17:33, Ned Ludd wrote:
> I tend to agree this might be a cleaner approach vs having to edit &
> redit CFLAGS all over the place.
Really if one has to disable mmx support in one package, it should be disabled 
altogether, in the real world we're all in, mmx useflag is enabled by the 
vast majority of our users.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ned Ludd]

On Thu, 2006-07-06 at 18:44 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 06 July 2006 17:33, Ned Ludd wrote:
> > I tend to agree this might be a cleaner approach vs having to edit &
> > redit CFLAGS all over the place.


> Really if one has to disable mmx support in one package, it should be disabled 
> altogether, in the real world we're all in, mmx useflag is enabled by the 
> vast majority of our users.

All together as in across the board? Or simply for the 1 pkg 
in question?

I seriously hope you are not suggesting across the board cuz that 
would make me laugh at you for a good hour solid.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 18:58, Ned Ludd wrote:
> All together as in across the board? Or simply for the 1 pkg
> in question?
For the package in question of course. Do you think I'm an idiot? Seriously?

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Ned Ludd]

On Thu, 2006-07-06 at 19:09 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 06 July 2006 18:58, Ned Ludd wrote:
> > All together as in across the board? Or simply for the 1 pkg
> > in question?
> For the package in question of course. Do you think I'm an idiot? Seriously?

Well. Sorry but there is very little we can assume these days.
Just when you think people know what they are doing along comes 
some hair brained idea that sound ok on the surface but can cause lots 
of fun problems.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:
> On Thursday 06 July 2006 17:33, Ned Ludd wrote:
>> I tend to agree this might be a cleaner approach vs having to edit &
>> redit CFLAGS all over the place.
> Really if one has to disable mmx support in one package, it should be disabled 
> altogether, in the real world we're all in, mmx useflag is enabled by the 
> vast majority of our users.
> 

Depending on who wrote the altivec part of a program you may like to
disable it since works just on macosx....

/me still would rather have both systems in place.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Kevin F. Quinn]

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

On Thu, 6 Jul 2006 12:52:29 +0200
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> So, I've been drafting this up in my blog[1], and it is a simple way
> to replace the CPU feature useflags.
>[...]

To paraphrase the idea - use the compiler's knowledge of the target
processor to select cpu-specific code.

I like the idea a lot.  To my mind, the sse/sse2/3dnow etc should be
derived from the target arch, which is what you're doing with the
compiler's macro definitions.  This could easily be done by configure
scripts; perhaps it would be a good idea to look into writing some
autoconf macros.

re. hardened - all we ever need, is to be able to force a package to
fall back to it's portable C implementation when the asm code breaks
PIC (which is independent of whether it uses mmx, sse etc) or
generates code at runtime. I think most packages provide this, as it's
useful to the developer to compare the C implementation with
accelerated asm versions easily.

re. Donnie's point about non-gcc compilers - handling these can be
hidden in the has_cpuset() function.  They can always be determined
from the target arch (combination of ARCH and -march or equivalent
CFLAGS).  The suggested code already does the worst-case fall-back, as
it responds 'no' if the compiler doesn't support -dM or doesn't define
the relevant macro.

echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null | grep -q ${def} || 
hasfeat="no"

The '2>/dev/null' is the critical element for that.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 14:35, Kevin F. Quinn wrote:
> This could easily be done by configure
> scripts; perhaps it would be a good idea to look into writing some
> autoconf macros.
Actually there's little need, you can simply use the #ifdef in the code, 
unless you have separated source files for MMX, SSE and so on (that might as 
well be), but even then, it's really trivial to autoconf.

The problem is that many autoconf scripts do it the other way around, by 
forcing -march or -mcpu (that is deprecated by -mtune too) deduced 
from /proc/cpuinfo.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Kevin F. Quinn]

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

On Thu, 6 Jul 2006 14:44:22 +0200
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> On Thursday 06 July 2006 14:35, Kevin F. Quinn wrote:
> > This could easily be done by configure
> > scripts; perhaps it would be a good idea to look into writing some
> > autoconf macros.
> Actually there's little need, you can simply use the #ifdef in the
> code, unless you have separated source files for MMX, SSE and so on
> (that might as well be), but even then, it's really trivial to
> autoconf.

Yep; I've seen that several packages do it the #ifdef way, which is
ideal as we don't need to do set any configure stuff at all then (I
guess those packages don't have configure options/use flags to select
between mmx, sse etc anyway).

> The problem is that many autoconf scripts do it the other way around,
> by forcing -march or -mcpu (that is deprecated by -mtune too) deduced 
> from /proc/cpuinfo.

Ooh; that's nasty.  Let me guess - mplayer ... yeah; what a surprise.
Presumably we disable such trickery if we see it, as it makes the
target code depend on the build system which is obviously wrong - at
least for Gentoo.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:
> So, I've been drafting this up in my blog[1], and it is a simple way to 
> replace the CPU feature useflags.

My counterproposal:

- keep the useflags
- add an eclass with the guessing logic from gcc
- add an useflag to let people decide the priority between gcc decisions
or useflag decisions.

So:

- don't have to wait for per package cflags

- have the hopefully best results if you don't really care (gcc guess)

- if you care do whatever you want, eg: turn cflags for vector units AND
autovectorized and shut down hand vectorized code (yes it could be dump
if the handmade stuff isn't wrong)

Sounds fair or I'm missing something?

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Diego 'Flameeyes' Pettenò]

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

On Thursday 06 July 2006 18:02, Luca Barbato wrote:
> - if you care do whatever you want, eg: turn cflags for vector units AND
> autovectorized and shut down hand vectorized code (yes it could be dump
> if the handmade stuff isn't wrong)
In the case you need to shut down the hand vectorised code, it has to be done 
always, not selected by users. It should be transparent for them, and if the 
code is wrong, just punt it entirely. Or fix it, your call.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Kevin F. Quinn]

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

Had a rough scan through the tree; there are 73 packages that make
direct use of mmx, sse*, 3dnow or altivec in IUSE (list below),
excluding gcc itself. They also appear in the mythtv-plugin eclass
so presumably some of media-plugins/myth* (11 packages) are also
affected.

I don't know if altivec is as clearly determined from the target arch;
perhaps the ppc people could chime in.

Clearly most are in media-* categories, so that would be a good place
to start :)

app-crypt/johntheripper
dev-lang/pike
dev-lang/squeak
dev-libs/DirectFB
dev-libs/DirectFB-extra
dev-php5/eaccelerator
games-emulation/dgen-sdl
games-emulation/visualboyadvance
games-emulation/xmame
games-emulation/xmess
games-engines/exult
media-gfx/gimp
media-gfx/inkscape
media-gfx/optipng
media-libs/allegro
media-libs/flac
media-libs/gdk-pixbuf
media-libs/imlib2
media-libs/libfame
media-libs/libggi
media-libs/libmovtar
media-libs/libmpeg3
media-libs/libquicktime
media-libs/mlt
media-libs/sdl-gfx
media-libs/smpeg
media-libs/speex
media-libs/xvid
media-plugins/eq-xmms
media-plugins/vdr-softdevice
media-plugins/xmms-mpg123
media-sound/ardour
media-sound/audacious
media-sound/fluidsynth
media-sound/jack-audio-connection-kit
media-sound/mpg123
media-sound/noxmms
media-sound/terminatorx
media-sound/xmms
media-sound/zynaddsubfx
media-tv/mythtv
media-tv/xawtv
media-tv/xdtv
media-video/avidemux
media-video/cinelerra-cvs
media-video/dirac
media-video/dxr3player
media-video/effectv
media-video/fame
media-video/ffmpeg
media-video/gephex
media-video/mjpegtools
media-video/mpeg4ip
media-video/mplayer
media-video/ogle
media-video/recmpeg
media-video/transcode
media-video/vlc
media-video/xmovie
net-irc/xchat
net-irc/xchat-gnome
net-misc/asterisk
sci-chemistry/gromacs
sci-libs/acml
sci-libs/fftw
x11-base/xorg-x11
x11-libs/evas
x11-libs/libast
x11-misc/rss-glx
x11-terms/eterm
x11-themes/polymer
x11-wm/afterstep
x11-wm/metisse

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Luca Barbato]

Kevin F. Quinn wrote:
> Had a rough scan through the tree; there are 73 packages that make
> direct use of mmx, sse*, 3dnow or altivec in IUSE (list below),
> excluding gcc itself. They also appear in the mythtv-plugin eclass
> so presumably some of media-plugins/myth* (11 packages) are also
> affected.
> 
> I don't know if altivec is as clearly determined from the target arch;
> perhaps the ppc people could chime in.

it is

> 
> Clearly most are in media-* categories, so that would be a good place
> to start :)
> 

yes

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:
[summary:provide a way to enable simd features by extracting them from
the ones supported by the cflags selected and the compiler]

Pros:
- automagic : you just carefully select your cflags and your apps will
have all the simd goodness you may dream/want/expect.
- less useflags around
- simpler life when building stages (given we gut cpuinfo checks in
configures)

Cons:
- assumes gcc
- per ebuild cflags feat isn't ready yet
- makes less simple to have certain corner case

Alternatives:

- as PPC we provide a default cflags & use tuned per certain cpu
families using profiles, amd64 could provide a nocona profile that bans
3dnow* useflags.

- have simdflags as use_expand to keep them on a single place and
improve the description

- as before but provide an eclass that uses flameeyes infrastructure to
warn about possible mismatch between what the cflags could do and what
you expect to obtain eg: -mcpu=nocona use 3dnow would issue a warning
and disable it

- as the one before again but with a var to decide if follow the use or
the gcc check.


lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Simon Stelling]

Luca Barbato wrote:
> Alternatives:
> 
> - as PPC we provide a default cflags & use tuned per certain cpu
> families using profiles, amd64 could provide a nocona profile that bans
> 3dnow* useflags.

Not really. There are athlon64s and opterons with and without sse3 support. The
users who have an sse3-enabled CPU mostly stick -msse3 into their CFLAGS, as
they expect the flag to do what it says. The problem is even worse for x86:
You'd have to provide own profiles for:

* i386
* pentium-mmx,k6
* athlon xp,pentium3
* pentium4,athlon64/opteron (starting from 'Paris' core),celeron (starting from
'willamette' core)
* celeron D/M, core solo/duo,core 2 duo, core 2 extreme,athlon64 (starting from
venice stepping E3 or san diego stepping E4), athlon64 X2, athlon64 FX (starting
from san diego stepping E4), sempron (starting from palermo stepping E3),
pentium4 (starting from 'prescott')
etc...

and now you want to let your pentium4(paris)-server, which is running 24/7,
compile a binpkg for your pentium4(prescott), using SSE3

have fun 8-)

> - as before but provide an eclass that uses flameeyes infrastructure to
> warn about possible mismatch between what the cflags could do and what
> you expect to obtain eg: -mcpu=nocona use 3dnow would issue a warning
> and disable it

I'm not sure whether I understand this correctly. If we use flameeyes logic
anyway, why keeping the use flags?

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Luca Barbato]

Simon Stelling wrote:
> Luca Barbato wrote:
>> Alternatives:
>>
>> - as PPC we provide a default cflags & use tuned per certain cpu
>> families using profiles, amd64 could provide a nocona profile that bans
>> 3dnow* useflags.
> 
> Not really. There are athlon64s and opterons with and without sse3 support. The
> users who have an sse3-enabled CPU mostly stick -msse3 into their CFLAGS, as
> they expect the flag to do what it says. The problem is even worse for x86:
> You'd have to provide own profiles for:
> 
> * i386

there is already isn't it?

> * pentium-mmx,k6

people know what they are

> * athlon xp,pentium3

ditto

> * pentium4,athlon64/opteron (starting from 'Paris' core),celeron (starting from
> 'willamette' core)

those are relatively new

> * celeron D/M, core solo/duo,core 2 duo, core 2 extreme,athlon64 (starting from
> venice stepping E3 or san diego stepping E4), athlon64 X2, athlon64 FX (starting
> from san diego stepping E4), sempron (starting from palermo stepping E3),

Don't complain with me about marketing

> pentium4 (starting from 'prescott')

and so on...

> etc...
> 
> and now you want to let your pentium4(paris)-server, which is running 24/7,
> compile a binpkg for your pentium4(prescott), using SSE3
> 
> have fun 8-)

I take the base profile and turn sse3 useflag on, tune the cflags
properly and then I issue the emerge -B foo as usual

specific profiles are good just for disoriented users that need
something working quickly, people knowing their system and what they
want would be much happy with the useflags.

Having better descriptions for flags could be of help too.

Keep in mind that discover what your cpu or another cpu could take as
cflags or simdflags requires the same (look at the arch faq about it,
parse the cpuinfo, google a bit)

> I'm not sure whether I understand this correctly. If we use flameeyes logic
> anyway, why keeping the use flags?
> 

Because you may not want all the flags the gcc guess would set for a
reason or another (and there are many, including having gcc-X.ugly doing
the worst with -msimd_du_jour but having some nicely tuned routines for
that simd triggered by --enable-simd_du_jour)

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Replacing cpu-feature USE flags

[Richard Fish]

On 7/6/06, Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> wrote:
> Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in
> the tree, almost never used to get new dependencies, but usually used to
> supply econf switches.

Hoping the S/N ratio here hasn't gotten too high...

IMO the main purpose of USE flags should be econf switches.  Pulling
in dependancies should be viewed as more of a side-effect, even if a
common one.  If the user wants "./configure ... --enable-gtk", then
they need gtk on their box.

Similarly, the mmx,sse,3dnow,etc useflags should be there for econf
switches, not additions to CFLAGS.  If the autoconf script has an
--enable-mmx option, then the proper way to control that is through a
useflag.

I don't object to ebuilds adding CFLAGS/CXXFLAGS based on the result
of your has_cpuset (for example, --fpmath= could be useful), but I
don't believe has_cpuset should be used to set econf switches.

And users should absolutely not have to muck with bashrc to disable
this.  Add a FEATURE, or something, to enable/disable it if necessary.

-Richard

-- 
gentoo-dev@gentoo.org mailing list