[Bug sanitizer/85777] [7/8/9/10 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85777

--- Comment #11 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > That is not true, automake is highly customizable, you can e.g. override
> > COMPILE/LTCOMPILE variables in Makefile.am or something similar.
> 
> The issue is that what COMPILE/LTCOMPILE should contain is not specified, so
> that it is impossible to write a replacement that will be guaranteed to work
> in a portable way.
> 
> For instance, the following is generated:
> 
> LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
>         $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
>         $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
>         $(AM_CFLAGS) $(CFLAGS)
> 
> but the AM_V_lt variable is nowhere documented. Thus replacing
> COMPILE/LTCOMPILE would require the developer to use obscure internals. I
> will never do that!
> 
> Anyway, this would not be these variables that one would need to change, but
> the Make rules that invoke the compiler, like:
> 
> .c.o:
>         $(AM_V_CC)depbase=`echo $@ | sed
> 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
>         $(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
>         $(am__mv) $$depbase.Tpo $$depbase.Po
> #       $(AM_V_CC)source='$<' object='$@' libtool=no \
> #       DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
> #       $(AM_V_CC_no)$(COMPILE) -c -o $@ $<
> 
> But this is even worse: more internals, more code that is
> platform-dependent...

The lack of specification/documentation sounds more like a bug with
automake/libtool than with anything under GCC's control. I'd suggest reporting
the issue to automake/libtool instead, but they're not exactly very actively
maintained these days, so... YMMV.