C++11 support still experimental?
[1] still says in its third paragraph: --q-- Important: GCC's support for C++11 is still experimental. Some features were implemented based on early proposals, and no attempt will be made to maintain backward compatibility when they are updated to match the final C++11 standard. --/q-- [1] https://gcc.gnu.org/projects/cxx0x.html Uros.
Re: C++11 support still experimental?
On 21 November 2015 at 10:35, Uros Bizjak wrote: > [1] still says in its third paragraph: > > --q-- > Important: GCC's support for C++11 is still experimental. Some > features were implemented based on early proposals, and no attempt > will be made to maintain backward compatibility when they are updated > to match the final C++11 standard. > --/q-- > > [1] https://gcc.gnu.org/projects/cxx0x.html I posted a patch for it https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00531.html but never made the changes Gerald requested. I've committed the first part now, as attached. Index: cxx0x.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx0x.html,v retrieving revision 1.69 diff -u -r1.69 cxx0x.html --- cxx0x.html 30 Sep 2015 09:01:43 - 1.69 +++ cxx0x.html 21 Nov 2015 12:31:42 - @@ -27,10 +27,10 @@ GCC 4.7 and later support -std=c++11 and -std=gnu++11 as well. - Important: GCC's support for C++11 is still + Important: Before GCC 5.1 support for C++11 was experimental. Some features were implemented based on - early proposals, and no attempt will be made to maintain backward - compatibility when they are updated to match the final C++11 + early proposals, and no attempt was made to maintain backward + compatibility when they were updated to match the final C++11 standard. C++11 Language Features
Re: basic asm and memory clobbers
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
[middle-end] How to handle fake register in DECL_INCOMING_RTL?
When implementing interrupt attribute for x86 interrupt handlers, we have a difficult time to access interrupt data passed down by x86 processors. On x86, interrupt handlers are only called by processors which push interrupt data onto stack at the address where the normal return address is. Interrupt handlers must access interrupt data via pointers so that they can update interrupt data. TARGET_FUNCTION_ARG_ADVANCE is skipped by interrupt handlers since they are only called by processors. Since interrupt data is at one word below the normal argument location on stack and must be accessed via pointer, we changed TARGET_FUNCTION_ARG to return a fake hard register for interrupt handlers and updated expander to covert the fake register to its address on stack. However, we run into problems with /* For PARM_DECL, holds an RTL for the stack slot or register where the data was actually passed. */ #define DECL_INCOMING_RTL(NODE) \ (PARM_DECL_CHECK (NODE)->parm_decl.incoming_rtl) >From what I can tell, DECL_INCOMING_RTL is a constant after it is set up. For interrupt handlers, DECL_INCOMING_RTL contains a fake register, which isn't a problem in codegen since it is covered by expander. But DECL_INCOMING_RTL is also used to generate debug information and debug output never expects a fake register in DECL_INCOMING_RTL. To work around it, we changed x86 prologue expander to update DECL_INCOMING_RTL with the fake register in interrupt handlers to its address on stack. We are asking middle-end maintainers, is this a correct solution? If not, what other approaches should we try? -- H.J.
Re: basic asm and memory clobbers
On 11/19/2015 5:53 PM, Sandra Loosemore wrote: On 11/19/2015 06:23 PM, David Wohlferd wrote: About the only immediate task would be to ensure that the documentation for traditional asms clearly documents the desired semantics and somehow note that there are known bugs in the implementation (ie 24414, handling of flags registers, and probably other oddities) Given that gcc is at phase 3, I'm guessing this work won't be in v6? Or would this be considered "general bugfixing?" The reason I ask is I want to clearly document what the current behavior is as well as informing them about what's coming. If this isn't changing until v7, the text can be updated then to reflect the new behavior. Documentation fixes are accepted all the way through Stage 4, since there's less risk of introducing regressions in user programs from accidental documentation mistakes than code errors. The code change isn't yet finalized. I'm hoping to doc something vaguely like: "basic asm (other than at top level) is being deprecated because blah> potentially unsafe due to optimizations . You can locate the statements that will no longer be supported using -Wonly-top-basic-asm. Change them to use extended asm instead." What's your take on having the user guide link to the gcc wiki? If we do make this change, I'd kinda like to create a "how to convert basic asm to extended." But it doesn't seem like a good fit for the user docs. But if the user docs don't reference the wiki, I doubt anyone would ever find it. OTOH, I'd discourage adding anything to the docs about anticipated changes in future releases, except possibly to note that certain features or behavior are deprecated and may be removed in future releases (with a suggestion about what you should do instead). I'd love to see the doc folks make a pass and remove every "some day this won't work" text that doesn't include this. If there is no way for users to prepare, you aren't helping. And remove all the "some day there might be a new feature" stuff too. It just wastes users' time trying to figure out if "some day" has arrived yet. And it makes them cry when the new feature, which is exactly what they need, isn't there yet. We've already got too many "maybe someday this will be fixed" notes in the manual that are not terribly useful to users. You'd get my vote to remove them all. If I got a vote. dw
