Re: 990208-1.c / our backend

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Sep 19, 2013 at 3:03 PM, Hendrik Greving
<hendrik.greving.intel@gmail.com> wrote:
> Hi,
>
> I have a GCC regression test failing for our backend for -O3. I am
> posting its code below. This might be more of a C-standard question,
> but is the optimization case guaranteed not to fail from a C
> perspective? When compiling it with our backend, the 'here' labels
> actually match.
>
>
> /* As a quality of implementation issue, we should not prevent inlining
>    of function explicitly marked inline just because a label therein had
>    its address taken.  */
>
> #ifndef NO_LABEL_VALUES
> static void *ptr1, *ptr2;
> static int i = 1;
>
> static __inline__ void doit(void **pptr, int cond)
> {
>   if (cond) {
>   here:
>     *pptr = &&here;
>   }
> }
>
> static void f(int cond)
> {
>   doit (&ptr1, cond);
> }
>
> static void g(int cond)
> {
>   doit (&ptr2, cond);
> }
>
> static void bar(void);
>
> int main()
> {
>   f (i);
>   bar();
>   g (i);
>
> #ifdef  __OPTIMIZE__
>   if (ptr1 == ptr2)
>     abort ();
> #endif
>
>   exit (0);
> }
>
> void bar(void) { }
>
> #else /* NO_LABEL_VALUES */
> int main() { exit(0); }
> #endif

It also failed on trunk with -O2/-O3 on x86.  But 990208-1.c has
been changed to

__attribute__ ((noinline))
static void f(int cond)
{
  doit (&ptr1, cond);
}

__attribute__ ((noinline))
static void g(int cond)
{
  doit (&ptr2, cond);
}

__attribute__ ((noinline))
static void bar(void);


-- 
H.J.