This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why 2.0.34 compiles with gcc 2.8.* and egcs, whereas 2.0.33 will not , work properly
- To: egcs at cygnus dot com
- Subject: Re: Why 2.0.34 compiles with gcc 2.8.* and egcs, whereas 2.0.33 will not , work properly
- From: Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>
- Date: 6 Jun 1998 15:24:49 -0000
- References: <Pine.LNX.3.96.980606121006.27202A-100000@DreamWeb.matt>
> Even though work is being done on the 2.1.* kernels, work is still
> continuing on the 2.0.* kernels, (for now). This means that the latest
> 2.0.* kernel, which is 2.0.34, actually came out *after* the 2.1.40
> kernel, so the bug was already found and fixed.
>
> I'm sure the bug in question has been documentedm and can probably be
> found on kernel.org, but I haven't tried to find it. The problem is that
> linux/arch/<appropriate>/kernel/ioport.c gets partially optimized out,
> breaking the socket layer of the kernel.
Unless you've got a different 2.0.34 from me, the ioport.c issue has
_not_ been fixed in 2.0.34 ! 2.0.34 appears to have been prepared by
Alan Cox, who still swears by using gcc-2.7 to compile Linux-2.0.
> The general message is:
> 2.0.34 - Use any compiler
No -- only gcc-2.7 and egcs-1.0.x will compile this correctly
without the following patch.
--- ./arch/i386/kernel/ioport.c.orig Sun May 17 14:10:39 1998
+++ ./arch/i386/kernel/ioport.c Sun May 17 14:19:08 1998
@@ -76,7 +76,7 @@
asmlinkage int sys_iopl(long ebx,long ecx,long edx,
long esi, long edi, long ebp, long eax, long ds,
long es, long fs, long gs, long orig_eax,
- long eip,long cs,long eflags,long esp,long ss)
+ long eip,long cs,volatile long eflags,long esp,long ss)
{
unsigned int level = ebx;
Actually, this is relevant to the current discussion on optimizing
away code `without effects': the line in question reads
*(&eflags) = (eflags & 0xffffcfff) | (level << 12);
Doesn't the mere presence of &eflags in the source constitute an alias
and force the evaluation strictly according to the rules of the
abstract machine, even without specifying `volatile' ? Otherwise, why
would one write *(&x) anyway ?
Regards,
Wolfram.
--
`Surf the sea, not double-u three...'
wmglo@dent.med.uni-muenchen.de