Re: gcc/DATESTAMP not updated any longer
Iain Sandoe via Gcc wrote: Jakub Jelinek via Gcc wrote: On Fri, Nov 06, 2020 at 08:56:25PM +0100, Richard Biener wrote: Darwin: Darwin 20 is to be macOS 11 (Big Sur). So, I'm afraid it must fail or bypass this code path somewhere earlier in the hooks. Is that maybe already known to the repo when it is on some rebased user branch? I don't think so. That commit was only present on a local branch, so not “known” to the repo, for sure. I think I'll work with Martin early next week to think about further spots to add logging, so we narrow down where it is still called and where it isn't. But we really don't have a reliable reproducer, commit this and it won't show up. Here’s another one ; r11-4824-g49393e266a2570cb622acd4674f922c8a26b In this case: 1) the commit message seems simple - no quotes, paretheses or other such characters. 2) there were no other commits close in time to this. (I don’t know if the server itself was busy or something of that nature, of course) Iain
Definition of EAF_NOESCAPE and fnspec strings
Hi,
I implemented simple propagation of EAF arguments for ipa-modref (that is not
hard to do). My main aim was to detect cases where THIS parameter does not
escape but is used to read/write pointed to memory. This is meant to
avoid poor code produced when we i.e. offline destructors on cold path.
Unfortunately detecting EAF_NOESCAPE for such parameters breaks. This is
already
visible on memcpy if we let it to be be handled via its fnspec
attribute. If I disable special handling in structalias:
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index a4832b75436..2b614913b57 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -4389,7 +4389,6 @@ find_func_aliases_for_builtin_call (struct function *fn,
gcall *t)
case BUILT_IN_STRCPY:
case BUILT_IN_STRNCPY:
case BUILT_IN_BCOPY:
- case BUILT_IN_MEMCPY:
case BUILT_IN_MEMMOVE:
case BUILT_IN_MEMPCPY:
case BUILT_IN_STPCPY:
In the following testcase we miss the fact that memcpy may merge i4p PTA
set to i3p.
extern void exit (int);
extern void abort (void);
int size = 8;
int main (void)
{
int i3 = -1, i4 = 55;
int *i3p = &i3;
int *i4p = &i4;
memcpy(&i3p, &i4p, size);
if (i3p != i4p)
abort ();
exit (0);
}
This seems to be documented for some degree:
/* Add *tem = nonlocal, do not add *tem = callused as
EAF_NOESCAPE parameters do not escape to other parameters
and all other uses appear in NONLOCAL as well. */
But it also means that some of our FNSPECs are wrong now. I wonder if we can
split this porperty to two different flags like EAF_NOEASCAPE and
EAF_INDIRECT_NOESCAPE?
Auto-detecting EAF_INDIRECT_NOESCAPE seems bit harder at least assuming
that any read can actually load few bits of pointer possibly written
there beause if simple member functions accesses values pointer by THIS
and return them we lose a track if the returned value is an escape point
I would say.
The difference in constraints are:
--- good/a.c.035t.ealias2020-11-08 13:34:04.397499515 +0100
+++ a.c.035t.ealias 2020-11-08 13:39:15.483438469 +0100
@@ -106,7 +106,15 @@
size = NONLOCAL
size.0_1 = size
_2 = size.0_1
-i3p = i4p
+callarg(18) = &i3p
+callarg(18) = callarg(18) + UNKNOWN
+CALLUSED(16) = callarg(18)
+CALLCLOBBERED(17) = callarg(18)
+*callarg(18) = NONLOCAL
+callarg(19) = &i4p
+callarg(19) = callarg(19) + UNKNOWN
+CALLUSED(16) = callarg(19)
+ESCAPED = _2
i3p.1_3 = i3p
i4p.2_4 = i4p
ESCAPED = &NULL
...
Call clobber information
-ESCAPED, points-to NULL, points-to vars: { }
+ESCAPED, points-to non-local, points-to NULL, points-to vars: { }
Flow-insensitive points-to information
-i3p.1_3, points-to NULL, points-to vars: { D.1947 D.1948 }
+i3p.1_3, points-to non-local, points-to escaped, points-to NULL, points-to
vars: { D.1947 }
i4p.2_4, points-to NULL, points-to vars: { D.1948 }
main ()
Honza
gcc-11-20201108 is now available
Snapshot gcc-11-20201108 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20201108/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision b642fca1c31b2e2175e0860daf32b4ee0d918085 You'll find: gcc-11-20201108.tar.xz Complete GCC SHA256=56aa7737dfb968a57e7cd7d8e1e8d2e02e6944d46c6b12a3c002a160ee7316c5 SHA1=9d8bb0ed5674b3c5941fb52a11f15e8dbc74d924 Diffs from 11-20201101 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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.
Why does -march=x86-64-v[234] require SysV psABI?
The current development docs say: >x86-64-v2 >x86-64-v3 >x86-64-v4 > > These choices for cpu-type select the corresponding > micro-architecture level from the x86-64 psABI. They are only available > when compiling for an x86-64 target that uses the System V psABI. > > Since these cpu-type values do not have a corresponding -mtune > setting, using -march with these values enables generic tuning. Specific > tuning can be enabled using the -mtune=other-cpu-type option with an > appropriate other-cpu-type value. Why are those options valid only for the SysV psABI targets? Despite the fact that SysV psABI specification is the document where those levels are defined, I don't think there's anything ABI-specific about them. It seems arbitrary to prevent the other targets (most notably Windows) from using them.
What rules should be followed when passing values with libcall?
I’m woking on TARGET_PROMOTE_FUNCTION_MODE for csky, and now there’s some
confusion.
For csky, the “POMOTE_MODE” is:
qi/hi -> si
the code is
#define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \
if (GET_MODE_CLASS (MODE) == MODE_INT \
&& GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \
(MODE) = SImode;
And the TARGET_PROMOTE_FUNCTION_MODE is
default_promote_function_mode_always_promote.
I expected it can work as “POMOTE_MODE” just as the description at “gcc
internal”. But it calls promote_mode() and treat “libcalls” specially.:
machine_mode
promote_mode (const_tree type ATTRIBUTE_UNUSED, machine_mode mode,
int *punsignedp ATTRIBUTE_UNUSED)
{
#ifdef PROMOTE_MODE
enum tree_code code;
int unsignedp;
scalar_mode smode;
#endif
/* For libcalls this is invoked without TYPE from the backends
TARGET_PROMOTE_FUNCTION_MODE hooks. Don't do anything in that
case. */
if (type == NULL_TREE)
return mode;
……
Why don’t promote the mode here? And when I compile runtime library, the
“char” and “short” args are promoted WITHOUT special treatment!
So, I modified the code to make sure the TARGET_PROMOTE_FUNCTION_MODE work
as POMOTE_MODE：
#undef TARGET_PROMOTE_FUNCTION_MODE
#define TARGET_PROMOTE_FUNCTION_MODE \
csky_promote_function_mode
……
static machine_mode
csky_promote_function_mode (const_tree type ATTRIBUTE_UNUSED,
machine_mode mode,
int *punsignedp ATTRIBUTE_UNUSED,
const_tree fntype ATTRIBUTE_UNUSED,
int for_return ATTRIBUTE_UNUSED)
{
if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD)
return SImode;
return mode;
}
But this code could lead to another mistake when I use some builtin
functions.
The __sync_val_compare_and_swap_1() coded at
“libgcc/config/csky/linux-atomic.c” use type “unsigned char” as its
argrument.
And this is consistent with the definition at gcc/builtins.def.
But when the code run at emit_library_call_value_1, all of the args are
treated as “signed”.
Part of source code of emit_library_call_value_1 ↓. The “unsigned_p” was
inited to 0, and was used at prmote_funciton_mode without reassignment.
for (unsigned int i = 0; count < nargs; i++, count++)
{
rtx val = args[i].first;
function_arg_info arg (args[i].second, /*named=*/true);
int unsigned_p = 0;
……
arg.mode = promote_function_mode (NULL_TREE, arg.mode, &unsigned_p,
NULL_TREE, 0);
argvec[count].mode = arg.mode;
argvec[count].value = convert_modes (arg.mode, GET_MODE (val), val,
unsigned_p);
argvec[count].reg = targetm.calls.function_arg (args_so_far, arg);
……
What’s reason for this act?
Re: Definition of EAF_NOESCAPE and fnspec strings
On Sun, 8 Nov 2020, Jan Hubicka wrote:
> Hi,
> I implemented simple propagation of EAF arguments for ipa-modref (that is not
> hard to do). My main aim was to detect cases where THIS parameter does not
> escape but is used to read/write pointed to memory. This is meant to
> avoid poor code produced when we i.e. offline destructors on cold path.
>
> Unfortunately detecting EAF_NOESCAPE for such parameters breaks. This is
> already
> visible on memcpy if we let it to be be handled via its fnspec
> attribute. If I disable special handling in structalias:
>
> diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
> index a4832b75436..2b614913b57 100644
> --- a/gcc/tree-ssa-structalias.c
> +++ b/gcc/tree-ssa-structalias.c
> @@ -4389,7 +4389,6 @@ find_func_aliases_for_builtin_call (struct function
> *fn, gcall *t)
>case BUILT_IN_STRCPY:
>case BUILT_IN_STRNCPY:
>case BUILT_IN_BCOPY:
> - case BUILT_IN_MEMCPY:
>case BUILT_IN_MEMMOVE:
>case BUILT_IN_MEMPCPY:
>case BUILT_IN_STPCPY:
>
> In the following testcase we miss the fact that memcpy may merge i4p PTA
> set to i3p.
>
> extern void exit (int);
> extern void abort (void);
> int size = 8;
>
> int main (void)
> {
> int i3 = -1, i4 = 55;
> int *i3p = &i3;
> int *i4p = &i4;
>
> memcpy(&i3p, &i4p, size);
> if (i3p != i4p)
> abort ();
> exit (0);
> }
>
> This seems to be documented for some degree:
>
> /* Add *tem = nonlocal, do not add *tem = callused as
>EAF_NOESCAPE parameters do not escape to other parameters
>and all other uses appear in NONLOCAL as well. */
>
> But it also means that some of our FNSPECs are wrong now. I wonder if we can
> split this porperty to two different flags like EAF_NOEASCAPE and
> EAF_INDIRECT_NOESCAPE?
Note that EAF_NOESCAPE allows "escaping" to the return value (see
handle_rhs_call). I guess for simplicity we could allow escaping
of not escaped but USED params to other written to params. I think
we also don't handle "escaping" of a parameter indirectly to itself, thus
int i;
int *p = &i;
int **q = &p;
foo (&q);
if (*q != i)
abort ();
and
foo (int ***p)
{
*p = **p;
}
or so with foos param EAF_NOESCAPE (but not EAF_DIRECT).
Splitting up EAF_NOESCAPE makes it quite difficult to understand.
Arguably explicit handling of memcpy and friends _does_ pay off
for points-to analysis since I'd say modelling all possible and useful
things in fnspec would make it a monster ... you'd basically want
to have a way to specify additional constraints in the fnspec itself,
like *1 = *2, but then also distinguish points-to effects from
may-alias ones.
I wonder if we should teach the GIMPLE FE to parse 'fn spec'
so we can write unit tests for the attribute ... or maybe simply
add this to the __GIMPLE spec string.
> Auto-detecting EAF_INDIRECT_NOESCAPE seems bit harder at least assuming
> that any read can actually load few bits of pointer possibly written
> there beause if simple member functions accesses values pointer by THIS
> and return them we lose a track if the returned value is an escape point
> I would say.
>
> The difference in constraints are:
>
> --- good/a.c.035t.ealias 2020-11-08 13:34:04.397499515 +0100
> +++ a.c.035t.ealias 2020-11-08 13:39:15.483438469 +0100
> @@ -106,7 +106,15 @@
> size = NONLOCAL
> size.0_1 = size
> _2 = size.0_1
> -i3p = i4p
> +callarg(18) = &i3p
> +callarg(18) = callarg(18) + UNKNOWN
> +CALLUSED(16) = callarg(18)
> +CALLCLOBBERED(17) = callarg(18)
> +*callarg(18) = NONLOCAL
> +callarg(19) = &i4p
> +callarg(19) = callarg(19) + UNKNOWN
> +CALLUSED(16) = callarg(19)
> +ESCAPED = _2
> i3p.1_3 = i3p
> i4p.2_4 = i4p
> ESCAPED = &NULL
>
> ...
>
> Call clobber information
>
> -ESCAPED, points-to NULL, points-to vars: { }
> +ESCAPED, points-to non-local, points-to NULL, points-to vars: { }
>
> Flow-insensitive points-to information
>
> -i3p.1_3, points-to NULL, points-to vars: { D.1947 D.1948 }
> +i3p.1_3, points-to non-local, points-to escaped, points-to NULL, points-to
> vars: { D.1947 }
> i4p.2_4, points-to NULL, points-to vars: { D.1948 }
>
> main ()
>
> Honza
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
Re: gcc/DATESTAMP not updated any longer
On 11/6/20 8:59 PM, Jakub Jelinek wrote:
I think I'll work with Martin early next week to think about further spots
to add logging, so we narrow down where it is still called and where it
isn't.
Hello.
I'm suggesting to use the following extra logging.
Martin
>From a39631f6515b60ae2a3c8de0129b9920471df18b Mon Sep 17 00:00:00 2001
From: marxin
Date: Mon, 9 Nov 2020 08:56:44 +0100
Subject: [PATCH] Another debugging.
---
sourceware/projects/src-home/git-hooks/hooks/post_receive.py | 4
1 file changed, 4 insertions(+)
diff --git a/sourceware/projects/src-home/git-hooks/hooks/post_receive.py b/sourceware/projects/src-home/git-hooks/hooks/post_receive.py
index 0e931f8..37166e6 100644
--- a/sourceware/projects/src-home/git-hooks/hooks/post_receive.py
+++ b/sourceware/projects/src-home/git-hooks/hooks/post_receive.py
@@ -18,6 +18,7 @@ from updates.factory import new_update
from utils import debug, warn
import traceback
+import datetime
def post_receive_one(ref_name, old_rev, new_rev, refs, submitter_email):
"""post-receive treatment for one reference.
@@ -35,6 +36,9 @@ def post_receive_one(ref_name, old_rev, new_rev, refs, submitter_email):
'new_rev=%s)'
% (ref_name, old_rev, new_rev))
+with open("/tmp/gcc-git-mail.log", "a") as f:
+ts = str(datetime.datetime.now())
+f.write('post_receive_one:%s: ref_name=%s, old_rev=%s, new_rev=%s\n' % (ts, ref_name, old_rev, new_rev))
update = new_update(ref_name, old_rev, new_rev, refs, submitter_email)
if update is None:
# We emit a warning, rather than trigger an assertion, because
--
2.29.2
