On Fri, Mar 18, 2016 at 1:46 PM, Bernd Schmidt wrote:
> On 03/17/2016 06:23 AM, David Wohlferd wrote:
>>
>> 2016-03-16 David Wohlferd
>> Bernd Schmidt
>>
>> * doc/extend.texi: Doc basic asm behavior re clobbers.
>>
>
> Any objections from the release managers if I install this f
On 3/14/2016 8:28 AM, Bernd Schmidt wrote:
The example is not good, as discussed previously, and IMO the best
option is to remove it. Otherwise I have no objections to the latest
variant.
Despite the problems I have with the existing sample, adding the
information/warnings is more important t
On 03/17/2016 06:23 AM, David Wohlferd wrote:
2016-03-16 David Wohlferd
Bernd Schmidt
* doc/extend.texi: Doc basic asm behavior re clobbers.
Any objections from the release managers if I install this for David at
this stage?
Bernd
On 03/17/2016 06:23 AM, David Wohlferd wrote:
On 3/14/2016 8:28 AM, Bernd Schmidt wrote:
The example is not good, as discussed previously, and IMO the best
option is to remove it. Otherwise I have no objections to the latest
variant.
Despite the problems I have with the existing sample, adding
On 03/11/2016 01:55 AM, David Wohlferd wrote:
So, we have been discussing this issue for 4 months now. Over that
time, I have tried to incorporate everyone's feedback.
As a result we have gone from a tiny doc patch (just describe the
current semantics), to a big doc patch (completely deprecate
So, we have been discussing this issue for 4 months now. Over that
time, I have tried to incorporate everyone's feedback.
As a result we have gone from a tiny doc patch (just describe the
current semantics), to a big doc patch (completely deprecate basic asm
when used in a function) to a medi
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 it to be
be
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 it to be
better doesn't get anything checked in.
I ha
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 th
On 20.02.2016 02:03, David Wohlferd wrote:
> @example
> -/* Note that this code will not compile with -masm=intel */
> -#define DebugBreak() asm("int $3")
> +/* Define macro at file scope with basic asm. */
> +/* Add macro parameter p to eax. */
> +asm (".macro testme p\n\t"
> +"addl $\\p,
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
Bernd Schmidt
* doc/extend.texi: Doc basic asm behavior re clobbers
On 16.02.2016 15:03, Jan Hubicka wrote:
>> @example
>> -/* Note that this code will not compile with -masm=intel */
>> -#define DebugBreak() asm("int $3")
>> +/* Define macro at file scope with basic asm. */
>> +/* Add macro parameter p to eax. */
>> +asm(".macro test p\n\t"
>> +"addl $\\p, %
> @example
> -/* Note that this code will not compile with -masm=intel */
> -#define DebugBreak() asm("int $3")
> +/* Define macro at file scope with basic asm. */
> +/* Add macro parameter p to eax. */
> +asm(".macro test p\n\t"
> +"addl $\\p, %eax\n\t"
> +".endm");
> +
> +/* Use macro in
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 a (di
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 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 a (disabled) warning.
The doc patch (minus mentionin
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 the warning) could go in now, but for
gcc-6
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 issu
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 behav
why not simply -Wbasic-asm ?
Since both you and Bernd favor this shorter name, I have changed it.
Indentation wrong here. The whole block must be indented by 2 spaces.
Fixed.
Comments should end with dot space space */
Fixed.
the DECL_ATTRIBUTES should be at the same column as the "nak
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 issue because (a) I thought the technical details w
On 02/11/2016 12:49 AM, David Wohlferd wrote:
I believe the attached patch addresses all the other outstanding comments.
Bernd Edlinger made some thorough comments; I'll just add a few more. I
don't think this is a patch we're considering for gcc-6, at least not
for the initial release - I im
On 11.2.2016, David Wohlferd wrote:
>
> Since no one expressed any objections, I have renamed the option from
> -Wonly-top-basic-asm to -Wbasic-asm-in-function. This more clearly
> conveys what the option does (give a warning if you find basic asm in a
> function).
>
why not
Since no one expressed any objections, I have renamed the option from
-Wonly-top-basic-asm to -Wbasic-asm-in-function. This more clearly
conveys what the option does (give a warning if you find basic asm in a
function).
I believe the attached patch addresses all the other outstanding
ding) so I counter-proposed
-Wbasic-asm-in-function (a little verbose, but clearer). I have no
strong preferences here, and you haven't said one way or the other. Are
we just going to stick with -Wonly-top-basic-asm?
Hopefully one more try and this will be done.
Thanks,
dw
On 8. 2. 2016 04:45, David Wohlferd wrote:
> Hey Bernd.
>
> 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 have cleaned up the testcases so they aren't so i386-sp
27;T USE IT!"
But reading it all again, you are right: It's too much.
On 1/25/2016 4:25 AM, 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
/25/2016 4:25 AM, 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.
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 *
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 *is* the
> >meaning of a basic asm, what do
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 *is* the
meaning of a basic asm, what does it clobber.
I think this may be too hard to figure out in general wit
Hi David,
On Sun, Jan 24, 2016 at 02:23:53PM -0800, David Wohlferd wrote:
> - Warn that this could change in future versions of gcc. To avoid
> impacts from this change, use extended asm.
> - Implement and document -Wonly-top-basic-asm (disabled by default) as a
> way to loc
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?
+/* Warn on basic asm used inside of functions,
+ EXCEPT when in naked functions. Also allow asm
the
behavior of other compilers.
- Warn that this could change in future versions of gcc. To avoid
impacts from this change, use extended asm.
- Implement and document -Wonly-top-basic-asm (disabled by default) as a
way to locate affected statements.
This patch does these things.
34 matches
Mail list logo
