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 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
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?
I have cleaned up the testcases so they aren't so i386-specific, but
otherwise this patch (attached) is the same. Let me know if there is
somethi
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 a function makes sense. What's more, either they currently
work incorrectly and need to be found
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 locate affected stateme
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("").
19 matches
Mail list logo
