Debugging optimizer problems

Debugging optimizer problems

[jacob navia]

Hi

I am confronted with a classical problem: a program gives correct 
results when compiled with optimizations off, and gives the wrong ones 
with optimization (-O2) on.

I have isolated the probem in a single file but now there is no way that 
I can further track down the problem to one of the many functions in 
that file.

I have in my small C compiler introduced the following construct:

#pragma optimize(on/off,push/pop)

to deal with optimizer bugs.

#pragma optimize(off)

turns OFF all optimizations until a #pragma optimize(on) is seen or 
until the end of the compiulation unit. If

#pragma optimize(off,push)

is given, the optimization state can be retrieved with a

#pragma optimize(pop), or

#pragma optimize(on)

This has three advantages:

1) Allows the user to reduce the code area where the problem is hiding.

2) Provides a work around to the user for any optimizer bug.

3) Allows gcc developers to find bugs in a more direct fashion.

These pragmas can only be given at a global scope, not within a function.

I do not know gcc internals, and this improvement could be difficult to 
implement, and I do not know either your priorities in gcc development 
but it surely would help users. Obviously I think that the problem is in 
the code I am compiling, not in gcc, but it *could* be in gcc. That 
construct would help enormously.

Thanks in advance for your time.

jacob

Re: Debugging optimizer problems

[Florian Weimer]

* jacob navia:

> I have in my small C compiler introduced the following construct:
>
> #pragma optimize(on/off,push/pop)

Not sure what you are after.  GCC has something quite similar:

<https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html>

Re: Debugging optimizer problems

[jacob navia]

Le 02/02/2018 à 22:11, Florian Weimer a écrit :
> * jacob navia:
>
>> I have in my small C compiler introduced the following construct:
>>
>> #pragma optimize(on/off,push/pop)
> Not sure what you are after.  GCC has something quite similar:
>
> <https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html>

Great!

I had never seen it, and the docs in my machine weren't very explicit 
about that.

I apologize for the noise and thank you for pointing me to that doc.

jacob

Re: Debugging optimizer problems

[David Brown]

On 02/02/18 23:03, jacob navia wrote:
> Le 02/02/2018 à 22:11, Florian Weimer a écrit :
>> * jacob navia:
>>
>>> I have in my small C compiler introduced the following construct:
>>>
>>> #pragma optimize(on/off,push/pop)
>> Not sure what you are after.  GCC has something quite similar:
>>
>> <https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html>
>>
> 
> Great!
> 
> I had never seen it, and the docs in my machine weren't very explicit
> about that.
> 
> I apologize for the noise and thank you for pointing me to that doc.
> 
> jacob
> 
> 

You will find gcc manuals for many versions of the tools at
<https://gcc.gnu.org/onlinedocs/>.

In your debugging, I find the most common causes of "it works when
optimisation is disabled" to be aliasing problems, integer overflow
issues, or missing volatiles (that is more common in my world of
embedded programming, rather than PC software).  So rather than just:

#pragma GCC optimize("-O2")

and

#pragma GCC optimize("-O0")

I'd recommend testing with

#pragma GCC optimize("-fno-strict-aliasing")

and

#pragma GCC optimize("-fwrapv")

to see if that helps you isolate your problems quickly.

And if you have a reasonably modern gcc, try out the -fsanitize options
- they can be a great help in spotting bugs at run-time.

Re: Debugging optimizer problems

[Martin Sebor]

On 02/02/2018 12:29 PM, jacob navia wrote:
> Hi
>
> I am confronted with a classical problem: a program gives correct
> results when compiled with optimizations off, and gives the wrong ones
> with optimization (-O2) on.
>
> I have isolated the probem in a single file but now there is no way that
> I can further track down the problem to one of the many functions in
> that file.

The approach that usually works reasonably well is to use a tool
like delta or creduce to shrink the size of the problem to a small
test case.  https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction.

FWIW, the trick I've successfully used in the past is to add
an assert or some such conditional close to the point where
you see the wrong results being computed in the debugger.  Then
take the entry point into the file (whatever function eventually
leads to the bad behavior) and create a main that calls it with
the right values of all the arguments to trigger the bug.
Linking that into an executable typically causes many unresolved
references to symbols defined elsewhere in the file.  Provide
dummy definitions for those symbols in the same file so that
the program eventually links while still exhibiting the problem.
(Doing the same for other functions in the same file helps speed
up the whole process).  Then create a shell script that compiles
and links the file (treating all warnings as errors to avoid bad
changes from masking the problem) and runs the program looking
for the same failed assertion.  Let it run under delta for a few
hours or a day until the size is small enough so you understand
exactly what triggers the problem.

Martin

>
> I have in my small C compiler introduced the following construct:
>
> #pragma optimize(on/off,push/pop)
>
> to deal with optimizer bugs.
>
> #pragma optimize(off)
>
> turns OFF all optimizations until a #pragma optimize(on) is seen or
> until the end of the compiulation unit. If
>
> #pragma optimize(off,push)
>
> is given, the optimization state can be retrieved with a
>
> #pragma optimize(pop), or
>
> #pragma optimize(on)
>
> This has three advantages:
>
> 1) Allows the user to reduce the code area where the problem is hiding.
>
> 2) Provides a work around to the user for any optimizer bug.
>
> 3) Allows gcc developers to find bugs in a more direct fashion.
>
> These pragmas can only be given at a global scope, not within a function.
>
> I do not know gcc internals, and this improvement could be difficult to
> implement, and I do not know either your priorities in gcc development
> but it surely would help users. Obviously I think that the problem is in
> the code I am compiling, not in gcc, but it *could* be in gcc. That
> construct would help enormously.
>
> Thanks in advance for your time.
>
> jacob
>
>