;gp_sp_offset = offset;
> > /* The hard frame pointer points above the callee-saved GPRs.
> > */
> > frame->hard_frame_pointer_offset = offset;
> > /* Above the hard frame pointer is the callee-allocated varags
> > save area. */
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Like add.w/sub.w/mul.w, div.w/mod.w/div.wu/mod.wu also sign-extend the
output on LA64. But, LoongArch v1.00 mandates that the inputs of 32-bit
division to be sign-extended so we have to expand 32-bit division into
RTL sequences.
We defined div.w/mod.w/div.wu/mod.wu as a (DI, DI) -> SI
Currently in the description of LoongArch integer division instructions,
the output is marked as earlyclobbered ('&'). It's necessary when
loongarch_check_zero_div_p() because clobbering operand 2 (divisor) will
make the checking for zero divisor impossible.
But, for -mno-check-zero-division
, uint32_t, int64_t}.
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
Xi Ruoyao (2):
loongarch: add alternatives for idiv insns to improve code generation
loongarch: avoid unnecessary sign-extend after 32-bit division
gcc/config/loongarch/loongarch-protos.h| 1 +
gcc/config
On Thu, 2022-07-07 at 02:11 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Wed, 2022-07-06 at 11:34 +, Dimitrije Milosevic wrote:
> > Ping. :)
> > This change just landed on LLVM (see
> > https://reviews.llvm.org/rG5d8077565e4196efdd4ed525a64c11a96d5aa5dd)
> > .
>
On Wed, 2022-07-06 at 11:34 +, Dimitrije Milosevic wrote:
> Ping. :)
> This change just landed on LLVM (see
> https://reviews.llvm.org/rG5d8077565e4196efdd4ed525a64c11a96d5aa5dd).
> Unfortunately, I do not have commit access, so if anyone can commit it, that
> would be great!
> Here is the
i Xi, thanks for looking into this. I've tried running the testsuite
> > > on a cross-toolchain (as I do not currently have access to a physical
> > > machine)
> > > for a MIPS64R6 and the test passes successfully. Could you please
> > > verify that the test fails solely based on this change?
I've got a clue about why this happens. See
https://reviews.llvm.org/D129112.
It depends on how the dynamic linker arranges TLS blocks so different
version of Glibc may produce different results.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2022-07-05 at 12:51 +0800, Xi Ruoyao via Gcc-patches wrote:
> I agree it's fine, but the problem is TSAN is currently "unsupported"
> within GCC (i. e. when you build gcc libtsan is not built). So it
> does
> not make any benefit to commit this change before m
fault to omit frame pointer, so it's a
> bit unfortunately that we need to enable unwind tables to get good
> diagnostics.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -55,6 +55,9 @@ case "${target}" in
arm*-*-linux*)
;;
mips*-*-linux*)
+ if test x$ac_cv_sizeof_void_p = x8; then
+ TSAN_SUPPORTED=yes
+ fi
;;
aarch64*-*-linux*)
if test x$ac_cv_sizeof_void_p = x8; then
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Document a behavior change in r12-8546. Ok for wwwdocs?
---
htdocs/gcc-12/changes.html | 26 ++
1 file changed, 26 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index ae03c3c6..ef957204 100644
--- a/htdocs/gcc-12/changes.html
+++
On Mon, 2022-07-04 at 14:25 +0800, Lulu Cheng wrote:
> > How do you think about the suggestion from Richard about a backport into
> > gcc-12 branch? Normally we don't backport behavior changes, but making
> > 12.1 the only exception seems compelling.
>
> I agree with you and Richard.
>
>
On Sat, 2022-07-02 at 16:35 +0800, Lulu Cheng wrote:
> 在 2022/7/2 下午4:24, Xi Ruoyao 写道:
> >
> > I'll commit the patch with the hook removed after another regtest on
> > loongarch64-linux-gnu. I just rebuilt the entire system on my
> > 3A5000,
> > so I need som
On Sat, 2022-07-02 at 15:39 +0800, Lulu Cheng wrote:
> diff --git a/gcc/common/config/loongarch/loongarch-common.cc
> b/gcc/common/config/loongarch/loongarch-common.cc
> index b6cbd84b873..f8b4660fabf 100644
> --- a/gcc/common/config/loongarch/loongarch-common.cc
> +++
gt; index 8fe0d831431..8bd9a327623 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_platform.h
> +++ b/libsanitizer/sanitizer_common/sanitizer_platform.h
> @@ -159,7 +159,7 @@
>
> #if defined(__mips__)
> # define SANITIZER_MIPS 1
> -# if defined(__mips64)
> +# if defined(__mips64) && _MIPS_SIM == _ABI64
> # define SANITIZER_MIPS32 0
> # define SANITIZER_MIPS64 1
> # else
>
> ---
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
: FIRST_32_SECOND_64(144, 216);
> + : FIRST_32_SECOND_64(160, 216);
> const unsigned struct_kernel_stat64_sz = 104;
> #elif defined(__s390__) && !defined(__s390x__)
> const unsigned struct_kernel_stat_sz = 64;
>
> ---
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
= @localedir@
> diff --git a/libsanitizer/sanitizer_common/Makefile.in
> b/libsanitizer/sanitizer_common/Makefile.in
> index 07047bd4b17..e916a803786 100644
> --- a/libsanitizer/sanitizer_common/Makefile.in
> +++ b/libsanitizer/sanitizer_common/Makefile.in
> @@ -342,6 +342,7 @@ libexecdir = @libexecdir@
> link_libasan = @link_libasan@
> link_libhwasan = @link_libhwasan@
> link_liblsan = @link_liblsan@
> +link_libsan_rpath = @link_libsan_rpath@
> link_libtsan = @link_libtsan@
> link_libubsan = @link_libubsan@
> localedir = @localedir@
> diff --git a/libsanitizer/tsan/Makefile.in
> b/libsanitizer/tsan/Makefile.in
> index 36498832bb8..ab8db13a268 100644
> --- a/libsanitizer/tsan/Makefile.in
> +++ b/libsanitizer/tsan/Makefile.in
> @@ -379,6 +379,7 @@ libexecdir = @libexecdir@
> link_libasan = @link_libasan@
> link_libhwasan = @link_libhwasan@
> link_liblsan = @link_liblsan@
> +link_libsan_rpath = @link_libsan_rpath@
> link_libtsan = @link_libtsan@
> link_libubsan = @link_libubsan@
> localedir = @localedir@
> diff --git a/libsanitizer/ubsan/Makefile.in
> b/libsanitizer/ubsan/Makefile.in
> index 92a8e387fd7..5fc063fe9ee 100644
> --- a/libsanitizer/ubsan/Makefile.in
> +++ b/libsanitizer/ubsan/Makefile.in
> @@ -344,6 +344,7 @@ libexecdir = @libexecdir@
> link_libasan = @link_libasan@
> link_libhwasan = @link_libhwasan@
> link_liblsan = @link_liblsan@
> +link_libsan_rpath = @link_libsan_rpath@
> link_libtsan = @link_libtsan@
> link_libubsan = @link_libubsan@
> localedir = @localedir@
>
> ---
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
anitizer_common/sanitizer_platform_limits_posix.h
> @@ -83,7 +83,7 @@ const unsigned struct_kernel_stat64_sz = 104;
> #elif defined(__mips__)
> const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
> ? FIRST_32_SECOND_64(104, 128)
> - : FIRST_32_SECOND_64(144, 216);
> + : FIRST_32_SECOND_64(160, 216);
> const unsigned struct_kernel_stat64_sz = 104;
> #elif defined(__s390__) && !defined(__s390x__)
> const unsigned struct_kernel_stat_sz = 64;
>
> ---
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
A documentation improvement with no code change. OK for trunk?
-- >8 --
We are receiving several reports that people are (mis)using
--enable-libsanitizer option, which was not documented by GCC
installation doc. It forces to build libsanitizer even for unsupported
targets, causing build
In libsanitizer code, the size of some GNU libc data structure (notably,
struct stat) is hard coded. These sizes may trigger a static assert
buidling against another libc.
Just make non-GNU libc targets UNSUPPORTED now. If someone really cares
about those alternative libc implementations,
Hi,
We've made a consensus [1] that not to enable trapping for division by
zero by default for LLVM, and we think GCC should behave similarly.
The main rationales:
1. Division by zero is undefined behavior, so in theory any portable
program shall not depend on it.
2. There are already many
Pushed as r13-1319 and r12-8520. Already approved by port maintainer at
bugzilla.
-- >8 --
The epilogue may clobber LARCH_PROLOGUE_TEMP ($r13/$t1), so it cannot be
used for sibcalls.
gcc/ChangeLog:
PR target/106096
* config/loongarch/loongarch.h (REG_CLASS_CONTENTS): Exclude
Cherry-pick libffi commit 280fe78d37f58927b280e2e316a2ae19201f2b83,
and regenerate configure.
libffi/ChangeLog:
* configure.ac: Call AC_PROG_EGREP, and use $EGREP instead of
egrep.
* configure: Regenerate.
---
libffi/configure| 270
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the warning.
We can't hard code grep -F here or it may break build on hosts w/o GNU
grep. autoconf documentation contains
Python 2 has been EOL'ed for two years. egrep has been deprecated
for many years and the next grep release will start to print warning if
it is used.
-E option may be unsupported by some non-POSIX grep implementations, but
gcc-auto-profile won't work on non-Linux systems anyway.
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
Some non-POSIX grep implementations does not support -E option, so for
test_summary and warn_summary we prefer
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
However, simply replacing egrep with grep -E will break build on some
systems (notably Solaris) w/o a
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
But, we can't simply replace fgrep to grep -F, or the build will break
with some non-GNU grep implementations (lacking -F support).
As "add-gnu-debuglink"
egrep/fgrep has been deprecated in favor of grep -E/-F for a long time,
and the next grep release (3.8 or 4.0) will print a warning if egrep or
fgrep is used. Stop using egrep and fgrep so we won't see the warning.
But, we can't simply replace egrep to grep -E or fgrep to grep -F or the
build
egrep has been deprecated in favor of grep -E for a long time, and the
next GNU grep release (3.8 or 4.0) will print a warning if egrep is used.
Unfortunately, old hosts with non-GNU grep may lack the support for -E
option. Use AC_PROG_EGREP and $EGREP variable so we'll work fine on
both old and
-profile separately and include the egrep fix in that patch.
Bootstrapped and regtested on x86_64-linux-gnu and sparc-sun-solaris2.11
(gcc211.fsffrance.org, where grep does not support -E and autoconf sets
EGREP="ggrep -E").
Xi Ruoyao (7):
config: use $EGREP instead of egrep
fixinc
On Wed, 2022-06-01 at 11:04 +0200, Aldy Hernandez via Gcc-patches wrote:
> Final patch committed.
>
> All users but one of Value_Range::set_type() have been removed in
> favor of using a constructor taking a type. We still need to delay
> initialization for one use in gimple_infer_range, as it
On Fri, 2022-06-24 at 16:06 +, Joseph Myers wrote:
> On Fri, 24 Jun 2022, Xi Ruoyao via Gcc-patches wrote:
>
> > fgrep has been deprecated in favor of grep -F for a long time, and
> > the
> > next grep release (3.8 or 4.0) will print a warning of fgrep is
> > us
n/grep live in separate packages
> that may or may not be installed).
>
> I just want to make the entry barries for normal builds as low as
> possible.
Pushed as r13-1242 with ChangeLog fix, as compatibility-related stuff
"resolved" and this does not depend on other patches in the series.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
author thinks fgrep
may save several CPU cycles :). I'll just use a plain grep in PATCH v2.
Rainer: do you have some idea about the availability of "-q" on
different hosts? If you agree I'll use it instead of -s > /dev/null
too.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> wrote:
> >
> > egrep has been deprecated in favor of grep -E for a long time, and
> > the
> > next grep release (3.8 or 4.0) will print a warning
On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
> please remember that there's a world outside of GNU grep: e.g. Solaris
> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
> unconditionally replacing egrep with grep -E in several places is
> likely
> to break at least
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
contrib/ChangeLog:
* check_GNU_style.sh: Use grep -E instead of egrep.
* test_summary:
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
gcc/testsuite/ChangeLog:
* ada/acats/run_all.sh: Use grep -E instead of egrep.
*
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the warning.
gcc/ChangeLog:
* fortran/Make-lang.in: Use grep -F instead of fgrep.
---
gcc/fortran/Make-lang.in |
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
And, the fgrep command in exgettext is no longer useful after we
migrated from SVN to Git. Remove the fgrep command so we won't see the
warning.
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the warning.
libbacktrace/ChangeLog:
* configure.ac: Use grep -F instead of fgrep.
* configure:
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
libstdc++-v3/ChangeLog:
* scripts/extract_symvers.in: Use grep -E instead of egrep.
*
egrep/fgrep has been deprecated in favor of grep -E/-F for a long time,
and the next grep release (3.8 or 4.0) will print a warning if egrep or
fgrep is used. Stop using egrep and fgrep so we won't see the warning.
fixincludes/ChangeLog:
* fixinc.in: Use grep -E instead of egrep.
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
ChangeLog:
* configure.ac: Use grep -E instead of egrep.
* config.rpath: Likewise.
*
/gcc-auto-profile:
I'll make a patch later (now download.01.org seems down so I can't
test or regenerate gcc-auto-profile) porting gen_autofdo_event.py to
Python 3.
Xi Ruoyao (8):
config: use grep -E instead of egrep
fixincludes: use grep -E/-F instead of egrep/fgrep
libstdc++: use grep
220621/dbb112d2/attachment-0001.obj
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
tsan_thread_start_func
../../../../gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp:1009
(libtsan.so.2+0x3e5dc)
#5 start_thread /sources/glibc-2.35/nptl/pthread_create.c:442
(libc.so.6+0xc75f4)
I've tried to diagnose the root cause but failed.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
another approach?
> > Eric
A patch should not edit configure directly. configure.ac should be
edited and configure should be regenerated from it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
arch64-
> > > linux-
> > > gnuf64
> > > an x86_64-pc-linux-gnu.
> > >
> > > Any recommendations? Please review. Thanks a lot.
>
> The patch looks good to me.
Pushed as r13-1010.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ch.
Well, so should we add TSAN_SUPPORTED=yes for MIPS64 in
libsanitizer/configure.tgt first? I'll try this on my MIPS64 in a few
days.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
DOW_OFFSET \
> - (POINTER_SIZE == 64 ? HOST_WIDE_INT_1 << 37 : HOST_WIDE_INT_C
> (0x0aaa))
> -#endif
>
> ---
I think this depends on https://reviews.llvm.org/D127096 (not committed
yet)?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
jit.prev)
> @$(call LINK_PROGRESS,$(INDEX.jit),start)
> +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ -shared \
> $(jit_OBJS) libbackend.a libcommon-target.a libcommon.a \
> $(CPPLIB) $(LIBDECNUMBER) $(EXTRA_GCC_LIBS) $(LIBS)
> $(BACKENDLIBS) \
> -
.cc (pch_VA_max_size): Remove.
(mingw32_gt_pch_get_address): ... ...
I know almost nothing about Windoge/MinGW so the technical review is
left for others.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Ping.
On Wed, 2022-04-06 at 23:26 +0800, Xi Ruoyao via Gcc-patches wrote:
> Document ABI changes in r12-7961, 7962, and 8023. Ok for wwwdocs?
>
> ---
> htdocs/gcc-12/changes.html | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff
On Wed, 2022-04-27 at 14:57 +0800, Lulu Cheng wrote:
> I think the modification should be below.
> > >
> > > > if (!TYPE_P (TREE_TYPE (f)))
> > > > return -1;
I think (!TYPE_P (TREE_TYPE (f)) will never be true (the code handling
calling convention of other ports
a bug, and it has to be fixed anyway. If you don't like the
idea of this patch, please develop another solution and apply it *before
GCC 12*.
On Wed, 2022-04-20 at 14:23 +0800, Xi Ruoyao via Gcc-patches wrote:
> Currently, LoongArch ELF psABI is not clear on the handling of zero-
> sized
Currently, LoongArch ELF psABI is not clear on the handling of zero-
sized fields in aggregates arguments or return values [1]. The behavior
of GCC trunk is puzzling considering the following cases:
struct test1
{
double a[0];
float x;
};
struct test2
{
float a[0];
float x;
};
GCC
I can confirm this patch fixes t033 failure. LGTM, except...
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.cc: Fix bug for
> tmpdir-g++.dg-struct-layout-1/t033.
^^ These two whitespaces should not exist
(I was taught this just several days ago :)
-
Another simple testcase change for LoongArch. Ok for trunk?
---
LoongArch backend allocates two additional 8-byte stack slots for LP64,
one for saving $fp and another for saving the temporary value "1".
Ideally they are both unneeded, but (1) we're using -O0 so the code is
suboptimized by the
A simple testcase change, tested on loongarch64-linux-gnuabif64. Ok for trunk?
---
On LoongArch, variadic functions use different arugment passing
conventions so this test is not valid (see the section named "Variadic
argument" in the [ELF ABI][1]) and should be skipped.
[1]:
Another brown paper bag fix for MIPS :(.
This failure was not detected running mips.exp=pr102024-* with a cross
compiler, so I just spotted it now running the test natively.
---
The body of func is optimized away with -flto -fno-fat-lto-objects, so
the psABI inform is not emitted, causing a
Document ABI changes in r12-7961, 7962, and 8023. Ok for wwwdocs?
---
htdocs/gcc-12/changes.html | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 4f2ee77f..c924bca3 100644
---
On Wed, 2022-04-06 at 16:34 +0200, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 09:44:33PM +0800, Xi Ruoyao wrote:
> > @@ -6527,6 +6554,27 @@ mips_function_value_1 (const_tree valtype,
> > const_tree fn_decl_or_type,
> > if (has_cxx_zero_width_bf)
&g
v2: Add psABI warning and test.
--
This fixes tmpdir-g++.dg-struct-layout-1/{t032,t059} failure. Clang++
also ignores C++17 empty bases in return values.
gcc/
* config/mips/mips.cc (mips_fpr_return_fields): Ignore
cxx17_empty_base_field_p fields and set an indicator.
On Wed, 2022-04-06 at 14:44 +0200, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 08:33:40PM +0800, Xi Ruoyao via Gcc-patches wrote:
> > Another MIPS function return ABI fix. Ok for trunk?
> >
> > --
> >
> > This fixes tmpdir-g++.dg-struct-layout-1/{t032,t059
Fixes gcc.dg/torture/pr91323.c fail for MIPS. Ok for trunk?
LTGT should trap for unordered operands (see discussion in bugzilla),
but c.ueq does not trap for qNaN. Use c.ngl as it handles non-NaN
operands like c.ueq, but traps for qNaN as we want for LTGT.
gcc/
PR target/91323
Another MIPS function return ABI fix. Ok for trunk?
--
This fixes tmpdir-g++.dg-struct-layout-1/{t032,t059} failure. Clang++
ignores C++17 empty bases in return values as well.
gcc/
* config/mips/mips.cc (mips_fpr_return_fields): Ignore
cxx17_empty_base_field_p fields.
---
I made a mistake in r12-7962 and it causes an ICE running g++.dg-struct-
layout-1 tests. The fix and a reduced test are included in this patch.
Ok for trunk?
DECL_SIZE(x) is NULL if x is a flexible array member, but I forgot to
check it in r12-7962. Then if we increase the
Document PR102024 change (r12-7961 and 7962) for MIPS. Ok for wwwdocs?
--
htdocs/gcc-12/changes.html | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 4e1f6b0f..a2d8156f 100644
---
v1 -> v2:
* "int has_zero_width_bf_abi_change" -> "bool
zero_width_field_abi_change". "int" -> "bool" because it's only 0/1,
"bf" -> "field" because the change also affects zero-length arrays and
empty structs/unions, etc.
* Add tests with zero-length array and empty struct.
* Coding style
v1 -> v2:
* "int has_zero_width_bf" -> "bool has_cxx_zero_width_bf". "int" to
"bool" because the value is 0/1 only. Add "cxx" because it only
indicates C++ zero-width bit-fields (not those bit-fields from C).
* Coding style fix.
* Rewrite mips_return_in_msb so mips_fpr_return_fields is not
Part 2/2 of PR 102024 fix for MIPS.
The ABI says:
"Regardless of the struct field structure, it is treated as a sequence
of 64-bit chunks. If a chunk consists solely of a double float field
(but not a double, which is part of a union), it is passed in a floating
point register. Any other chunk
Part 1/2 of PR 102024 fix for MIPS.
No change for code generation. It only adds a -Wpsabi inform for return
values affected by the change in C++ FE.
The ABI is clear that any zero-width bit-field in a return value will
disallow using FPRs for it, so the behavior of GCC trunk is correct
(it's
ry like this
> (yet).
UBSAN can catch __builtin_unreachable() and print a message "execution
reached an unreachable program point".
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
g
> this option (i.e, it’s possible that the compiler might clear more
> registers than the user
> requests on some targets due to the implementation limitation).
>
> I can make this change if we decide to do this.
I'd vote for this. Richard?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
| ^~~
It seems changing the constraint "o" to "m" can work around this issue.
I'm not sure if this is a compiler bug or a kernel bug.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Mon, 2022-03-14 at 16:04 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Now I think the only rational ways are:
> >
> > (1) allow zeroing more registers than need_zeroed_hardregs.
>
> I think this is the way to go. I agree it's a bit hacky, but it s
On Mon, 2022-03-14 at 16:18 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > * configure.tgt: Enable build on mips64.
I changed this to "mips*64*-*-linux*" to be more precise.
> OK, thanks.
>
> Richard
Two patches pushed as r12-7645 and r12-76
On Sat, 2022-03-12 at 18:48 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2022-03-11 at 21:26 +, Qing Zhao wrote:
> > Hi, Ruoyao,
> >
> > (I might not be able to reply to this thread till next Wed due to a
> > short vacation).
> >
> > First, so
d "not work" on MIPS) in the
patch so I think it's unnecessary to add new test cases.
Richard: can we use MIPS_EPILOGUE_TEMP as a scratch register in the
sequence for zeroing the call-used registers, and then zero itself
(despite it's not in need_zeroed_hardregs)?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sat, 2022-03-12 at 01:29 +0800, Xi Ruoyao via Gcc-patches wrote:
> I'm now thinking: is there always at least one *GPR* which need to be
> cleared? If it's true, let's say GPR $12, and fcc0 & fcc2 needs to be
> cleared, we can use something like:
>
> cfc1 $12, $25
> a
, I still think that we should keep it.
>
> The “need_zeroed_hardregs” is computed based on
>
> 1. User’s request from command line option;
> 2. Data flow info of the routine;
> 3. Abi info of the target;
>
> If zero_call_used_regs target hook return registers out of
> “need_zeroed_
Bootstrapped and regtested on mips64el-linux-gnuabi64.
bootstrap-ubsan revealed 3 bugs (PR 104842, 104843, 104851).
bootstrap-asan did not reveal any new bug.
gcc/
* config/mips/mips.h (SUBTARGET_SHADOW_OFFSET): Define.
* config/mips/mips.cc (mips_option_override): Make
libsanitizer/
* sanitizer_common/sanitizer_atomic_clang.h: Ensures to only
include sanitizer_atomic_clang_mips.h for O32.
---
libsanitizer/sanitizer_common/sanitizer_atomic_clang.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
_ZERO_CALL_USED_REGS hook?
If yes then we'll happily to do so (like how the v2 of the patch does),
otherwise we'd need to clobber those registers NOT in
need_zeroed_hardregs explicitly.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Thu, 2022-03-10 at 21:41 +0800, Xi Ruoyao wrote:
> Changes from v1:
>
> * Added all zeroed registers into the return value of
> TARGET_ZERO_CALL_USED_REGS. **The question: is this allowed?**
> * Define mips_zero_fcc insn only for ISA_HAS_8CC and mips_isa >
> MI
Changes from v1:
* Added all zeroed registers into the return value of
TARGET_ZERO_CALL_USED_REGS. **The question: is this allowed?**
* Define mips_zero_fcc insn only for ISA_HAS_8CC and mips_isa >
MIPS_ISA_MIPS4, because MIPS I-IV and MIPSr6 don't support
"ISA_HAS_8CC && mips_isa >
On Wed, 2022-03-09 at 18:25 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Bootstrapped and regtested on mips64el-linux-gnuabi64.
> >
> > I'm not sure if it's "correct" to clobber other registers during the
> > zeroing of scratch registers. But I c
On Thu, 2022-03-10 at 09:01 +0100, Richard Biener wrote:
> On Wed, Mar 9, 2022 at 5:12 PM Xi Ruoyao
> wrote:
> >
> > On Wed, 2022-03-09 at 15:55 +0100, Richard Biener wrote:
> >
> > > isn't it better to make targetm.const_anchor unsigned?
> > > The
On Wed, 2022-03-09 at 15:55 +0100, Richard Biener wrote:
> isn't it better to make targetm.const_anchor unsigned?
> The & and ~ are not subject to overflow rules.
It's not enough: if n is the minimum value of HOST_WIDE_INT and
const_anchor = 0x8000 (the value for MIPS), we'll have a signed
Bootstrapped and tested on mips64el-linux-gnuabi64, and MIPS is the only
port with a non-zero targetm.const_anchor. Ok for trunk?
-- >8 --
With a non-zero const_anchor, the behavior of this function relied on
signed overflow.
gcc/
PR rtl-optimization/104843
* cse.cc
On Tue, 2022-03-08 at 18:20 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > I think this one obvious. Ok for trunk?
> OK, thanks.
Committed r12-7555.
/* snip */
> > #define LUI_OPERAND(VALUE) \
> > (((VALUE) | 0
On Wed, 2022-03-09 at 09:37 +0100, Richard Biener wrote:
> On Wed, Mar 9, 2022 at 5:06 AM Xi Ruoyao via Gcc-patches
> wrote:
> >
> > This should be obvious, OK for trunk?
>
> OK.
Committed r12-7559.
> > -- >8 --
> >
> > Calling VECTOR_MODE_P
This should be obvious, OK for trunk?
-- >8 --
Calling VECTOR_MODE_P with MAX_MACHINE_MODE has caused out-of-bound
access.
gcc/
PR tree-optimization/104851
* optabs-query.cc (supports_vec_convert_optab_p): Fix off-by-one
error.
---
gcc/optabs-query.cc | 2 +-
1 file
I think this one obvious. Ok for trunk?
gcc/
PR target/104842
* config/mips/mips.h (LUI_OPERAND): Cast the input to an unsigned
value before adding an offset.
---
gcc/config/mips/mips.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Bootstrapped and regtested on mips64el-linux-gnuabi64.
I'm not sure if it's "correct" to clobber other registers during the
zeroing of scratch registers. But I can't really come up with a better
idea: on MIPS there is no simple way to clear one bit in FCSR (i. e.
FCC[x]). We can't just use
rand:FCC 0 "register_operand" "=z")
+ (const_int 0))]
+ ""
+ "movgr2cf\t%0,$r0")
+
;; Conditional move instructions.
(define_insn "*sel_using_"
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
teering.html
It says the best place to reach the SC members is the list
g...@gcc.gnu.org.
And Joseph is also a SC member.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ot an expert in software engineering (or social interaction :) and
I don't know if the process has been changed in these years.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
701 - 800 of 970 matches
Mail list logo
