As a followup to my update to the inline asm docs, I'm cleaning up the
docs for 'Asm Labels.' The changes I want to make are pretty
straight-forward (attached; comments welcome). But then I came across
this line of code (from
https://github.com/rschmukler/cs537-p5/blob/master/xv6/proc.h#L38):
There isn't any description of using asm like this in the current Asm
Labels docs.
And there shouldn't be. It's a hack.
Ok, good. After experimenting with this, I wasn't looking forward to
trying to describe what did and didn't work.
dw
Thank you for the review and comments.
On 8/17/2015 3:41 AM, Segher Boessenkool wrote:
On Sun, Aug 16, 2015 at 06:33:40PM -0700, David Wohlferd wrote:
On systems where an underscore is normally prepended to the name of a C
-function or variable, this feature allows you to define names for
(Resending due to email glitch)
Thanks again for your comments.
On 8/18/2015 2:23 AM, Segher Boessenkool wrote:
On Mon, Aug 17, 2015 at 09:55:48PM -0700, David Wohlferd wrote:
On systems where an underscore is normally prepended to the name
of a C
-function or variable, this feature allows
[snip]
how about replacing the existing
text ("It does not make sense to use this feature with a non-static
local variable since such variables do not have assembler names.") with
"Do not use this feature with a non-static local variable." or maybe "It
is not supported to use this feature with a
In order for the doc maintainers to approve this patch, I need to have
someone sign off on the technical accuracy. Now that I have included
the points we have discussed (attached), hopefully we are there.
Original text: https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html
Proposed text: http://l
Having updated the docs for Basic asm, Extended asm, and Asm Labels, I
am now sending my patches for the last of the inline asm sections:
Explicit Reg Vars.
My first attempt to update this got postponed (see
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02369.html). This patch
addresses the
Patch 2/3 is the update for the Global Register Variables page (attached).
Reviewing this patch is going to be difficult.
It's a lot easier to review a patch that just has a few lines of text
being added. However, this leads to 'chunky' docs with a bunch of
disjointed paragraphs (which is wha
Patch 3/3 is the update for the Local Register Variables page (attached).
This patch starts with a question. Looking at bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64951 (register variable
with template function) is this a bug that will be fixed? Or a
limitation that should be doc'ed? B
Abot the patches themselves... Hard to review again, sigh...
I know, and I'm sorry.
I just can't see any way to completely re-org the text without the patch
becoming a nightmare. I was hoping the html links would make that
easier, but I guess not. On the plus side, Explicit reg vars is the
- Eventually the compiler may work differently than it does now.
That is helpful. It's a way signaling that things may change and that
depending on the precise syntax and semantics may be unwise.
From time to time, particularly with GCC extensions, it has been
necessary to declare certain u
Line too long. I know quite a bit of doc does that, but that's no
excuse :-)
Reduced to < 79.
+Registers can be a limited resource on some systems and allowing the
They are a limited resource on almost all systems. "Scarce resource"?
"Scarce" it is. I've left the rest alone for the mome
I'm trying to sum up what was discussed here. What I'm hearing is
(quoting Jeff):
> the technical reality is I can't see a use outside the extended asm.
Andrew has discussed some other uses, but as Jeff observed:
> Given the way the optimizers and register allocation work,
> I don't think we
I installed this patch from David with an update to use the "Registers
are a scarce resource ..." text.
2 down, 1 to go. Thanks.
dw
Given this, I'm going to go ahead and re-work the local register
variables page (probably tomorrow) stating extended asm is the only
supported usage. Although I also think it's important to mention
Andrew's point. If someone sees it in code somewhere, at least the docs
will give them some idea
Does gcc's inline asm support multi-alternative constraints? Or are
they only supported for md?
The fact that it is doc'ed with the other constraints
(https://gcc.gnu.org/onlinedocs/gcc/Constraints.html) says it works for
inline. But https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10396#c17 say
On 10/29/2015 1:47 PM, Richard Henderson wrote:
On 10/27/2015 02:05 PM, Jeff Law wrote:
On 10/25/2015 09:41 PM, David Wohlferd wrote:
Does gcc's inline asm support multi-alternative constraints? Or are
they only supported for md?
dw
PS If it *is* supported, then the docs need some wor
On 11/2/2015 3:43 PM, Sandra Loosemore wrote:
On 11/02/2015 04:06 PM, Jeff Law wrote:
On 10/30/2015 09:09 PM, David Wohlferd wrote:
I have updated the non-md text with (most of) the changes I think it
needs (attached). These changes are pleasantly minor, mostly just
adding some example text
On 11/6/2015 4:46 PM, Segher Boessenkool wrote:
On Fri, Nov 06, 2015 at 03:29:43PM -0700, Jeff Law wrote:
It's never easy to predict whether or not something like this will be
contentious. Worst case is you post, it's contentious, we iterate a bit
and reach some kind of resolution (ok, worst ca
It seems like a doc update is what is needed to close PR24414 (Old-style
asms don't clobber memory). I'm working on this now (phase 1) in the
unlikely event that someone is inspired to make a code change here instead.
Like Richard Henderson, I rather expected basic (or "old-style") asm to
pe
On 11/9/2015 1:52 PM, Jeff Law wrote:
On 11/07/2015 12:50 AM, David Wohlferd wrote:
- Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable
for inline asm. But both "#*" seem sketchy.
Right. =+& are no-brainer yes, as a
On 11/9/2015 2:03 AM, Richard Earnshaw wrote:
On 09/11/15 09:57, Richard Earnshaw wrote:
On 07/11/15 09:23, Segher Boessenkool wrote:
On Fri, Nov 06, 2015 at 11:50:40PM -0800, David Wohlferd wrote:
The same goes for some constraints and almost all output modifiers.
Are you suggesting more
On 11/9/2015 1:32 AM, Segher Boessenkool wrote:
On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote:
It seems like a doc update is what is needed to close PR24414 (Old-style
asms don't clobber memory).
What is needed to close the bug is to make the compiler work properly.
On 11/16/2015 1:29 PM, Jeff Law wrote:
On 11/15/2015 06:23 PM, David Wohlferd wrote:
On 11/9/2015 1:32 AM, Segher Boessenkool wrote:
On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote:
It seems like a doc update is what is needed to close PR24414
(Old-style
asms don't cl
Unless there are other benefits I'm just not seeing?
When we fix 24414 by honoring the "uses/clobbers all hard registers
and memory" semantics for old-style asms, those old-style asms will be
*less* likely to cause problems in the presence of ever-improving
optimization techniques.
Ok, this
On 11/20/2015 2:17 AM, Andrew Haley wrote:
On 20/11/15 01:23, David Wohlferd wrote:
I tried to picture the most basic case I can think of that uses
something clobber-able:
for (int x=0; x < 1000; x++)
asm("#stuff");
This generates very simple and highly pe
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:
"clobberall" - This gives extended the same semantics as whatever th
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 being the case, "memory&quo
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 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'
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/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
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 ste
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'
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
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.
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
>> 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 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 re
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
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
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
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 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 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 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 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
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
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
Not enough to call it a consensus, but perhaps the beginning
of one:
- Andrew Haley
- David Wohlferd
- Richard Henderson
- Segher Boessenkool
- Bernd Schmidt
Anyone else want to add their name here?
Maybe it's the implementation details that have other people concerned.
My thought is tha
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
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 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
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
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
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/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
I have been discussing adding some content to the basic asm docs. As
part of this work, I want to add a discussion of "How to convert basic
asm to extended asm." However it doesn't seem like this is a good fit
for the User Guide. This is both because the UG doesn't generally talk
about "How T
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 s
It is well known that on i386, the "cc" clobber is always set for
extended asm, whether it is specified or not. I was wondering how much
difference it might make if the generated code actually followed what
the user specified (expectation: not much). But implementing this
turned up a differen
On 1/26/2016 4:31 PM, Bernd Schmidt wrote:
On 01/27/2016 12:12 AM, David Wohlferd wrote:
I started by just commenting out the code in ix86_md_asm_adjust that
unconditionally clobbered the flags. I figured this would allow the
'normal' "cc" handling to occur. But apparently
On 2/1/2016 6:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catches this case as well.
This doesn't work on i386 bec
On 2/1/2016 12:40 PM, Richard Henderson wrote:
On 02/02/2016 01:58 AM, Ulrich Weigand wrote:
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catche
As part of the work I've done on inline asm, I've been looking thru the
bugs for it. There appear to be a number that have been fixed or
overtaken by events over the years, but the bug is still open.
Is closing some of these old bugs of any value?
If so, how do I pursue this?
dw
On 4/28/2016 2:01 AM, Richard Biener wrote:
On Thu, Apr 28, 2016 at 9:35 AM, David Wohlferd wrote:
As part of the work I've done on inline asm, I've been looking thru the bugs
for it. There appear to be a number that have been fixed or overtaken by
events over the years, but the bu
On 4/28/2016 9:41 AM, Martin Sebor wrote:
On 04/28/2016 01:35 AM, David Wohlferd wrote:
As part of the work I've done on inline asm, I've been looking thru the
bugs for it. There appear to be a number that have been fixed or
overtaken by events over the years, but the bug is still
On 4/28/2016 12:23 PM, Andrew Pinski wrote:
On Thu, Apr 28, 2016 at 12:35 AM, David Wohlferd
wrote:
As part of the work I've done on inline asm, I've been looking thru the bugs
for it. There appear to be a number that have been fixed or overtaken by
events over the years, but
Looking at the v6 release criteria
(https://gcc.gnu.org/gcc-6/criteria.html) there are about a dozen
supported platforms.
Looking at the Machine Constraints docs
(https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), there are
34 architectures listed. That's a lot of entries to scrol
On 5/9/2016 6:42 AM, paul_kon...@dell.com wrote:
On May 8, 2016, at 6:27 PM, David Wohlferd wrote:
If these architectures aren't supported anymore, is it time to drop some of
these from this page?
Your theory is quite mistaken. A lot of the ones you labeled "drop" are
su
Perhaps this post should be directed toward port maintainers?
Since several global maintainers have now suggested it, I have created a
patch that deprecates basic asm when used in a function (attached). It
excludes (ie does not deprecate) top level asm, asm in "naked"
functions, asm with empt
In the end, my problems with basic-asm-in-functions (BAIF) come down to
reliably generating correct code.
Optimizations are based on the idea of "you can safely modify x if you
can prove y." But given that basic asm are opaque blocks, there is no
way to prove, well, much of anything. Adding
On 6/21/2016 9:43 AM, Jeff Law wrote:
> I think there's enough resistance to deprecating basic asms within a
function that we should probably punt that idea.
I don't disagree that there has been pushback. I just wish less of it
was of the form "Because I don't wanna." A few examples of "Here
I'm looking at gcc/config/i386/avx512fintrin.h, and I see this:
extern __inline __m256i
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_cvtsepi64_epi32 (__m512i __A)
{
__v8si __O;
return (__m256i) __builtin_ia32_pmovsqd512_mask ((__v8di) __A,
According to the docs
(https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html),
__builtin_ia32_fxsave() has return type 'void.' Given that, does this
code (from gcc/config/i386/fxsrintrin.h) make sense?
_fxsave (void *__P)
{
return __builtin_ia32_fxsave (__P);
}
Ret
Best regards,
lh_mouse
2016-08-19
-----
发件人：David Wohlferd
发送日期：2016-08-19 11:51
收件人：gcc@gcc.gnu.org
抄送：
主题：fxsrintrin.h
According to the docs
(https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html),
__builtin_ia32_fxsave() has return type 'void.'
On 9/20/2016 12:36 PM, Gerald Pfeifer wrote:
[ Old e-mail alert ]
On Sat, 19 Dec 2015, David Wohlferd wrote:
I have been discussing adding some content to the basic asm docs. As part of
this work, I want to add a discussion of "How to convert basic asm to extended
asm." However
After updating gcc's docs about inline asm, I'm trying to improve some
of the related sections. One that I feel has problems with clarity is
__attribute__ naked.
I have attached my proposed update. Comments/corrections are welcome.
In a related question:
To better understand how this attri
Thank you for your response. This is exactly what I wanted to know. One
last question:
+While it
+is discouraged, it is possible to write your own prologue/epilogue code
+using asm and use ``C'' code in the middle.
I wouldn't remove the last sentence since IMO it's not the intent of the featu
After thinking about this some more, I believe I have some better text.
Previously I used the word "discouraged" to describe this practice. The
existing docs use the term "avoid." I believe what you want is
something more like the attached. Direct and clear, just like docs
should be.
If y
I have been looking at asm_fprintf in final.c, and I think there's a
design flaw. But since the change affects ARM and since I have no
access to an ARM system, I need a second opinion.
asm_fprintf allows platforms to add support for new format specifiers by
using the ASM_FPRINTF_EXTENSIONS ma
I believe that sometimes gcc is promoting the ints to long longs when
doing the overflow testing. If I try to overflow a long long, I get the
trap as expected.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
dw
On 7/23/2014 7:56 AM, Thomas Mertes wrote:
C is popular as intermedi
Not that the following would constitute the actual testing
usually required for a patch, but:
/path/to/toplevel/configure --target=arm-eabi && make all-gcc
# Yay, the compiler-proper for a "bare iron" ARM compiler.
./gcc/xgcc -B./gcc -S test.c
Woot, compiled your first ARM program. :) Just e
Hans-Peter Nilsson: I should have listened to you back when you raised
concerns about this. My apologies for ever doubting you.
In summary:
- The "trick" in the docs for using an arbitrarily sized struct to force
register flushes for inline asm does not work.
- Placing the inline asm in a sep
On 9/25/2014 12:36 AM, Yury Gribov wrote:
On 09/24/2014 12:31 PM, Richard Biener wrote:
On Wed, Sep 24, 2014 at 9:43 AM, David Wohlferd
wrote:
Hans-Peter Nilsson: I should have listened to you back when you raised
concerns about this. My apologies for ever doubting you.
In summary:
- The
You want
"=m" (*( struct foo { char x[8]; } __attribute__((may_alias)) *)Dest)
Thank you. With your help, that worse-than-useless sample in the docs
is getting closer to something people can actually use.
Except for one last serious problem: This trick only works for very
specific (and
Sorry for the (very) delayed response. I'm still looking for feedback
here so I can fix the docs.
To refresh: The topic of conversation was the (extremely) wrong
explanation that has been in the docs since forever about how to use
memory constraints with inline asm to avoid the performance hi
On 11/13/2014 6:02 AM, Richard Biener wrote:
On Thu, Nov 13, 2014 at 2:53 PM, Hans-Peter Nilsson wrote:
On Thu, 13 Nov 2014, David Wohlferd wrote:
Sorry for the (very) delayed response. I'm still looking for feedback here so
I can fix the docs.
Thank you for your diligence.
As I
Can you please file a bug in bugzilla if you haven't already done so?
We can still fix bugs during the next three months ;)
Well, I opened one. Briefly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63900
dw
On 1/17/2015 12:13 PM, Sandra Loosemore wrote:
BTW, as a GCC user I'm also very frustrated by the (lack of)
organization in the extensions chapter; the information about
attributes and built-in functions is all mixed up with sections on
random syntactic extensions like "Dollar Signs in Identif
The page for Extensions to the C Language Family
(https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html) is very long (60+
items) and completely unordered. This makes it hard to find things,
even when you know they are there. I have taken a first shot at
grouping these. Hopefully it can at le
> H, looking at your list, I think it is better to leave things that
> are hard to categorize where they are, as top-level sections within the
> chapter, rather than trying to group them arbitrarily with other things
> that are hard to categorize; the latter only makes things things harder
> t
On 1/22/2015 1:23 PM, Joseph Myers wrote:
On Thu, 22 Jan 2015, Jeff Law wrote:
Inline: Defining inline functions (as fast as macros).
Doesn't seem to belong here.
Given that inline isn't really an extension anymore, one could argue this
isn't relevant anymore.
Well, we need to documen
Why does gcc allow you to specify clobbers using numbers:
asm ("" : : "r" (var) : "0"); // i386: clobbers eax
How is this better than using register names?
This makes even less sense when you realize that (apparently) the
indices of registers aren't fixed. Which means there is no way to kn
On 3/11/2015 4:19 PM, Ian Lance Taylor wrote:
On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd wrote:
Why does gcc allow you to specify clobbers using numbers:
asm ("" : : "r" (var) : "0"); // i386: clobbers eax
How is this better than using register name
On 3/11/2015 4:41 PM, paul_kon...@dell.com wrote:
On Mar 11, 2015, at 7:19 PM, Ian Lance Taylor wrote:
On Wed, Mar 11, 2015 at 3:58 PM, David Wohlferd wrote:
Why does gcc allow you to specify clobbers using numbers:
asm ("" : : "r" (var) : "0"); // i
Resending due to bounced email.
On 3/11/2015 6:19 PM, Ian Lance Taylor wrote:
On Wed, Mar 11, 2015 at 5:51 PM, David Wohlferd wrote:
The reason I believe the order can change is this comment from i386.h:
/* Order in which to allocate registers. Each register must be
listed once, even
On 3/12/2015 7:24 AM, paul_kon...@dell.com wrote:
On Mar 11, 2015, at 8:53 PM, David Wohlferd wrote:
...
I would agree that one should avoid it. I'd be wary of removing it
from GCC at this point since it might break working code.
It certainly would. It’s not all that common, but I
Environment:
gcc 6.1
compiling for 64bit i386
optimizations: -O2
Consider this simple bit of code (from
https://stackoverflow.com/a/45656087/2189500):
#include
int getStringLength(const char *pStr){
int len;
__asm__ (
"repne scasb\n\t"
"not %%ecx\n\t"
"dec
On 8/12/2017 10:14 PM, Andrew Pinski wrote:
On Sat, Aug 12, 2017 at 10:08 PM, Andrew Pinski wrote:
On Sat, Aug 12, 2017 at 9:21 PM, David Wohlferd wrote:
Environment:
gcc 6.1
compiling for 64bit i386
optimizations: -O2
Consider this simple bit of code (from
https://stackoverflow.com/a
99 matches
Mail list logo
