Re: C++ order of evaluation of operands, arguments
On 11/25/2015 01:25 PM, Martin Sebor wrote:
On 11/24/2015 02:55 AM, Andrew Haley wrote:
On 23/11/15 23:01, Jason Merrill wrote:
There's a proposal working through the C++ committee to define the order
of evaluation of subexpressions that previously had unspecified
ordering:
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
I agree with much of this, but was concerned about the proposal to
define order of evaluation of function arguments as left-to-right, since
GCC does right-to-left on PUSH_ARGS_REVERSED targets, including x86_64.
Any thoughts?
Not about PUSH_ARGS_REVERSED targets, but my two-penn'orth:
The proposal seems to be a bit of a minefield. This one:
a(b, c, d)
is a bit counter-intuitive. I wouldn't expect a to be evaluated before
the arg list. I wonder how many C++ programmers would.
The motivating example in the paper suggests that many C++
programmers expect a left to right order of evaluation here
due to the commonality of constructs like chains of calls.
Yes, although chains of calls like
var.fn1(args1).fn2(args2)
are covered by the "a.b" bullet. The above bullet would be more
relevant to a chain like
fn1(args1)(args2)
or
[captures]{...}(args)
Jason
gcc-6-20151129 is now available
Snapshot gcc-6-20151129 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20151129/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 231049 You'll find: gcc-6-20151129.tar.bz2 Complete GCC MD5=0dfcf510608cf3aeab75b33b5e7e0ce5 SHA1=016c2dd031ca7c8cffcea1b7123f366f0cad3184 Diffs from 6-20151122 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: basic asm and memory clobbers - Proposed solution
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 implementation should follow that
> direction.
>
attached is a patch that implements the above proposal.
I tried with this simple test case:
int x;
int main()
{
x = 1;
asm("test %eax,2");
x = 2;
}
gcc -O3 -S test.c
main:
.LFB0:
.cfi_startproc
movl$1, x(%rip)
#APP
# 5 "test.c" 1
test %eax,2
# 0 "" 2
#NO_APP
movl$2, x(%rip)
xorl%eax, %eax
ret
.cfi_endproc
What do you guys think?
Bernd.Index: gimple.c
===
--- gimple.c (Revision 230815)
+++ gimple.c (Arbeitskopie)
@@ -2567,6 +2567,10 @@
return true;
}
+ /* Non-empty basic ASM implicitly clobbers memory. */
+ if (gimple_asm_input_p (stmt) && strlen (gimple_asm_string (stmt)) != 0)
+return true;
+
return false;
}
Index: cfgexpand.c
===
--- cfgexpand.c (Revision 230815)
+++ cfgexpand.c (Arbeitskopie)
@@ -2650,9 +2650,23 @@
{
rtx body;
- if (TREE_CODE (string) == ADDR_EXPR)
-string = TREE_OPERAND (string, 0);
+ /* Non-empty basic ASM implicitly clobbers memory. */
+ if (TREE_STRING_LENGTH (string) != 0)
+{
+ rtx asm_op, clob;
+ asm_op = gen_rtx_ASM_OPERANDS (VOIDmode, empty_string, empty_string, 0,
+rtvec_alloc (0), rtvec_alloc (0),
+rtvec_alloc (0), locus);
+ MEM_VOLATILE_P (asm_op) = 1;
+
+ clob = gen_rtx_SCRATCH (VOIDmode);
+ clob = gen_rtx_MEM (BLKmode, clob);
+ clob = gen_rtx_CLOBBER (VOIDmode, clob);
+
+ emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, asm_op, clob)));
+}
+
body = gen_rtx_ASM_INPUT_loc (VOIDmode,
ggc_strdup (TREE_STRING_POINTER (string)),
locus);
Re: basic asm and memory clobbers - Proposed solution
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 volatile ("nonempty with optional %%" ::: "memory").
I agree. Even if that goes beyond the letter of what the manual has promised
before, it is the cautious answer, and it matches expectations of a lot of
existing code.
Trying to guess what people might have been expecting is a losing game.
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 these years.
And the first step to do that is to provide a means of finding them.
That's what the patch at
https://gcc.gnu.org/ml/gcc/2015-11/msg00198.html does.
Once they are located, people can decide for themselves what to do. If
they favor the 'cautious' approach, they can change their asms to use
:::"memory" (or start clobbering registers too, to be *really* safe).
For people who require maximum backward compatibility and/or minimum
impact, they can use :::.
Have you tried that patch? How many warnings does it kick out for your
projects?
dw
