optimization with GCC 4.1.1 yields invalid code

roland....@gmail.com

unread,

Jan 30, 2009, 7:19:53 AM1/30/09

to

Hello,

I had to optimize my C code for speed to achieve some time constraints
in my requirements.
I tried -O3 to get best results, but my code crashed. I found out
looking at the generated assembly code, that the compiler failed to
notice subroutines with a pointer to a local variable might indeed
change it.

How come such an oversight happen?
Is there a way to prevent the compiler to do such risky assumptions?

Thanks for your help,
Roland.

PS: I use GCC 4.1.1 to compile C source to PowerPC assembly.
Also, even using -O1 gave me "corrupt" code.

tni

unread,

Jan 30, 2009, 7:48:36 AM1/30/09

to

You likely have an aliasing issue (you should post some code). Try
compiling with '-fno-strict-aliasing'. (GCC 4 is much more aggressive
with aliasing analysis than most other compilers.)

SG

unread,

Jan 30, 2009, 7:54:59 AM1/30/09

to

On 30 Jan., 13:19, roland.arth...@gmail.com wrote:
> I had to optimize my C code for speed to achieve some time constraints
> in my requirements.
> I tried -O3 to get best results, but my code crashed. I found out
> looking at the generated assembly code, that the compiler failed to
> notice subroutines with a pointer to a local variable might indeed
> change it.
>
> How come such an oversight happen?
> Is there a way to prevent the compiler to do such risky assumptions?

Aure you sure that it's not your fault? (read: Are you sure you don't
invoke undefined behaviour?) I can think of the following possibility:
The compiler rearranged some instructions in a way that you didn't
anticipate because you violated the strict aliasing rules.

Without seeing the code we can't tell for sure.

Cheers!
SG

Lionel B

unread,

Jan 30, 2009, 8:16:30 AM1/30/09

to

On Fri, 30 Jan 2009 04:19:53 -0800, roland.arthaud wrote:

> Hello,
>
> I had to optimize my C code for speed to achieve some time constraints
> in my requirements.

If it's C code you may be better off posting to comp.lang.c rather than
here.

> I tried -O3 to get best results, but my code crashed. I found out
> looking at the generated assembly code, that the compiler failed to
> notice subroutines with a pointer to a local variable might indeed
> change it.

Impossible to check without seeing any code.Why not post a minimal program
exhibiting the problem, then others can check your result.

If it is indeed a compiler bug then you should, of course, report it to
the developers.

> How come such an oversight happen?

If it is a bug, then the answer is: compiler writers are generally humans

> Is there a way to prevent the compiler to do such risky assumptions?

What risky assumptions exactly? In what context? We don't know without
seeing code.

> Thanks for your help,
> Roland.
>
> PS: I use GCC 4.1.1 to compile C source to PowerPC assembly. Also, even
> using -O1 gave me "corrupt" code.

So -O3 is not the problem?

--
Lionel B

Zeppe

unread,

Jan 30, 2009, 11:12:28 AM1/30/09

to

roland....@gmail.com wrote:
>
> How come such an oversight happen?

Without any code, the best suggestion you can get is: usually, between
the compiler and the programmer, it's the last one that is wrong.

Best wishes,

Zeppe