Does anyone care about gcc 3.x support for *x86* anymore?

Does anyone care about gcc 3.x support for *x86* anymore?

[H. Peter Anvin]

[Reposting as a separate thread]

Recently, we have seen an increasing number of problems with gcc 3.4 on
x86; mostly due to poor constant propagation producing not just bad code
but failing to properly eliminate what should be dead code.

I'm wondering if there is any remaining real use of gcc 3.4 on x86 for
compiling current kernels (as opposed to residual use for compiling
applications on old enterprise distros.)  I'm specifically not referring
to other architectures here -- most of these issues have been in
relation to low-level arch-specific code, and as such only affects the
x86 architectures.  Other architectures may very well have a much
stronger need for continued support of an older toolchain.

If there isn't a reason to preserve support, I would like to consider
discontinue support for using gcc 3 to compile x86 kernels.  If there is
a valid use case, it would be good to know what it is.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Does anyone care about gcc 3.x support for *x86* anymore?

[Ingo Molnar]

(reposted with Andrew and Linus Cc:-ed too)

* H. Peter Anvin <hpa@zytor.com> wrote:

> [Reposting as a separate thread]
> 
> Recently, we have seen an increasing number of problems 
> with gcc 3.4 on x86; mostly due to poor constant 
> propagation producing not just bad code but failing to 
> properly eliminate what should be dead code.
> 
> I'm wondering if there is any remaining real use of gcc 
> 3.4 on x86 for compiling current kernels (as opposed to 
> residual use for compiling applications on old 
> enterprise distros.)  I'm specifically not referring to 
> other architectures here -- most of these issues have 
> been in relation to low-level arch-specific code, and as 
> such only affects the x86 architectures.  Other 
> architectures may very well have a much stronger need 
> for continued support of an older toolchain.
> 
> If there isn't a reason to preserve support, I would 
> like to consider discontinue support for using gcc 3 to 
> compile x86 kernels.  If there is a valid use case, it 
> would be good to know what it is.
> 
> 	-hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.

Re: Does anyone care about gcc 3.x support for *x86* anymore?

[Andi Kleen]

"H. Peter Anvin" <hpa@zytor.com> writes:
>
> If there isn't a reason to preserve support, I would like to consider
> discontinue support for using gcc 3 to compile x86 kernels.  If there is
> a valid use case, it would be good to know what it is.

I suspect there are still distributions around that use it as a standard
compiler. Wasn't it used in some major release of Debian?

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Does anyone care about gcc 3.x support for *x86* anymore?

[H. Peter Anvin]

On 05/19/2010 06:38 AM, Andi Kleen wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>>
>> If there isn't a reason to preserve support, I would like to consider
>> discontinue support for using gcc 3 to compile x86 kernels.  If there is
>> a valid use case, it would be good to know what it is.
> 
> I suspect there are still distributions around that use it as a standard
> compiler. Wasn't it used in some major release of Debian?
> 
> -Andi

There are, but that doesn't mean it's relevant for people to compile
bleeding-edge kernels with it.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: Does anyone care about gcc 3.x support for *x86* anymore?

[Justin P. Mattock]

On 05/19/2010 07:08 AM, H. Peter Anvin wrote:
> On 05/19/2010 06:38 AM, Andi Kleen wrote:
>> "H. Peter Anvin"<hpa@zytor.com>  writes:
>>>
>>> If there isn't a reason to preserve support, I would like to consider
>>> discontinue support for using gcc 3 to compile x86 kernels.  If there is
>>> a valid use case, it would be good to know what it is.
>>
>> I suspect there are still distributions around that use it as a standard
>> compiler. Wasn't it used in some major release of Debian?
>>
>> -Andi
>
> There are, but that doesn't mean it's relevant for people to compile
> bleeding-edge kernels with it.
>
> 	-hpa
>

no need for it here(using 4.6.0)..
Any distro still using this version
should upgrade(but who am I to say anything)

