GCC optimization bug?

[Jobbo]

[Edit] It wasn't an optimization bug, turned out to be bad copper setup.

I've been using the awesome VSCode C/C++ environment by Bartman/Abyss.

However now that my project has reached a certain size I'm running into a weird bug that I can't easily attribute to any code, it's very hard to determine exactly what is going on. The bug seems to be some optimization problem causing my copper driven blitter lines to flicker.

I've been able to narrow the problem down to the use of -fwhole-program. If I turn that option off everything seems fine. While trying to investigate why this might be I found this documentation:

-fwhole-program
Assume that the current compilation unit represents the whole program being compiled. All public functions and variables with the exception of main and those merged by attribute externally_visible become static functions and in effect are optimized more aggressively by interprocedural optimizers.
This option should not be used in combination with -flto. Instead relying on a linker plugin should provide safer and more precise information.

The documentation says you should not combine fwhole-programe with -flto but that is what the sample makefile does so I'm doing the same.

This is where I found the information about -fwhole-program

https://gcc.gnu.org/onlinedocs/gcc/O...e-Options.html

It later states: "If the program does not require any symbols to be exported, it is possible to combine -flto and -fwhole-program..." So it all seems quite murky.

Does anyone know more about gcc compiler options than I do and had some thoughts on what might be going on, or suggestions for further narrowing the problem down?

[Ernst Blofeld]

Originally Posted by Jobbo

copper driven blitter lines

Oh my, I can't even think how you would start debugging that.

The only thing I can think to suggest, based on what you've said about the optimisation flags you've tried toggling, is to check whether you need to add any memory barriers to force the optimiser to keep things in the order they're written: https://stackoverflow.com/questions/...0the%20barrier.

[pipper]

Are the hardware registers all marked volatile? If not the compiler may omit seemingly superfluous reads and reorder writes to them.

[Jobbo]

Adding -fno-tree-loop-vectorize to the gcc options seems to have fixed it instead of removing -fwhole-program.

Not really sure what that does.

[Ernst Blofeld]

Originally Posted by Jobbo

Adding -fno-tree-loop-vectorize to the gcc options seems to have fixed it instead of removing -fwhole-program.

Not really sure what that does.

If disabling certain compiler optimisations makes your code works, it's possible your code actually has undefined behaviour, and the non-working version is actually just as valid. Things like signed numbers overflowing or copying data between memory areas that overlap being optimised into memcpy calls. Or you may have disabled reordering that memory barriers would prevent, i.e. updates to your copper lists may happen out of order with your wait for vertical blank.

[Jobbo]

I’ve been trying all sorts of things with no luck.

However turning off warp mode which was on during the init phase also fixes the problem.

Not sure if that gives any clues?

[Antiriad_UK]

I’ve only had warp mode break something when floppy emulation speed was not set to 100%. Doesn’t seem likely in this case though.

Only other issue I’ve had with gcc is with a macro change of mulsw in Amigaklang and a recent change in Bartmans macro definition. If optimisation is on something breaks in mulsw but we’ve not worked out why. When I turn optimisations off, or roll back to the old macro it works. Long shot, but if you using that macro maybe worth a look.

[hooverphonique]

I agree with Ernst that it sounds like you have a bug/undefined behavior, which can manifest itself differently depending on different optimization options (i.e. messing with them is probably not going to fix it)..

[Jobbo]

I agree that it has that stink about it, I'm just not really sure what sort of undefined behavior might lead to problems?

So far I've been able to fix the problem in lots of different ways.
- Adjust optimization settings
- Remove debug asserts
- Remove debug KPrint calls
- Move the warpmode call to earlier

The problem persists however when I change my many inline asm functions to use a C version.

I'm not sure that any of this gives me anything to go on. What it might suggest is that the problem is in the initialization phase where I allocate and setup my buffers, because those are where the debug asserts and prints mostly live and that is what the warpmode is used to speed up.

The per frame code is the inline asm and so it kind of makes sense that that changing that code isn't helping if the problem is all in initialization.

I've tried examining the different .s files from a working and non-working compile and so far there's nothing that really jumps out as the problem.

Any further suggestions on how to narrow this down would be much appreciated.

[Jobbo]

I should also point out that I've tried turning on a whole bunch of extra warnings for undefined behavior and haven't found anything in my code.

Some of the gcc_support code causes warnings, so not sure if I am tripping something in there?

[Ernst Blofeld]

Have you tried adding memory barriers all over the place?

[Jobbo]

I have with no luck.

[Jobbo]

I'm using:

asm volatile("" ::: "memory");

as a memory barrier. Not sure if there is some other method?

[Ernst Blofeld]

Originally Posted by Jobbo

I'm using:

asm volatile("" ::: "memory");

as a memory barrier. Not sure if there is some other method?

That's the only method I know of:

#define BARRIER() asm volatile ("" ::: "memory")

Are all your inline assembly blocks declared with

volatile

too, and

memory

if they need that?

It's all guesswork without seeing your code, or even the effect you're describing.

It could be something as simple as how you wait for vertical blank.

[Jobbo]

All but one inline assembly have been switched to the C version and the problem persists.

I think I will look into more compiler options that might help narrow down any undefined behavior. Stuff like signed overflow seems like it would be easy to trip without knowing.

[Jobbo]

I resolved this, it was a copper setup bug.

http://eab.abime.net/showthread.php?t=105358