from:"David Abdurachmanov"

Re: [PATCH] RISC-V: Add minimal support for 7 new unprivileged extensions

2024-02-01 Thread David Abdurachmanov

On Thu, Feb 1, 2024 at 10:43 AM Kito Cheng  wrote:

> Could you add some document for doc/invoke.texi, I just added a list
> for listing all supported extensions before[1].
>
> [1]
> https://github.com/gcc-mirror/gcc/commit/19260a04ba6f75b1fae52afab50dcb43d44eb259


Offtopic, but looking at the file I don't see xtheadvector extension. I
think it was merged some time ago.


>
>
> On Thu, Feb 1, 2024 at 4:29 PM Monk Chiang  wrote:
> >
> > The RISC-V Profiles specification here:
> >
> https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions
> >
> > These extensions don't add any new features but
> > describe existing features. So this patch only adds parsing.
> >
> > Za64rs: Reservation set size of 64 bytes
> > Za128rs: Reservation set size of 128 bytes
> > Ziccif: Main memory supports instruction fetch with atomicity requirement
> > Ziccrse: Main memory supports forward progress on LR/SC sequences
> > Ziccamoa: Main memory supports all atomics in A
> > Zicclsm: Main memory supports misaligned loads/stores
> > Zic64b: Cache block size isf 64 bytes
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-common.cc: Add Za64rs, Za128rs,
> > Ziccif, Ziccrse, Ziccamoa, Zicclsm, Zic64b items.
> > * config/riscv/riscv.opt: New macro for 7 new unprivileged
> > extensions.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/za-ext.c: New test.
> > * gcc.target/riscv/zi-ext.c: New test.
> > ---
> >  gcc/common/config/riscv/riscv-common.cc | 14 
> >  gcc/config/riscv/riscv.opt  | 14 
> >  gcc/testsuite/gcc.target/riscv/za-ext.c | 17 +++
> >  gcc/testsuite/gcc.target/riscv/zi-ext.c | 29 +
> >  4 files changed, 74 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/za-ext.c
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/zi-ext.c
> >
> > diff --git a/gcc/common/config/riscv/riscv-common.cc
> b/gcc/common/config/riscv/riscv-common.cc
> > index 6ac0422ac13..631ce8309a0 100644
> > --- a/gcc/common/config/riscv/riscv-common.cc
> > +++ b/gcc/common/config/riscv/riscv-common.cc
> > @@ -247,6 +247,8 @@ static const struct riscv_ext_version
> riscv_ext_version_table[] =
> >
> >{"zicond", ISA_SPEC_CLASS_NONE, 1, 0},
> >
> > +  {"za64rs",  ISA_SPEC_CLASS_NONE, 1, 0},
> > +  {"za128rs", ISA_SPEC_CLASS_NONE, 1, 0},
> >{"zawrs", ISA_SPEC_CLASS_NONE, 1, 0},
> >
> >{"zba", ISA_SPEC_CLASS_NONE, 1, 0},
> > @@ -276,6 +278,11 @@ static const struct riscv_ext_version
> riscv_ext_version_table[] =
> >{"zicboz",ISA_SPEC_CLASS_NONE, 1, 0},
> >{"zicbom",ISA_SPEC_CLASS_NONE, 1, 0},
> >{"zicbop",ISA_SPEC_CLASS_NONE, 1, 0},
> > +  {"zic64b",   ISA_SPEC_CLASS_NONE, 1, 0},
> > +  {"ziccamoa", ISA_SPEC_CLASS_NONE, 1, 0},
> > +  {"ziccif",   ISA_SPEC_CLASS_NONE, 1, 0},
> > +  {"zicclsm",  ISA_SPEC_CLASS_NONE, 1, 0},
> > +  {"ziccrse",  ISA_SPEC_CLASS_NONE, 1, 0},
> >
> >{"zicntr", ISA_SPEC_CLASS_NONE, 2, 0},
> >{"zihpm",  ISA_SPEC_CLASS_NONE, 2, 0},
> > @@ -1494,6 +1501,8 @@ static const riscv_ext_flag_table_t
> riscv_ext_flag_table[] =
> >{"zifencei", _options::x_riscv_zi_subext, MASK_ZIFENCEI},
> >{"zicond",   _options::x_riscv_zi_subext, MASK_ZICOND},
> >
> > +  {"za64rs", _options::x_riscv_za_subext, MASK_ZA64RS},
> > +  {"za128rs", _options::x_riscv_za_subext, MASK_ZA128RS},
> >{"zawrs", _options::x_riscv_za_subext, MASK_ZAWRS},
> >
> >{"zba",_options::x_riscv_zb_subext, MASK_ZBA},
> > @@ -1523,6 +1532,11 @@ static const riscv_ext_flag_table_t
> riscv_ext_flag_table[] =
> >{"zicboz", _options::x_riscv_zicmo_subext, MASK_ZICBOZ},
> >{"zicbom", _options::x_riscv_zicmo_subext, MASK_ZICBOM},
> >{"zicbop", _options::x_riscv_zicmo_subext, MASK_ZICBOP},
> > +  {"zic64b", _options::x_riscv_zicmo_subext, MASK_ZIC64B},
> > +  {"ziccamoa", _options::x_riscv_zicmo_subext, MASK_ZICCAMOA},
> > +  {"ziccif", _options::x_riscv_zicmo_subext, MASK_ZICCIF},
> > +  {"zicclsm", _options::x_riscv_zicmo_subext, MASK_ZICCLSM},
> > +  {"ziccrse", _options::x_riscv_zicmo_subext, MASK_ZICCRSE},
> >
> >{"zve32x",   _options::x_target_flags, MASK_VECTOR},
> >{"zve32f",   _options::x_target_flags, MASK_VECTOR},
> > diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> > index b6d8e9a3f74..f6ff70b2b30 100644
> > --- a/gcc/config/riscv/riscv.opt
> > +++ b/gcc/config/riscv/riscv.opt
> > @@ -225,11 +225,25 @@ Mask(ZIHINTPAUSE) Var(riscv_zi_subext)
> >
> >  Mask(ZICOND)  Var(riscv_zi_subext)
> >
> > +Mask(ZIC64B)  Var(riscv_zi_subext)
> > +
> > +Mask(ZICCAMOA)Var(riscv_zi_subext)
> > +
> > +Mask(ZICCIF)  Var(riscv_zi_subext)
> > +
> > +Mask(ZICCLSM) Var(riscv_zi_subext)
> > +
> > +Mask(ZICCRSE) Var(riscv_zi_subext)
> > +
> >  TargetVariable
> >  int riscv_za_subext
> >
> >  Mask(ZAWRS) Var(riscv_za_subext)
> >
> > +Mask(ZA64RS)  Var(riscv_za_subext)
> > +
> > +Mask(ZA128RS) Var(riscv_za_subext)
>