cheers.

Justin P. Mattock

Re: Does anyone care about gcc 3.x support for *x86* anymore?

[Martin Michlmayr]

* Andi Kleen <andi@firstfloor.org> [2010-05-19 15:38]:
> > If there isn't a reason to preserve support, I would like to consider
> > discontinue support for using gcc 3 to compile x86 kernels.  If there is
> > a valid use case, it would be good to know what it is.
> 
> I suspect there are still distributions around that use it as a standard
> compiler. Wasn't it used in some major release of Debian?

Not in a recent one, no.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: Does anyone care about gcc 3.x support for *x86* anymore?

[Miguel Ojeda]

On Thu, May 20, 2010 at 8:37 PM, Martin Michlmayr <tbm@cyrius.com> wrote:
> * Andi Kleen <andi@firstfloor.org> [2010-05-19 15:38]:
>> > If there isn't a reason to preserve support, I would like to consider
>> > discontinue support for using gcc 3 to compile x86 kernels.  If there is
>> > a valid use case, it would be good to know what it is.
>>
>> I suspect there are still distributions around that use it as a standard
>> compiler. Wasn't it used in some major release of Debian?
>
> Not in a recent one, no.

Not even in oldstable (etch).

> --
> Martin Michlmayr
> http://www.cyrius.com/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

[PATCH v3 1/2] x86: eliminate TS_XSAVE

[Avi Kivity]

The fpu code currently uses current->thread_info->status & TS_XSAVE as
a way to distinguish between XSAVE capable processors and older processors.
The decision is not really task specific; instead we use the task status to
avoid a global memory reference - the value should be the same across all
threads.

Eliminate this tie-in into the task structure by using an alternative
instruction keyed off the XSAVE cpu feature; this results in shorter and
faster code, without introducing a global memory reference.

Signed-off-by: Avi Kivity <avi@redhat.com>
---
 arch/x86/include/asm/i387.h        |   20 ++++++++++++++++----
 arch/x86/include/asm/thread_info.h |    1 -
 arch/x86/kernel/cpu/common.c       |    5 +----
 arch/x86/kernel/i387.c             |    5 +----
 arch/x86/kernel/xsave.c            |    6 +++---
 5 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/i387.h b/arch/x86/include/asm/i387.h
index da29309..a301a68 100644
--- a/arch/x86/include/asm/i387.h
+++ b/arch/x86/include/asm/i387.h
@@ -56,6 +56,18 @@ extern int restore_i387_xstate_ia32(void __user *buf);
 
 #define X87_FSW_ES (1 << 7)	/* Exception Summary */
 
+static inline bool use_xsave(void)
+{
+	u8 has_xsave;
+
+	alternative_io("mov $0, %0",
+		       "mov $1, %0",
+		       X86_FEATURE_XSAVE,
+		       "=g"(has_xsave));
+
+	return has_xsave;
+}
+
 #ifdef CONFIG_X86_64
 
 /* Ignore delayed exceptions from user space */
@@ -99,7 +111,7 @@ static inline void clear_fpu_state(struct task_struct *tsk)
 	/*
 	 * xsave header may indicate the init state of the FP.
 	 */
