Problem with compiling code with option -O2

Hello, everyone. I have met a problem when I was trying compiling the next code.

Code:

---

#include <stdio.h>

typedef union {
    short s[2];
    int i[1];
}foo;

int main()
{

    foo f;
    short *a = f.s;
    int  cnt = 0x22222222;;

    f.s[0]=0x1111;
    f.s[1]=0x1111;

    printf("%x %x\n", a[0], a[1]);
    printf("%x %x\n", f.s[0], f.s[1]);
    printf("\n");

    *f.i = cnt;

    printf("%x %x\n", a[0], a[1]);
    printf("%x %x\n", f.s[0], f.s[1]);
    printf("\n");


    printf("%x %x\n", a[0], a[1]);
    printf("%x %x\n", f.s[0], f.s[1]);
    printf("\n");

    return 0;
}

---

The compiler is gcc 3.2.3. When I used options -O. I got the result which I expected:
1111 1111
1111 1111

2222 2222
2222 2222

2222 2222
2222 2222

But when I used options -O2, I got the next result:
1111 1111
1111 1111

1111 1111
2222 2222

2222 2222
2222 2222

Could you explain where is the problem in the code?
Thanks for your help.

1111 1111
1111 1111

2222 1111
2222 2222

2222 2222
2222 2222

Gcc 3.4.5 if -O2 is turned on

I have come up with an idea,
is it because that a is only a pointer to 2 bytes so the compiler doesn't think it has effect beyond the 2 bytes to assign a value to pointer a

Looks like the compiler deduces that "*f.i = cnt;" and "a[0], a[1]" cannot access the same memory location, so it does puts a[0] and a[1] on the stack (in order to pass it to printf) prior or at the same time as modifying "*f.i". This is technically allowed, because accessing the member of a union as a short after assigning to the int version to is undefined behavior.

I surprised the compiler makes such a determination, however.

compiling with -fno-strict-aliasing -O2 produces the correct result (or so it seems).

The wrong part is to declare i as a pointer (or an array, nevermind), because the compiler assumes it is not an alias to s, replacing int i[1]; by int i; in the union, and *f.i=0x2..2 by f.i=0x2..2 produces the correct result with -O2 and no additional option (because the compiler knows s and i are related).

Thank you for your comment.
Actually, this sample is modified from the next code:

Code:

---

#include <stdio.h>

int main()
{

  volatile short a[2];
  int  cnt = 0x22222222;

      a[0]=0x1111;
      a[1]=0x1111;

      printf("%x %x\n", a[0], a[1]);

      *(int *)a = (int)cnt; /* violation of aliasing rules */

      printf("%x %x\n", a[0], a[1]);

      printf("%x %x\n", a[0], a[1]);

  return 0;
}

---

According the information from google, I have known the line *(int *)a = (int)cnt; violate the aliasing rules. So I tried to fix this using union. But it seems not work. I want to figure out where the problem is and how to avoid it.
Some information from google may be helpful.
https://www.securecoding.cert.org/co...ompatible+type

Any helpful comment is welcome.

The page you linked provide a solution (the one you tried in your first post, except member i is not an array) and it works. Your last problem occurs when casting a pointer to a (non-compatible) type (an array of 2 shorts in not necessarily equivalent to an int, it depends on the implementation type size [the standard only says an int and a short have to be at least 16 bits long]). Plus in your case, indianness may also be an issue.

Thank you for your comment.
But I want to ask some further question.

Quote:

---

Originally Posted by root4

The wrong part is to declare i as a pointer (or an array, nevermind), because the compiler assumes it is not an alias to s, replacing int i[1]; by int i; in the union, and *f.i=0x2..2 by f.i=0x2..2 produces the correct result with -O2 and no additional option (because the compiler knows s and i are related).

---

In an union, how compiler determines one member is an alias to others or not? Is there any rule?

Quote:

---

Originally Posted by koushikyou

Thank you for your comment.
But I want to ask some further question.



In an union, how compiler determines one member is an alias to others or not? Is there any rule?

---

I expect it ALWAYS assumes members are aliased - since storing different forms of data aliased is the exact purpose of unions.

--
Mats

Quote:

---

Originally Posted by root4

The wrong part is to declare i as a pointer (or an array, nevermind), because the compiler assumes it is not an alias to s, replacing int i[1]; by int i; in the union, and *f.i=0x2..2 by f.i=0x2..2 produces the correct result with -O2 and no additional option (because the compiler knows s and i are related).

---

If there is something bad in the union, how to explain the next code.

Code:

---

#include <stdio.h>

typedef union {
    short s[2];
    int i;
}foo;

int main()
{

    foo f;
    short *a = f.s;
    int * b = &f.i;
    int  cnt = 0x22222222;;

    f.s[0]=0x1111;
    f.s[1]=0x1111;

    printf("%x %x\n", a[0], a[1]);
    printf("%x %x\n", f.s[0], f.s[1]);
    printf("\n");

  // f.i = cnt;
    *b = cnt;

    printf("%x %x\n", a[0], a[1]);
    printf("%x %x\n", f.s[0], f.s[1]);
    printf("\n");


    printf("%x %x\n", a[0], a[1]);
    printf("%x %x\n", f.s[0], f.s[1]);
    printf("\n");

    return 0;
}

---

The code results:
1111 1111
1111 1111

1111 1111
2222 2222

2222 2222
2222 2222

After a quick test, simply replacing "*f.i=..." by "f.i[0]=..." seems enough to tell the optimizer 'i' is an alias for 's'. Using 'i' as a pointer, knowing it is of a different type of 's' and using strict aliasing makes the optimizer thinks they are unrelated objects. So in fact, you don't even have to modify your union, ignore my comment about that.

Quote:

---

Originally Posted by matsp

I expect it ALWAYS assumes members are aliased - since storing different forms of data aliased is the exact purpose of unions.

--
Mats

---

I agree with you.

Yes, replace all occurences of 's' in what I told, by 'a'...

To sum up (how I see things, but I'm not expert on the topic):
's' and 'i' are aliases by default, 'a' is an alias of 's' when initialized, then 'i' is modified, it is accessed as a pointer and its type is _different_ of 'a', so the optimizer (strict aliasing) assumes those objects are no longer related, and applies its optimization (as details by King Mir probably). Same thing with the last example 'b'.

Is it a bad coding style or bug of gcc?

Quote:

---

Originally Posted by koushikyou

Is it a bad coding style or bug of gcc?

---

Depends on how you look at it - you are aliasing pointers, and gcc -O2 assumes "pointers do not alias" - if you want to avoid that, you should turn of that particular optimization step for the relevant code with -fno-strict-aliasing

But it is at the very least bad coding style to do this - even if it's technically not in itself incorrect and the C standard does certainly not forbid pointer aliases.

--
Mats

May be it is another trap or pitfall of C. But at least, The compiler should give a warning to programmers.

Quote:

---

May be it is another trap or pitfall of C.

---

I do not agree, this has nothing to do with C, this is an optimization issue and the standard says nothing about it. Plus this is a 'known' problem (or it should be): when you try to optimize (too much) some code, you're no longer ensured to get a correct result (except if you select carefully which optimizations you want and if you know what the optimizer will do). Nobody forces you to use the optimizer, this is a bonus (to use with caution).

Quote:

---

The compiler should give a warning to programmers.

---

There is the -Wstrict-aliasing warning despite it does not help much in this case. Last versions of gcc surely have better support (-Wstrict-aliasing=2), but I didn't try.