This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition
On Fri, Sep 06, 2019 at 04:42:58PM -0700, Nick Desaulniers via gcc-patches wrote:
> On Fri, Sep 6, 2019 at 3:56 PM Segher Boessenkool
> <firstname.lastname@example.org> wrote:
> Oh, I misunderstood. I see your point. Define the symbol as a number
> for what level of output flags you support (ie. the __cplusplus
That works if history is linear. I guess with enough effort we can make
that work in most cases (for backports it is a problem, if you want to
support a new feature -- or bugfix! -- you need to support all previous
ones as well... Distros are going to hate us, too ;-) )
> > > 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.
> I still don't think feature detection is worse than version detection
> (until you find your feature broken in a way that forces the use of
> version detection).
*You* bring up version detection. I don't. You want some halfway thing,
with some macros that say what version some part of your compiler is.
I say to just detect the feature you want, and if it actually works the
way you want it, etc.
> Just to prove my point about version checks being brittle, it looks
> like Rasmus' version check isn't even right. GCC supported `asm
> inline` back in the 8.3 release, not 9.1 as in this patch:
Yes, I backported it so that it is available in 7.5, 8.3, and 9.1, so
that more users will have this available sooner. (7.5 has not been
released yet, but asm inline has been supported in GCC 7 since Jan 2
> Or was it "broken" until 9.1? Lord knows, as `asm inline` wasn't in
> any release notes or bug reports I can find:
It never was accepted, and I dropped the ball.
> Ah, here it is:
> Which looks like the qualifier was added to this page:
Sure, it is part of the documentation just fine. And it works just fine
too, it is a *very* simple feature. By design.
> I like many of the GNU C extensions, and I want to help support them
> in Clang so that they can be used in more places, but the current
> process (and questions I have when I implement some of them) leaves me
> with the sense that there's probably room for improvement on some of
> these things before they go out the door.
> Segher, next time there's discussion about new C extensions for the
> kernel, can you please include me in the discussions?
You can lurk on gcc-patches@ and/or gcc@? But I'll try to remember, sure.
Not that I am involved in all such discussions myself, mind.