On 5/23/2016 12:46 AM, Richard Biener wrote:
> On Sun, 22 May 2016, Andrew Haley wrote:
>> On 05/20/2016 07:50 AM, David Wohlferd wrote:
>>> I realize deprecation/removal is drastic. Especially since basic
>>> asm (mostly) works as is. But fixing memory clobbers
On 5/18/2016 3:07 PM, Jeff Law wrote:
On 05/07/2016 11:38 AM, Andrew Haley wrote:
My argument in support of Bernd's proposal is that it makes sense from
a *practical* software reliability point of view. It wouldn't hurt,
and might fix some significant bugs. It's similar to the targets
which
A few questions:
1) I'm not clear precisely what problem this patch fixes. It's true
that some people have incorrectly assumed that basic asm clobbers memory
and this change would fix their code. But some people also incorrectly
assume it clobbers registers. I assume that's why Jeff Law
On 5/5/2016 10:29 AM, Bernd Edlinger wrote:
Hi!
this patch is inspired by recent discussion about basic asm:
Currently a basic asm is an instruction scheduling barrier,
but not a memory barrier, and most surprising, basic asm
does _not_ implicitly clobber CC on targets where
extended asm
On 4/25/2016 2:51 AM, Bernd Schmidt wrote:
On 04/16/2016 01:12 AM, David Wohlferd wrote:
There were basically 3 changes I was trying for in that doc patch. Are
any of them worth keeping? Or are we done?
1) "Do not clobber flags if they are being used as outputs."
2) Output fl
I've had it in a successful test run, and committed it with a minor
tweak (__builtin_abort vs return 1).
It didn't find anything, but it's probably good to have.
As for the docs, I think you are unnecessarily worried about things
that are never going to be a problem in practice.
Perhaps
Ping?
dw
On 4/1/2016 4:39 PM, David Wohlferd wrote:
> I would like executable code that verifies that this feature is
indeed working as intended.
First draft is attached. It tests all 28 (14 conditions plus 14
inverted). I wasn't sure what to set for optimization (O2? O3? O0?),
so I l
> I would like executable code that verifies that this feature is
indeed working as intended.
First draft is attached. It tests all 28 (14 conditions plus 14
inverted). I wasn't sure what to set for optimization (O2? O3? O0?), so
I left the default.
It looks like even at O3 there are some
Thanks for the feedback. While I agree with some of this, there are
parts that I want to defend. If after explaining why I did what I did
you still feel it should be changed, I'm prepared to do that.
On 3/24/2016 8:00 AM, Bernd Schmidt wrote:
> More problematic than a lack of documentation
show the benefit of the feature, it just seemed like
too much detail. Showing people the c code and reminding them to enable
optimizations (what the current patch does) seems like it should be
sufficient.
dw
On 3/12/2016 8:00 PM, David Wohlferd wrote:
The docs for the new(-ish) @cc co
to me, and more valuable to
users. Perhaps we can revisit the sample when pr24414 gets addressed.
I have removed my changes to the sample in the attached patch.
ChangeLog:
2016-03-16 David Wohlferd <d...@limegreensocks.com>
Bernd Schmidt <bschm...@redhat.com>
* doc
The docs for the new(-ish) @cc constraint need an example. Attached.
ChangeLog:
2016-03-12 David Wohlferd <d...@limegreensocks.com>
* doc/extend.texi: Add sample for @cc constraint
Note that while I have a release on file with FSF, I don't have write
access to SVN.
dw
that this patch both contains important information users need
and is better than the current text. I expect that Sandra is prepared
to check this in as soon as someone signs off on its technical accuracy.
dw
On 2/28/2016 11:02 PM, David Wohlferd wrote:
On 2/26/2016 7:09 AM, Bernd Schmidt wrote:
On 02/21
On 2/26/2016 7:09 AM, Bernd Schmidt wrote:
On 02/21/2016 11:27 AM, David Wohlferd wrote:
So now what? I have one Bernd who likes the sample, and one who
doesn't. Obviously I think what I'm proposing is better than what's
there now and I've done my best to say why. But me believing
On 2/20/2016 4:08 AM, Bernd Edlinger wrote:
Sorry, but I don't like this example at all.
First the new example is essentially academic and useless,
When used within a function, basic asm:
- causes difficulties for optimizers
- produces incompatibilities with other compilers
- has semantics
On 2/13/2016 8:00 PM, David Wohlferd wrote:
Fair enough. Committing what we can right now sounds like a good plan.
Attached is the doc patch, minus the proposed warning.
ChangeLog:
2016-02-19 David Wohlferd <d...@limegreensocks.com>
Bernd Schmidt <bschm...@redhat.com>
On 2/12/2016 4:51 AM, Bernd Schmidt wrote:
On 02/12/2016 08:05 AM, David Wohlferd wrote:
Actually, it was my intent that this apply to v6. It's not like there
is a significant change here. We're documenting long-time behavior, and
adding a (disabled) warning.
The doc patch (minus mentioning
On 2/12/2016 5:03 PM, Sandra Loosemore wrote:
On 02/12/2016 05:51 AM, Bernd Schmidt wrote:
On 02/12/2016 08:05 AM, David Wohlferd wrote:
Actually, it was my intent that this apply to v6. It's not like there
is a significant change here. We're documenting long-time behavior,
and
adding
something
different this time. Hopefully fixed.
Please split the ChangeLog
use relative file names.
Fixed (I think).
Please add the function name where you changed in brackets.
Fixed. == ChangeLog:
2016-02-11 David Wohlferd <d...@li
I don't think this is a patch we're considering for gcc-6, at least
not for the initial release - I imagine it could be backported from
gcc-7 at some point.
Actually, it was my intent that this apply to v6. It's not like there
is a significant change here. We're documenting long-time
On 2/11/2016 8:03 AM, Sandra Loosemore wrote:
On 02/11/2016 08:40 AM, Bernd Schmidt wrote:
But again, if someone feels the docs patch as posted is preferrable, go
ahead and approve it (for stage1 I assume).
TBH, I haven't looked at the documentation patch at all; I've been
ignoring this
comments.
ChangeLog:
2016-02-10 David Wohlferd <d...@limegreensocks.com>
* doc/extend.texi: Doc basic asm behavior and new
-Wbasic-asm-in-function option.
* doc/invoke.texi: Doc new -Wbasic-asm-in-function option.
* c-family/c.opt: Define -Wbasic-asm-in-function.
* c/c-pa
On 2/7/2016 10:45 PM, Bernd Edlinger wrote:
On 8. 2. 2016 04:45, David Wohlferd wrote:
I replied with a patch that includes most of the changes you asked for
(see inline below). Were you waiting on me for something more?
ChangeLog entries are still missing.
I'll add them back in the next
if there is
something more I need to do here.
Thanks,
dw
On 1/27/2016 11:20 PM, David Wohlferd wrote:
Rumors that I earn a commission for every person I switch to the
"extended asm" plan are completely unfounded... :)
That said, I truly believe there are very few cases where using basic
asm within
M, Bernd Schmidt wrote:
On 01/24/2016 11:23 PM, David Wohlferd wrote:
+Wonly-top-basic-asm
+C ObjC ObjC++ C++ Var(warn_only_top_basic_asm) Warning
+Warn on unsafe uses of basic asm.
Maybe just -Wbasic-asm?
Hmm. Maybe. I've never been completely satisfied with that name. But
wouldn't this s
On 1/26/2016 8:11 AM, Segher Boessenkool wrote:
On Tue, Jan 26, 2016 at 01:11:36PM +0100, Bernd Schmidt wrote:
On 01/26/2016 01:29 AM, Segher Boessenkool wrote:
In my opinion we should not warn for any asm that means the same both
as basic and as extended asm. The problem then becomes, what
://www.LimeGreenSocks.com/gcc/Basic-Asm.html
ChangeLog:
2016-01-24 David Wohlferd <d...@limegreensocks.com>
* doc/extend.texi: Doc basic asm behavior and new
-Wonly-top-basic-asm option.
* doc/invoke.texi: Doc new -Wonly-top-basic-asm option.
* c-family/c.opt: Define -Wonly-top-bas
On 2/5/2015 9:13 AM, Sandra Loosemore wrote:
In addition to fixing markup and capitalization, I've moved things
around a little bit to improve the flow, and rephrased a few things
that I thought were awkward or confusing. I propose to commit this in
a few days unless somebody tells me
Ping?
dw
On 11/15/2014 7:59 PM, David Wohlferd wrote:
On 9/15/2014 2:51 PM, Jeff Law wrote:
Let's go with your original inputs + outputs + labels change and punt
the clobbers stuff for now.
jeff
I have also added the test code you requested.
I have a release on file with the FSF
can get the ICE when using asm
goto.
ChangeLog:
2014-11-15 David Wohlferd d...@limegreensocks.com
PR target/61692
* cfgexpand.c (expand_asm_operands): Count all inline asm params.
* testsuite/gcc.dg/pr61692.c: New test.
dw
Index: gcc/cfgexpand.c
/01/14 02:07, David Wohlferd wrote:
I'd love to. Unfortunately, my platform doesn't support valgrind.
Ah.
Also, please include the testcase you had nlabels part.
I have created the testcase for the 31 labels problem. However, not so
much for the nclobbers part. And if I'm going to patch
On 7/28/2014 3:21 PM, Joseph S. Myers wrote:
On Wed, 23 Jul 2014, David Wohlferd wrote:
2014-07-23 David Wohlferd d...@limegreensocks.com
* doc/c-family/c-format.c: Add support for target macro
ASM_FPRINTF_TABLE, remove arm-specific formats.
* gcc/config/arm/arm.h
On 7/30/2014 9:58 PM, Jeff Law wrote:
On 07/28/14 16:39, David Wohlferd wrote:
On 7/28/2014 12:42 PM, Jeff Law wrote:
On 07/27/14 01:26, David Wohlferd wrote:
I'm not sure which maintainer to cc for inline asm stuff?
I have a release on file with the FSF, but don't have SVN write
access
On 7/28/2014 12:42 PM, Jeff Law wrote:
On 07/27/14 01:26, David Wohlferd wrote:
I'm not sure which maintainer to cc for inline asm stuff?
I have a release on file with the FSF, but don't have SVN write access.
Problem:
extract_insn() in recog.c will ICE if (noperands MAX_RECOG_OPERANDS
and reports a proper error for this condition. However,
expand_asm_operands() only checks (ninputs + noutputs) instead of
(ninputs + noutputs + nlabels), so you can get the ICE when using asm
goto. See the bugzilla entry for sample code.
ChangeLog:
2014-07-27 David Wohlferd d
-23 David Wohlferd d...@limegreensocks.com
* doc/c-family/c-format.c: Add support for target macro
ASM_FPRINTF_TABLE, remove arm-specific formats.
* gcc/config/arm/arm.h: Use ASM_FPRINTF_TABLE for %@ and %r.
* gcc/doc/tm.texi: Document new target macro
on LLP64 systems (like
Windows).
ChangeLog:
2014-07-09 David Wohlferd d...@limegreensocks.com
PR target/61662
* config/i386/ia32intrin.h: Use __LP64__ to determine size of long
This is OK for mainline and 4.9 backport.
Thank you for reviewing and approving this. However while I
) necessitate a
change to the ada docs. A few other minor clarifications are included.
ChangeLog:
2014-07-14 David Wohlferd d...@limegreensocks.com
* ada/gnat_rm.texi (Machine Code Insertions): Inline asm cleanup.
dw
Index: gnat_rm.texi
David Wohlferd d...@limegreensocks.com
* ada/gnat_rm.texi: Various cleanups for makeinfo 5.2.
dw
Index: gnat_rm.texi
===
--- gnat_rm.texi (revision 212420)
+++ gnat_rm.texi (working copy)
@@ -84,8 +84,10 @@
* Implementation
I changed more than I should have. A slightly smaller patch.
dw
On 7/14/2014 12:31 AM, David Wohlferd wrote:
I have a release on file with the FSF, but don't have SVN write access.
Problem description:
gnat docs have warning messages when compiled with makeinfo 5.2. Most
of them revolve
Doh! Since the component here is 'Target', I probably should have
included the x86-64 Port Maintainer in the TO line.
Jan, while I have a release on file with the FSF, I don't have SVN write
access.
dw
On 7/9/2014 12:51 AM, David Wohlferd wrote:
As requested, I am posting this patch
to
return incorrect results on LLP64 systems (like Windows).
ChangeLog:
2014-07-09 David Wohlferd d...@limegreensocks.com
PR target/61662
* config/i386/ia32intrin.h: Use __LP64__ to determine size of long
dw
Index: ia32intrin.h
describing things such as calling Basic asm
discourage people from attempting to misuse the feature.
ChangeLog:
2014-06-30 David Wohlferd d...@limegreensocks.com
* doc/extend.texi (Explicit Reg Vars): Rewrite and clarify.
* doc/implement-c.texi (Hints implementation): Use new name.
dw
On 6/30/2014 2:01 PM, Jeff Law wrote:
On 06/30/14 02:18, David Wohlferd wrote:
I don't have permissions to commit this patch, but I do have a release
on file with the FSF.
Problem description:
The text for using Explicit Register Variables is confusing, redundant,
and fails to make certain
On 6/30/2014 6:30 PM, Mike Stump wrote:
On Jun 30, 2014, at 4:10 PM, David Wohlferd d...@limegreensocks.com wrote:
- Vague descriptions of things that are reported to work on certain
platforms are not useful (On the SPARC, there are reports that).
I'd disagree. But what's more important here
to changing
the text from the vague avoid using to the very clear not supported
regarding the usage of Extended asm with 'naked.' Lastly, this
attribute should be mentioned when describing the differences between
Basic and Extended asm.
ChangeLog:
2014-06-17 David Wohlferd d...@limegreensocks.com
On 6/12/2014 9:21 AM, Kai Tietz wrote:
with addition of adding a second peephole2 pass after sched2 pass, I
was able to get some improvement for PR target/39284. I think by this
addition we can close bug as fixed.
Additionally additional peephole2 pass shows better results for PR
target/51840
David Wohlferd d...@limegreensocks.com
* doc/extend.texi: Create Label Attributes section,
move all label attributes into it and reference it.
dw
Index: extend.texi
===
--- extend.texi (revision 210577
My bad. My version of makeinfo wasn't reporting these errors.
However, this isn't right either. There are two subsections that are
now under Size of an asm that should be under Variables in Specified
Registers. How about this (attached)?
dw
On 5/17/2014 6:06 AM, Uros Bizjak wrote:
the origins of the directive and clarify when to use it (or not).
ChangeLog:
2014-05-16 David Wohlferd d...@limegreensocks.com
* doc/extend.texi (Symbol-Renaming Pragmas): Restore (slightly
modified) reference to Solaris.
dw
keep documenting the heritage so it's clear why
without having to give each a visibility attribute See
Function Attributes, for more information about visibility and the
attribute syntax.
ChangeLog:
2014-05-14 David Wohlferd d...@limegreensocks.com
* doc/extend.texi: (Visibility Pragmas) Fix misplaced @xref
dw
Index: extend.texi
Thank you for taking the time to review this.
the current text makes reference to compatibility with the Solaris system
headers, the remaining pragma is (according to the existing text)
currently on all platforms. This makes referring to Solaris both
superfluous and potentially confusing.
I
You misunderstood completely: I'm not at all demanding to remove support
for that pragma in the cross-platform part of the docs or even in the
code,
Whew! Ok, that's good. Sorry I went all crazy on you. When I thought
that *was* what you were asking for, I wanted to try to talk you out of
is
(according to the existing text) currently on all platforms. This
makes referring to Solaris both superfluous and potentially confusing.
ChangeLog:
2014-05-12 David Wohlferd d...@limegreensocks.com
* doc/extend.texi: Reflect current pragma count and remove
Solaris.
dw
Index
a long time ago (June 2012) in
revision 188983 (pr33190), leaving this perplexing sentence behind.
ChangeLog:
2014-05-11 David Wohlferd d...@limegreensocks.com
* doc/tm.texi: Remove reference to deleted macro.
* doc/tm.texi.in: Likewise.
dw
Index: tm.texi
55 matches
Mail list logo
