Re: Invert sense of NO_IMPLICIT_EXTERN_C

[Nathan Sidwell <nathan at acm dot org>]

could a global reviewer comment?  This touches a lot of target-specific 
config files.  David has kindly checked AIX is ok, the known target 
needing the functionality.

https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01568.html

nathan

On 06/25/2018 12:48 PM, Nathan Sidwell wrote:
> NO_IMPLICIT_EXTERN_C was introduced to tell the compiler that it didn't 
> need to fake up 'extern "C" { ... }' around system header files.  Over 
> the years more and more system headers have become C++-aware, leading to 
> more targets defining this macro.
>
> Unfortunately because of the sense of this macro, and that the 
> requirement is based on the target-OS, whereas we partition the config 
> directory by target-ARCH, it's become hard to know which targets still 
> require the older functionality.
>
> There have been a few questions over the past 2 decades to figure this 
> out, but they didn;t progress.
>
> This patch replaces the negative NO_IMPLICIT_EXTERN_C with the positive 
> SYSTEM_IMPLICIT_EXTERN_C.  Targets that previously did not define 
> NO_IMPLICIT_EXTERN_C now need to define SYSTEM_IMPLICIT_EXTERN_C.  I 
> know of one such target -- AIX, and I'd be grateful this patch could be 
> tried there.
>
> Going through the config files was tricky, and I may well have missed 
> something.  One suspicious file is config/sparc/openbsd64.h which did 
> explicitly undef the macro, with the comment:
>
>    /* Inherited from sp64-elf.  */
>
> sp64-elf.h does define the macro, but the other bsd's also define it, 
> which leaves me wondering if openbsd.h has bit rotted here.  Which leads 
> me to another observation:
>
> It's quite possible the extern "C" functionality is enabled on targets 
> that no longer need it, because their observed behaviour would not be 
> broken.  On the other hand, the failure mode of not defining its 
> replacement (or alternatively mistakenly defining NO_IMPLICIT_EXTERN_C), 
> would be immediate and obvious.  And the fix is also simple.
>
> So, if you have a target that you think has C++-unaware system headers, 
> please give this patch a spin and report.  Blessing from a GM after a 
> few days out there would be nice :)
>
> The lesson here is that when one has a transition, chose an enablement 
> mechanism that makes it easy to tell when the transition is complete.
>
> nathan


--
Nathan Sidwell