Re: [PATCH v4] RISC-V: Add support for inlining subword atomic operations

2022-10-28 Thread David Abdurachmanov via Gcc-patches

On Fri, Sep 2, 2022 at 1:09 PM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> LGTM with minor comments, it's time to move forward, thanks Patrick and
> Palmer.
>

Ping.

Any plans to finally land this one for GCC 13?

The hope is that this patch would make life significantly easier for
distributions. There are way too many packages failing to build due to
sub-word atomics, which is highly annoying considering that it's not
consistent between package versions. Build times on riscv64 are extremely
long which makes it even more annoying. Would love to see this finally
fixed.


> > +
> > +void
> > +riscv_subword_address (rtx mem, rtx *aligned_mem, rtx *shift, rtx *mask,
> > +  rtx *not_mask)
> > +{
> > +  /* Align the memory addess to a word.  */
> > +  rtx addr = force_reg (Pmode, XEXP (mem, 0));
> > +
> > +  rtx aligned_addr = gen_reg_rtx (Pmode);
> > +  emit_move_insn (aligned_addr,  gen_rtx_AND (Pmode, addr,
> > + gen_int_mode (-4, Pmode)));
> > +
> > +  *aligned_mem = change_address (mem, SImode, aligned_addr);
> > +
> > +  /* Calculate the shift amount.  */
> > +  *shift = gen_reg_rtx (SImode);
>
> Already allocated reg_rtx outside, this line could be removed.
>
> > +  emit_move_insn (*shift, gen_rtx_AND (SImode, gen_lowpart (SImode,
> addr),
> > + gen_int_mode (3, SImode)));
> > +  emit_move_insn (*shift, gen_rtx_ASHIFT (SImode, *shift,
> > +gen_int_mode(3, SImode)));
> > +
> > +  /* Calculate the mask.  */
> > +  int unshifted_mask;
> > +  if (GET_MODE (mem) == QImode)
> > +unshifted_mask = 0xFF;
> > +  else
> > +unshifted_mask = 0x;
> > +
> > +  rtx mask_reg = gen_reg_rtx (SImode);
>
> Ditto.
>
> > @@ -152,6 +348,128 @@
> >DONE;
> >  })
> >
> > +(define_expand "atomic_compare_and_swap"
> > +  [(match_operand:SI 0 "register_operand" "");; bool output
> > +   (match_operand:SHORT 1 "register_operand" "") ;; val output
> > +   (match_operand:SHORT 2 "memory_operand" "")   ;; memory
> > +   (match_operand:SHORT 3 "reg_or_0_operand" "") ;; expected value
> > +   (match_operand:SHORT 4 "reg_or_0_operand" "") ;; desired value
> > +   (match_operand:SI 5 "const_int_operand" "")   ;; is_weak
> > +   (match_operand:SI 6 "const_int_operand" "")   ;; mod_s
> > +   (match_operand:SI 7 "const_int_operand" "")]  ;; mod_f
> > +  "TARGET_ATOMIC && TARGET_INLINE_SUBWORD_ATOMIC"
> > +{
> > +  emit_insn (gen_atomic_cas_value_strong (operands[1],
> operands[2],
> > +   operands[3], operands[4],
> > +   operands[6],
> operands[7]));
> > +
> > +  rtx val = gen_reg_rtx (SImode);
> > +  if (operands[1] != const0_rtx)
> > +emit_insn (gen_rtx_SET (val, gen_rtx_SIGN_EXTEND (SImode,
> operands[1])));
> > +  else
> > +emit_insn (gen_rtx_SET (val, const0_rtx));
>
> nit: emit_move_insn rather than emit_insn + gen_rtx_SET
>
> > +
> > +  rtx exp = gen_reg_rtx (SImode);
> > +  if (operands[3] != const0_rtx)
> > +emit_insn (gen_rtx_SET (exp, gen_rtx_SIGN_EXTEND (SImode,
> operands[3])));
> > +  else
> > +emit_insn (gen_rtx_SET (exp, const0_rtx));
>
> nit: emit_move_insn rather than emit_insn + gen_rtx_SET
>
> > +
> > +  rtx compare = val;
> > +  if (exp != const0_rtx)
> > +{
> > +  rtx difference = gen_rtx_MINUS (SImode, val, exp);
> > +  compare = gen_reg_rtx (SImode);
> > +  emit_insn (gen_rtx_SET (compare, difference));
>
> nit: emit_move_insn rather than emit_insn + gen_rtx_SET
>
> > +}
> > +
> > +  if (word_mode != SImode)
> > +{
> > +  rtx reg = gen_reg_rtx (word_mode);
> > +  emit_insn (gen_rtx_SET (reg, gen_rtx_SIGN_EXTEND (word_mode,
> compare)));
>
> nit: emit_move_insn rather than emit_insn + gen_rtx_SET
>
>
> > +  compare = reg;
> > +}
> > +
> > +  emit_insn (gen_rtx_SET (operands[0], gen_rtx_EQ (SImode, compare,
> const0_rtx)));
>
> nit: emit_move_insn rather than emit_insn + gen_rtx_SET
>

Re: libgo patch committed: Update to Go1.14beta1

2020-02-03 Thread David Abdurachmanov

On Sat, Feb 1, 2020 at 2:38 PM Andreas Schwab  wrote:

> ../../../libgo/go/syscall/syscall_linux_riscv64.go:7:14: error: imported
> and not used: unsafe
> 7 | import "unsafe"
>   |  ^

I see the same issue in Fedora/RISCV, the last two builds of GCC 10 failed
due to it.

Btw, 1.14 Beta 2 should ship riscv64 support (marked as experimental).
See: https://go-review.googlesource.com/c/go/+/216757/

david

Re: [PATCH] D support for RISC-V

2019-04-09 Thread David Abdurachmanov

On Tue, Apr 9, 2019 at 12:22 PM Andreas Schwab  wrote:
>
> On Apr 09 2019, David Abdurachmanov  wrote:
>
> > diff --git 
> > a/libphobos/src/std/experimental/allocator/building_blocks/region.d 
> > b/libphobos/src/std/experimental/allocator/building_blocks/region.d
> > index dfcecce72bd..cafe059a61f 100644
> > --- a/libphobos/src/std/experimental/allocator/building_blocks/region.d
> > +++ b/libphobos/src/std/experimental/allocator/building_blocks/region.d
> > @@ -391,7 +391,8 @@ struct InSituRegion(size_t size, size_t minAlign = 
> > platformAlignment)
> >  else version (PPC) enum growDownwards = Yes.growDownwards;
> >  else version (PPC64) enum growDownwards = Yes.growDownwards;
> >  else version (MIPS32) enum growDownwards = Yes.growDownwards;
> > -else version (MIPS64) enum growDownwards = Yes.growDownwards;
> > +else version (RISCV32) enum growDownwards = Yes.growDownwards;
> > +else version (RISCV64) enum growDownwards = Yes.growDownwards;
>
> Why do you remove the MIPS64 case?

Good catch. It's a mistake. Will be fixed in v2.

david

> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

[PATCH] D support for RISC-V

2019-04-09 Thread David Abdurachmanov

This patch has been in Fedora/RISCV for the last couple of months.
I have tested simple applications (e.g. word count example), which
worked without a problem.

I believe Iain Buclaw did run GCC testsuite using Fedora/RISCV
build and QEMU. The patch has not changed since that.

Signed-off-by: David Abdurachmanov 
---
 libphobos/configure.tgt   |  2 +
 libphobos/libdruntime/core/atomic.d   |  6 +-
 .../libdruntime/rt/sections_elf_shared.d  | 14 -
 .../allocator/building_blocks/region.d|  3 +-
 libphobos/src/std/math.d  | 59 +++
 5 files changed, 79 insertions(+), 5 deletions(-)

diff --git a/libphobos/configure.tgt b/libphobos/configure.tgt
index 0471bfd816b..811fdfa21a7 100644
--- a/libphobos/configure.tgt
+++ b/libphobos/configure.tgt
@@ -32,6 +32,8 @@ case "${target}" in
;;
   x86_64-*-netbsd* | i?86-*-netbsd*)
;;
+  riscv*-*-linux*)
+   ;;
   *)
