On Fri, Sep 06, 2019 at 03:35:02PM -0700, Nick Desaulniers wrote: > On Fri, Sep 6, 2019 at 3:03 PM Segher Boessenkool > <seg...@kernel.crashing.org> wrote: > > And if instead you tested whether the actual feature you need works as > > you need it to, it would even work fine if there was a bug we fixed that > > breaks things for the kernel. Without needing a new compiler. > > That assumes a feature is broken out of the gate and is putting the > cart before the horse. If a feature is available, it should work.
GCC currently has 91696 bug reports. > > Or as another example, if we added support for some other flags. (x86 > > has only a few flags; many other archs have many more, and in some cases > > newer hardware actually has more flags than older). > > I think compiler flags are orthogonal to GNU C extensions we're discussing > here. No, I am talking exactly about what you brought up. The flags output for inline assembler, using the =@ syntax. If I had implemented that for Power when it first came up, I would by now have had to add support for another flag (the CA32 flag). Oh, and I would not have implemented support for OV or SO at all originally, but perhaps they are useful, so let's add that as well. And there is OV32 now as well. > > With the "macro" scheme we would need to add new macros in all these > > cases. And since those are target-specific macros, that quickly expands > > beyond reasonable bounds. > > I don't think so. Can you show me an example codebase that proves me wrong? No, of course not, because we aren't silly enough to implement something like that. > > If you want to know if you can do X in some environment, just try to do X. > > That's a very autoconf centric viewpoint. Why doesn't the kernel take > that approach for __GCC_ASM_FLAG_OUTPUTS__? Ask them, not me. Segher
