On Mon, 2017-10-23 at 16:40 +0100, Pedro Alves wrote:
> On 10/23/2017 04:17 PM, Jonathan Wakely wrote:
> > On 23/10/17 17:07 +0200, Michael Matz wrote:
> > > Hi,
> > >
> > > On Mon, 23 Oct 2017, Richard Biener wrote:
> > >
> > > > I guess so. But we have to make gdb happy as well. It really
> > > > depends how
> > > > much each TU grows with the extra (unneeded) include grows in
> > > > C++11 and
> > > > C++04 mode.
> > >
> > > The c++ headers unconditionally included from system.h, with:
> > >
> > > % echo '#include <$name>' | g++-7 -E -x c++ - | wc -l
> > > new: 3564
> > > cstring: 533
> > > utility: 3623
> > > memory: 28066
> >
> > That's using the -std=gnu++4 default for g++-7, and for that mode
> > the header *is* needed, to get the definition of std::unique_ptr.
> >
> > For C++98 (when it isn't needed) that header is much smaller:
> >
> > tmp$ echo '#include <memory>' | g++ -E -x c++ - | wc -l
> > 28101
> > tmp$ echo '#include <memory>' | g++ -E -x c++ - -std=gnu++98 | wc
> > -l
> > 4267
> >
> > (Because it doesn't contain std::unique_ptr and std::shared_ptr
> > before
> > C++11).
> >
> > > compile time:
> > > % echo -e '#include <$name>\nint i;' | time g++-7 -c -x c++ -
> > > new: 0:00.06elapsed, 17060maxresident, 0major+3709minor
> > > cstring: 0:00.03elapsed, 13524maxresident, 0major+3075minor
> > > utility: 0:00.05elapsed, 16952maxresident, 0major+3776minor
> > > memory: 0:00.25elapsed, 40356maxresident, 0major+9764minor
> > >
> > > Hence, <memory> is not cheap at all, including it unconditionally
> > > from
> > > system.h when it isn't actually used by many things doesn't seem
> > > a good
> > > idea.
> > >
>
> I think the real question is whether it makes a difference in
> a full build. There won't be many translation units that
> don't include some other headers. (though of course I won't
> be surprised if it does make a difference.)
>
> If it's a real issue, you could fix this like how the
> other similar cases were handled by system.h, by adding this
> in system.h:
>
> #ifdef __cplusplus
> #ifdef INCLUDE_UNIQUE_PTR
> # include "unique-ptr.h"
> #endif
> #endif
>
> instead of unconditionally including <memory> there,
> and then translation units that want unique-ptr.h would
> do "#define INCLUDE_UNIQUE_PTR" instead of #include "unique-ptr.h",
> like done for a few other C++ headers.
>
> (I maintain that IMO this is kind of self-inflicted GCC pain due
> to the fact that "#pragma poison" poisons too much. If #pragma
> poison's behavior were adjusted (or a new variant/mode created) to
> ignore references to the poisoned symbol names in system headers (or
> something like that), then you wouldn't need this manual management
> of header dependencies in gcc/system.h and the corresponding
> '#define INCLUDE_FOO' contortions. There's nothing that you can
> reasonably
> do with a reference to a poisoned symbol in a system header, other
> than
> avoid having the system header have the '#pragma poison' in effect
> when
> its included, which leads to contortions like system.h's. Note that
> the poisoned names are _still used anyway_. So can we come up with
> a GCC change that would avoid having to worry about manually doing
> this? It'd likely help other projects too.)
>
> Thanks,
> Pedro Alves
FWIW, this one isn't from #pragma poison, it's from:
#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
(I messed up the --in-reply-to when posting the patch, but Gerald noted
the issue was due to:
/usr/include/c++/v1/typeinfo:199:2: error: no member named
'fancy_abort' in namespace 'std::__1'; did you mean simply
'fancy_abort'?
_VSTD::abort();
^~~~~~~
/usr/include/c++/v1/__config:390:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
/scratch/tmp/gerald/gcc-HEAD/gcc/system.h:725:13: note: 'fancy_abort'
declared here
extern void fancy_abort (const char *, int, const char *)
^
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01289.html
)