UNSUPPORTED=1
;;
diff --git a/libphobos/libdruntime/core/atomic.d 
b/libphobos/libdruntime/core/atomic.d
index 0b39cddb6c9..5a6c4b854c7 100644
--- a/libphobos/libdruntime/core/atomic.d
+++ b/libphobos/libdruntime/core/atomic.d
@@ -1353,7 +1353,7 @@ else version (GNU)
 
 private bool casImpl(T,V1,V2)( shared(T)* here, V1 ifThis, V2 writeThis ) 
pure nothrow @nogc @trusted
 {
-static assert(GNU_Have_Atomics, "cas() not supported on this 
architecture");
+static assert(GNU_Have_Atomics || GNU_Have_LibAtomic, "cas() not 
supported on this architecture");
 bool res = void;
 
 static if (T.sizeof == byte.sizeof)
@@ -1406,7 +1406,7 @@ else version (GNU)
 {
 static assert(ms != MemoryOrder.rel, "Invalid MemoryOrder for 
atomicLoad");
 static assert(__traits(isPOD, T), "argument to atomicLoad() must be 
POD");
-static assert(GNU_Have_Atomics, "atomicLoad() not supported on this 
architecture");
+static assert(GNU_Have_Atomics || GNU_Have_LibAtomic, "atomicLoad() 
not supported on this architecture");
 
 static if (T.sizeof == ubyte.sizeof)
 {
@@ -1444,7 +1444,7 @@ else version (GNU)
 {
 static assert(ms != MemoryOrder.acq, "Invalid MemoryOrder for 
atomicStore");
 static assert(__traits(isPOD, T), "argument to atomicLoad() must be 
POD");
-static assert(GNU_Have_Atomics, "atomicStore() not supported on this 
architecture");
+static assert(GNU_Have_Atomics || GNU_Have_LibAtomic, "atomicStore() 
not supported on this architecture");
 
 static if (T.sizeof == ubyte.sizeof)
 {
diff --git a/libphobos/libdruntime/rt/sections_elf_shared.d 
b/libphobos/libdruntime/rt/sections_elf_shared.d
index d4e1ff07699..45c1dcbc7f3 100644
--- a/libphobos/libdruntime/rt/sections_elf_shared.d
+++ b/libphobos/libdruntime/rt/sections_elf_shared.d
@@ -10,6 +10,9 @@
 
 module rt.sections_elf_shared;
 
+version (RISCV32) version = RISCV_Any;
+version (RISCV64) version = RISCV_Any;
+
 version (CRuntime_Glibc) enum SharedELF = true;
 else version (FreeBSD) enum SharedELF = true;
 else version (NetBSD) enum SharedELF = true;
@@ -671,7 +674,16 @@ version (Shared)
 if (dyn.d_tag == DT_STRTAB)
 {
 version (linux)
-strtab = cast(const(char)*)dyn.d_un.d_ptr;
+{
+// This might change in future glibc releases (after 2.29) 
as dynamic sections
+// are not required to be read-only on RISC-V. This was 
copy & pasted from MIPS while
+// upstreaming RISC-V support. Otherwise MIPS is the only 
arch which sets in glibc:
+// #define DL_RO_DYN_SECTION 1
+version (RISCV_Any)
+strtab = cast(const(char)*)(info.dlpi_addr + 
dyn.d_un.d_ptr); // relocate
+else
+strtab = cast(const(char)*)dyn.d_un.d_ptr;
+}
 else version (FreeBSD)
 strtab = cast(const(char)*)(info.dlpi_addr + 
dyn.d_un.d_ptr); // relocate
 else version (NetBSD)
diff --git a/libphobos/src/std/experimental/allocator/building_blocks/region.d 
b/libphobos/src/std/experimental/allocator/building_blocks/region.d
index dfcecce72bd..cafe059a61f 100644
--- a/libphobos/src/std/experimental/allocator/building_blocks/region.d
+++ b/libphobos/src/std/experimental/allocator/building_blocks/region.d
@@ -391,7 +391,8 @@ struct InSituRegion(size_t size, size_t minAlign = 
platformAlignment)
 else version (PPC) enum growDownwards = Yes.growDownwards;
 else version (PPC64) enum growDownwards = Yes.growDownwards;
 else version (MIPS32) enum growDownwards = Yes.growDownwards;
-else version (MIPS64) enum growDownwards = Yes.growDownwards;
+else version (RISCV32) enum growDownwards

Re: [PATCH] Backport of RISC-V support for libffi

2018-03-20 Thread David Abdurachmanov

On Tue, 2018-03-20 at 12:09 +0100, Andreas Schwab wrote:
> On Mär 20 2018, David Abdurachmanov <david@gmail.com> wrote:
> 
> > What is the current situation/resolution regarding GOARCH? GCC use
> > RISCV64, but golang port uses RISCV. It would be nice to have a
> > resolution before GCC 8 release is cut.
> 
> I didn't know that GOARCH has any significance.  Did you file a bug?

I don't know about significance of GOARCH, but I do care about
consistency with golang port to avoid confusion by users later on.

I have not filed a bug report. I though Stefan (CC) was in contact with
you regarding this.

david

Re: [PATCH] Backport of RISC-V support for libffi

2018-03-20 Thread David Abdurachmanov

I am using the same changes in Fedora RISC-V with GCC 8.0.1-0.19
(libffi patch + s/FFI_ALIGN/ALIGN/ + regen).

Note that libffi port is missing go closures support. Small things like
hello world work fine, but utilities like "go" will complain with run-
time error:

fatal error: libgo built without FFI does not support reflect.Call or
runtime.SetFinalizer"

What is the current situation/resolution regarding GOARCH? GCC use
RISCV64, but golang port uses RISCV. It would be nice to have a
resolution before GCC 8 release is cut.

david

On Tue, 2018-03-20 at 11:50 +0100, Andreas Schwab wrote:
> This is a backport of  9aaa>
> (the only difference to upstream is s/FFI_ALIGN/ALIGN/, as we don't
> have
> commit bd72848c7a).  This is needed for libgo.
> 
> Andreas.
> 
>   * configure.host: Add RISC-V support.
>   * Makefile.am: Likewise.
>   * Makefile.in: Regenerate.
>   * src/riscv/ffi.c, src/riscv/ffitarget.h, src/riscv/sysv.S: New
>   files.
> ---
>  libffi/Makefile.am   |   2 +
>  libffi/Makefile.in   |  25 ++-
>  libffi/configure.host|   5 +
>  libffi/src/riscv/ffi.c   | 445
> +++
>  libffi/src/riscv/ffitarget.h |  68 +++
>  libffi/src/riscv/sysv.S  | 214 +
>  6 files changed, 757 insertions(+), 2 deletions(-)
>  create mode 100644 libffi/src/riscv/ffi.c
>  create mode 100644 libffi/src/riscv/ffitarget.h
>  create mode 100644 libffi/src/riscv/sysv.S
> 
> diff --git a/libffi/Makefile.am b/libffi/Makefile.am
> index dc43328536..37f5ecaf3c 100644
> --- a/libffi/Makefile.am
> +++ b/libffi/Makefile.am
> @@ -138,6 +138,7 @@ noinst_HEADERS = \
>   src/or1k/ffitarget.h
> \
>   src/pa/ffitarget.h  
> \
>   src/powerpc/ffitarget.h src/powerpc/asm.h
> src/powerpc/ffi_powerpc.h \
> + src/riscv/ffitarget.h   
>   \
>   src/s390/ffitarget.h
> \
>   src/sh/ffitarget.h  
> \
>   src/sh64/ffitarget.h
> \
> @@ -173,6 +174,7 @@ EXTRA_libffi_la_SOURCES = \
>src/powerpc/linux64_closure.S src/powerpc/ppc_closure.S
> \
>src/powerpc/aix.S src/powerpc/darwin.S
> src/powerpc/aix_closure.S \
>src/powerpc/darwin_closure.S src/powerpc/ffi_darwin.c  
>   \
> + src/riscv/ffi.c src/riscv/sysv.S
> \
>   src/s390/ffi.c src/s390/sysv.S  
>   \
>   src/sh/ffi.c src/sh/sysv.S  
> \
>   src/sh64/ffi.c src/sh64/sysv.S  
>   \
> diff --git a/libffi/Makefile.in b/libffi/Makefile.in
> index 8a99ee58b6..d395d3a8d3 100644
> --- a/libffi/Makefile.in
> +++ b/libffi/Makefile.in
> @@ -432,6 +432,7 @@ noinst_HEADERS = \
>   src/or1k/ffitarget.h
> \
>   src/pa/ffitarget.h  
> \
>   src/powerpc/ffitarget.h src/powerpc/asm.h
> src/powerpc/ffi_powerpc.h \
> + src/riscv/ffitarget.h   
>   \
>   src/s390/ffitarget.h
> \
>   src/sh/ffitarget.h  
> \
>   src/sh64/ffitarget.h
> \
> @@ -467,6 +468,7 @@ EXTRA_libffi_la_SOURCES = \
>src/powerpc/linux64_closure.S src/powerpc/ppc_closure.S
> \
>src/powerpc/aix.S src/powerpc/darwin.S
> src/powerpc/aix_closure.S \
>src/powerpc/darwin_closure.S src/powerpc/ffi_darwin.c  
>   \
> + src/riscv/ffi.c src/riscv/sysv.S
> \
>   src/s390/ffi.c src/s390/sysv.S  
>   \
>   src/sh/ffi.c src/sh/sysv.S  
> \
>   src/sh64/ffi.c src/sh64/sysv.S  
>   \
> @@ -831,6 +833,16 @@ src/powerpc/darwin_closure.lo:
> src/powerpc/$(am__dirstamp) \
>   src/powerpc/$(DEPDIR)/$(am__dirstamp)
>  src/powerpc/ffi_darwin.lo: src/powerpc/$(am__dirstamp) \
>   src/powerpc/$(DEPDIR)/$(am__dirstamp)
> +src/riscv/$(am__dirstamp):
> + @$(MKDIR_P) src/riscv
> + @: > src/riscv/$(am__dirstamp)
> +src/riscv/$(DEPDIR)/$(am__dirstamp):
> + @$(MKDIR_P) src/riscv/$(DEPDIR)
> + @: > src/riscv/$(DEPDIR)/$(am__dirstamp)
> +src/riscv/ffi.lo: src/riscv/$(am__dirstamp) \
> + src/riscv/$(DEPDIR)/$(am__dirstamp)
> +src/riscv/sysv.lo: src/riscv/$(am__dirstamp) \
> + src/riscv/$(DEPDIR)/$(am__dirstamp)
>  src/s390/$(am__dirstamp):
>   @$(MKDIR_P) src/s390
>   @: > src/s390/$(am__dirstamp)
> @@ -1051,6 +1063,10 @@ mostlyclean-compile:
>   -rm -f src/prep_cif.lo
>   -rm

Re: [PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators

2016-04-09 Thread David Abdurachmanov

> On 15 Jan 2016, at 05:10, Patrick Palka  wrote:
> 
> On Thu, 14 Jan 2016, Ryan Burn wrote:
> 
>> Also caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091
> 
> Thanks for the heads up, I was not aware I had caused this regression.

While looking at last few failures with GCC 6.0.0 in our software, I found one
compilation error related to PR c++/21802 fix. I am not yet sure if this is a
compiler issue or something else, thus instead just made a comment [1] to PR
c++/21802 with the current details (incl. pre-processed source).

It works fine with GCC 5.3.0, Clang 3.7.0 and ICC (16.0.2 20160204).

david
- - -
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802#c8

Re: [PING ^ 3] [RFC PATCH, AARCH64] Add support for -mlong-calls option

2015-01-16 Thread David Abdurachmanov

Ping.

This was posted in Stage 1, thus still should be valid for Stage 3.

First we hit a issue with OpenLoops package were we generated big functions
bodies (1-2MB) [1]. This caused the GNU assembler not to be happy as it 
generated
PC-relative offsets to literal pool above 1MB. The authors of package are
attempting to split the functions into smaller pieces, but now we are hitting
GNU bfd linker issues:

virtual_6_pplljjj_eexuuxggg_1_qp.f90:(.text+0x22820): relocation truncated to
fit: R_AARCH64_CALL26 against symbol __ol_last_step_qp_MOD_check_last_aq_v
defined in .text section i

After reading: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-June/073992.html

Seems that this is GNU linker limitation as ARM linker handles this situation.

GCC AArch64 supports -mcmodel=large, but that's only for static linking. I
hope -mlong-calls can force gfortran to generate long calls instead for
shared linking.

Can we get this one in GCC 5?

Thanks,
david
- - -
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304

On Dec 9, 2014, at 9:28 AM, Yangfei (Felix) wrote:

 Hi, 
  This is a pin for: 
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02258.html 
 
 Thanks.

Re: libsanitizer merge from upstream r221802

2014-12-31 Thread David Abdurachmanov


On Dec 30, 2014, at 11:48 PM, Andrew Pinski wrote:
 If we have 64-bit kernel and 64-bit application is executed sys_getresuid is
 used for getresuid syscall, otherwise if 32-bit application is executed --
 sys_getresuid16 is used. Thus 64-bit application will never call
 sys_getresuid16 implemenation. Then
 getresuid16/getresgid16/getgroups16/setgroups16/etc only needs to in 32-bit
 binary of libsanitizer. Same should apply for x86_64/i*86.
 
 Is that correct?
 
 Kinda.  It only applies for aarch32 and not for AARCH64:ILP32.
 AARCH64:ILP32 uses the standard system calls here too.


I am attaching an updated patch, bootstrapped trunk on arrch64 with kernels 
3.12 and 3.17 (QEMU).

I looked at kernel source. If CONFIG_COMPAT is set then CONFIG_HAVE_UID16 is 
set.

From include/linux/syscalls.h

523 #ifdef CONFIG_UID16
524 asmlinkage long sys_chown16(const char __user *filename,
525 old_uid_t user, old_gid_t group);
526 asmlinkage long sys_lchown16(const char __user *filename,
527 old_uid_t user, old_gid_t group);
528 asmlinkage long sys_fchown16(unsigned int fd, old_uid_t user, old_gid_t 
group);
529 asmlinkage long sys_setregid16(old_gid_t rgid, old_gid_t egid);
530 asmlinkage long sys_setgid16(old_gid_t gid);
531 asmlinkage long sys_setreuid16(old_uid_t ruid, old_uid_t euid);
532 asmlinkage long sys_setuid16(old_uid_t uid);
533 asmlinkage long sys_setresuid16(old_uid_t ruid, old_uid_t euid, old_uid_t 
suid);
534 asmlinkage long sys_getresuid16(old_uid_t __user *ruid,
535 old_uid_t __user *euid, old_uid_t __user 
*suid);
536 asmlinkage long sys_setresgid16(old_gid_t rgid, old_gid_t egid, old_gid_t 
sgid);
537 asmlinkage long sys_getresgid16(old_gid_t __user *rgid,
538 old_gid_t __user *egid, old_gid_t __user 
*sgid);
539 asmlinkage long sys_setfsuid16(old_uid_t uid);
540 asmlinkage long sys_setfsgid16(old_gid_t gid);
541 asmlinkage long sys_getgroups16(int gidsetsize, old_gid_t __user 
*grouplist);
542 asmlinkage long sys_setgroups16(int gidsetsize, old_gid_t __user 
*grouplist);
543 asmlinkage long sys_getuid16(void);
544 asmlinkage long sys_geteuid16(void);
545 asmlinkage long sys_getgid16(void);
546 asmlinkage long sys_getegid16(void);
547 #endif

Thus I disabled such syscalls in libsanitizer with SANITIZER_WORDSIZE macro and 
disabled
type checks for __kernel_old_{uid,gid}_t. Did not touch the fragment which sets 
__kernel_old_{uid,gid}_t.

SANITIZER_WORDSIZE is set based on _LP64 macro.

If patch is acceptable I could do more tests after holidays.

Thanks,
david



pr64435v2.patch
Description: Binary data

Re: libsanitizer merge from upstream r221802

2014-12-30 Thread David Abdurachmanov


On Dec 29, 2014, at 7:46 PM, Jakub Jelinek wrote:

 On Mon, Dec 29, 2014 at 07:36:42PM +0100, David Abdurachmanov wrote:
 I believe this is breaking bootstrap on aarch64-linux-gnu with kernels 
 =3.15,
 3.16 and above are fine.
 
 __kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned
 short. =3.15 kernel will trigger static asserts in libsanitizer while
 compiling GCC.
 
 I created PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 (includes 
 all
 the details).
 
 Attaching a patch with resolved issues on F19 + 3.12 kernel (also 
 bootstrapped
 in QEMU with F21 rootfs + 3.17 kernel) on aarch64-linux-gnu.
 
 That looks very much wrong, ABI can't depend on what kernel headers you are
 compiling against.
 So, better would be just to ifdef out the check and always use 16-bit
 __kernel_old_*_t on aarch64.  Are the
 getresuid16/getresgid16/getgroups16/setgroups16 syscalls wired at all on
 aarch64?  If not, then supposedly the sanitizer_common_syscalls.inc stuff
 for these syscalls should be ifdefed out on aarch64 (or any other arch that
 doesn't have those syscalls).

I am not an expert here.

# uname -r -m
3.17.0-301.fc21.aarch64 aarch64

# cat /proc/kallsyms | sed -n 's/.* sys_//p' | grep 16
chown16
fchown16
getegid16
geteuid16
getgid16
getgroups16
getresgid16
getresuid16
getuid16
lchown16
setfsgid16
setfsuid16
setgid16
setgroups16
setregid16
setresgid16
setresuid16
setreuid16
setuid16

The following are syscall implementations available in my current kernel with
16 suffix.

From include/uapi/asm-generic/unistd.h

435 #define __NR_getresuid 148
436 __SYSCALL(__NR_getresuid, sys_getresuid)

From arch/arm64/include/asm/unistd32.h

354 #define __NR_getresuid 165
355 __SYSCALL(__NR_getresuid, sys_getresuid16)

Isn't this needed for 32-bit (compat) application support on 64-bit system?

https://lkml.org/lkml/2012/7/6/570
https://lkml.org/lkml/2012/7/6/545

If we have 64-bit kernel and 64-bit application is executed sys_getresuid is
used for getresuid syscall, otherwise if 32-bit application is executed --
sys_getresuid16 is used. Thus 64-bit application will never call
sys_getresuid16 implemenation. Then
getresuid16/getresgid16/getgroups16/setgroups16/etc only needs to in 32-bit
binary of libsanitizer. Same should apply for x86_64/i*86.

Is that correct?

david


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: libsanitizer merge from upstream r221802

2014-12-29 Thread David Abdurachmanov

Hi,

I believe this is breaking bootstrap on aarch64-linux-gnu with kernels =3.15,
3.16 and above are fine.

__kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned
short. =3.15 kernel will trigger static asserts in libsanitizer while
compiling GCC.

I created PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 (includes all
the details).

Attaching a patch with resolved issues on F19 + 3.12 kernel (also bootstrapped
in QEMU with F21 rootfs + 3.17 kernel) on aarch64-linux-gnu.

david



gcc-pr64435.patch
Description: Binary data



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: libsanitizer merge from upstream r221802

2014-12-29 Thread David Abdurachmanov

Hi,

I believe this is breaking bootstrap on aarch64-linux-gnu with kernels =3.15,
3.16 and above are fine.

__kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned
short. =3.15 kernel will trigger static asserts in libsanitizer while
compiling GCC.

I created PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 (includes all
the details).

Attaching a patch with resolved issues on F19 + 3.12 kernel (also bootstrapped
in QEMU with F21 rootfs + 3.17 kernel) on aarch64-linux-gnu.

david



gcc-pr64435.patch
Description: Binary data



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK

2013-08-20 Thread David Abdurachmanov

ping^2

david

On Aug 12, 2013, at 2:31 PM, David Abdurachmanov wrote:

 Hi,
 
 Ping. Any news of the following patch being included into the trunk?
 
 Thanks,
 david
 
 On Aug 2, 2013, at 1:45 PM, Martin Jambor wrote:
 
 Hi,
 
 while compute_record_mode in stor-layout.c makes sure it assigns BLK
 mode to structs with flexible arrays, it has no such provisions for
 zero length arrays
 (http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Zero-Length.html).  I
 think that in order to avoid problems and surprises like PR 57748
 (where this triggered code that was intended for small structures that
 fit into a scalar mode and ICEd), we should assign both variable array
 possibilities the same mode.
 
 Bootstrapped and tested on x86_64-linux without any problems.  OK for
 trunk and the 4.8 branch?  (I'm not sure about the 4.7, this PR does
 not happen there despite the wrong mode so I'd ignore it for now.)
 
 Thanks,
 
 Martin
 
 
 2013-08-01  Martin Jambor  mjam...@suse.cz
 
  PR middle-end/57748
  * stor-layout.c (compute_record_mode): Treat zero-sized array fields
  like incomplete types.
 
 testsuite/
  * gcc.dg/torture/pr57748.c: New test.
 
 
 *** /tmp/lV6Ba8_stor-layout.cThu Aug  1 16:28:25 2013
 --- gcc/stor-layout.cThu Aug  1 15:36:18 2013
 *** compute_record_mode (tree type)
 *** 1604,1610 
  integer_zerop (TYPE_SIZE (TREE_TYPE (field)
|| ! host_integerp (bit_position (field), 1)
|| DECL_SIZE (field) == 0
 !  || ! host_integerp (DECL_SIZE (field), 1))
  return;
 
   /* If this field is the whole struct, remember its mode so
 --- 1604,1612 
  integer_zerop (TYPE_SIZE (TREE_TYPE (field)
|| ! host_integerp (bit_position (field), 1)
|| DECL_SIZE (field) == 0
 !  || ! host_integerp (DECL_SIZE (field), 1)
 !  || (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
 !   tree_low_cst (DECL_SIZE (field), 1) == 0))
  return;
 
   /* If this field is the whole struct, remember its mode so
 *** /dev/nullTue Jun  4 12:34:56 2013
 --- gcc/testsuite/gcc.dg/torture/pr57748.c   Thu Aug  1 15:42:14 2013
 ***
 *** 0 
 --- 1,45 
 + /* PR middle-end/57748 */
 + /* { dg-do run } */
 + 
 + #include stdlib.h
 + 
 + extern void abort (void);
 + 
 + typedef long long V
 +   __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
 + 
 + typedef struct S { V a; V b[0]; } P __attribute__((aligned (1)));
 + 
 + struct __attribute__((packed)) T { char c; P s; };
 + 
 + void __attribute__((noinline, noclone))
 + check (struct T *t)
 + {
 +   if (t-s.b[0][0] != 3 || t-s.b[0][1] != 4)
 + abort ();
 + }
 + 
 + int __attribute__((noinline, noclone))
 + get_i (void)
 + {
 +   return 0;
 + }
 + 
 + void __attribute__((noinline, noclone))
 + foo (P *p)
 + {
 +   V a = { 3, 4 };
 +   int i = get_i();
 +   p-b[i] = a;
 + }
 + 
 + int
 + main ()
 + {
 +   struct T *t = (struct T *) malloc (128);
 + 
 +   foo (t-s);
 +   check (t);
 + 
 +   return 0;
 + }

Re: [PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK

2013-08-12 Thread David Abdurachmanov

Hi,

Ping. Any news of the following patch being included into the trunk?

Thanks,
david

On Aug 2, 2013, at 1:45 PM, Martin Jambor wrote:

 Hi,
 
 while compute_record_mode in stor-layout.c makes sure it assigns BLK
 mode to structs with flexible arrays, it has no such provisions for
 zero length arrays
 (http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Zero-Length.html).  I
 think that in order to avoid problems and surprises like PR 57748
 (where this triggered code that was intended for small structures that
 fit into a scalar mode and ICEd), we should assign both variable array
 possibilities the same mode.
 
 Bootstrapped and tested on x86_64-linux without any problems.  OK for
 trunk and the 4.8 branch?  (I'm not sure about the 4.7, this PR does
 not happen there despite the wrong mode so I'd ignore it for now.)
 
 Thanks,
 
 Martin
 
 
 2013-08-01  Martin Jambor  mjam...@suse.cz
 
   PR middle-end/57748
   * stor-layout.c (compute_record_mode): Treat zero-sized array fields
   like incomplete types.
 
 testsuite/
   * gcc.dg/torture/pr57748.c: New test.
 
 
 *** /tmp/lV6Ba8_stor-layout.c Thu Aug  1 16:28:25 2013
 --- gcc/stor-layout.c Thu Aug  1 15:36:18 2013
 *** compute_record_mode (tree type)
 *** 1604,1610 
   integer_zerop (TYPE_SIZE (TREE_TYPE (field)
 || ! host_integerp (bit_position (field), 1)
 || DECL_SIZE (field) == 0
 !   || ! host_integerp (DECL_SIZE (field), 1))
   return;
 
/* If this field is the whole struct, remember its mode so
 --- 1604,1612 
   integer_zerop (TYPE_SIZE (TREE_TYPE (field)
 || ! host_integerp (bit_position (field), 1)
 || DECL_SIZE (field) == 0
 !   || ! host_integerp (DECL_SIZE (field), 1)
 !   || (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
 !tree_low_cst (DECL_SIZE (field), 1) == 0))
   return;
 
/* If this field is the whole struct, remember its mode so
 *** /dev/null Tue Jun  4 12:34:56 2013
 --- gcc/testsuite/gcc.dg/torture/pr57748.cThu Aug  1 15:42:14 2013
 ***
 *** 0 
 --- 1,45 
 + /* PR middle-end/57748 */
 + /* { dg-do run } */
 + 
 + #include stdlib.h
 + 
 + extern void abort (void);
 + 
 + typedef long long V
 +   __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
 + 
 + typedef struct S { V a; V b[0]; } P __attribute__((aligned (1)));
 + 
 + struct __attribute__((packed)) T { char c; P s; };
 + 
 + void __attribute__((noinline, noclone))
 + check (struct T *t)
 + {
 +   if (t-s.b[0][0] != 3 || t-s.b[0][1] != 4)
 + abort ();
 + }
 + 
 + int __attribute__((noinline, noclone))
 + get_i (void)
 + {
 +   return 0;
 + }
 + 
 + void __attribute__((noinline, noclone))
 + foo (P *p)
 + {
 +   V a = { 3, 4 };
 +   int i = get_i();
 +   p-b[i] = a;
 + }
 + 
 + int
 + main ()
 + {
 +   struct T *t = (struct T *) malloc (128);
 + 
 +   foo (t-s);
 +   check (t);
 + 
 +   return 0;
 + }

Re: [PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK

2013-08-12 Thread David Abdurachmanov

Hi,

Ping. Any news of the following patch being included into the trunk?

Thanks,
david

On Aug 2, 2013, at 1:45 PM, Martin Jambor wrote:

 Hi,
 
 while compute_record_mode in stor-layout.c makes sure it assigns BLK
 mode to structs with flexible arrays, it has no such provisions for
 zero length arrays
 (http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Zero-Length.html).  I
 think that in order to avoid problems and surprises like PR 57748
 (where this triggered code that was intended for small structures that
 fit into a scalar mode and ICEd), we should assign both variable array
 possibilities the same mode.
 
 Bootstrapped and tested on x86_64-linux without any problems.  OK for
 trunk and the 4.8 branch?  (I'm not sure about the 4.7, this PR does
 not happen there despite the wrong mode so I'd ignore it for now.)
 
 Thanks,
 
 Martin
 
 
 2013-08-01  Martin Jambor  mjam...@suse.cz
 
   PR middle-end/57748
   * stor-layout.c (compute_record_mode): Treat zero-sized array fields
   like incomplete types.
 
 testsuite/
   * gcc.dg/torture/pr57748.c: New test.
 
 
 *** /tmp/lV6Ba8_stor-layout.c Thu Aug  1 16:28:25 2013
 --- gcc/stor-layout.c Thu Aug  1 15:36:18 2013
 *** compute_record_mode (tree type)
 *** 1604,1610 
   integer_zerop (TYPE_SIZE (TREE_TYPE (field)
 || ! host_integerp (bit_position (field), 1)
 || DECL_SIZE (field) == 0
 !   || ! host_integerp (DECL_SIZE (field), 1))
   return;
 
/* If this field is the whole struct, remember its mode so
 --- 1604,1612 
   integer_zerop (TYPE_SIZE (TREE_TYPE (field)
 || ! host_integerp (bit_position (field), 1)
 || DECL_SIZE (field) == 0
 !   || ! host_integerp (DECL_SIZE (field), 1)
 !   || (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
 !tree_low_cst (DECL_SIZE (field), 1) == 0))
   return;
 
/* If this field is the whole struct, remember its mode so
 *** /dev/null Tue Jun  4 12:34:56 2013
 --- gcc/testsuite/gcc.dg/torture/pr57748.cThu Aug  1 15:42:14 2013
 ***
 *** 0 
 --- 1,45 
 + /* PR middle-end/57748 */
 + /* { dg-do run } */
 + 
 + #include stdlib.h
 + 
 + extern void abort (void);
 + 
 + typedef long long V
 +   __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
 + 
 + typedef struct S { V a; V b[0]; } P __attribute__((aligned (1)));
 + 
 + struct __attribute__((packed)) T { char c; P s; };
 + 
 + void __attribute__((noinline, noclone))
 + check (struct T *t)
 + {
 +   if (t-s.b[0][0] != 3 || t-s.b[0][1] != 4)
 + abort ();
 + }
 + 
 + int __attribute__((noinline, noclone))
 + get_i (void)
 + {
 +   return 0;
 + }
 + 
 + void __attribute__((noinline, noclone))
 + foo (P *p)
 + {
 +   V a = { 3, 4 };
 +   int i = get_i();
 +   p-b[i] = a;
 + }
 + 
 + int
 + main ()
 + {
 +   struct T *t = (struct T *) malloc (128);
 + 
 +   foo (t-s);
 +   check (t);
 + 
 +   return 0;
 + }

Re: [PATCH] RISC-V: Add minimal support for 7 new unprivileged extensions

Re: [PATCH v4] RISC-V: Add support for inlining subword atomic operations

Re: libgo patch committed: Update to Go1.14beta1

Re: [PATCH] D support for RISC-V

[PATCH] D support for RISC-V

Re: [PATCH] Backport of RISC-V support for libffi

Re: [PATCH] Backport of RISC-V support for libffi

Re: [PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators

Re: [PING ^ 3] [RFC PATCH, AARCH64] Add support for -mlong-calls option

Re: libsanitizer merge from upstream r221802

Re: libsanitizer merge from upstream r221802

Re: libsanitizer merge from upstream r221802

Re: libsanitizer merge from upstream r221802

Re: [PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK

Re: [PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK

Re: [PATCH, PR 57748] Set mode of structures with zero sized arrays to be BLK

16 matches

Site Navigation

Mail list logo

Footer information