GNU Arm Embedded Toolchain

dereferencing type punned pointer will break strict-aliasing rules

Asked by Nayani P

Hi all,
Sorry to ask questions in a short span!!! I tried to compile a code distributed by an ARM Cortex-M3 manufacturing company. Though their sample codes are not for GCC, having come from a reputed company, I was sure they will compile without a hitch in GCC. But to my surprise I got the warning mentioned in summary. I understand pointers are used to access I/O ports or memory and I do not want to suppress the warnings lest I may run into a problem some time later. Any suggestions please? Thank for your time.

Partha

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Nayani P
Solved:
Last query:
Last reply:
Revision history for this message
Freddie Chopin (freddie-chopin) said : 		#1

I suggest to show the problematic code - no one can guess what the problem is.

Revision history for this message
Nayani P (partha-nayani) said : 		#2

Hi,
I am sorry for the delayed reply. Here is the code snippet:

myfunction ((IO_TypeDef* pio)
{
 switch (*(u32*)&pio)
  {
    case mycase1:
. . . . . . .

Above pio is a pointer to a struct.

Thank you.

Partha

Revision history for this message
Joey Ye (jinyun-ye) said : 		#3

Suggest you either change the code to use union, or try option
-fno-strict-aliasing (might be with spelling error. Please check gcc manual
if error)
On May 5, 2013 6:21 PM, "Nayani P" <email address hidden>
wrote:

> Question #227772 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/227772
>
> Status: Needs information => Open
>
> Nayani P gave more information on the question:
> Hi,
> I am sorry for the delayed reply. Here is the code snippet:
>
> myfunction ((IO_TypeDef* pio)
> {
> switch (*(u32*)&pio)
> {
> case mycase1:
> . . . . . . .
>
> Above pio is a pointer to a struct.
>
> Thank you.
>
> Partha
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Revision history for this message
Nayani P (partha-nayani) said : 		#4

Hi Joey,
Thanks for the reply. I did not want to suppress warning lest the code may do something unexpected. I changed the code a bit by removing the switch statement and putting an if ((u32 *) pio == mycase1) does not report any warnings. You may kindly treat this as closed. However a question is nagging me. Is it a correct way of type casting a pointer content (*(u32*)&pio) as shown in my earlier post? Cause if it is then GCC should not complain. Thank you once again.

Partha

Revision history for this message
Joey Ye (jinyun-ye) said : 		#5

According to C specification, behavior of that type casting is
implementation defined. For earlier version of gcc (4.3-) or some other
compiler it is fine. But for later gcc, it is very likely to result in
instruction sequence whose runtime behavior is unintended to programmer.

So, I'd say it is NOT a correct way. It happens to work with some compiler
implementation but WILL malfunction with some others.
On May 7, 2013 5:21 AM, "Nayani P" <email address hidden>
wrote:

> Question #227772 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/227772
>
> Status: Answered => Solved
>
> Nayani P confirmed that the question is solved:
> Hi Joey,
> Thanks for the reply. I did not want to suppress warning lest the code may
> do something unexpected. I changed the code a bit by removing the switch
> statement and putting an if ((u32 *) pio == mycase1) does not report any
> warnings. You may kindly treat this as closed. However a question is
> nagging me. Is it a correct way of type casting a pointer content
> (*(u32*)&pio) as shown in my earlier post? Cause if it is then GCC should
> not complain. Thank you once again.
>
> Partha
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Revision history for this message
Nayani P (partha-nayani) said : 		#6

Thank you Joey.