[chbot] Compiler optimisation

[Charles Manning]

You can just declare elements volatile, but it is better, IMHO, to make a
whole structure volatile and or pointers to the structure volatile.

There is another potential issue at play: pointer aliasing which can easily
happen if you're dealing with structs and pointers to them without careful
casting.
These can go wonky when the optimiser kicks in.

https://stackoverflow.com/questions/2958633/gcc-strict-aliasing-and-horror-stories


On Fri, Jul 2, 2021 at 12:39 PM Robin Gilks <gb7ipd at gmail.com> wrote:

> I've managed to get the change in behaviour down to a single file now and
> have started to sprinkle 'volatiles' about the place.
>
> Question - if an element of a structure is defined as volatile, does the
> instantiation of the structure need to be also or does the whole struct
> effectively become volatile.
>
> Cheers
>
> On Fri, Jul 2, 2021 at 12:23 PM Charles Manning <cdhmanning at gmail.com>
> wrote:
>
>> If you want optimisations that are still debuggable then try -Og. That
>> will optimise as far as it can without killing debuggability.
>>
>> If your optimised code is running differently to non-optimised, then the
>> first thing to check is that you're using volatile where you need it.
>>
>> A trick I've pulled in the past is to split my makefile to build two
>> types of object file:  *.o and, say, *.og with *.o built with -O2 or
>> whatever and -Og or -O0 for the *.og files.
>> They will still link fine.
>>
>>
>>
>>
>>
>> On Fri, Jul 2, 2021 at 12:12 PM Robin Gilks <gb7ipd at gmail.com> wrote:
>>
>>> Does anyone have any tips on how to debug an issue that only arises when
>>> GCC optimisation is increased from -O0 to -O1 (or above).
>>>
>>> I have an issue with the hardware jpeg encoder on an stm32f7 MCU when I
>>> crank up the optimise (the first time I've tried it as I prefer -O0 for
>>> debugging). I've tried putting:
>>>      #pragma GCC optimize("O0")
>>> at the start of the 3 files that directly implement the jpeg stuff to
>>> turn off optimise on them as it looks like the conversion functions that
>>> generate the YCbCr 4:2:0 data from the ARGB8888 ready for the hardware
>>> engine have bits optimised away!
>>>
>>> I would expect the lookup tables generated by the code for these
>>> conversions would be the same irrespective of optimisation level but that's
>>> the only place I can think to look (the '.lst' files output from the
>>> compiler are way too different to make any sensible comparisons between
>>> optimisation levels)
>>>
>>> Ideas? Cheers
>>>
>>> --
>>> Robin Gilks
>>>
>>> _______________________________________________
>>> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
>>> https://lists.ourshack.com/mailman/listinfo/chchrobotics
>>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>>> Meetings usually 3rd Monday each month. See http://kiwibots.org for
>>> venue, directions and dates.
>>> When replying, please edit your Subject line to reflect new subjects.
>>
>> _______________________________________________
>> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
>> https://lists.ourshack.com/mailman/listinfo/chchrobotics
>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>> Meetings usually 3rd Monday each month. See http://kiwibots.org for
>> venue, directions and dates.
>> When replying, please edit your Subject line to reflect new subjects.
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20210702/2c732e70/attachment-0001.html>