On 11/20/2015 3:55 PM, David Wohlferd wrote:
On 11/20/2015 8:14 AM, Richard Henderson wrote:
On 11/20/2015 04:34 PM, Jakub Jelinek wrote:
Isn't that going to break too much code though? I mean, e.g. including
libgcc...
I don't know. My suspicion is very little.
But that's actually what I'd like to know before we start adjusting
code in other ways wrt basic asms.
I can provide a little data here.
In an effort to gain some perspective, I've been looking at inline asm
usage in the linux kernel (4.3). Clearly this isn't "typical usage,"
but it is probably one of the biggest users of inline asm, and likely
has the best justifications for doing so (being an OS and all).
There are ~5,678 instances of inline asm in use. Of those, ~4,833 are
extended and ~845 are basic.
I don't have any numbers about how many are top level vs in function,
but let me see what I can do.
Ok, the news here is mixed. Of those 845:
- Only 50 of them look like top level asm. I was hoping for more.
- 457 are in 6 files in the lib/raid6 directory, so there's a bunch that
can be done quickly.
- That leaves 338 miscellaneous other uses spread throughout some 200
files across multiple platforms. That seems like a lot.
Despite the concerns expressed by Jeff about the difficulties in
changing from basic to extended, it looks to me like they don't need any
conversion (other s/%/%%/). Adding the trailing colon should be
sufficient to provide the semantics they have now, which apparently is
deemed sufficient.
A quick look at libgcc shows that there are 109 extended and 45 basic
asm statements. I'll see how many end up being top-level, but it
looks like most of them.
Of the 45 basic asm statements, only 9 aren't top-level. They all
appear to be trivial to change to extended.
To sum up:
- Some projects (like libgcc) are going to be simple to update. Maybe an
hour's work all told.
- Some projects (like testsuite) are going to take longer. While the
changes are mostly straight-forward, the number of files involved will
be a factor.
- I took a look at the Mingw-w64 project. It has ~20 non-top level
asms, so also pretty simple to update.
- But some projects (like linux kernel) are going to be more
challenging. Not so much making the changes (although that will take a
while) as convincing yourself that the change was harmless and still
compiles on all supported platforms.
Yes, this represents a very limited sample. And one weighted towards
projects that are more likely to use asm. But it does give some sense
of the scale.
So, what now?
While I'd like to take the big step and start kicking out warnings for
non-top-level right now, that may be too bold for phase 3. A more
modest step for v6 would just provide a way to find them (maybe
something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the
current behavior as well as the upcoming change.
Adding the warning is not something I can do. But I'll create the doc
patch once someone confirms that this is the plan.
dw