Invert sense of NO_IMPLICIT_EXTERN_C

[Nathan Sidwell]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: siec.diff
Type: text/x-patch
Size: 24115 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20180625/1a75732c/attachment.bin>