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
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 (
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:
-
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 only
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 af
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 no
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 aggr
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 Studi
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 it
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 ch
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 fine
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
> j
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.
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 affec
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 against deprecation. We sho
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 la
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
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
> 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 that.
>
> You know, there a
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 -Wonly-top
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 en
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 clobber, e.g.
asm(""), asm("
> 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"), ...
>
> I wonder about
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 this
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 this. People keep bringing up "a lot of existing basic
asm" in gener
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 be
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 t
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. S
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
>
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 m
> 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 register clobbers.
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 damag
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 do
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 targets
> 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 memory clobber
> or it can use ou
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
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 e
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 mo
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 volatile
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,
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 se
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 sem
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 doe
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 confu
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 (v
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.
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 thes
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 I
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
c/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. As mentioned previously, this patch
>>> introduces a
the previous thread, this patch now
>> does what it needs to do (code-wise) to resolve this "basic asm and
>> memory clobbers" issue. As mentioned previously, this patch
>> introduces a new warning (-Wonly-top-basic-asm), which is disabled by
>> default. When ena
> 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 should treat a asm ("")
>>> as if it
>>> were asm vo
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 ambiguit
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
should
treat it as asm vol
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 i
> 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 ("nonempty with optional %%" :::
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 @co
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 betwe
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 betwe
solve this "basic asm and
memory clobbers" issue. As mentioned previously, this patch
introduces a new warning (-Wonly-top-basic-asm), which is disabled by
default. When enabled, it triggers a warning for any basic asm inside
a function, unless the function has the "naked"
On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
> >Should asm("bla"); then be an extended asm with no input, no outputs,
> >no (non-automatic) clobbers? That would be the most straightforward and
> >logical semantics, but wil
>> To be clear, wouldn't asm("":) have the same effect?
>
> That does not matter. It'd require source-code changes to
> users' code.
My suggestion was to allow the exception to the "basic asm in a
function" warning, but change the docs to show using the new syntax.
This does not require any u
On Thu, 26 Nov 2015, David Wohlferd wrote:
> On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote:
> > On Thu, 26 Nov 2015, Segher Boessenkool wrote:
> > > On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> > > > @item noinline
...
> > > > asm ("");
...
> > I know, the point is that w
On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote:
On Thu, 26 Nov 2015, Segher Boessenkool wrote:
On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
On Fri, 20 Nov 2015, Richard Henderson wrote:
I'd be perfectly happy to deprecate and later completely remove basic asm
within fun
On Thu, 26 Nov 2015, Segher Boessenkool wrote:
> On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> > On Fri, 20 Nov 2015, Richard Henderson wrote:
> > > I'd be perfectly happy to deprecate and later completely remove basic asm
> > > within functions.
> >
> > We've explictly prom
On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> On Fri, 20 Nov 2015, Richard Henderson wrote:
> > I'd be perfectly happy to deprecate and later completely remove basic asm
> > within functions.
>
> We've explictly promised (directed to kernel people IIRC) that
> the empty bas
On Fri, 20 Nov 2015, Richard Henderson wrote:
> I'd be perfectly happy to deprecate and later completely remove basic asm
> within functions.
We've explictly promised (directed to kernel people IIRC) that
the empty basic asm; 'asm ("")', has forward-compatible
outlining magic, so people would not
On 25/11/15 02:11, David Wohlferd wrote:
> The 'fix' I am proposing is to give warnings for every use of basic asm
> inside functions (top-level asm is not a problem).
I'm not sure that's such a great idea on its own.
My suggestion:
1. Clobber memory.
2. Document a rule which says that all r
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
clobb
On 11/24/2015 8:58 AM, paul_kon...@dell.com wrote:
On Nov 23, 2015, at 8:39 PM, David Wohlferd wrote:
On 11/23/2015 1:44 PM, paul_kon...@dell.com wrote:
On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
...
The more I think about it, I'm just not keen on forcing all those old-style
asms t
> On Nov 24, 2015, at 12:49 PM, Ian Lance Taylor wrote:
>
> On Tue, Nov 24, 2015 at 8:58 AM, wrote:
>>
>> I'm really concerned with loosening the meaning of basic asm. I
>> wish I could find the documentation that says, or implies, that it
>> is a memory clobber. And/or that it is implicitl
On Tue, Nov 24, 2015 at 8:58 AM, wrote:
>
> I'm really concerned with loosening the meaning of basic asm. I
> wish I could find the documentation that says, or implies, that it
> is a memory clobber. And/or that it is implicitly volatile.
The volatile one is right there in the current docs.
h
> On Nov 23, 2015, at 8:39 PM, David Wohlferd wrote:
>
> On 11/23/2015 1:44 PM, paul_kon...@dell.com wrote:
>>> On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
>>>
>>> ...
The more I think about it, I'm just not keen on forcing all those
old-style asms to change.
>>> If you mean
On 23/11/15 21:02, David Wohlferd wrote:
>> On 11/23/2015 2:04 AM, Andrew Haley wrote:
>> > My warning still holds: there are modes of compilation on some
>> > machines where you can't clobber all registers without causing reload
>> > failures. This is why Jeff didn't fix this in 1999. So, if we
On 11/23/2015 10:12 PM, Segher Boessenkool wrote:
On Mon, Nov 23, 2015 at 09:48:42PM -0700, Jeff Law wrote:
On 11/23/2015 07:22 PM, Segher Boessenkool wrote:
Here is a test that shows that on at least PowerPC the basic asm is
identical to the extended asm without clobber (compile with -O2 -S a
On Mon, Nov 23, 2015 at 09:48:42PM -0700, Jeff Law wrote:
> On 11/23/2015 07:22 PM, Segher Boessenkool wrote:
> >
> >Here is a test that shows that on at least PowerPC the basic asm is
> >identical to the extended asm without clobber (compile with -O2 -S and
> >-fno-ipa-icf if you want to have it e
On 11/23/2015 07:22 PM, Segher Boessenkool wrote:
Here is a test that shows that on at least PowerPC the basic asm is
identical to the extended asm without clobber (compile with -O2 -S and
-fno-ipa-icf if you want to have it easier to read). In this case,
the basic asm is treated as not clobber
On Mon, Nov 23, 2015 at 05:39:17PM -0800, David Wohlferd wrote:
> On 11/23/2015 1:44 PM, paul_kon...@dell.com wrote:
> >>On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
> >>
> >>...
> >>>The more I think about it, I'm just not keen on forcing all those
> >>>old-style asms to change.
> >>If you
On 11/23/2015 1:44 PM, paul_kon...@dell.com wrote:
On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
...
The more I think about it, I'm just not keen on forcing all those old-style
asms to change.
If you mean you aren't keen to change them to "clobber all," I'm with you. If
you are worrie
> On Nov 23, 2015, at 4:36 PM, David Wohlferd wrote:
>
> ...
>> The more I think about it, I'm just not keen on forcing all those old-style
>> asms to change.
>
> If you mean you aren't keen to change them to "clobber all," I'm with you.
> If you are worried about changing them from basic to
On 11/23/2015 12:37 PM, Jeff Law wrote:
On 11/23/2015 03:04 AM, Andrew Haley wrote:
On 21/11/15 12:56, David Wohlferd wrote:
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 v
On 11/23/2015 2:04 AM, Andrew Haley wrote:
On 21/11/15 12:56, David Wohlferd wrote:
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 (m
On 11/23/2015 03:04 AM, Andrew Haley wrote:
On 21/11/15 12:56, David Wohlferd wrote:
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 (
On 21/11/15 12:56, David Wohlferd wrote:
> 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-b
Note that basic asm is part of the standard C++ syntax. "An asm
declaration has the form
asm-definition:
asm ( string-literal ) ;
The asm declaration is conditionally-supported; its meaning is
implementation-defined. [ Note: Typically
it is used to pass information through the implementation to
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
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
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
> On Nov 20, 2015, at 3:01 PM, Jeff Law wrote:
>
> On 11/20/2015 07:56 AM, Segher Boessenkool wrote:
>
> When basic asm changes, I expect that having a way to "just do what it
> used to do" is going to be useful for some people.
24414 says the documented behaviour hasn't been true
On 11/20/2015 07:56 AM, Segher Boessenkool wrote:
When basic asm changes, I expect that having a way to "just do what it
used to do" is going to be useful for some people.
24414 says the documented behaviour hasn't been true for at least
fourteen years. It isn't likely anyone is relying on tha
> On Nov 20, 2015, at 1:24 PM, Jeff Law wrote:
>
> On 11/20/2015 06:05 AM, Richard Henderson wrote:
>
>> ...
>> It seems to me that it would be better to remove the feature, forcing
>> what must be an extremely small number of users to audit and update to
>> extended asm.
> That might be a litt
On 11/20/2015 06:05 AM, Richard Henderson wrote:
I'd be perfectly happy to deprecate and later completely remove basic
asm within functions.
Because IMO it's essentially useless. It has no inputs, no outputs, and
no way to tell the compiler what machine state has been changed. We can
say tha
On 11/20/2015 04:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such being the case, "memory" is not sufficient:
#d
On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> >>It seems to me that it would be better to remove the feature, forcing what
> >>must be an extremely small number of users to audit and update to extended
> >>asm.
> >
> >Should asm("bla"); then be an extended asm with no input
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.
r~
On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
> >On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
> >>I'd be perfectly happy to deprecate and later completely remove basic asm
> >>within functions.
> >>
> >>B
On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
I'd be perfectly happy to deprecate and later completely remove basic asm
within functions.
Because IMO it's essentially useless. It has no inputs, no outputs, and no
way to tel
On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
> I'd be perfectly happy to deprecate and later completely remove basic asm
> within functions.
>
> Because IMO it's essentially useless. It has no inputs, no outputs, and no
> way to tell the compiler what machine state has bee
On Fri, Nov 20, 2015 at 02:45:05AM -0800, David Wohlferd wrote:
> On 11/19/2015 7:14 PM, Segher Boessenkool wrote:
> >On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote:
> >>For that reason, I'd like to propose adding 2 new clobbers to extended
> >>asm as part of this work:
> >>
> >>"cl
On 11/20/2015 01:38 PM, David Wohlferd wrote:
On 11/20/2015 3:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such b
1 - 100 of 119 matches
Mail list logo
