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: *** com
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:
0x00
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=ma
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 y
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_le
> 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
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 i
> 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
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 identic
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_ty
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_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_t
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_t
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_da
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
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_t
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
cre
D'oh! Now I had a typo when CCing myself :(
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(&o
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 t
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;
> __built
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 complica
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 "
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
> hook
> > 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
> > d
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 looke
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 ch
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: *** Th
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
> > 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 b
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 t
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.
> >
> 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 repos
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 exclud
> 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
> >
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 "getExceptionSelectorReg
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);
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 mu
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,
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
40 matches
Mail list logo
