Messages in this thread |  | | Date | Fri, 6 Sep 2019 17:56:06 -0500 | From | Segher Boessenkool <> | Subject | Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition |
| |
On Fri, Sep 06, 2019 at 03:35:02PM -0700, Nick Desaulniers wrote: > On Fri, Sep 6, 2019 at 3:03 PM Segher Boessenkool > <segher@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
|  |