Compiler Warning in case of -O3 or -O2

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like to get rid of a compiler warning which only appears with the optimization switch -O2 or -O3.

This is the warning:
protocol.c:111: warning: dereferencing type-punned pointer will break strict-aliasing rules

This is the prototype of a function which call causes the warning:

extern unsigned char get_cobs_tx_buf(unsigned char **tx_buf);

For this function call I get the above mentioned warning:

t2m_error_t *msg;
  unsigned char idx;

  idx=get_cobs_tx_buf((unsigned char **)(&msg));

But the following function call does not cause a warning:

unsigned char *msg;
  unsigned char idx;

  idx=get_cobs_tx_buf(&msg);

1. Am I doing anything wrong? (Although the code seems to work...)
2. Is it possible to change the optimization level by a #pragma?
3. Can I supress a certain warning or a group of warnings by a #pragma?

Thanks in advance!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How is t2m_error_t defined?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tjena!

typedef struct
{
  unsigned char rec_type;
  unsigned char status;
}t2m_error_t;
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hejdu! (Excuse us for our subversive act of greeting in swedish)

1: Do a search for "dereferencing type-punned pointer will break" at Google. It will give you heaps of explanations of the warning message, eg. http://mail.opensolaris.org/pipe... . Essentially it is a warning that different types aren't stored in the same way, and in extension this means that a pointer of type

t2m_error_t * *

is not (guaranteed to be) storage compatible with

unsigned char * *

Totally aside: Please note this little gem in the footer of the post that I am linking to above:
"Sir, we're surrounded!"
"Excellent; we can attack in any direction!"

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Johan (not to say 'tack'),

I chose the pragmatic way and use the compiler option -fno-strict-aliasing. My code size (.text) increased from 14288 to 14304 bytes. This is acceptable.

But have a look at point 2 and 3 of my introducing post. Is there a way to control the compiler behaviour by pragmas? I haven't found anything for GCC. I know that other compilers have this ability.

Regards,
ce

OT: I was a couple of months in Sweden. But I only learned to say 'hello', 'two beers, please' and 'thanks'. ;-)

Last Edited: Tue. Oct 30, 2007 - 10:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No GCC does not have (many) #pragmas

http://gcc.gnu.org/onlinedocs/gc...

So, to answer (2), if you want to change the optimisation level of a certain function then put it in a separate source file and change the compile command for that file to use a different optimisation setting (course you cannot isolate the change of optimisation to just a few lines using this method, only an entire function)

As for (3), you have the following options for changing specific warning behaviour:

http://gcc.gnu.org/onlinedocs/gc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks,

this is what I also found. But I searched for pragmas supressing warnings or changing compiler optimization levels. But it's hard to find something which does not exist. :-)

Thanks to all of you!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note: GCC does not *yet* have the ability to change optimization levels per function. However, I know that it is on a GCC developer's todo list to implement that feature at some point. I've talked to him and mentioned that that feature would be highly desirable in the embedded community. But, like all open source projects, it's a matter of when volunteers get around to implementing the feature.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Note: GCC does not *yet* have the ability to change optimization levels per function. However, I know that it is on a GCC developer's todo list to implement that feature at some point. I've talked to him and mentioned that that feature would be highly desirable in the embedded community. But, like all open source projects, it's a matter of when volunteers get around to implementing the feature.

I remember seeing the new "hot" and "cold" attributes for GCC4.3, which allow for per-function optimization. Was I seeing things?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

I remember seeing the new "hot" and "cold" attributes for GCC4.3, which allow for per-function optimization. Was I seeing things?

Yeah, don't even go there. I don't think that stuff is valid for the AVR.