Git rejecting branch merge
Hello, I am trying to update me/honza-gcc-benchmark-branch to current trunk which I do by deleting it, recreating locally and pushing out. The problem is that the push fails witih: remote: *** The following commit was rejected by your hooks.commit-extra-checker script (status: 1) remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1 remote: *** The first line of a commit message should be a short description of the change, not a single word. remote: error: hook declined to update The broken commit is: $ git show 03e87724864a17e22c9b692cc0caa014e9dba6b1 commit 03e87724864a17e22c9b692cc0caa014e9dba6b1 Author: Georg-Johann Lay Date: Tue Jan 14 11:09:38 2020 +0100 Typo. libgcc/ * config/avr/lib1funcs.S (skip): Simplify. I wonder is there a way to get this done? Thanks, Honza
mstackalign vs rbp order in gcc optimization level epilogue/prologue - O2/O3
Hi, I was looking at the implementation of mstackalign in gcc (O2/O3) and it looks like we generate code for mstackalign (i.e. generate instructions for stack alignment) before pushing $rbp to stack/setting $rbp. In the epilogue, we do the same in reverse order. some_routine: 0x00400860 <+0>:lea0x8(%rsp),%r10 0x00400865 <+5>:and$0xfff0,%rsp 0x00400869 <+9>:pushq -0x8(%r10) 0x0040086d <+13>: push %rbp 0x0040086e <+14>: mov%rsp,%rbp : 0x00400983 <+291>: pop%rbp >> 0x00400984 <+292>: lea-0x8(%r10),%rsp 0x00400988 <+296>: retq In gdb, when I single-step to IP (Instruction Pointer) 0x00400984 (shown above) and try to get my stack trace using ‘gdb - where’, I do not get my full stack trace, this is what I get: (gdb) where #0 0x004009e3 in backtrace() () #1 0x00400b18 in fac(int) () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) And of course, if I just do one more ‘single stepi’ and stop at the next instruction retq / IP: 0x00400988, then everything works fine. (gdb) si 0x004009e7 in backtrace() () (gdb) where #0 0x004009e7 in backtrace() () #1 0x00400b18 in fac(int) () #2 0x00400b49 in func1(int) () #3 0x00400b69 in func2(int) () #4 0x0040078a in main () (gdb) It looks like this issue is showing up due to the order in which ‘%rbp’ is saved/restored w.r.t the ‘stack alignment code’ execution. In CLANG, %rbp is pushed/set first, then the stack is aligned, here is the CLANG generated code: Some_func: 0x00400850 <+0>:push %rbp 0x00400851 <+1>:mov%rsp,%rbp : 0x0040085d <+13>: and$0xfff0,%rsp 0x00400861 <+17>: sub$0x8d0,%rsp 0x00400868 <+24>: lea0x520(%rsp),%r14 0x00400870 <+32>: mov%r14,%rdi : 0x0040093a <+234>: lea-0x28(%rbp),%rsp : 0x00400947 <+247>: pop%rbp 0x00400948 <+248>: retq And with the CLANG generated code, ‘gdb – where’ works fine at every instruction pointer. Whereas, in GCC, the stack is aligned first, then the %rbp is pushed/set and that seems to be opening up a few instruction holes where 'gdb - where' wouldn't work. Would you folks consider this as a GCC bug? Do you folks see any issue in the CLANG approach? Is there a way (any switch) in gcc which would reverse the order of ‘setting %rbp’ vs ‘stack alignment code’ (like CLANG)? I used -mstackrealign with -O3 and -fomit-frame-pointer for generating my code.
Re: On IPA PTA field sensitivity and pointer expression (part 2)
Hi, answering my own question:
It looks that field_sensitivity was disabled for this particular
example. Because I was compiling with -O as opposed to -O2. (I disable
-O2 because I needed to parse gimple exactly as I wrote it, otherwise
some things might be optimized). After adding
--param=max-fields-for-field-sensitive=$val we have the correct
points-to solution.
c = { }
p1.0+64 = { }
p1.64+64 = { c }
p1.128+64 = { p1.0+64 }
main.clobber = { }
main.use = { p1.64+64 }
i_15 = { NONLOCAL } same as main.arg0
pc_28 = { c }
_27 = { NULL }
cast_32 = { c } same as pc_28
temp_33 = { p1.0+64 } same as p1.128+64
temp2_34 = { c }
Thanks!
On 28/09/2020 14:30, Erick Ochoa wrote:
On 28/09/2020 14:25, Erick Ochoa wrote:
Hi,
previously I sent an e-mail inquiring about the state of points-to
information of structure variables allocated in the heap. It was
brought to my attention that heap variables do not have a size to
model and therefore IPA-PTA is not able to provide field sensitivity.
I now understand better how field sensitivity is modeled in IPA-PTA
and the way size is needed in order to compute the correct solution.
However, I am now trying to compute the points-to analysis for pointer
expressions for stack allocated struct variables. I am trying to
answer the question:
What does `temp->f1` points to? For the following simple example
without heap allocated memory.
```c
struct A { char* f0; char *f1; struct A *f2;};
int __GIMPLE(startwith("ipa-pta"))
main (int argc, char * * argv)
{
struct A p1;
char * pc;
char c;
char *cast;
struct A*temp;
char *temp2;
int i;
int _27;
i_15 = 1;
pc = &c;
p1.f1 = pc;
p1.f2 = &p1;
_27 = 0;
cast = pc;
temp = p1.f2;
temp2 = temp->f1;
return _27;
}
```
There are two question I have regarding this example. The first one is
that IPA-PTA will determine that temp2 points to { c p1 } while I
think it should only point to { c } and I'm trying to understand why.
The second thing is that, I am still unsure how to get points-to
information for pointer expressions like temp->f1.
Details:
IPA-PTA correctly points out that the structure p1 and structure
pointer temp can point to both { c and p1 }
```
c = { }
p1 = { c p1 } same as temp_33
temp_33 = { c p1 }
```
I believe this is because p1 is a the whole struct variable, and
temp_33 is also modeling the whole struct variable. (in other words
*temp_33+64 points-to c, *temp_33+128 points-to p1. Note that nothing
is in field f0)
However, in the case of temp2, we have the following points-to
information:
```
temp2_34 = { c p1 }
```
which I believe is an over approximation. Looking at the constraints
generated, we see that temp2_34 was assigned the following constraint
temp2_34 = *temp_33 + 64
And that means that the method do_sd_constraint should have been used
to compute the correct points to information. Looking at the the
method, and adding some print statements, it is clear to me that the
problem with this imprecision is that temp_33 may point to { c } in
its second field.
Small correction: temp_33 may point to p1 in its third field.
However, isn't GCC supposed to take into account field
information in this case? I believe that in order to make this more
precise we need a change in the get_varinfo API to something that
takes into account offsets and gets the solution for pointer expressions.
Instead of this line
else if (v->may_have_pointers
&& add_graph_edge (graph, lhs, t))
flag |= bitmap_ior_into (sol, get_varinfo (t)->solution);
something like:
else if (v->may_have_pointers
&& add_graph_edge (graph, lhs, t))
flag |= bitmap_ior_into (sol, get_varinfo (t,
roffset)->solution);
This seems to me that it is already a known issue and it might be
described accurately by this comment.
TODO: Adding offsets to pointer-to-structures can be handled (IE
not punted
on and turned into anything), but isn't. You can just see what offset
inside the pointed-to struct it's going to access.
So, I just want to confirm, does this comment refer concretely to what
I'm trying to do? And does this mean that in order to accomplish an
API similar to what I described, would I need to create new constraint
variables? (One new constraint variable for each field in all pointer
to struct variables)
Thanks!
Re: Git rejecting branch merge
On Tue, Sep 29, 2020 at 9:17 AM Jan Hubicka wrote: > > Hello, > I am trying to update me/honza-gcc-benchmark-branch to current trunk > which I do by deleting it, recreating locally and pushing out. > > The problem is that the push fails witih: > > remote: *** The following commit was rejected by your > hooks.commit-extra-checker script (status: 1) > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1 > remote: *** The first line of a commit message should be a short > description of the change, not a single word. > remote: error: hook declined to update > > The broken commit is: > > $ git show 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > commit 03e87724864a17e22c9b692cc0caa014e9dba6b1 > Author: Georg-Johann Lay > Date: Tue Jan 14 11:09:38 2020 +0100 It's odd that your branch contains a change as old as this? Maybe you can rebase onto sth more recent. > > Typo. > libgcc/ > * config/avr/lib1funcs.S (skip): Simplify. > > > I wonder is there a way to get this done? > > Thanks, > Honza
[PATCH 0/8] Add some types
Hi Michael, I started with types. I joined them by groups: intN_t instead of having an entry for each int8_t, int16_t, ... I think that way I could better explain the types, common things, differences, and exceptions. I'll wait until you review them to write about the remaining types: [u]int_leastN_t, [u]int_fastN_t, and [u]intptr_t. Thanks, Alex Alejandro Colomar (8): system_data_types.7: Add 'intmax_t' intmax_t.3: New link to system_data_types(7) system_data_types.7: Add 'uintmax_t' uintmax_t.3: New link to system_data_types(7) system_data_types.7: Add intN_t family of types int8_t.3, int16_t.3, int32_t.3, int64_t.3, intN_t.3: New links to system_data_types(7) system_data_types.7: Add uintN_t family of types uint8_t.3, uint16_t.3, uint32_t.3, uint64_t.3, uintN_t.3: New links to system_data_types(7) man3/int16_t.3 | 1 + man3/int32_t.3 | 1 + man3/int64_t.3 | 1 + man3/int8_t.3| 1 + man3/intN_t.3| 1 + man3/intmax_t.3 | 1 + man3/uint16_t.3 | 1 + man3/uint32_t.3 | 1 + man3/uint64_t.3 | 1 + man3/uint8_t.3 | 1 + man3/uintN_t.3 | 1 + man3/uintmax_t.3 | 1 + man7/system_data_types.7 | 272 +++ 13 files changed, 284 insertions(+) create mode 100644 man3/int16_t.3 create mode 100644 man3/int32_t.3 create mode 100644 man3/int64_t.3 create mode 100644 man3/int8_t.3 create mode 100644 man3/intN_t.3 create mode 100644 man3/intmax_t.3 create mode 100644 man3/uint16_t.3 create mode 100644 man3/uint32_t.3 create mode 100644 man3/uint64_t.3 create mode 100644 man3/uint8_t.3 create mode 100644 man3/uintN_t.3 create mode 100644 man3/uintmax_t.3 -- 2.28.0
Re: Git rejecting branch merge
> On Tue, Sep 29, 2020 at 9:17 AM Jan Hubicka wrote: > > > > Hello, > > I am trying to update me/honza-gcc-benchmark-branch to current trunk > > which I do by deleting it, recreating locally and pushing out. > > > > The problem is that the push fails witih: > > > > remote: *** The following commit was rejected by your > > hooks.commit-extra-checker script (status: 1) > > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > remote: *** The first line of a commit message should be a short > > description of the change, not a single word. > > remote: error: hook declined to update > > > > The broken commit is: > > > > $ git show 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > > > commit 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > Author: Georg-Johann Lay > > Date: Tue Jan 14 11:09:38 2020 +0100 > > It's odd that your branch contains a change as old as this? I use it for benchmarking on lnt and it is indeed usued for some time. > > Maybe you can rebase onto sth more recent. That is what I am trying to do. But my understanding is that in meantime the hook checking for more than one word in description was implemented and thus I can't. Perhaps I can just remove the remote branch and create again? Honza > > > > > Typo. > > libgcc/ > > * config/avr/lib1funcs.S (skip): Simplify. > > > > > > I wonder is there a way to get this done? > > > > Thanks, > > Honza
Re: Git rejecting branch merge
On Tue, Sep 29, 2020 at 11:11 AM Jan Hubicka wrote: > > > On Tue, Sep 29, 2020 at 9:17 AM Jan Hubicka wrote: > > > > > > Hello, > > > I am trying to update me/honza-gcc-benchmark-branch to current trunk > > > which I do by deleting it, recreating locally and pushing out. > > > > > > The problem is that the push fails witih: > > > > > > remote: *** The following commit was rejected by your > > > hooks.commit-extra-checker script (status: 1) > > > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > > remote: *** The first line of a commit message should be a short > > > description of the change, not a single word. > > > remote: error: hook declined to update > > > > > > The broken commit is: > > > > > > $ git show 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > > > > > commit 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > > Author: Georg-Johann Lay > > > Date: Tue Jan 14 11:09:38 2020 +0100 > > > > It's odd that your branch contains a change as old as this? > > I use it for benchmarking on lnt and it is indeed usued for some time. > > > > Maybe you can rebase onto sth more recent. > > That is what I am trying to do. But my understanding is that in meantime > the hook checking for more than one word in description was implemented > and thus I can't. > > Perhaps I can just remove the remote branch and create again? That should work as well. > Honza > > > > > > > > Typo. > > > libgcc/ > > > * config/avr/lib1funcs.S (skip): Simplify. > > > > > > > > > I wonder is there a way to get this done? > > > > > > Thanks, > > > Honza
Re: mstackalign vs rbp order in gcc optimization level epilogue/prologue - O2/O3
> Would you folks consider this as a GCC bug? Do you folks see any issue in > the CLANG approach? Is there a way (any switch) in gcc which would reverse > the order of ‘setting %rbp’ vs ‘stack alignment code’ (like CLANG)? How does Clang align the frame pointer? What happens if the function uses dynamic stack allocation, e.g. by means of alloca? -- Eric Botcazou
[PATCH v2 0/8] Add some types
Hi Michael, I made a mistake when sending the emails, and I only CCd linux-man (and other lists) in PATCH 0/8. The rest were only sent to you. Actually, I was playing with the --cc option in git format-patch. I'm resending all of them as v2. I fixed a typo in 5/8, while the rest are all identical to v1. Thanks, Alex Alejandro Colomar (8): system_data_types.7: Add 'intmax_t' intmax_t.3: New link to system_data_types(7) system_data_types.7: Add 'uintmax_t' uintmax_t.3: New link to system_data_types(7) system_data_types.7: Add intN_t family of types int8_t.3, int16_t.3, int32_t.3, int64_t.3, intN_t.3: New links to system_data_types(7) system_data_types.7: Add uintN_t family of types uint8_t.3, uint16_t.3, uint32_t.3, uint64_t.3, uintN_t.3: New links to system_data_types(7) man3/int16_t.3 | 1 + man3/int32_t.3 | 1 + man3/int64_t.3 | 1 + man3/int8_t.3| 1 + man3/intN_t.3| 1 + man3/intmax_t.3 | 1 + man3/uint16_t.3 | 1 + man3/uint32_t.3 | 1 + man3/uint64_t.3 | 1 + man3/uint8_t.3 | 1 + man3/uintN_t.3 | 1 + man3/uintmax_t.3 | 1 + man7/system_data_types.7 | 272 +++ 13 files changed, 284 insertions(+) create mode 100644 man3/int16_t.3 create mode 100644 man3/int32_t.3 create mode 100644 man3/int64_t.3 create mode 100644 man3/int8_t.3 create mode 100644 man3/intN_t.3 create mode 100644 man3/intmax_t.3 create mode 100644 man3/uint16_t.3 create mode 100644 man3/uint32_t.3 create mode 100644 man3/uint64_t.3 create mode 100644 man3/uint8_t.3 create mode 100644 man3/uintN_t.3 create mode 100644 man3/uintmax_t.3 -- 2.28.0
[PATCH v2 2/8] intmax_t.3: New link to system_data_types(7)
Signed-off-by: Alejandro Colomar --- man3/intmax_t.3 | 1 + 1 file changed, 1 insertion(+) create mode 100644 man3/intmax_t.3 diff --git a/man3/intmax_t.3 b/man3/intmax_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/intmax_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 -- 2.28.0
[PATCH v2 1/8] system_data_types.7: Add 'intmax_t'
Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 56 1 file changed, 56 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index fe6e90afe..e718b3c30 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_types.7 @@ -343,6 +343,62 @@ Conforming to: C99 and later; POSIX.1-2001 and later. See also: .BR imaxdiv (3) .RE +.\"- intmax_t -/ +.TP +.I intmax_t +.RS +.br +Include: +.IR . +Alternatively, +.IR . +.PP +A signed integer type +capable of representing any value of any signed integer type +supported by the implementation. +According to the C language standard, it shall be +capable of storing values in the range +.RB [ INTMAX_MIN , +.BR INTMAX_MAX ]. +.PP +The macro +.B INTMAX_C +.\" TODO: Document INT*_C(3) +expands its argument to an integer constant of type +.IR intmax_t . +.PP +The length modifier for +.I intmax_t +for the +.BR printf (3) +and the +.BR scanf (3) +families of functions is +.BR j ; +resulting commonly in +.B %jd +or +.B %ji +for printing +.I intmax_t +values. +.PP +Bugs: +.I intmax_t +is not large enough to represent values of type +.I __int128 +in implementations where +.I __int128 +is defined and +.I long long +is less than 128 bits wide. +.PP +Conforming to: C99 and later; POSIX.1-2001 and later. +.PP +See also the +.I uintmax_t +type in this page. +.RE .\"- lconv / .TP .I lconv -- 2.28.0
[PATCH v2 3/8] system_data_types.7: Add 'uintmax_t'
Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 55 1 file changed, 55 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index e718b3c30..2e7aca7d2 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_types.7 @@ -1136,6 +1136,61 @@ See also: .BR getpwnam (2), .BR credentials (7) .RE +.\"- uintmax_t / +.TP +.I uintmax_t +.RS +.br +Include: +.IR . +Alternatively, +.IR . +.PP +An unsigned integer type +capable of representing any value of any unsigned integer type +supported by the implementation. +According to the C language standard, it shall be +capable of storing values in the range [0, +.BR UINTMAX_MAX ]. +.PP +The macro +.B UINTMAX_C +.\" TODO: Document UINT*_C(3) +expands its argument to an integer constant of type +.IR uintmax_t . +.PP +The length modifier for +.I uintmax_t +for the +.BR printf (3) +and the +.BR scanf (3) +families of functions is +.BR j ; +resulting commonly in +.B %ju +or +.B %jx +for printing +.I uintmax_t +values. +.PP +Bugs: +.I uintmax_t +is not large enough to represent values of type +.I unsigned __int128 +in implementations where +.I unsigned __int128 +is defined and +.I unsigned long long +is less than 128 bits wide. +.PP +Conforming to: C99 and later; POSIX.1-2001 and later. +.PP +See also the +.I intmax_t +type in this page. +.RE .\"- va_list --/ .TP .I va_list -- 2.28.0
[PATCH v2 5/8] system_data_types.7: Add intN_t family of types
Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 79 1 file changed, 79 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 2e7aca7d2..9b8244649 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_types.7 @@ -399,6 +399,85 @@ See also the .I uintmax_t type in this page. .RE +.\"- intN_t ---/ +.TP +.IR int N _t +.RS +.br +Include: +.IR . +Alternatively, +.IR . +.PP +.IR int8_t ", " int16_t ", " int32_t ", " int64_t +.PP +A signed integer type +of a fixed width of exactly N bits, +N being the value specified in its type name. +According to the C language standard, they shall be +capable of storing values in the range +.RB [ INT N _MIN , +.BR INT N _MAX ], +substituting N by the appropriate number. +.PP +According to POSIX, +.IR int8_t ", " int16_t +and +.I int32_t +are required; +.I int64_t +is only required in implementations that provide integer types +with width 64; +and all other types of this form are optional. +.PP +The length modifiers for the +.IR int N _t +types for the +.BR printf (3) +family of functions +are expanded by macros of the forms +.BR PRId N +and +.BR PRIi N +(defined in +.IR ); +resulting for example in +.B %"PRId64" +or +.B %"PRIi64" +for printing +.I int64_t +values. +The length modifiers for the +.IR int N _t +types for the +.BR scanf (3) +family of functions +are expanded by macros of the forms +.BR SCNd N +and +.BR SCNi N, +(defined in +.IR ); +resulting for example in +.B %"SCNd8" +or +.B %"SCNi8" +for scanning +.I int8_t +values. +.PP +Conforming to: C99 and later; POSIX.1-2001 and later. +.PP +See also the +.IR __int128 , +.IR intmax_t , +.IR uint N _t , +.I uintmax_t +and +.I unsigned __int128 +types in this page. +.RE .\"- lconv / .TP .I lconv -- 2.28.0
[PATCH v2 4/8] uintmax_t.3: New link to system_data_types(7)
Signed-off-by: Alejandro Colomar --- man3/uintmax_t.3 | 1 + 1 file changed, 1 insertion(+) create mode 100644 man3/uintmax_t.3 diff --git a/man3/uintmax_t.3 b/man3/uintmax_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/uintmax_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 -- 2.28.0
[PATCH v2 6/8] int8_t.3, int16_t.3, int32_t.3, int64_t.3, intN_t.3: New links to system_data_types(7)
Signed-off-by: Alejandro Colomar --- man3/int16_t.3 | 1 + man3/int32_t.3 | 1 + man3/int64_t.3 | 1 + man3/int8_t.3 | 1 + man3/intN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/int16_t.3 create mode 100644 man3/int32_t.3 create mode 100644 man3/int64_t.3 create mode 100644 man3/int8_t.3 create mode 100644 man3/intN_t.3 diff --git a/man3/int16_t.3 b/man3/int16_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/int16_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 diff --git a/man3/int32_t.3 b/man3/int32_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/int32_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 diff --git a/man3/int64_t.3 b/man3/int64_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/int64_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 diff --git a/man3/int8_t.3 b/man3/int8_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/int8_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 diff --git a/man3/intN_t.3 b/man3/intN_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/intN_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 -- 2.28.0
[PATCH v2 7/8] system_data_types.7: Add uintN_t family of types
Signed-off-by: Alejandro Colomar --- man7/system_data_types.7 | 82 1 file changed, 82 insertions(+) diff --git a/man7/system_data_types.7 b/man7/system_data_types.7 index 9b8244649..2f21e6849 100644 --- a/man7/system_data_types.7 +++ b/man7/system_data_types.7 @@ -1270,6 +1270,88 @@ See also the .I intmax_t type in this page. .RE +.\"- uintN_t --/ +.TP +.IR uint N _t +.RS +.br +Include: +.IR . +Alternatively, +.IR . +.PP +.IR uint8_t ", " uint16_t ", " uint32_t ", " uint64_t +.PP +An unsigned integer type +of a fixed width of exactly N bits, +N being the value specified in its type name. +According to the C language standard, they shall be +capable of storing values in the range [0, +.BR UINT N _MAX ], +substituting N by the appropriate number. +.PP +According to POSIX, +.IR uint8_t ", " uint16_t +and +.I uint32_t +are required; +.I uint64_t +is only required in implementations that provide integer types +with width 64; +and all other types of this form are optional. +.PP +The length modifiers for the +.IR uint N _t +types for the +.BR printf (3) +family of functions +are expanded by macros of the forms +.BR PRIu N, +.BR PRIo N, +.BR PRIx N +and +.BR PRIX N +(defined in +.IR ); +resulting for example in +.B %"PRIu32" +or +.B %"PRIx32" +for printing +.I uint32_t +values. +The length modifiers for the +.IR uint N _t +types for the +.BR scanf (3) +family of functions +are expanded by macros of the forms +.BR SCNu N, +.BR SCNo N, +.BR SCNx N +and +.BR SCNX N +(defined in +.IR ); +resulting for example in +.B %"SCNu16" +or +.B %"SCNx16" +for scanning +.I uint16_t +values. +.PP +Conforming to: C99 and later; POSIX.1-2001 and later. +.PP +See also the +.IR __int128 , +.IR intmax_t , +.IR int N _t , +.I uintmax_t +and +.I unsigned __int128 +types in this page. +.RE .\"- va_list --/ .TP .I va_list -- 2.28.0
[PATCH v2 8/8] uint8_t.3, uint16_t.3, uint32_t.3, uint64_t.3, uintN_t.3: New links to system_data_types(7)
Signed-off-by: Alejandro Colomar --- man3/uint16_t.3 | 1 + man3/uint32_t.3 | 1 + man3/uint64_t.3 | 1 + man3/uint8_t.3 | 1 + man3/uintN_t.3 | 1 + 5 files changed, 5 insertions(+) create mode 100644 man3/uint16_t.3 create mode 100644 man3/uint32_t.3 create mode 100644 man3/uint64_t.3 create mode 100644 man3/uint8_t.3 create mode 100644 man3/uintN_t.3 diff --git a/man3/uint16_t.3 b/man3/uint16_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/uint16_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 diff --git a/man3/uint32_t.3 b/man3/uint32_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/uint32_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 diff --git a/man3/uint64_t.3 b/man3/uint64_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/uint64_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 diff --git a/man3/uint8_t.3 b/man3/uint8_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/uint8_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 diff --git a/man3/uintN_t.3 b/man3/uintN_t.3 new file mode 100644 index 0..db50c0f09 --- /dev/null +++ b/man3/uintN_t.3 @@ -0,0 +1 @@ +.so man7/system_data_types.7 -- 2.28.0
Re: [PATCH v2 0/8] Add some types
D'oh! Now I had a typo when CCing myself :(
Is there a way to tell GCC not to reorder a specific instruction?
Hi everyone,
I tried to set the "vlen" after the add & multi, as shown in the following code:
➜
vf32 x3,x4;
void foo1(float16_t* input, float16_t* output, int vlen){
vf32 add = x3 + x4;
vf32 mul = x3 * x4;
__builtin_riscv_vlen(vlen); //<
storevf(&output[0], add);
storevf(&output[4], mul);
}
but after compilation, the "vlen" is reordered:
➜
foo1:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
addia4,a5,64
vfldv0,a5
vfldv1,a4
csrwvlen,a2 //<
vfadd v2,v0,v1
addia5,a1,8
vfmul v0,v0,v1
vfstv2,a1
vfstv0,a5
ret
And I've tried to add some barrier code shown as the following:
➜
#define barrier() __asm__ __volatile__("": : :"memory")
vf32 x3,x4;
void foo1(float16_t* input, float16_t* output, int vlen){
vf32 add = x3 + x4;
vf32 mul = x3 * x4;
barrier();
__builtin_riscv_vlen(vlen);
barrier();
storevf(&output[0], add);
storevf(&output[4], mul);
}
➜
vf32 x3,x4;
void foo1(float16_t* input, float16_t* output, int vlen){
vf32 add = x3 + x4;
vf32 mul = x3 * x4;
__asm__ __volatile__ ("csrw\tvlen,%0" : : "rJ"(vlen) : "memory");
storevf(&output[0], add);
storevf(&output[4], mul);
}
Both methods compiled out the same false assembly.
===
But if I tried the code like: (add & multi are using different operands)
➜
vf32 x1,x2;
vf32 x3,x4;
void foo1(float16_t* input, float16_t* output, int vlen){
vf32 add = x3 + x4;
vf32 mul = x1 * x2;
__builtin_riscv_vlen(vlen);
storevf(&output[0], add);
storevf(&output[4], mul);
}
the assembly will be right:
➜
foo1:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
addia0,a5,64
addia3,a5,128
addia4,a5,192
vfldv1,a5
vfldv3,a0
vfldv0,a3
vfldv2,a4
vfadd v1,v1,v3
vfmul v0,v0,v2
csrwvlen,a2 <
addia5,a1,8
vfstv1,a1
vfstv0,a5
ret
Is there any other way for coding or other option for gcc compilation to deal
with this issue.
Any suggestion would be appreciated. Thank you very much!
Best,
Jin
Re: [PATCH 0/8] Add some types
Hi Alex On Tue, 29 Sep 2020 at 10:26, Alejandro Colomar wrote: > > Hi Michael, > > I started with types. Good. I wanted those the other day :-), but then I saw they weren't in the page yet! > I joined them by groups: > intN_t instead of having an entry for each int8_t, int16_t, ... > I think that way I could better explain the types, common things, > differences, and exceptions. Yes, I think that's a good approach. > I'll wait until you review them to write about the remaining > types: [u]int_leastN_t, [u]int_fastN_t, and [u]intptr_t. Although the patch at https://lore.kernel.org/linux-man/20200928151646.20271-1-colomar.6@gmail.com/ doesn't apply (can you send me a revision please), and even though these patches employ the "Include/Alternatively" form, I've applied them. (Everything is now pushed.) Thanks, Michael
Re: Is there a way to tell GCC not to reorder a specific instruction?
On Tue, Sep 29, 2020 at 12:55 PM 夏 晋 via Gcc wrote:
>
> Hi everyone,
> I tried to set the "vlen" after the add & multi, as shown in the following
> code:
> ➜
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> __builtin_riscv_vlen(vlen); //<
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
> but after compilation, the "vlen" is reordered:
> ➜
> foo1:
> lui a5,%hi(.LANCHOR0)
> addia5,a5,%lo(.LANCHOR0)
> addia4,a5,64
> vfldv0,a5
> vfldv1,a4
> csrwvlen,a2 //<
> vfadd v2,v0,v1
> addia5,a1,8
> vfmul v0,v0,v1
> vfstv2,a1
> vfstv0,a5
> ret
> And I've tried to add some barrier code shown as the following:
> ➜
> #define barrier() __asm__ __volatile__("": : :"memory")
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> barrier();
> __builtin_riscv_vlen(vlen);
> barrier();
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
> ➜
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> __asm__ __volatile__ ("csrw\tvlen,%0" : : "rJ"(vlen) : "memory");
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
> Both methods compiled out the same false assembly.
> ===
> But if I tried the code like: (add & multi are using different operands)
> ➜
> vf32 x1,x2;
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x1 * x2;
> __builtin_riscv_vlen(vlen);
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
> the assembly will be right:
> ➜
> foo1:
> lui a5,%hi(.LANCHOR0)
> addia5,a5,%lo(.LANCHOR0)
> addia0,a5,64
> addia3,a5,128
> addia4,a5,192
> vfldv1,a5
> vfldv3,a0
> vfldv0,a3
> vfldv2,a4
> vfadd v1,v1,v3
> vfmul v0,v0,v2
> csrwvlen,a2 <
> addia5,a1,8
> vfstv1,a1
> vfstv0,a5
> ret
>
> Is there any other way for coding or other option for gcc compilation to deal
> with this issue.
> Any suggestion would be appreciated. Thank you very much!
You need to present GCC with a data dependence that prevents the re-ordering
for example by adding input/outputs for add/mul like
asm volatile ("crsw\tvlen, %0" : "=r" (add), "=r" (mul) : "0" (add),
"0" (mul), "rJ" (vlen));
Richard.
> Best,
> Jin
Re: [PATCH 0/8] Add some types
Hi Michael, On 2020-09-29 13:50, Michael Kerrisk (man-pages) wrote: > Hi Alex > > On Tue, 29 Sep 2020 at 10:26, Alejandro Colomar wrote: >> >> Hi Michael, >> >> I started with types. > > Good. I wanted those the other day :-), but then I saw they weren't in > the page yet! They were complicated, so I left them for when the page was a bit more mature :-) > >> I joined them by groups: >> intN_t instead of having an entry for each int8_t, int16_t, ... >> I think that way I could better explain the types, common things, >> differences, and exceptions. > > Yes, I think that's a good approach. Good. > >> I'll wait until you review them to write about the remaining >> types: [u]int_leastN_t, [u]int_fastN_t, and [u]intptr_t. > > Although the patch at > https://lore.kernel.org/linux-man/20200928151646.20271-1-colomar.6@gmail.com/ > doesn't apply (can you send me a revision please), and even though > these patches employ the "Include/Alternatively" form, I've applied > them. (Everything is now pushed.) I had the following commit history. I'll rebase again anyway and check what is pending, etc, and fix anything that broke. * 736f143b4 - Tue, 29 Sep 2020 10:05:33 +0200 (3 hours ago) (origin/alx, origin/HEAD, alx) | uint8_t.3, uint16_t.3, uint32_t.3, uint64_t.3, uintN_t.3: New links to system_data_types(7) - Alejandro Colomar * 3afc79ba6 - Tue, 29 Sep 2020 10:04:26 +0200 (3 hours ago) | system_data_types.7: Add uintN_t family of types - Alejandro Colomar * 3e317d073 - Tue, 29 Sep 2020 10:03:37 +0200 (3 hours ago) | int8_t.3, int16_t.3, int32_t.3, int64_t.3, intN_t.3: New links to system_data_types(7) - Alejandro Colomar * 46f64d53c - Tue, 29 Sep 2020 10:01:52 +0200 (3 hours ago) | system_data_types.7: Add intN_t family of types - Alejandro Colomar * 30f375485 - Tue, 29 Sep 2020 10:00:27 +0200 (3 hours ago) | uintmax_t.3: New link to system_data_types(7) - Alejandro Colomar * 1c95c8701 - Tue, 29 Sep 2020 10:00:02 +0200 (3 hours ago) | system_data_types.7: Add 'uintmax_t' - Alejandro Colomar * 8b1faa88d - Tue, 29 Sep 2020 09:58:08 +0200 (3 hours ago) | intmax_t.3: New link to system_data_types(7) - Alejandro Colomar * 0beb4210b - Tue, 29 Sep 2020 09:57:31 +0200 (3 hours ago) | system_data_types.7: Add 'intmax_t' - Alejandro Colomar * 40b39dc1f - Mon, 28 Sep 2020 17:08:46 +0200 (20 hours ago) | system_data_types.7: wfix + ffix - Alejandro Colomar * 4cefd8302 - Sun, 27 Sep 2020 23:11:43 +0200 (2 days ago) | FILE.3: New link to system_data_types(7) - Alejandro Colomar * a65f25603 - Sun, 27 Sep 2020 23:10:36 +0200 (2 days ago) | system_data_types.7: Add 'FILE' - Alejandro Colomar * 9cdd2e051 - Sun, 27 Sep 2020 23:13:43 +0200 (2 days ago) (upstream/master, master) | system_data_types.7: ffix - Alejandro Colomar > > Thanks, > > Michael > Thanks, Alex
回复: Is there a way to tell GCC not to reorder a specific instruction?
Hi Richard,
Thank you for your reply.
If we use < asm volatile ("crsw\tvlen, %0" : "=r" (add), "=r" (mul) : "0"
(add),"0" (mul), "rJ" (vlen)); > we need to know all the calculation steps
before the "vlen" setting.
For example we add a "sub" like:
vf32 sub = x3 - x4;
at this time, we need to add "0" (sub) to the dependency.
Is there a way that we can ignore the steps before the "vlen"? so that we can
make it more universal.
Best,
Jin
发件人: Richard Biener
发送时间: 2020年9月29日 20:00
收件人: 夏 晋
抄送: gcc@gcc.gnu.org
主题: Re: Is there a way to tell GCC not to reorder a specific instruction?
On Tue, Sep 29, 2020 at 12:55 PM 夏 晋 via Gcc wrote:
>
> Hi everyone,
> I tried to set the "vlen" after the add & multi, as shown in the following
> code:
> ➜
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> __builtin_riscv_vlen(vlen); //<
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
> but after compilation, the "vlen" is reordered:
> ➜
> foo1:
> lui a5,%hi(.LANCHOR0)
> addia5,a5,%lo(.LANCHOR0)
> addia4,a5,64
> vfldv0,a5
> vfldv1,a4
> csrwvlen,a2 //<
> vfadd v2,v0,v1
> addia5,a1,8
> vfmul v0,v0,v1
> vfstv2,a1
> vfstv0,a5
> ret
> And I've tried to add some barrier code shown as the following:
> ➜
> #define barrier() __asm__ __volatile__("": : :"memory")
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> barrier();
> __builtin_riscv_vlen(vlen);
> barrier();
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
> ➜
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> __asm__ __volatile__ ("csrw\tvlen,%0" : : "rJ"(vlen) : "memory");
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
> Both methods compiled out the same false assembly.
> ===
> But if I tried the code like: (add & multi are using different operands)
> ➜
> vf32 x1,x2;
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x1 * x2;
> __builtin_riscv_vlen(vlen);
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
> the assembly will be right:
> ➜
> foo1:
> lui a5,%hi(.LANCHOR0)
> addia5,a5,%lo(.LANCHOR0)
> addia0,a5,64
> addia3,a5,128
> addia4,a5,192
> vfldv1,a5
> vfldv3,a0
> vfldv0,a3
> vfldv2,a4
> vfadd v1,v1,v3
> vfmul v0,v0,v2
> csrwvlen,a2 <
> addia5,a1,8
> vfstv1,a1
> vfstv0,a5
> ret
>
> Is there any other way for coding or other option for gcc compilation to deal
> with this issue.
> Any suggestion would be appreciated. Thank you very much!
You need to present GCC with a data dependence that prevents the re-ordering
for example by adding input/outputs for add/mul like
asm volatile ("crsw\tvlen, %0" : "=r" (add), "=r" (mul) : "0" (add),
"0" (mul), "rJ" (vlen));
Richard.
> Best,
> Jin
Re: Git rejecting branch merge
On Tue, 29 Sep 2020, Jan Hubicka wrote: > Hello, > I am trying to update me/honza-gcc-benchmark-branch to current trunk > which I do by deleting it, recreating locally and pushing out. > > The problem is that the push fails witih: > > remote: *** The following commit was rejected by your > hooks.commit-extra-checker script (status: 1) > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1 > remote: *** The first line of a commit message should be a short > description of the change, not a single word. > remote: error: hook declined to update Joel, my understanding was that commit-extra-checker was the right setting to use for a hook that should check new commits - commits new to the repository, not commits already in the repository that are being added to the ancestry of a ref. Is that not the case? All the checks I've implemented via that hook are only intended to apply to commits that are new to the repository. -- Joseph S. Myers jos...@codesourcery.com
Re: Git rejecting branch merge
> > The problem is that the push fails witih: > > > > remote: *** The following commit was rejected by your > > hooks.commit-extra-checker script (status: 1) > > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > remote: *** The first line of a commit message should be a short > > description of the change, not a single word. > > remote: error: hook declined to update > > Joel, my understanding was that commit-extra-checker was the right setting > to use for a hook that should check new commits - commits new to the > repository, not commits already in the repository that are being added to > the ancestry of a ref. Is that not the case? All the checks I've > implemented via that hook are only intended to apply to commits that are > new to the repository. That's correct. The commit-extra-checker is called using the same list of "added commits" as the other checks implemented in the hooks, and that list excludes all commits accessible from existing references in the repository. -- Joel
Registers used for exception handling on Linux/m68k?
Hello! I'm looking for an information regarding exception handling on Linux/m68k, in particular I need to know what registers are used by the ABI in order to implement the functions "getExceptionPointerRegister" and "getExceptionSelectorRegister" in the M680x0 backend in LLVM [1], [2]. I looked into the GCC source code to find the corresponding parts but I could only find the macros prefixed with "EH_" [4] which I didn't fully understand. Can any of the experienced GCC/m68k folks tell me which registers in [5] I need to use? Adrian > [1] https://github.com/M680x0/M680x0-mono-repo/issues/15 > [2] > https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/Sparc/SparcISelLowering.h#L107 > [3] > https://github.com/llvm/llvm-project/blob/ee34d9b210cb5a6d14fe069e2e2ae75b0548dba9/llvm/lib/Target/Sparc/SparcRegisterInfo.td#L151 > [4] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/m68k/m68k.h#L741 > [5] > https://github.com/M680x0/M680x0-mono-repo/blob/master/llvm/lib/Target/M680x0/M680x0RegisterInfo.td -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: First set of patches to allow changing the long double default were posted:
On Mon, 28 Sep 2020 at 23:15, Joseph Myers wrote: > > On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote: > > > > I'm not sure which patch in the series is supposed to be implementing > > > that, but C requires that long double and _Float128 are distinct types (so > > > you can use _Generic to choose between them, for example) even if they > > > have the same ABI. > > > > Hmmm, but others said that it would complicate things if __float128 were > > different than long double. I've implemented it both ways (I would have to > > dig > > up the patches to have separate types). > > > > And doing so might break all of the glibc efforts to provide dual symbols. > > > > I could obviously use __float128 to be the same as long double, and > > _Float128 > > being a unique type if long double is IEEE. And since C++ doesn't have > > _Float128, it would 'work' without introducing a new mangling name. > > My comment is specifically about _Float128, in C; it doesn't say anything > about what should happen for C++ (though it would be nice to resolve the > ICEs that occur when _FloatN / _FloatNx types leak into C++ code via > built-in functions, bug 85518). Maybe it makes sense for the type (or at > least the type used by the built-in functions and __float128, since > _Float128 itself can't be accessed directly in C++) to be the same in the > C++ case. I imagine C++ will want to support _Float128 at some point, with similar semantics to C. But if __float128 is the same type as __ieee128 (which is sometimes the same as long double), which is a different type to _Float128, then I think that will work for both C and C++. If the standards say we have a standard _Float128 type which is different to long double, that's fine. If the standard wants a different type, we'll support that. What I'd like to avoid is a non-standard __float128 type that is a different type to long double even if they use the same representation. That seems like a needless difference just for the sake of it.
Re: Git rejecting branch merge
On Tue, 29 Sep 2020, Joel Brobecker wrote: > > > The problem is that the push fails witih: > > > > > > remote: *** The following commit was rejected by your > > > hooks.commit-extra-checker script (status: 1) > > > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1 > > > remote: *** The first line of a commit message should be a short > > > description of the change, not a single word. > > > remote: error: hook declined to update > > > > Joel, my understanding was that commit-extra-checker was the right setting > > to use for a hook that should check new commits - commits new to the > > repository, not commits already in the repository that are being added to > > the ancestry of a ref. Is that not the case? All the checks I've > > implemented via that hook are only intended to apply to commits that are > > new to the repository. > > That's correct. The commit-extra-checker is called using the same list > of "added commits" as the other checks implemented in the hooks, and > that list excludes all commits accessible from existing references > in the repository. Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the repository (on master) since before GCC 10 branched, something must be going wrong for a push to be rejected based on a check of that commit. -- Joseph S. Myers jos...@codesourcery.com
Re: First set of patches to allow changing the long double default were posted:
On Tue, 29 Sep 2020, Jonathan Wakely via Gcc wrote: > I imagine C++ will want to support _Float128 at some point, with > similar semantics to C. Unless it chooses a class-based approach like that used for std::decimal::decimal128. -- Joseph S. Myers jos...@codesourcery.com
Re: Git rejecting branch merge
> > That's correct. The commit-extra-checker is called using the same list > > of "added commits" as the other checks implemented in the hooks, and > > that list excludes all commits accessible from existing references > > in the repository. > > Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the repository > (on master) since before GCC 10 branched, something must be going wrong > for a push to be rejected based on a check of that commit. OK. Can you create a tarball of the GCC's bare repository as it is now, and give me access to both this tarball and the branch that the user was trying to update, I can try to spend a bit of time this weekend trying to reproduce and then investigating it. And just for the avoidance of doubt, if I could get the git command that was used to attempt the push, this would avoid wasting time investigating the wrong thing. In the meantime, perhaps you can add a workaround in your script that calls git to check whether the commit already exists in one of the references, and if it does, just bail? -- Joel
Re: Git rejecting branch merge
On Tue, Sep 29, 2020 at 10:01:23AM -0700, Joel Brobecker wrote: > > > That's correct. The commit-extra-checker is called using the same list > > > of "added commits" as the other checks implemented in the hooks, and > > > that list excludes all commits accessible from existing references > > > in the repository. > > > > Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the repository > > (on master) since before GCC 10 branched, something must be going wrong > > for a push to be rejected based on a check of that commit. > > OK. Can you create a tarball of the GCC's bare repository as it is now, > and give me access to both this tarball and the branch that the user > was trying to update, I can try to spend a bit of time this weekend > trying to reproduce and then investigating it. And just for the avoidance > of doubt, if I could get the git command that was used to attempt > the push, this would avoid wasting time investigating the wrong thing. Good news; If I read the code correctly, I think I found the source of your issue, and the fix should be relatively simple. The data above would be useful to confirm we're looking at the same issue, though. > In the meantime, perhaps you can add a workaround in your script > that calls git to check whether the commit already exists in one > of the references, and if it does, just bail? -- Joel
Re: Git rejecting branch merge
On Tue, 29 Sep 2020, Joel Brobecker wrote: > > > That's correct. The commit-extra-checker is called using the same list > > > of "added commits" as the other checks implemented in the hooks, and > > > that list excludes all commits accessible from existing references > > > in the repository. > > > > Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the repository > > (on master) since before GCC 10 branched, something must be going wrong > > for a push to be rejected based on a check of that commit. > > OK. Can you create a tarball of the GCC's bare repository as it is now, > and give me access to both this tarball and the branch that the user > was trying to update, I can try to spend a bit of time this weekend > trying to reproduce and then investigating it. And just for the avoidance > of doubt, if I could get the git command that was used to attempt > the push, this would avoid wasting time investigating the wrong thing. It's /git/gcc.git on sourceware (I think you have shell access, or can git clone --mirror to get a full bare copy). refs/users/hubicka/heads/honza-gcc-benchmark-branch currently points to c478047c0fd71e8bd8e069c729b57a89b75ee004, "Add changelog". I don't know exactly what Honza is pushing there (whether it's a merge or a rebase), but whatever he's pushing, the hook should not be checking commits that are already in the repository. -- Joseph S. Myers jos...@codesourcery.com
Re: Git rejecting branch merge
> On Tue, 29 Sep 2020, Joel Brobecker wrote: > > > > > That's correct. The commit-extra-checker is called using the same list > > > > of "added commits" as the other checks implemented in the hooks, and > > > > that list excludes all commits accessible from existing references > > > > in the repository. > > > > > > Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the repository > > > (on master) since before GCC 10 branched, something must be going wrong > > > for a push to be rejected based on a check of that commit. > > > > OK. Can you create a tarball of the GCC's bare repository as it is now, > > and give me access to both this tarball and the branch that the user > > was trying to update, I can try to spend a bit of time this weekend > > trying to reproduce and then investigating it. And just for the avoidance > > of doubt, if I could get the git command that was used to attempt > > the push, this would avoid wasting time investigating the wrong thing. > > It's /git/gcc.git on sourceware (I think you have shell access, or can git > clone --mirror to get a full bare copy). > refs/users/hubicka/heads/honza-gcc-benchmark-branch currently points to > c478047c0fd71e8bd8e069c729b57a89b75ee004, "Add changelog". I don't know > exactly what Honza is pushing there (whether it's a merge or a rebase), > but whatever he's pushing, the hook should not be checking commits that > are already in the repository. I did the following (and perhaps you can do it for me) git branch -D me/honza-gcc-benchmark-branch git checkout master git co -b me/honza-gcc-benchmark-branch git push -f Which I hope should replace the existing (old) branch by a copy of current trunk on which I could do more of tuning tests. Honza > > -- > Joseph S. Myers > jos...@codesourcery.com
Re: Git rejecting branch merge
On Tue, Sep 29, 2020 at 07:16:45PM +0200, Jan Hubicka wrote: > > On Tue, 29 Sep 2020, Joel Brobecker wrote: > > > > > > > That's correct. The commit-extra-checker is called using the same list > > > > > of "added commits" as the other checks implemented in the hooks, and > > > > > that list excludes all commits accessible from existing references > > > > > in the repository. > > > > > > > > Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the > > > > repository > > > > (on master) since before GCC 10 branched, something must be going wrong > > > > for a push to be rejected based on a check of that commit. > > > > > > OK. Can you create a tarball of the GCC's bare repository as it is now, > > > and give me access to both this tarball and the branch that the user > > > was trying to update, I can try to spend a bit of time this weekend > > > trying to reproduce and then investigating it. And just for the avoidance > > > of doubt, if I could get the git command that was used to attempt > > > the push, this would avoid wasting time investigating the wrong thing. > > > > It's /git/gcc.git on sourceware (I think you have shell access, or can git > > clone --mirror to get a full bare copy). > > refs/users/hubicka/heads/honza-gcc-benchmark-branch currently points to > > c478047c0fd71e8bd8e069c729b57a89b75ee004, "Add changelog". I don't know > > exactly what Honza is pushing there (whether it's a merge or a rebase), > > but whatever he's pushing, the hook should not be checking commits that > > are already in the repository. > > I did the following (and perhaps you can do it for me) > > git branch -D me/honza-gcc-benchmark-branch > git checkout master > git co -b me/honza-gcc-benchmark-branch > git push -f > > Which I hope should replace the existing (old) branch by a copy of > current trunk on which I could do more of tuning tests. So, IIUC, you're trying to replace the old refs/users/hubicka/heads/honza-gcc-benchmark-branch with whatever is on master at this moment, is that correct (that would wipe whatever changes you've made in your old branch)? For instance, currently master is pointing to commit adcf8a11c772e7a0c64d4ae3eb19a520566f32b9. -- Joel
Re: Git rejecting branch merge
> On Tue, Sep 29, 2020 at 07:16:45PM +0200, Jan Hubicka wrote: > > > On Tue, 29 Sep 2020, Joel Brobecker wrote: > > > > > > > > > That's correct. The commit-extra-checker is called using the same > > > > > > list > > > > > > of "added commits" as the other checks implemented in the hooks, and > > > > > > that list excludes all commits accessible from existing references > > > > > > in the repository. > > > > > > > > > > Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the > > > > > repository > > > > > (on master) since before GCC 10 branched, something must be going > > > > > wrong > > > > > for a push to be rejected based on a check of that commit. > > > > > > > > OK. Can you create a tarball of the GCC's bare repository as it is now, > > > > and give me access to both this tarball and the branch that the user > > > > was trying to update, I can try to spend a bit of time this weekend > > > > trying to reproduce and then investigating it. And just for the > > > > avoidance > > > > of doubt, if I could get the git command that was used to attempt > > > > the push, this would avoid wasting time investigating the wrong thing. > > > > > > It's /git/gcc.git on sourceware (I think you have shell access, or can > > > git > > > clone --mirror to get a full bare copy). > > > refs/users/hubicka/heads/honza-gcc-benchmark-branch currently points to > > > c478047c0fd71e8bd8e069c729b57a89b75ee004, "Add changelog". I don't know > > > exactly what Honza is pushing there (whether it's a merge or a rebase), > > > but whatever he's pushing, the hook should not be checking commits that > > > are already in the repository. > > > > I did the following (and perhaps you can do it for me) > > > > git branch -D me/honza-gcc-benchmark-branch > > git checkout master > > git co -b me/honza-gcc-benchmark-branch > > git push -f > > > > Which I hope should replace the existing (old) branch by a copy of > > current trunk on which I could do more of tuning tests. > > So, IIUC, you're trying to replace the old > refs/users/hubicka/heads/honza-gcc-benchmark-branch > with whatever is on master at this moment, is that correct > (that would wipe whatever changes you've made in your old > branch)? > > For instance, currently master is pointing to commit > adcf8a11c772e7a0c64d4ae3eb19a520566f32b9. Yes, i want to replace it with current master. Thanks, Honza > > -- > Joel
Re: Registers used for exception handling on Linux/m68k?
On 9/29/20 11:22 AM, John Paul Adrian Glaubitz wrote: Hello! I'm looking for an information regarding exception handling on Linux/m68k, in particular I need to know what registers are used by the ABI in order to implement the functions "getExceptionPointerRegister" and "getExceptionSelectorRegister" in the M680x0 backend in LLVM [1], [2]. I don;t know what those functions are, but from their names they seem to be related to figuring out the exception object and type? Do you understand the itanium ABI's unwinding mechanism -- 1) follow stack to get to landing pad. 2) invoke landing pad to see if it wants to catch 3) if not, continue following stack 4) once we've found one to catch it, we need to unwind properly, which involves invoking cleanups. and eventually getting to the catcher invoking the landing pad means passing (a) an integer telling it what's happening, and (b) a pointer to data. I looked into the GCC source code to find the corresponding parts but I could only find the macros prefixed with "EH_" [4] which I didn't fully understand. Those are the bits you want. one of those is the selector (0?) and the other is the data pointer (1?). I can never remember more than that, and usually go build a compiler and inspect its output to figure more. nathan -- Nathan Sidwell
Re: Is there a way to tell GCC not to reorder a specific instruction?
On Tue, Sep 29, 2020 at 3:47 AM 夏 晋 via Gcc wrote:
> I tried to set the "vlen" after the add & multi, as shown in the following
> code:
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> __builtin_riscv_vlen(vlen); //<
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
Not clear what __builtin_riscv_vlen is doing, or what exactly your
target is, but the gcc port I did for the RISC-V draft V extension
creates new fake vector type and vector length registers, like the
existing fake fp and arg pointer registers, and the vsetvl{i}
instruction sets the fake vector type and vector length registers, and
all vector instructions read the fake vector type and vector length
registers. That creates the dependence between the instructions that
prevents reordering. It is a little more complicated than that, as
you can have more than one vsetvl{i} instruction setting different
vector type and/or vector length values, so we have to match on the
expected values to make sure that vector instructions are tied to the
right vsetvl{i} instruction. This is a work in progress, but overall
it is working pretty well. This requires changes to the gcc port, as
you have to add the new fake registers in gcc/config/riscv/riscv.h.
This isn't something you can do with macros and extended asms.
See for instance
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/Krhw8--wmi4/m/-3IPvT7JCgAJ
Jim
Re: New pseudos in splitters
On Wed, 23 Sep 2020, Ilya Leoshkevich via Gcc wrote:
> Hi,
>
> "Defining How to Split Instructions" in gccint states the following:
>
> The preparation-statements are similar to those statements that are
> specified for define_expand ... Unlike those in define_expand, however,
> these statements must not generate any new pseudo-registers.
>
> I see that there is code that does this anyway, e.g. "Split
> calculate_pic_address into pic_load_addr_* and a move." in arm.md.
>
> Is this restriction still valid today? Is there a reason we can't
> introduce new pseudos in a splitter before LRA?
There are passes splitting insns before register allocation.
The pattern after the quoted comment 6557 gates its call to
gen_reg_rtx conditional by can_create_pseudo_p (), thus is
valid.
IIUC the restriction is still in place, but the gccint section
you quote should be updated to the effect of "must not generate
any new pseudo-registers *after register allocation has started,
@xref{How-to-conditionalize-pre-post-reload}*" with the xref
referring to a new section to-be-written from pieces given by
grep reload_completed and can_create_pseudo_p.
brgds, H-P
回复: Is there a way to tell GCC not to reorder a specific instruction?
Hi Jim,
Thank you for your reply. I've tried the following code on GCC for RVV
extendsion, still met the same issue.
➜
vint16m1_t foo3(vint16m1_t a, vint16m1_t b){
vint16m1_t add = a+b;
vint16m1_t mul = a*b;
vsetvl_e8m1(32);
return add + mul;
}
the assembly is:
➜
foo3:
li a4,32
vl1r.v v1,0(a1)
vl1r.v v3,0(a2)
vsetvli a4,a4,e8,m1
vsetvli x0,x0,e16,m1
vadd.vv v2,v1,v3
vmul.vv v1,v1,v3
vadd.vv v1,v2,v1
vs1r.v v1,0(a0)
ret
Unfortunately, the "vsetvl_e8m1" has been reordered.
Have you ever encountered this problem? Has it been solved and how? Thanks
again.
Best,
Jin
发件人: Jim Wilson
发送时间: 2020年9月30日 3:45
收件人: 夏 晋
抄送: gcc@gcc.gnu.org
主题: Re: Is there a way to tell GCC not to reorder a specific instruction?
On Tue, Sep 29, 2020 at 3:47 AM 夏 晋 via Gcc wrote:
> I tried to set the "vlen" after the add & multi, as shown in the following
> code:
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> __builtin_riscv_vlen(vlen); //<
> storevf(&output[0], add);
> storevf(&output[4], mul);
> }
Not clear what __builtin_riscv_vlen is doing, or what exactly your
target is, but the gcc port I did for the RISC-V draft V extension
creates new fake vector type and vector length registers, like the
existing fake fp and arg pointer registers, and the vsetvl{i}
instruction sets the fake vector type and vector length registers, and
all vector instructions read the fake vector type and vector length
registers. That creates the dependence between the instructions that
prevents reordering. It is a little more complicated than that, as
you can have more than one vsetvl{i} instruction setting different
vector type and/or vector length values, so we have to match on the
expected values to make sure that vector instructions are tied to the
right vsetvl{i} instruction. This is a work in progress, but overall
it is working pretty well. This requires changes to the gcc port, as
you have to add the new fake registers in gcc/config/riscv/riscv.h.
This isn't something you can do with macros and extended asms.
See for instance
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/Krhw8--wmi4/m/-3IPvT7JCgAJ
Jim
Re: Is there a way to tell GCC not to reorder a specific instruction?
On Tue, Sep 29, 2020 at 9:46 PM Jim Wilson wrote:
>
> On Tue, Sep 29, 2020 at 3:47 AM 夏 晋 via Gcc wrote:
> > I tried to set the "vlen" after the add & multi, as shown in the following
> > code:
>
> > vf32 x3,x4;
> > void foo1(float16_t* input, float16_t* output, int vlen){
> > vf32 add = x3 + x4;
> > vf32 mul = x3 * x4;
> > __builtin_riscv_vlen(vlen); //<
> > storevf(&output[0], add);
> > storevf(&output[4], mul);
> > }
>
> Not clear what __builtin_riscv_vlen is doing, or what exactly your
> target is, but the gcc port I did for the RISC-V draft V extension
> creates new fake vector type and vector length registers, like the
> existing fake fp and arg pointer registers, and the vsetvl{i}
> instruction sets the fake vector type and vector length registers, and
> all vector instructions read the fake vector type and vector length
> registers. That creates the dependence between the instructions that
> prevents reordering. It is a little more complicated than that, as
> you can have more than one vsetvl{i} instruction setting different
> vector type and/or vector length values, so we have to match on the
> expected values to make sure that vector instructions are tied to the
> right vsetvl{i} instruction. This is a work in progress, but overall
> it is working pretty well. This requires changes to the gcc port, as
> you have to add the new fake registers in gcc/config/riscv/riscv.h.
> This isn't something you can do with macros and extended asms.
But this also doesn't work on GIMPLE. On GIMPLE riscv_vlen would
be a barrier for code motion if you make it __attribute__((returns_twice))
since then abnormal edges distort the CFG in a way preventing such motion.
> See for instance
>
> https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/Krhw8--wmi4/m/-3IPvT7JCgAJ
>
> Jim