-	if ((task_thread_info(tsk)->status & TS_XSAVE) &&
+	if (use_xsave() &&
 	    !(xstate->xsave_hdr.xstate_bv & XSTATE_FP))
 		return;
 
@@ -164,7 +176,7 @@ static inline void fxsave(struct task_struct *tsk)
 
 static inline void __save_init_fpu(struct task_struct *tsk)
 {
-	if (task_thread_info(tsk)->status & TS_XSAVE)
+	if (use_xsave())
 		xsave(tsk);
 	else
 		fxsave(tsk);
@@ -218,7 +230,7 @@ static inline int fxrstor_checking(struct i387_fxsave_struct *fx)
  */
 static inline void __save_init_fpu(struct task_struct *tsk)
 {
-	if (task_thread_info(tsk)->status & TS_XSAVE) {
+	if (use_xsave()) {
 		struct xsave_struct *xstate = &tsk->thread.xstate->xsave;
 		struct i387_fxsave_struct *fx = &tsk->thread.xstate->fxsave;
 
@@ -266,7 +278,7 @@ end:
 
 static inline int restore_fpu_checking(struct task_struct *tsk)
 {
-	if (task_thread_info(tsk)->status & TS_XSAVE)
+	if (use_xsave())
 		return xrstor_checking(&tsk->thread.xstate->xsave);
 	else
 		return fxrstor_checking(&tsk->thread.xstate->fxsave);
diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
index d017ed5..d4092fa 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -242,7 +242,6 @@ static inline struct thread_info *current_thread_info(void)
 #define TS_POLLING		0x0004	/* true if in idle loop
 					   and not sleeping */
 #define TS_RESTORE_SIGMASK	0x0008	/* restore signal mask in do_signal() */
-#define TS_XSAVE		0x0010	/* Use xsave/xrstor */
 
 #define tsk_is_polling(t) (task_thread_info(t)->status & TS_POLLING)
 
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 4868e4a..c1c00d0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1243,10 +1243,7 @@ void __cpuinit cpu_init(void)
 	/*
 	 * Force FPU initialization:
 	 */
-	if (cpu_has_xsave)
-		current_thread_info()->status = TS_XSAVE;
-	else
-		current_thread_info()->status = 0;
+	current_thread_info()->status = 0;
 	clear_used_math();
 	mxcsr_feature_mask_init();
 
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 54c31c2..14ca1dc 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -102,10 +102,7 @@ void __cpuinit fpu_init(void)
 
 	mxcsr_feature_mask_init();
 	/* clean state in init */
-	if (cpu_has_xsave)
-		current_thread_info()->status = TS_XSAVE;
-	else
-		current_thread_info()->status = 0;
+	current_thread_info()->status = 0;
 	clear_used_math();
 }
 #endif	/* CONFIG_X86_64 */
diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index 782c3a3..c1b0a11 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -99,7 +99,7 @@ int save_i387_xstate(void __user *buf)
 		if (err)
 			return err;
 
-		if (task_thread_info(tsk)->status & TS_XSAVE)
+		if (use_xsave())
 			err = xsave_user(buf);
 		else
 			err = fxsave_user(buf);
@@ -116,7 +116,7 @@ int save_i387_xstate(void __user *buf)
 
 	clear_used_math(); /* trigger finit */
 
-	if (task_thread_info(tsk)->status & TS_XSAVE) {
+	if (use_xsave()) {
 		struct _fpstate __user *fx = buf;
 		struct _xstate __user *x = buf;
 		u64 xstate_bv;
@@ -225,7 +225,7 @@ int restore_i387_xstate(void __user *buf)
 		clts();
 		task_thread_info(current)->status |= TS_USEDFPU;
 	}
-	if (task_thread_info(tsk)->status & TS_XSAVE)
+	if (use_xsave())
 		err = restore_user_xstate(buf);
 	else
 		err = fxrstor_checking((__force struct i387_fxsave_struct *)
-- 
1.7.0.4

[tip:x86/fpu] x86: Add new static_cpu_has() function using alternatives

[tip-bot for H. Peter Anvin]

Commit-ID:  a3c8acd04376d604370dcb6cd2143c9c14078a50
Gitweb:     http://git.kernel.org/tip/a3c8acd04376d604370dcb6cd2143c9c14078a50
Author:     H. Peter Anvin <hpa@zytor.com>
AuthorDate: Tue, 11 May 2010 17:47:07 -0700
Committer:  H. Peter Anvin <hpa@zytor.com>
CommitDate: Tue, 11 May 2010 17:47:07 -0700

x86: Add new static_cpu_has() function using alternatives

For CPU-feature-specific code that touches performance-critical paths,
introduce a static patching version of [boot_]cpu_has().  This is run
at alternatives time and is therefore not appropriate for most
initialization code, but on the other hand initialization code is
generally not performance critical.

On gcc 4.5+ this uses the new "asm goto" feature.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1273135546-29690-2-git-send-email-avi@redhat.com>
---
 arch/x86/include/asm/cpufeature.h |   57 +++++++++++++++++++++++++++++++++++++
 1 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 0cd82d0..9b11a5c 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -175,6 +175,7 @@
 
 #if defined(__KERNEL__) && !defined(__ASSEMBLY__)
 
+#include <asm/asm.h>
 #include <linux/bitops.h>
 
 extern const char * const x86_cap_flags[NCAPINTS*32];
@@ -283,6 +284,62 @@ extern const char * const x86_power_flags[32];
 
 #endif /* CONFIG_X86_64 */
 
+/*
+ * Static testing of CPU features.  Used the same as boot_cpu_has().
+ * These are only valid after alternatives have run, but will statically
+ * patch the target code for additional performance.
+ *
+ */
+static __always_inline __pure bool __static_cpu_has(u8 bit)
+{
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5)
+		asm goto("1: jmp %l[t_no]\n"
+			 "2:\n"
+			 ".section .altinstructions,\"a\"\n"
+			 _ASM_ALIGN "\n"
+			 _ASM_PTR "1b\n"
+			 _ASM_PTR "0\n" 	/* no replacement */
+			 " .byte %P0\n"		/* feature bit */
+			 " .byte 2b - 1b\n"	/* source len */
+			 " .byte 0\n"		/* replacement len */
+			 " .byte 0xff + 0 - (2b-1b)\n"	/* padding */
+			 ".previous\n"
+			 : : "i" (bit) : : t_no);
+		return true;
+	t_no:
+		return false;
+#else
+		u8 flag;
+		/* Open-coded due to __stringify() in ALTERNATIVE() */
+		asm volatile("1: movb $0,%0\n"
+			     "2:\n"
+			     ".section .altinstructions,\"a\"\n"
+			     _ASM_ALIGN "\n"
+			     _ASM_PTR "1b\n"
+			     _ASM_PTR "3f\n"
+			     " .byte %P1\n"		/* feature bit */
+			     " .byte 2b - 1b\n"		/* source len */
+			     " .byte 4f - 3f\n"		/* replacement len */
+			     " .byte 0xff + (4f-3f) - (2b-1b)\n" /* padding */
+			     ".previous\n"
+			     ".section .altinstr_replacement,\"ax\"\n"
+			     "3: movb $1,%0\n"
+			     "4:\n"
+			     ".previous\n"
+			     : "=qm" (flag) : "i" (bit));
+		return flag;
+#endif
+}
+
+#define static_cpu_has(bit)					\
+(								\
+	__builtin_constant_p(boot_cpu_has(bit)) ?		\
+		boot_cpu_has(bit) :				\
+	(__builtin_constant_p(bit) && !((bit) & ~0xff)) ?	\
+		__static_cpu_has(bit) :				\
+		boot_cpu_has(bit)				\
+)
+
 #endif /* defined(__KERNEL__) && !defined(__ASSEMBLY__) */
 
 #endif /* _ASM_X86_CPUFEATURE_H */

Re: [tip:x86/fpu] x86: Add new static_cpu_has() function using alternatives

[Eric Dumazet]

Le mercredi 12 mai 2010 à 01:06 +0000, tip-bot for H. Peter Anvin a
écrit :
> Commit-ID:  a3c8acd04376d604370dcb6cd2143c9c14078a50
> Gitweb:     http://git.kernel.org/tip/a3c8acd04376d604370dcb6cd2143c9c14078a50
> Author:     H. Peter Anvin <hpa@zytor.com>
> AuthorDate: Tue, 11 May 2010 17:47:07 -0700
> Committer:  H. Peter Anvin <hpa@zytor.com>
> CommitDate: Tue, 11 May 2010 17:47:07 -0700
> 
> x86: Add new static_cpu_has() function using alternatives
> 
> For CPU-feature-specific code that touches performance-critical paths,
> introduce a static patching version of [boot_]cpu_has().  This is run
> at alternatives time and is therefore not appropriate for most
> initialization code, but on the other hand initialization code is
> generally not performance critical.
> 
> On gcc 4.5+ this uses the new "asm goto" feature.

Might be time to change Documentation/Changes about gcc requirements ...

# make
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  CC      arch/x86/kernel/process_32.o
/usr/src/linux-2.6/arch/x86/include/asm/cpufeature.h: In function
`prepare_to_copy':
/usr/src/linux-2.6/arch/x86/include/asm/cpufeature.h:315: warning: asm
operand 1 probably doesn't match constraints
/usr/src/linux-2.6/arch/x86/include/asm/cpufeature.h:315: error:
impossible constraint in `asm'
/usr/src/linux-2.6/arch/x86/include/asm/cpufeature.h:313: warning:
'flag' might be used uninitialized in this function
make[2]: *** [arch/x86/kernel/process_32.o] Error 1
make[1]: *** [arch/x86/kernel] Error 2
make: *** [arch/x86] Error 2
# gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)

Re: [tip:x86/fpu] x86: Add new static_cpu_has() function using alternatives

[H. Peter Anvin]

On 05/18/2010 01:10 PM, Eric Dumazet wrote:
> # gcc -v
> Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk
> --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)

I just implemented a fallback for gcc 3, but the real question is to
which degree we still care about gcc 3 support for x86 specifically
(other architectures might have other needs, but this is x86-specific code.)

Lately the number of issues with gcc 3 support seems to have gone way
up, and at some point we're going to have to cut it loose -- when would
depend largely on what the usage case is; e.g. why are you, yourself,
using gcc 3.4 to compile a state of the art kernel?

	-hpa

Re: [tip:x86/fpu] x86: Add new static_cpu_has() function using alternatives

[Eric Dumazet]

Le mardi 18 mai 2010 à 13:57 -0700, H. Peter Anvin a écrit :
> On 05/18/2010 01:10 PM, Eric Dumazet wrote:
> > # gcc -v
> > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
> > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > --disable-checking --with-system-zlib --enable-__cxa_atexit
> > --disable-libunwind-exceptions --enable-java-awt=gtk
> > --host=i386-redhat-linux
> > Thread model: posix
> > gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)
> 
> I just implemented a fallback for gcc 3, but the real question is to
> which degree we still care about gcc 3 support for x86 specifically
> (other architectures might have other needs, but this is x86-specific code.)
> 
> Lately the number of issues with gcc 3 support seems to have gone way
> up, and at some point we're going to have to cut it loose -- when would
> depend largely on what the usage case is; e.g. why are you, yourself,
> using gcc 3.4 to compile a state of the art kernel?

I use many different machines to compile kernels, and found this one
using gcc-3.4.6, but still running original 2.6.9.something RHEL
kernel ;)

For kernels I actually boot, I use gcc-4.5, 4.4.x, 4.3.x, 4.2.x, 4.1.2
(cross compiler)

Does anyone care about gcc 3.x support for x86 anymore?

[H. Peter Anvin]

Recently, we have seen an increasing number of problems with gcc 3.4 on
x86; mostly due to poor constant propagation producing not just bad code
but failing to properly eliminate what should be dead code.

I'm wondering if there is any remaining real use of gcc 3.4 on x86 for
compiling current kernels (as opposed to residual use for compiling
applications on old enterprise distros.)  I'm specifically not referring
to other architectures here -- most of these issues have been in
relation to low-level arch-specific code, and as such only affects the
x86 architectures.  Other architectures may very well have a much
stronger need for continued support of an older toolchain.

If there isn't a reason to preserve support, I would like to consider
discontinue support for using gcc 3 to compile x86 kernels.  If there is
a valid use case, it would be good to know what it is.

	-hpa

Re: Does anyone care about gcc 3.x support for x86 anymore?

[Mauro Carvalho Chehab]

H. Peter Anvin wrote:
> Recently, we have seen an increasing number of problems with gcc 3.4 on
> x86; mostly due to poor constant propagation producing not just bad code
> but failing to properly eliminate what should be dead code.

I don't see any problem, as, if people are using gcc3, they are probably
not interested on the bleeding edge kernel. 

However, if the problems are just performance/dead code removal, I would 
just add a big warning if someone tries to compile x86 with it. I don't 
like very much the idea of having different minimum gcc requirements 
for each architecture, except if gcc is producing a broken code. 

Currently,Documentation/Changes list just a common minimal list for
everything - although the text describing gcc say that the "version 
requirements" may vary for each CPU type.

-- 

Cheers,
Mauro

Re: Does anyone care about gcc 3.x support for x86 anymore?

[H. Peter Anvin]

On 05/19/2010 04:10 PM, Mauro Carvalho Chehab wrote:
> H. Peter Anvin wrote:
>> Recently, we have seen an increasing number of problems with gcc 3.4 on
>> x86; mostly due to poor constant propagation producing not just bad code
>> but failing to properly eliminate what should be dead code.
> 
> I don't see any problem, as, if people are using gcc3, they are probably
> not interested on the bleeding edge kernel. 
> 
> However, if the problems are just performance/dead code removal, I would 
> just add a big warning if someone tries to compile x86 with it. I don't 
> like very much the idea of having different minimum gcc requirements 
> for each architecture, except if gcc is producing a broken code. 
> 
> Currently,Documentation/Changes list just a common minimal list for
> everything - although the text describing gcc say that the "version 
> requirements" may vary for each CPU type.
> 

We already have different gcc version requirements, whether or not
they're written down is another matter...

	-hpa

Re: Does anyone care about gcc 3.x support for x86 anymore?

[H. Peter Anvin]

On 05/19/2010 04:10 PM, Mauro Carvalho Chehab wrote:
> 
> However, if the problems are just performance/dead code removal, I would 
> just add a big warning if someone tries to compile x86 with it. I don't 
> like very much the idea of having different minimum gcc requirements 
> for each architecture, except if gcc is producing a broken code. 
> 

I should clarify the problem.  The problems we have seen are related to
constant propagation, which causes gcc3 to die when there is an assembly
constraint like:

	asm("..." : : "i" (foo));

... since "foo" isn't constant as far as it is concerned.  We can put in
workarounds, but it's real effort to keep it alive that probably isn't
well spent.

Similarly, lack of constant propagation can cause code that should have
been compile-time removed to still be there, causing link failures.

	-hpa

Re: Does anyone care about gcc 3.x support for x86 anymore?

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> On 05/19/2010 04:10 PM, Mauro Carvalho Chehab wrote:
> > 
> > However, if the problems are just performance/dead 
> > code removal, I would just add a big warning if 
> > someone tries to compile x86 with it. I don't like 
> > very much the idea of having different minimum gcc 
> > requirements for each architecture, except if gcc is 
> > producing a broken code.
> > 
> 
> I should clarify the problem.  The problems we have seen 
> are related to constant propagation, which causes gcc3 
> to die when there is an assembly constraint like:
> 
> 	asm("..." : : "i" (foo));
> 
> ... since "foo" isn't constant as far as it is 
> concerned.  We can put in workarounds, but it's real 
> effort to keep it alive that probably isn't well spent.
> 
> Similarly, lack of constant propagation can cause code 
> that should have been compile-time removed to still be 
> there, causing link failures.

Put in a deprecation warning first perhaps?

	Ingo