Re: workarounds around GCC miscompilation

[<Joe...@t-...>]

Hi,

>> There's no configure check for it, it's simply hard-coded.
>Yes. Do you have another suggestion?

>> (I'm not suggesting that configure should check for it, I'm just 
>> saying that it would be useful for packagers to be able to identify work-arounds easily.
>What would you suggest to achieve this?

Just names. Perhaps "HACK:" as a prefix in the one-liner log message would be enough to raise attention. Or TRICK or WA (work-around) or whatever convention.
-> HACK: Fix build failure on Linux/sparc64: Disable optimizations in eval.d
The keyword HACK could be repeated in makemake.in


Likewise, I felt uncomfortable about this log message:
 < Make intparam.c compile with g++ >= 6.
-> Make intparam.c compile with g++ >= 6. The "auto" specifier changed with C++11.
Intparam and g++ 6 are symptoms -- or noise. "auto" is the root cause.

It appears C++ now interprets "auto" as a type specifier, whereas it used to (and still does in C) indicate a storage class (like static or register). Therefore, "auto int i = 0;" is old fashioned code in C, whereas it has become incorrect in C++14 because of the redundancy: either you write e.g. int i =..., or you let the compiler derive the type, and write auto i = ...;

OTOH, my experience is that few people read history. Therefore good descriptions in log messages
are often in vain and arguably lost effort.

Furthermore, somebody encountering this issue is more likely to google the symptoms, e.g.
"intparam.c won't compile with g++" rather than guess the cure, e.g. "auto changed in C++".

Regards,
	Jörg