On Wed, 19 Jul 2000, John Polstra wrote:

> In article <[EMAIL PROTECTED]>,
> Hellmuth Michaelis <[EMAIL PROTECTED]> wrote:
> > 
> > In the process of tracing down the problem of the kernel panic when booting
> > a kernel with pcvt enabled, i tried to compile a kernel without the -O
> > option to gcc and got this compile failure (sources from 18.7.2000 9:00 MET):
> > 
> > cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
> >   -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
> >   -fformat-extensions -ansi  -nostdinc -I- -I. -I../.. -I../../../include
> >   -D_KERNEL -include opt_global.h -elf  -mpreferred-stack-boundary=2
> >   -fomit-frame-pointer ../../i386/i386/atomic.c
> > In file included from ../../i386/i386/atomic.c:47:
> > machine/atomic.h: In function `atomic_set_char':
> > machine/atomic.h:106: inconsistent operand constraints in an `asm'
> > machine/atomic.h: In function `atomic_clear_char':
> > machine/atomic.h:107: inconsistent operand constraints in an `asm'
> [...]
> I have seen that same problem recently in a slightly different
> context.  After staring at the code for a very long time, I could
> only conclude that the problem was a bug in gcc.

Me too :-).

I didn't reply to John's private mail about this (sorry), partly because 
the problem seemed to be an old one that I wasn't able to solve before.
The "0" construct apparently doesn't work even with -O for gcc <= 2.8,
so atomic.h is ifdefed to not use it for non-current gcc's, although it
is strictly required for the input-output operands in atomic.h.  There
is also a problem with gcc's handling of volatile objects in atomic.h
(it just pessimizes them).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to