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
