Re: target/10222: Wrong code with -mcpu=ultrasparc using gcc 3.2.2

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> The attached file contains a very small and simple function extracted from
> a big application. The code produced by -03 is  correct.

Yes, but only by chance.

> The code produced using -03 -mcpu=ultrasparc is wrong and causes the
> application to go into an infinite loop.

Well, the code is wrong according to your expectations, but right according 
to the C standard (more precisely, gcc is allowed to produce this code in 
this situation).

> From what I can see, the problem is partly caused by the fact that the
> code lies about types when it appends elements to the free list. My guess
> is that -mcpu=ultrasparc triggers a scheduling pass, which assumes one
> store cannot affect another load, since they are of different types. I can
> pass -fno-strict-aliasing to gcc to work around that, but arguably this is
> unsatisfactory for various reasons

Right. Your code violates the ISO C aliasing rules:

void reclaim_del_ret_list(struct subgoal_frame *sg_frame)
{
  struct Answer_List_Node *x, *y;
  
  x = sg_frame->compl_stack_ptr->del_ret_list;
  while (x) {
    y = x;
1    x = x->link;
2    *(void**)y = smALN.struct_lists.dealloc;
    smALN.struct_lists.dealloc = y;
  }
}

The compiler is allowed to assume that load #1 and store #2 are independent 
since they are made through pointers of different types. So the first 
scheduling pass transforms the code into:

  while (x) {
    y = x;
2    *(void**)y = smALN.struct_lists.dealloc;
1    x = x->link;
    smALN.struct_lists.dealloc = y;
  }

hence the infinite loop.

> 1. What I naively expect from -mcpu=ultrasparc is to
>     perform target specific code generation; not to affect
>     the alias analysis which is used.

-mcpu doesn't modify the alias analysis, but it affects scheduling. The 
default scheduling is simply less aggressive than the ultrasparc scheduling, 
in that it doesn't reorder the insns to the same extent.

>  2. This behaviour is not something that happened with
>     previous versions of gcc (e.g. 2.95.x) and gcc 3.2
>     on x86 with -mcpu=pentiumpro does not exhibit such
>     behaviour.

-fstrict-aliasing was not enabled by default at -O2 for gcc 2.95.x. As for 
the behaviour on x86, it's again by chance, another scheduling could give the 
same infinite loop.

The solution is really the one you have proposed: to compile with 
-fno-strict-aliasing.

-- 
Eric Botcazou