ldionne wrote:
> > > I am on the fence whether a driver option is really needed. It is a very
> > > shallow layer of extra abstraction that a curious reader has to look
> > > through. I guess I'll not object to this, if people really want to add it.
> >
> >
> > Setting macros that are reserved names is really unappealing for people. We
> > want to provide a well integrated experience for library hardening and that
> > includes providing a friendly option at the compiler level. Other sanity
> > checking in the driver like erroring out when libc++ isn't in use is also
> > good,
>
> That pre-empts making it work for libstdc++ as suggested above...
Until we do something sane on libstdc++, I would error out in the Driver. As
soon as we know what to do on libstdc++, we should do that instead and stop
erroring out. Does that make sense? For example, in a next step we should
discuss whether it makes sense for `-fstdlib-hardening={extensive,debug}` to
turn on `_GLIBCXX_ASSERTIONS` on GCC. Maybe we even want that in `fast` mode?
We can do anything, but we should make sure to keep the libstdc++ folks in the
loop to make sure it makes sense.
https://github.com/llvm/llvm-project/pull/78763
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
