Is machine_name fix still needed?

[Segher Boessenkool]

Hi!

On Thu, Feb 06, 2020 at 11:26:23AM -0300, Matheus Castanho wrote:
> I recently faced problems while building GCC caused by a system header
> being broken by the machine_name fix from fixincludes [1]. And
> apparently I am not the first one [2][3].
> 
> After digging into the fixincludes code, I found the following comment
> on fixincludes/fixinc.in:
> 
> > # # # # # # # # # # # # # # # # # # # # #
> > #
> > #  Check to see if the machine_name fix needs to be disabled.
> > #
> > #  On some platforms, machine_name doesn't work properly and
> > #  breaks some of the header files.  Since everything works
> > #  properly without it, just wipe the macro list to
> > #  disable the fix.
> 
> Indeed adding the target to the case that follows this comment did the
> trick for me:
> 
> diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
> index 15cbaa23544..c0791454b9c 100755
> --- a/fixincludes/fixinc.in
> +++ b/fixincludes/fixinc.in
> @@ -136,6 +136,9 @@ fi
>  #  disable the fix.
> 
>  case "${target_canonical}" in
> +    powerpc*-*-linux-*)
> +	test -f ${MACRO_LIST} &&  echo > ${MACRO_LIST}
> +        ;;
>      *-*-vxworks*)
>  	test -f ${MACRO_LIST} &&  echo > ${MACRO_LIST}
>          ;;
> -- 
> 2.21.1
> 
> I haven't noticed any harm done by disabling this fix for my specific
> case. From what I could understand from the code and from the diffs of
> the 'fixed' headers, this fix just surrounds some identifiers with '__'
> on #ifdef/#define/#include lines.
> 
> Since even the source code states 'everything works properly without
> it', is this fix still really needed? Would it make any sense to disable
> machine_name by default for other targets upstream?
> 
> Note I'm not particularly familiar with the historical need for this, my
> question is based specially on the comment quoted above and my empirical
> tests.
> 
> [1] https://gcc.gnu.org/ml/gcc-help/2020-02/msg00023.html
> [2] https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01901.html
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085

Thanks for the investigation and patch!

If no one comes up with a better suggestion soon, I'll apply your patch
so that your AT builds work again.  (I'll write a changelog etc.)


Segher