compilation problems with gcc+asan

[matthieu-nesme]

Hi,

specializing CImg on a simple type does not compile on gcc8 (-O3) + asan (adding -fsanitize=address -fsanitize-address-use-after-scope -fno-omit-frame-pointer on compiler/linker flags).

It is more than certainly a gcc bug, but it is aggravated by the huge single file creating huge compilation units. I'll open another issue to give some hints on why it is a bad idea to use this single huge header file.

For more details : gcc+asan is optimizing-out to more stuff (the font variables)
``_ZN12cimg_library4cimgL14data_font_hugeE' referenced in section .data.rel.local' of .cpp.o: defined in discarded section .data.rel.ro.local._ZN12cimg_library4cimgL14data_font_hugeE[_ZZN12cimg_library8CImgListIhE4fontEjbE9font_data]'`

and when modifying the cimg code by adding some __attribute__ ((used)) to force gcc not to optimize these variables, the memory usage explodes (several tens of Go).

NB: everything if fine with clang using the same compilation options.

[dtschump]

Looks definitely like a gcc-8 bug. I've tried compiling G'MIC (https://gmic.eu, a quite big project I'm developing based on CImg), with your provided flags and gcc-9.2.1, and it works flawlessly, without exploding the memory. We also encountered compilation bugs with older versions of gcc, with large files with template. I'm not so surprised this may still happen from time to time.

I'll open another issue to give some hints on why it is a bad idea to use this single huge header file.

Having a single header file for CImg is definitely not a bad idea. It has been designed specifically like this to fill technical constraints as well as make the user's life easier. I really doubt one can find a better alternative without changing all the CImg spirit (I must say that during the last 20 years, we had some time to think about it). We can discuss about it if you wish.

Thanks for the report anyway.

[matthieu-nesme]

with your provided flags and gcc-9.2.1, and it works flawlessly, without exploding the memory.

Good to know, thanks