Re: basic asm and memory clobbers - Proposed solution

On Sun, Dec 20, 2015 at 02:53:15PM -0800, David Wohlferd wrote: > >You do not have to escape the { and } for extended asm, on this target, > >using %{ produces even an error. > > I believe the only the only target that needs to escape {} is i386, > since it's the only one that supports dialects

Re: basic asm and memory clobbers - Proposed solution

On 20.12.2015 23:53, David Wohlferd wrote: > On 12/20/2015 10:26 AM, Bernd Edlinger wrote: >> On 19.12.2015 19:54, David Wohlferd wrote: >> mep: mep_interrupt_saved_reg looks for ASM_INPUT in the body, and >> saves different registers if found. > I'm trying to follow this code. A real

Re: basic asm and memory clobbers - Proposed solution

On 12/20/2015 10:26 AM, Bernd Edlinger wrote: On 19.12.2015 19:54, David Wohlferd wrote: mep: mep_interrupt_saved_reg looks for ASM_INPUT in the body, and saves different registers if found. I'm trying to follow this code. A real challenge since I know nothing about mep. But what I see is:

Re: basic asm and memory clobbers - Proposed solution

Hi, On 19.12.2015 19:54, David Wohlferd wrote: > mep: mep_interrupt_saved_reg looks for ASM_INPUT in the body, and saves different registers if found. >>> I'm trying to follow this code. A real challenge since I know nothing >>> about mep. But what I see is: >>> >>> - This routine

Re: basic asm and memory clobbers - Proposed solution

On 12/18/2015 11:55 AM, Bernd Edlinger wrote: On 18.12.2015 10:27, David Wohlferd wrote: On 12/17/2015 11:30 AM, Bernd Edlinger wrote: Adding this warning to -Wall is too quickly and will bring the ia64, tilegx and mep ports into trouble. It doesn't look to me like adding the warnings will

Re: basic asm and memory clobbers - Proposed solution

On 12/17/2015 6:03 AM, Jeff Law wrote: On 12/17/2015 03:39 AM, Andrew Haley wrote: On 17/12/15 01:41, David Wohlferd wrote: On the contrary, I would be surprised to learn that there are ANY compilers (other than clang) that support gcc's extended asm format. Prepare to be surprised: Sun

Re: AW: basic asm and memory clobbers - Proposed solution

On 12/17/2015 11:30 AM, Bernd Edlinger wrote: On Thu, 17 Dec 2015 15:13:07, Bernd Schmidt wrote: What's your take on making -Wonly-top-basic-asm a default (either now or v7)? Is making it a non-default a waste of time because no one will ever see it? Or is making it a default too

Re: basic asm and memory clobbers - Proposed solution

On 18.12.2015 10:27, David Wohlferd wrote: > On 12/17/2015 11:30 AM, Bernd Edlinger wrote: >> On Thu, 17 Dec 2015 15:13:07, Bernd Schmidt wrote: What's your take on making -Wonly-top-basic-asm a default (either now or v7)? Is making it a non-default a waste of time because

Re: basic asm and memory clobbers - Proposed solution

On 17/12/15 01:41, David Wohlferd wrote: > On the contrary, I would be surprised to learn that there are ANY > compilers (other than clang) that support gcc's extended asm format. Prepare to be surprised: Sun Studio compilers seem to support it just fine. Andrew.

Re: basic asm and memory clobbers - Proposed solution

On 12/17/2015 02:41 AM, David Wohlferd wrote: So how about: - Update the basic asm docs to describe basic asm's current (and historical) semantics (ie clobber nothing). - Emphasize how that might be different from users' expectations or the behavior of other compilers. - Warn that this could

Re: basic asm and memory clobbers - Proposed solution

On 17/12/15 11:39, Andrew Haley wrote: > On 17/12/15 01:41, David Wohlferd wrote: >> On the contrary, I would be surprised to learn that there are ANY >> compilers (other than clang) that support gcc's extended asm format. > > Prepare to be surprised: Sun Studio compilers seem to support it >

Re: basic asm and memory clobbers - Proposed solution

On 12/17/2015 03:39 AM, Andrew Haley wrote: On 17/12/15 01:41, David Wohlferd wrote: On the contrary, I would be surprised to learn that there are ANY compilers (other than clang) that support gcc's extended asm format. Prepare to be surprised: Sun Studio compilers seem to support it just

AW: basic asm and memory clobbers - Proposed solution

Hi, On Thu, 17 Dec 2015 15:13:07, Bernd Schmidt wrote: > > What's your take on making -Wonly-top-basic-asm a default (either now or > > v7)? Is making it a non-default a waste of time because no one will > > ever see it? Or is making it a default too aggressive? What about > > adding

Re: basic asm and memory clobbers - Proposed solution

On 12/15/2015 2:43 PM, Joseph Myers wrote: On Tue, 15 Dec 2015, David Wohlferd wrote: Unlike top level, using basic asm within a function is deprecated. No new code should use this feature, but should use extended asm instead. Existing code should begin replacing such usage. Instances of

Re: basic asm and memory clobbers - Proposed solution

On 12/15/2015 5:01 PM, paul_kon...@dell.com wrote: On Dec 15, 2015, at 5:22 PM, David Wohlferd wrote: On 12/14/2015 1:53 AM, Andrew Haley wrote: This just seems like another argument for deprecating basic asm and pushing people to extended. Yes. I am not arguing

Re: basic asm and memory clobbers - Proposed solution

On 12/15/2015 12:42 PM, paul_kon...@dell.com wrote: In the codebase for the product I work on, I see about 200 of them. Many of those are the likes of asm("sync") for MIPS, which definitely wants to be treated as if it were asm ("sync" : : : "memory"). That's right, I meant to ask you about

Re: basic asm and memory clobbers - Proposed solution

On 12/15/2015 1:13 PM, Jeff Law wrote: Sadly, I'm putting most of this discussion into my gcc-7 queue anyway. Fair enough. If "clobbers" is what we're going to do, that sounds more like a phase 1 thing. That said, some people who have this problem may prefer to fix it sooner rather than

AW: basic asm and memory clobbers - Proposed solution

Hi, On 15. Dezember 2015 23:43, Joseph Myers wrote: > I think the typical use of basic asm is: you want to manipulate I/O > registers or other such state unknown to the compiler (not any registers > the compiler might use itself), and you want to do it in a way that is > maximally compatible with

Re: basic asm and memory clobbers - Proposed solution

On 12/14/2015 1:53 AM, Andrew Haley wrote: > This just seems like another argument for deprecating basic asm and pushing people to extended. Yes. I am not arguing against deprecation. We should do that. You know, there are several people who seem to generally support this direction. Not

Re: basic asm and memory clobbers - Proposed solution

On 12/15/2015 01:42 PM, paul_kon...@dell.com wrote: On Dec 15, 2015, at 7:52 AM, Bernd Schmidt wrote: On 12/14/2015 09:10 AM, Segher Boessenkool wrote: That, and adding a memory clobber degrades performance for a lot of existing basic asm that does not expect the

Re: basic asm and memory clobbers - Proposed solution

> On Dec 15, 2015, at 7:52 AM, Bernd Schmidt wrote: > > On 12/14/2015 09:10 AM, Segher Boessenkool wrote: >> That, and adding a memory clobber degrades performance for a lot of >> existing basic asm that does not expect the clobber, e.g. asm(""), >> asm("#"), asm("nop"),

Re: basic asm and memory clobbers - Proposed solution

On Tue, 15 Dec 2015, David Wohlferd wrote: > Unlike top level, using basic asm within a function is deprecated. No new code > should use this feature, but should use extended asm instead. Existing code > should begin replacing such usage. Instances of affected code can be found > using

Re: basic asm and memory clobbers - Proposed solution

> On Dec 15, 2015, at 5:22 PM, David Wohlferd wrote: > > On 12/14/2015 1:53 AM, Andrew Haley wrote: >> > This just seems like another argument for deprecating basic asm and >> > pushing people to extended. >> Yes. I am not arguing against deprecation. We should do

AW: basic asm and memory clobbers - Proposed solution

Hi, On 12/15/2015 13:52, Bernd Schmidt wrote: > > On 12/14/2015 09:10 AM, Segher Boessenkool wrote: > > That, and adding a memory clobber degrades performance for a lot of > > existing basic asm that does not expect the clobber, e.g. asm(""), > > asm("#"), asm("nop"), ... > > I wonder about

Re: basic asm and memory clobbers - Proposed solution

On 13/12/15 06:15, David Wohlferd wrote: > > However breakage and performance issues can still result solely from > adding memory clobbers. Breakage? Really? > And as I mentioned, "just memory clobber" may > not be the behavior people expect. And if we aren't solving that, might > there

Re: basic asm and memory clobbers - Proposed solution

On Sun, Dec 13, 2015 at 10:59:11PM -0800, David Wohlferd wrote: > Is there a decision maker still teetering on the edge of making a call > here? I think people are waiting for consensus, and we won't get consensus until there is a good solution, something that gives workable semantics (whatever

Re: basic asm and memory clobbers - Proposed solution

Hi, On 12.12.2015 10:51, Andrew Haley wrote: > On 11/12/15 22:18, David Wohlferd wrote: > >> And here are the three solutions that have been proposed: >> >> Solution 1: >> Just document the current behavior of basic asm. >> >> People who have written incorrect code can be pointed at the text and

Re: basic asm and memory clobbers - Proposed solution

Is there a decision maker still teetering on the edge of making a call here? Or have they all moved on and we are just talking among ourselves? I keep worrying that if I don't reply, someone will swoop in, read the last message in the thread, and charge off to make a changes based on that.

Re: basic asm and memory clobbers - Proposed solution

On 12/12/2015 1:51 AM, Andrew Haley wrote: Solution 2: Change the docs to say that basic asm clobbers everything (memory, all registers, etc) or perhaps just memory (some debate here), but that due to bugs that will eventually be addressed, it doesn't currently work this way. You've missed the

Re: basic asm and memory clobbers - Proposed solution

On 11/12/15 22:18, David Wohlferd wrote: > And here are the three solutions that have been proposed: > > Solution 1: > Just document the current behavior of basic asm. > > People who have written incorrect code can be pointed at the text and > told to fix their code. People whose code is

Re: basic asm and memory clobbers - Proposed solution

> On Dec 12, 2015, at 4:51 AM, Andrew Haley wrote: > > ... > You've missed the most practical solution, which meets most common > usage: clobber memory, but not registers. That allows most of the > effects that people intuitively want and expect, but avoids the > breakage of

Re: basic asm and memory clobbers - Proposed solution

On 12/1/2015 7:41 PM, Jeff Law wrote: > My strong preference is still to document the desired semantics for GCC and treat anything that does not adhere to those semantics as a bug. Despite nearly 100 posts over 2 threads, we don't seem to be reaching either a consensus or a conclusion. How

Re: basic asm and memory clobbers - Proposed solution

> On Dec 3, 2015, at 12:29 AM, Bernd Edlinger wrote: > >> ... >> If the goal is to order things wrt x, why wouldn't you just reference x? >> >> x = 1; >> asm volatile("nop":"+m"(x)); >> x = 0; >> > > Exactly, that is what I mean. Either the asm can use

Re: basic asm and memory clobbers - Proposed solution

Am 03.12.2015 um 16:24 schrieb paul_kon...@dell.com: > On the other hand, asm volatile ("foo":::) has a different meaning. > That specifically says that "foo" doesn't clobber anything. Well, not exactly, see the md_asm_adjust target callback. On i386, rs6000, visium, cris and mn10300

Re: basic asm and memory clobbers - Proposed solution

On 03.12.2015 00:27 David Wohlferd wrote: > On 12/2/2015 3:34 AM, Bernd Edlinger wrote: >> Hi, >> >>> Surely in code like that, you would make "x" volatile? Memory clobbers >>> are not a substitute for correct use of volatile accesses. >> No, >> >> It is as I wrote, a memory clobber is the only

Re: AW: basic asm and memory clobbers - Proposed solution

On 12/2/2015 3:34 AM, Bernd Edlinger wrote: Hi, Surely in code like that, you would make "x" volatile? Memory clobbers are not a substitute for correct use of volatile accesses. No, It is as I wrote, a memory clobber is the only way to guarantee that the asm statement is not move somewhere

Re: AW: basic asm and memory clobbers - Proposed solution

On 02/12/15 08:51, Bernd Edlinger wrote: > On 1.12.2015, David Wohlferd wrote: > On 12/1/2015 10:10 AM, Bernd Edlinger wrote: >>> But IMHO asm("bla":) isn't any better than asm("bla"). >>> I think _any_ asm with non-empty assembler string, that >>> claims to clobber _nothing_ is highly suspicious,

Re: AW: basic asm and memory clobbers - Proposed solution

Hi, > Surely in code like that, you would make "x" volatile? Memory clobbers > are not a substitute for correct use of volatile accesses. No, It is as I wrote, a memory clobber is the only way to guarantee that the asm statement is not move somewhere else. I changed the example to use

Re: AW: basic asm and memory clobbers - Proposed solution

On 02/12/15 12:34, Bernd Edlinger wrote: > Hi, > >> Surely in code like that, you would make "x" volatile? Memory clobbers >> are not a substitute for correct use of volatile accesses. > > No, > > It is as I wrote, a memory clobber is the only way to guarantee that > the asm statement is not

Re: basic asm and memory clobbers - Proposed solution

On 11/30/2015 4:01 AM, Andrew Haley wrote: >> There is a way for people to be clear about what they want to clobber, >> and that's to use extended asm. The way to clear up the ambiguity is to >> start deprecating basic asm, not to add to the confusion by changing its >> behavior after all

Re: basic asm and memory clobbers - Proposed solution

On 12/1/2015 10:10 AM, Bernd Edlinger wrote: > And a test case is missing too. > > I think this warning concentrates now only on basic asm. > And people will be probably fix it in the most easy way, > by just adding a colon. Probably true. At least I hope it's that easy for most people. > But

Re: basic asm and memory clobbers - Proposed solution

On 12/1/2015 8:08 AM, Richard Earnshaw wrote: > Formatting nit: the '== NULL_TREE)' should line up with the start of > 'lookup_attribute'. > Same here. Ok. Other than that, how do we proceed here? When pursuing a course to "deprecate and later completely remove basic asm within functions," I

Re: basic asm and memory clobbers - Proposed solution

On Tue, 1 Dec 2015, David Wohlferd wrote: > Saying it's dead in the docs is the first step to making it dead in the code. > This patch just implements an optional warning (unless #3,4 crank it up to a > default warning), but the intent is that eventually (v7? v8?) this turns into > a fatal error.

Re: basic asm and memory clobbers - Proposed solution

On 01/12/2015 17:08, Richard Earnshaw wrote: > On 28/11/15 04:05, David Wohlferd wrote: >> On 11/24/2015 6:50 PM, David Wohlferd wrote: >>> I have solved the problem with my previous patch. Here's the update >>> (feedback welcome): http://www.LimeGreenSocks.com/gcc/24414g.zip >>> >>> Based on my

AW: basic asm and memory clobbers - Proposed solution

On 1.12.2015, David Wohlferd wrote: On 12/1/2015 10:10 AM, Bernd Edlinger wrote: > > But IMHO asm("bla":) isn't any better than asm("bla"). > > I think _any_ asm with non-empty assembler string, that > > claims to clobber _nothing_ is highly suspicious, and worth to be > > warned about. I don't

Re: basic asm and memory clobbers - Proposed solution

On Tue, Dec 01, 2015 at 08:41:22PM -0700, Jeff Law wrote: > Isn't "asm" conditionally supported for ISO C++? In which case it's not > mandatory and semantics are implementation defined. Yes. > My strong preference is still to document the desired semantics for GCC > and treat anything that

Re: basic asm and memory clobbers - Proposed solution

On 12/1/2015 7:56 PM, Segher Boessenkool wrote: On Tue, Dec 01, 2015 at 08:41:22PM -0700, Jeff Law wrote: Isn't "asm" conditionally supported for ISO C++? In which case it's not mandatory and semantics are implementation defined. Yes. My strong preference is still to document the desired

Re: basic asm and memory clobbers - Proposed solution

On 12/01/2015 04:25 PM, Joseph Myers wrote: On Tue, 1 Dec 2015, David Wohlferd wrote: Saying it's dead in the docs is the first step to making it dead in the code. This patch just implements an optional warning (unless #3,4 crank it up to a default warning), but the intent is that eventually

Re: basic asm and memory clobbers - Proposed solution

On 12/01/2015 03:29 PM, David Wohlferd wrote: On 11/30/2015 4:01 AM, Andrew Haley wrote: >> There is a way for people to be clear about what they want to clobber, >> and that's to use extended asm. The way to clear up the ambiguity is to >> start deprecating basic asm, not to add to the

Re: basic asm and memory clobbers - Proposed solution

On 28/11/15 04:05, David Wohlferd wrote: > On 11/24/2015 6:50 PM, David Wohlferd wrote: >> I have solved the problem with my previous patch. Here's the update >> (feedback welcome): http://www.LimeGreenSocks.com/gcc/24414g.zip >> >> Based on my understanding from the previous thread, this patch

Re: basic asm and memory clobbers - Proposed solution

> On Nov 29, 2015, at 6:53 PM, David Wohlferd wrote: > > > > On 11/28/2015 10:30 AM, paul_kon...@dell.com wrote: >>> On Nov 28, 2015, at 2:02 AM, Bernd Edlinger >>> wrote: >>> >>> ... >>> Well, I start to think that Jeff is right, and we

Re: basic asm and memory clobbers - Proposed solution

On 11/29/2015 11:53 PM, David Wohlferd wrote: > > Trying to guess what people might have been expecting is a losing game. We have to do it all the time. > There is a way for people to be clear about what they want to clobber, > and that's to use extended asm. The way to clear up the

Re: basic asm and memory clobbers - Proposed solution

On 11/28/2015 10:30 AM, paul_kon...@dell.com wrote: On Nov 28, 2015, at 2:02 AM, Bernd Edlinger wrote: ... Well, I start to think that Jeff is right, and we should treat a asm ("") as if it were asm volatile ("" ::: ) but if the asm ("nonempty with optional %") we

RE: basic asm and memory clobbers - Proposed solution

Hi, > Well, I start to think that Jeff is right, and we should treat a asm ("") as > if it > were asm volatile ("" ::: ) > but if the asm ("nonempty with optional %") we should > treat it as asm volatile ("nonempty with optional %%" ::: "memory"). > Our docs should say that explicitly, and the

Re: basic asm and memory clobbers - Proposed solution

> On Nov 28, 2015, at 2:02 AM, Bernd Edlinger wrote: > > ... > Well, I start to think that Jeff is right, and we should treat a asm ("") as > if it > were asm volatile ("" ::: ) but if the asm ("nonempty with optional %") we > should > treat it as asm volatile

Re: basic asm and memory clobbers - Proposed solution

On 11/24/2015 6:50 PM, David Wohlferd wrote: I have solved the problem with my previous patch. Here's the update (feedback welcome): http://www.LimeGreenSocks.com/gcc/24414g.zip Based on my understanding from the previous thread, this patch now does what it needs to do (code-wise) to resolve

AW: basic asm and memory clobbers - Proposed solution

Hi, I just found this in the docs: The compiler copies the assembler instructions in a basic @code{asm} verbatim to the assembly language output file, without processing dialects or any of the @samp{%} operators that are available with extended @code{asm}. This results in minor differences

AW: basic asm and memory clobbers - Proposed solution

Hi, I just found this in the docs: The compiler copies the assembler instructions in a basic @code{asm} verbatim to the assembly language output file, without processing dialects or any of the @samp{%} operators that are available with extended @code{asm}. This results in minor differences

Re: AW: basic asm and memory clobbers - Proposed solution

On 11/27/2015 11:02 PM, Bernd Edlinger wrote: Hi, I just found this in the docs: The compiler copies the assembler instructions in a basic @code{asm} verbatim to the assembly language output file, without processing dialects or any of the @samp{%} operators that are available with extended

basic asm and memory clobbers - Proposed solution

I have solved the problem with my previous patch. Here's the update (feedback welcome): http://www.LimeGreenSocks.com/gcc/24414g.zip Based on my understanding from the previous thread, this patch now does what it needs to do (code-wise) to resolve this "basic asm and memory clobbers" issue.