Re: Linux and EGCS

Re: Linux and EGCS

[Linus Torvalds]

On Wed, 10 Dec 1997, Paul Koning wrote:
> 
> Not knowing much about Linux, I simply added them for any __asm__ that
> was documented as "no outputs" but didn't currently have one.
> 
> Things seem more stable now.

This sounds like a egcs bug. gcc documentation states that if an asm
doesn't have any outputs, it is automatically considered volatile:

	"An instruction without output operands will not be deleted or
	moved significantly, regardless, unless it is unreachable."

It turns out that the earlier "lidt" bug that I thought was a Linux bug
also falls under this category. In short, egcs is to be considered buggy,
or at least the documentation needs to be updated. 

Quite frankly, I think the old (and documented) gcc behaviour is the
correct one: if an asm does not have any outputs, the only reason for
having that asm in the first place is various "magic side effects" that
you cannot do in C. As such, such an asm should automatically be
considered volatile and not moved. 

		Linus

Re: Linux and EGCS

[Jeffrey A Law]

  In message <Pine.A32.3.95.971216022651.18974A-100000@ltoi.iap.physik.tu-darms
tadt.de>you write:
  > I applied the patch stmt.c (expand_asm_operands).
  > I thought it would fix the problems compiling linux-2.1.72. 
  > The compilation crashes on process.c in the arch/i386/kernel
  > directory. The compiler stops in the function flush_thread(void).
  > The strange thing is the success of the compilation depends on the
  > optimization level. Without optimization the compiler crashes, with -O
  > it works, with -O2 it does not work and with -O2 -fno-strenght-reduce it
  > works.
It's not meant to fix the crash -- it's meant to fix a code generation
error.

The crash is because the asm is bogus.  We've been over this before.

jeff

Re: Linux and EGCS

[Richard Henderson]

On Tue, Dec 16, 1997 at 02:28:20AM +0100, Peter Schmid wrote:
> The compilation crashes on process.c in the arch/i386/kernel
> directory. The compiler stops in the function flush_thread(void).

While the asm probably should be rewritten with a single "r" input
(and, incidentally, a memory clobber), I am pleased to note that
my giv combination patch actually makes this optimization.

But here's a patch for Linux anyway.


r~

Re: Linux and EGCS

[Peter Schmid]

I applied the patch stmt.c (expand_asm_operands).
I thought it would fix the problems compiling linux-2.1.72. 
The compilation crashes on process.c in the arch/i386/kernel
directory. The compiler stops in the function flush_thread(void).
The strange thing is the success of the compilation depends on the
optimization level. Without optimization the compiler crashes, with -O
it works, with -O2 it does not work and with -O2 -fno-strenght-reduce it
works.

Peter Schmid

cat t.c

extern struct desc_struct *idt, *gdt;

struct Xgt_desc_struct {
	unsigned short size;
	unsigned long address __attribute__((packed));
};
extern struct desc_struct default_ldt;
struct desc_struct {
	unsigned long a,b;
};

void flush_thread(void)
{
    int i;
    for (i=1 ; i< 512  ; i++) {
        {
            __asm__ __volatile__ ("movw $" "(( 1 << 3) - 1)" ",%1\n\t" "movw %%ax,%2\n\t" "rorl $16,%%eax\n\t" "movb %%al,%3\n\t" "movb $"  "0x82"  ",%4\n\t" "movb $0x00,%5\n\t" "movb %%ah,%6\n\t" "rorl $16,%%eax" : :"a" ( ((int)( &default_ldt )) ), "m" (
*( ((char *) ( gdt+(i<<1)+
                                                                                                                                                                                                                                                               
               (8 +1)  )) )), "m" (*( ((char *) ( gdt+(i<<1)+ 					     (8 +1)  )) +2)), "m" (*( ((char *) ( gdt+(i<<1)+ 					     (8 +1)  )) +4)), "m" (*( ((char *) ( gdt+(i<<1)+ 					     (8 +1)  )) +5)), "m" (*( ((char *) ( gdt+(i<<1)+ 					     (8 +1)
  )) +6)), "m" (*( ((char *) ( gdt+(i<<1)+ 					     (8 +1)  )) +7)) )  ;
            __asm__ __volatile__("lldt %%ax":   :"a" (((((unsigned long)   i  )<<4)+((8 +1) <<3)) )) ;
        }
    }	
}

peter:/dos/tmp$ gcc -c -W -Wall t.c
t.c: In function `flush_thread':
t.c:22: fixed or forbidden register 7 (sp) was spilled for class GENERAL_REGS.
This may be due to a compiler bug or to impossible asm
statements or clauses.
peter:/dos/tmp$ gcc -O -c -W -Wall t.c
peter:/dos/tmp$ gcc -O2 -c -W -Wall t.c
t.c: In function `flush_thread':
t.c:22: fixed or forbidden register 7 (sp) was spilled for class GENERAL_REGS.
This may be due to a compiler bug or to impossible asm
statements or clauses.
peter:/dos/tmp$ gcc -O2 -fno-strength-reduce -c -W -Wall t.c
peter:/dos/tmp$ 

Re: Linux and EGCS

[Paul Koning]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

>...
 Jeffrey> Can you try this change and let me know if it fixes your
 Jeffrey> problems?  If so I'd like to include it in egcs-1.0.1.

Looks good.  In the mips testcase it has the right effect (i.e.,
"volatile" is no longer needed in asm statements with no outputs, the
resulting .s file is the same either way (except, curiously, for the
fact that a lot of labels have different numbers...).

I also rebuilt my Linux kernel and it runs, though the real test of
that will take longer.

	paul

Re: Linux and EGCS

[Jeffrey A Law]

  In message <9712121715.AA19735@kona.>you write:
  > >>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  Jeffrey> Can either of you re-send me a testcase for the problem of
  >  Jeffrey> moving asm statements with no outputs?  I'd like to take a
  >  Jeffrey> look at this proble over the weekend if possible.
  > 
  > Attached is one I concocted out of one of our source files, where I
  > first spotted the problem.  I don't remember if this particular file
  > shows it when compiled for an x86 target (I think it doesn't; I do
  > remember that it definitely does not show the problem on a sparc
  > target).  It WILL show it on a mips64 target (when compiled -O3)
OK.  Thanks.

Interesting, from what I can find, it looks like gcc-2.7 worked correctly
more by accident than by design.  Particularly in the scheduler.

Seems to me the easiest and most correct fix is to set the volatile bit on
an asm which has no outputs.

Can you try this change and let me know if it fixes your problems?  If so
I'd like to include it in egcs-1.0.1.

	* stmt.c (expand_asm_operands): If an ASM has no outputs, then treat
	it as volatile.

Index: stmt.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/stmt.c,v
retrieving revision 1.10
diff -c -3 -p -r1.10 stmt.c
*** stmt.c	1997/12/11 16:26:01	1.10
--- stmt.c	1997/12/15 15:44:17
*************** expand_asm_operands (string, outputs, in
*** 1421,1426 ****
--- 1421,1430 ----
    /* The insn we have emitted.  */
    rtx insn;
  
+   /* An ASM with no outputs needs to be treated as volatile.  */
+   if (noutputs == 0)
+     vol = 1;
+ 
    if (output_bytecode)
      {
        error ("`asm' is invalid when generating bytecode");