POSIX says:
On some implementations, if buf is a null pointer, getcwd() may obtain
size bytes of memory using malloc(). In this case, the pointer returned
by getcwd() may be used as the argument in a subsequent call to free().
Invoking getcwd() with buf as a null pointer is not
incl
command fails anyway, so we don't need to really care it.
> On 11/11/21 8:33 AM, Xi Ruoyao wrote:
>
> > ---
> > fixincludes/fixincl.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/fixincludes/f
[Revised to handle PR 21283.]
POSIX says:
On some implementations, if buf is a null pointer, getcwd() may obtain
size bytes of memory using malloc(). In this case, the pointer returned
by getcwd() may be used as the argument in a subsequent call to free().
Invoking getcwd() with
On Wed, 2021-11-10 at 00:02 +, Joseph Myers wrote:
> On Tue, 9 Nov 2021, Xi Ruoyao via Gcc-patches wrote:
>
> > POSIX says:
> >
> > On some implementations, if buf is a null pointer, getcwd() may
> > obtain
> > size bytes of memory using
On Tue, 2021-11-09 at 23:52 +0800, Xi Ruoyao via Gcc-patches wrote:
> > gcc trunk does not build with glibc-2.34+ and --enable-werror-always
> > :(
> >
> > I've sent the fix as
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html.
>
> I a
On Tue, 2021-11-09 at 21:53 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Mon, 2021-11-08 at 23:14 +, Joseph Myers wrote:
>
> /* snip */
>
> > Please make sure the back end builds cleanly with current GCC mainline.
> > This can be tested either with a native b
rn char *getcwd (char *__buf, size_t __size) __THROW __wur
| ^~
cc1: all warnings being treated as errors
I've sent the fix as
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
POSIX says:
On some implementations, if buf is a null pointer, getcwd() may obtain
size bytes of memory using malloc(). In this case, the pointer returned
by getcwd() may be used as the argument in a subsequent call to free().
Invoking getcwd() with buf as a null pointer is not
+ sprintf (buff + strlen (buff), "2:\\n\\t");
> + sprintf (buff + strlen (buff), "dbar\\t0x700\\n\\t");
> + sprintf (buff + strlen (buff), "3:\\n\\t");
> +
> + return buff;
> +}
These "cascading" sprintf/strlen looks stupid. It can be simply:
return "%G5\\n\\t"
"1:\\n\\t"
"ll.\\t%0,%1\\n\\t"
...
"3:\\n\\t";
The compiler will concatenate the string literals so there will be no
runtime overhead.
And there should be some comment to explain this LL/SC loop and dbar
workaround IMO.
Likewise for other atomic LL/SC expansions.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote:
> From: chenglulu
>
> libgomp/
>
> * configure.tgt: Add LoongArch tuple.
"tuple" should be "triplet".
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
is the thread pointer, not the PIC register.
> #elif defined(__MMIX__)
> /* No pic register. */
> #elif defined(__mn10300__)
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sat, 2021-11-06 at 16:40 +0800, Chenghua Xu wrote:
/* snip */
> diff --git a/libgcc/config/loongarch/crti.S b/libgcc/config/loongarch/crti.S
> new file mode 100644
> index 000..bac029874b5
> --- /dev/null
> +++ b/libgcc/config/loongarch/crti.S
> @@ -0,0 +1,43 @@
> +/* Copyright (C)
successfully. I guess
it's because of some mail size limit issue... According to
https://gcc.gnu.org/contribute.html:
> If the patch is too big or too mechanical, posting it gzipped or
> bzip2ed and uuencoded or encoded as a base64 MIME part is acceptable,
> as long as the ChangeLog is s
On Tue, 2021-09-21 at 21:38 +0800, Xi Ruoyao via Gcc-patches wrote:
> BTW the "correct" way to get a NaN in C++ seems:
>
> #include
> constexpr double my_nan = std::numeric_limits::quiet_NaN();
Sorry, we were discussing inf, not NaN... Then
constexpr double my_inf
nstead of quiet_NaN() if you want a signaling NaN).
Otherwise the compilation will fail.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
r Sayle
>
> gcc/cp/ChangeLog
> * constexpr.c (cxx_eval_outermost_const_expr): Temporarily
> disable
> the middle-end from honoring floating point exceptions/traps
> while
> folding "manifestly constant" expressions.
>
> gcc/testsuite/ChangeLog
.c (98%)
> rename libffi/testsuite/{libffi.call =>
> libffi.closures}/nested_struct4.c (100%)
> rename libffi/testsuite/{libffi.call =>
> libffi.closures}/nested_struct5.c (100%)
> rename libffi/testsuite/{libffi.call =>
> libffi.closures}/nested_struct6.c (100%)
> rename libffi/testsuite/{libffi.call =>
> libffi.closures}/nested_struct7.c (100%)
> rename libffi/testsuite/{libffi.call =>
> libffi.closures}/nested_struct8.c (100%)
> rename libffi/testsuite/{libffi.call =>
> libffi.closures}/nested_struct9.c (100%)
> rename libffi/testsuite/{libffi.call => libffi.closures}/problem1.c
> (100%)
> create mode 100644
> libffi/testsuite/libffi.closures/single_entry_structs1.c
> create mode 100644
> libffi/testsuite/libffi.closures/single_entry_structs2.c
> create mode 100644
> libffi/testsuite/libffi.closures/single_entry_structs3.c
> rename libffi/testsuite/{libffi.call => libffi.closures}/stret_large.c
> (100%)
> rename libffi/testsuite/{libffi.call => libffi.closures}/stret_large2.c
> (100%)
> rename libffi/testsuite/{libffi.call => libffi.closures}/stret_medium.c
> (98%)
> rename libffi/testsuite/{libffi.call =>
> libffi.closures}/stret_medium2.c (98%)
> rename libffi/testsuite/{libffi.call => libffi.closures}/testclosure.c
> (95%)
> rename libffi/testsuite/{libffi.special =>
> libffi.closures}/unwindtest.cc (95%)
> rename libffi/testsuite/{libffi.special =>
> libffi.closures}/unwindtest_ffi_call.cc (94%)
> delete mode 100644 libffi/testsuite/libffi.special/ffitestcxx.h
> delete mode 100644 libffi/testsuite/libffi.special/special.exp
>
> https://gitlab.com/x86-gcc/gcc/-/commit/667397efc8307e45ca6ddec737b0caf8ca9d0fda
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
These two patches look good to me. Still, need a maintainer's approval.
On Sun, 2021-08-29 at 22:59 -0400, YunQiang Su wrote:
> Currently mips-cpu.defs, mips.h, netbsd.h and config.gcc are
> using hardcoded numbers for isa level.
>
> Let's replace them with more readable enum mips_isa.
>
>
(mips_isa == 34)
> -#define ISA_MIPS32R5 (mips_isa == 36)
> -#define ISA_MIPS32R6 (mips_isa == 37)
> -#define ISA_MIPS64 (mips_isa == 64)
> -#define ISA_MIPS64R2 (mips_isa == 65)
> -#define ISA_MIPS64R3 (mips_isa == 66)
> -#define ISA_MIPS64R5 (mips_isa == 68)
> -#define ISA_MIPS64R6 (mips_isa == 69)
> +#define ISA_MIPS1 (mips_isa == MIPS_ISA_MIPS1)
> +#define ISA_MIPS2 (mips_isa == MIPS_ISA_MIPS2)
> +#define ISA_MIPS3 (mips_isa == MIPS_ISA_MIPS3)
> +#define ISA_MIPS4 (mips_isa == MIPS_ISA_MIPS4)
> +#define ISA_MIPS32 (mips_isa == MIPS_ISA_MIPS32)
> +#define ISA_MIPS32R2 (mips_isa == MIPS_ISA_MIPS32R2)
> +#define ISA_MIPS32R3 (mips_isa == MIPS_ISA_MIPS32R3)
> +#define ISA_MIPS32R5 (mips_isa == MIPS_ISA_MIPS32R5)
> +#define ISA_MIPS32R6 (mips_isa == MIPS_ISA_MIPS32R6)
> +#define ISA_MIPS64 (mips_isa == MIPS_ISA_MIPS64)
> +#define ISA_MIPS64R2 (mips_isa == MIPS_ISA_MIPS64R2)
> +#define ISA_MIPS64R3 (mips_isa == MIPS_ISA_MIPS64R3)
> +#define ISA_MIPS64R5 (mips_isa == MIPS_ISA_MIPS64R5)
> +#define ISA_MIPS64R6 (mips_isa == MIPS_ISA_MIPS64R6)
>
> /* Architecture target defines. */
> #define TARGET_LOONGSON_2E (mips_arch ==
> PROCESSOR_LOONGSON_2E)
> @@ -708,25 +708,25 @@ struct mips_cpu_info {
> #endif
>
> #ifndef MULTILIB_ISA_DEFAULT
> -#if MIPS_ISA_DEFAULT == 1
> +#if MIPS_ISA_DEFAULT == MIPS_ISA_MIPS1
> #define MULTILIB_ISA_DEFAULT "mips1"
> -#elif MIPS_ISA_DEFAULT == 2
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS2
> #define MULTILIB_ISA_DEFAULT "mips2"
> -#elif MIPS_ISA_DEFAULT == 3
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS3
> #define MULTILIB_ISA_DEFAULT "mips3"
> -#elif MIPS_ISA_DEFAULT == 4
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS4
> #define MULTILIB_ISA_DEFAULT "mips4"
> -#elif MIPS_ISA_DEFAULT == 32
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS32
> #define MULTILIB_ISA_DEFAULT "mips32"
> -#elif MIPS_ISA_DEFAULT == 33
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS32R2
> #define MULTILIB_ISA_DEFAULT "mips32r2"
> -#elif MIPS_ISA_DEFAULT == 37
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS32R6
> #define MULTILIB_ISA_DEFAULT "mips32r6"
> -#elif MIPS_ISA_DEFAULT == 64
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS64
> #define MULTILIB_ISA_DEFAULT "mips64"
> -#elif MIPS_ISA_DEFAULT == 65
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS64R2
> #define MULTILIB_ISA_DEFAULT "mips64r2"
> -#elif MIPS_ISA_DEFAULT == 69
> +#elif MIPS_ISA_DEFAULT == MIPS_ISA_MIPS64R6
> #define MULTILIB_ISA_DEFAULT "mips64r6"
> #else
> #define MULTILIB_ISA_DEFAULT "mips1"
> diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
> index 455b9b802..f35e50ced 100644
> --- a/gcc/config/mips/mips.md
> +++ b/gcc/config/mips/mips.md
> @@ -21,6 +21,23 @@
> ;; along with GCC; see the file COPYING3. If not see
> ;; <http://www.gnu.org/licenses/>.
>
> +(define_enum "mips_isa" [
> + mips1=1
> + mips2
> + mips3
> + mips4
> + mips32=32
> + mips32r2
> + mips32r3
> + mips32r5=36
> + mips32r6
> + mips64=64
> + mips64r2
> + mips64r3
> + mips64r5=68
> + mips64r6
> +])
> +
> (define_enum "processor" [
> r3000
> 4kc
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ue_name, "=");
> + token = strtok (NULL, "=");
> + if (token)
> + cur_value = atoi (token);
> ev->name = value_name;
> }
> ev->def = add_constant (get_md_constants (), value_name,
> - md_decimal_string (def->num_values),
> def);
> + md_decimal_string (cur_value), def);
>
> *def->tail_ptr = ev;
> def->tail_ptr = >next;
> def->num_values++;
> + cur_value++;
> }
> }
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
two PRs are already merged, and released since libffi-3.3.0 (now the
upstream latest release is 3.4.2).
I don't have a MIPSr6 so I can't test though.
YunQiang: the commit message should mention the commit SHA in upstream
libffi repo's main branch, instead of a URL to PR. You can use "git
log&q
On Fri, 2021-08-27 at 15:38 -0600, Jeff Law wrote:
>
>
> On 8/26/2021 10:20 PM, Xi Ruoyao via Gcc-patches wrote:
> > On Thu, 2021-08-26 at 23:56 -0400, YunQiang Su wrote:
> > > gcc/ChangeLog:
> > >
> > > PR target/102089
> > >
On Fri, 2021-08-27 at 15:36 -0600, Jeff Law wrote:
> It's easier when someone has to debug the code later.
> enums show up in debug output by default, while #defines do not.
> >
> > switch (mips_isa)
> > {
> > case MIPS_ISA_MIPS1: return "mips1";
> > // ...
> > }
> >
> > It
On Fri, 2021-08-27 at 13:11 +0800, YunQiang Su wrote:
> 在 2021/6/18 11:29, YunQiang Su 写道:
> > Currently, the asm output file for MIPS has no rev info.
> > It can make some trouble, for example:
> > assembler is mips1 by default,
> > gcc is fpxx by default.
> > To assemble the output of gcc
On Thu, 2021-08-26 at 23:56 -0400, YunQiang Su wrote:
> gcc/ChangeLog:
>
> PR target/102089
> * config.gcc: MIPS: use N64 ABI by default if the triple end
> with -gnuabi64, which is used by Debian since 2013.
> ---
> gcc/config.gcc | 14 ++
> 1 file changed,
On Sun, 2021-08-22 at 19:21 -0600, Jeff Law wrote:
>
>
> On 8/20/2021 11:07 AM, Xi Ruoyao via Gcc-patches wrote:
> > When -mloongson-mmi is enabled, SHIFT_COUNT_TRUNCATED is turned off.
> > This causes untruncated immediate shift amount outputed into the
> > asm
On Sat, 2021-08-21 at 01:07 +0800, Xi Ruoyao via Gcc-patches wrote:
> When -mloongson-mmi is enabled, SHIFT_COUNT_TRUNCATED is turned off.
> This causes untruncated immediate shift amount outputed into the asm,
> and the GNU assembler refuses to assemble it.
>
> Truncate immedia
When -mloongson-mmi is enabled, SHIFT_COUNT_TRUNCATED is turned off.
This causes untruncated immediate shift amount outputed into the asm,
and the GNU assembler refuses to assemble it.
Truncate immediate shift amount when outputing the asm instruction to
make GAS happy again.
gcc/
PR
On Sat, 2021-07-31 at 02:08 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2021-07-30 at 16:23 +0800, Xi Ruoyao via Gcc-patches wrote:
> > On Fri, 2021-07-30 at 09:11 +0100, Richard Sandiford wrote:
> > > Xi Ruoyao writes:
> > > > Ping again.
> > > >
On Fri, 2021-07-30 at 16:23 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2021-07-30 at 09:11 +0100, Richard Sandiford wrote:
> > Xi Ruoyao writes:
> > > Ping again.
> > >
> > > On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> > > > Com
On Fri, 2021-07-30 at 16:17 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2021-07-30 at 09:04 +0100, Richard Sandiford wrote:
> > Xi Ruoyao writes:
> > > Ping again.
> >
> > Sorry that this has gone unreviewed for so long. I think in
> > pract
On Fri, 2021-07-30 at 09:11 +0100, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Ping again.
> >
> > On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> > > Commit message shamelessly copied from 1777beb6b129 by jakub:
> > >
> > > This funct
On Fri, 2021-07-30 at 09:04 +0100, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Ping again.
>
> Sorry that this has gone unreviewed for so long. I think in practice
> the MIPS port is essentially unmaintained at this point -- it would
> be great if someone would vol
On Fri, 2021-07-30 at 15:21 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2021-07-30 at 15:00 +0800, Kewen.Lin wrote:
> > Hi Ruoyao,
> >
> > on 2021/7/30 下午12:57, Xi Ruoyao via Gcc-patches wrote:
> > > Ping again.
> > >
> >
> &
On Fri, 2021-07-30 at 15:00 +0800, Kewen.Lin wrote:
> Hi Ruoyao,
>
> on 2021/7/30 下午12:57, Xi Ruoyao via Gcc-patches wrote:
> > Ping again.
> >
>
> This ping-ed patch has been approved by Richard at
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/57
Ping again.
On Sun, 2021-07-11 at 01:48 +0800, Xi Ruoyao wrote:
> We are comparing enum values (in wide_int) to check ODR violation.
> However, if we compare two wide_int values with different precision,
> we'll trigger an assert, leading to ICE. With enum-base introduced
> in C++1
Ping again.
On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> Commit message shamelessly copied from 1777beb6b129 by jakub:
>
> This function, because it is sometimes called even outside of function
> bodies, uses create_tmp_var_raw rather than create_tmp_var. Bu
Ping again.
On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote:
> Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing
> ICE on MIPS with MSA enabled. Add the pattern to prevent it.
>
> Bootstrapped and regression tested on mips64el-linux-gnu.
> Ok for
Ping again.
On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> Commit message shamelessly copied from 1777beb6b129 by jakub:
>
> This function, because it is sometimes called even outside of function
> bodies, uses create_tmp_var_raw rather than create_tmp_var.
Ping again.
On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote:
> Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing
> ICE on MIPS with MSA enabled. Add the pattern to prevent it.
>
> Bootstrapped and regression tested on mips64el-linux-gnu.
> Ok for
On Fri, 2021-07-23 at 11:18 +0800, Xi Ruoyao wrote:
> On Fri, 2021-07-23 at 04:21 +0200, Maciej W. Rozycki wrote:
> > On Fri, 9 Jul 2021, Richard Sandiford via Gcc-patches wrote:
> >
> > > > > > > The "smallest fix" is simply adding -fno-inline into
estsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -325,6 +325,7 @@ foreach option {
finite-math-only
fixed-hi
fixed-lo
+inline
lax-vector-conversions
omit-frame-pointer
optimize-sibling-calls
right? I'll do a regtest and if there is no problem I'll commit it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Ping.
On Sun, 2021-07-11 at 01:48 +0800, Xi Ruoyao wrote:
> We are comparing enum values (in wide_int) to check ODR violation.
> However, if we compare two wide_int values with different precision,
> we'll trigger an assert, leading to ICE. With enum-base introduced
> in C++11, it's
Ping again.
I heard that Matthew is too busy to deal with MIPS things from someone's
private mail. Hope someone else can review it.
On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote:
> Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing
> ICE on MIPS with MSA enabled
Ping again.
On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> Commit message shamelessly copied from 1777beb6b129 by jakub:
>
> This function, because it is sometimes called even outside of function
> bodies, uses create_tmp_var_raw rather than create_tmp_var. Bu
We are comparing enum values (in wide_int) to check ODR violation.
However, if we compare two wide_int values with different precision,
we'll trigger an assert, leading to ICE. With enum-base introduced
in C++11, it's easy to sink into this situation.
To fix the issue, we need to explicitly
Ping again.
On Mon, 2021-06-28 at 21:50 +0800, Xi Ruoyao wrote:
> Ping. CC several maintainers who may help to review MIPS patches.
> Sorry if it sounds buzzing.
>
> On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> > Commit message shamelessly copied from 177
PING again.
On Thu, 2021-07-01 at 16:11 +0800, Xi Ruoyao wrote:
> Ping.
>
> On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote:
> > Middle-end started to emit vec_cmp and vec_cmpu since GCC 11,
> > causing
> > ICE on MIPS with MSA enabled. Add the pattern to preven
On Fri, 2021-07-09 at 14:01 +0800, Xi Ruoyao wrote:
> On Thu, 2021-07-08 at 17:20 -0600, Jeff Law wrote:
> >
> > On 7/5/2021 8:04 PM, Paul Hua wrote:
> > > Looks good to me, but I have no right to approve.
> > But your opinions are well respected :-)
> >
On Thu, 2021-07-08 at 17:44 -0600, Jeff Law wrote:
>
>
> On 6/25/2021 8:40 AM, Richard Sandiford wrote:
> > Xi Ruoyao via Gcc-patches writes:
> > > On Fri, 2021-06-25 at 01:02 +0800, Xi Ruoyao wrote:
> > > > On Thu, 2021-06-24 at 10:48 -0600, Jeff Law wro
ing target specific work.
Thanks Paul & Jeff!
I'll edit the ChangeLog a little (PR is now required in ChangeLog)
and commit it then.
--
Xi Ruoyao
Ping.
On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote:
> Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing
> ICE on MIPS with MSA enabled. Add the pattern to prevent it.
>
> Bootstrapped and regression tested on mips64el-linux-gnu.
> Ok for
Ping patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573213.html
Status update: bootstrapped with BOOT_CFLAGS="-O3 -mmsa -mloongson-mmi"
(it failed without the patch), and regtested on mips64el-linux-gnu with
no new regression.
On Sat, 2021-06-19 at 15:34 +0800, Xi Ru
On Tue, 2021-06-29 at 08:53 -0700, Bruce Korb wrote:
> On 6/28/21 10:26 PM, Xi Ruoyao wrote:
> > v3:
> > use memmem/memchr instead of trivial loops
> > split most of the logic into a static function
> > avoid hardcoded magic number
> > adjust te
v3:
use memmem/memchr instead of trivial loops
split most of the logic into a static function
avoid hardcoded magic number
adjust test
fixincludes/
* fixfixes.c (check_has_inc): New static function.
(machine_name_fix): Don't replace header names in
Ping. CC several maintainers who may help to review MIPS patches.
Sorry if it sounds buzzing.
On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> Commit message shamelessly copied from 1777beb6b129 by jakub:
>
> This function, because it is sometimes called even outside of function
v2: match for __has_include explicitly, as it may contains
header name in <...> form.
fixincludes/
* fixfixes.c (machine_name_fix): Don't replace header names in
__has_include(...).
* inclhack.def (machine_name): Adjust test.
* tests/base/testing.h: Update.
---
On Fri, 2021-06-25 at 01:02 +0800, Xi Ruoyao wrote:
> On Thu, 2021-06-24 at 10:48 -0600, Jeff Law wrote:
> > I'd like to know a bit more here. mips.exp shouldn't care about the
> > options passed to the compiler and to the best of my knowledge
> > patch itself is wron
On Thu, 2021-06-24 at 00:05 -0600, Jeff Law wrote:
>
>
> On 6/22/2021 3:44 AM, Xi Ruoyao via Gcc-patches wrote:
> > [Resend because the original subject missed "[PATCH]" and the path
> > in
> > ChangeLog is wrong.]
> >
> > On MIPS a call to __sta
Bootstrapped and regtested on x86_64-linux-gnu. Ok for trunk?
fixincludes/
* fixfixes.c (print_quote): Define it unconditionally, taking
and returning const char *.
(machine_name_fix): Output quoted strings verbatim.
---
fixincludes/fixfixes.c | 30
On Thu, 2021-06-24 at 10:48 -0600, Jeff Law wrote:
>
>
> On 6/22/2021 1:05 AM, Xi Ruoyao via Gcc-patches wrote:
> > mips.exp does not support -fno-inline, causing the tests return
> > "ERROR:
> > Unrecognised option: -fno-inline for dg-options ... ".
>
Commit message shamelessly copied from 1777beb6b129 by jakub:
This function, because it is sometimes called even outside of function
bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order
for that to work, when first referenced, the VAR_DECLs need to appear in a
TARGET_EXPR so
[Resend because the original subject missed "[PATCH]" and the path in
ChangeLog is wrong.]
On MIPS a call to __stack_chk_fail needs an additional .reloc pseudo-op,
so "stack_chk_fail" will appear two times.
gcc/testsuite/
* g++.dg/no-stack-protector-attr-3.C (dg-final): Adjust for
On Tue, 2021-06-22 at 10:37 +0200, Richard Biener wrote:
> On Mon, Jun 21, 2021 at 6:53 PM Xi Ruoyao via Gcc-patches
> wrote:
> >
> > This test relies on wrap behavior of signed overflow. Without -
> > fwrapv
> > it is known to fail on mips (and maybe some other
On MIPS a call to __stack_chk_fail needs an additional .reloc pseudo-op,
so "stack_chk_fail" will appear two times.
gcc/testsuite/
* no-stack-protector-attr-3.C (dg-final): Adjust for MIPS.
---
gcc/testsuite/g++.dg/no-stack-protector-attr-3.C | 3 ++-
1 file changed, 2 insertions(+), 1
mips.exp does not support -fno-inline, causing the tests return "ERROR:
Unrecognised option: -fno-inline for dg-options ... ".
Use noinline attribute like other mips target tests, to workaround it.
gcc/testsuite/
* gcc.target/mips/cfgcleanup-jalr2.c: Remove -fno-inline and add
This test relies on wrap behavior of signed overflow. Without -fwrapv
it is known to fail on mips (and maybe some other targets as well).
gcc/testsuite/
* gcc.c-torture/execute/950704-1.c: Add -fwrapv to avoid
undefined behavior.
---
Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing
ICE on MIPS with MSA enabled. Add the pattern to prevent it.
Bootstrapped and regression tested on mips64el-linux-gnu.
Ok for trunk?
gcc/
* config/mips/mips-protos.h (mips_expand_vec_cmp_expr): Declare.
*
Check if the vector mode is really supported by MSA in certain cases,
instead of testing ISA_HAS_MSA. Simply testing ISA_HAS_MSA can cause
ICE when MSA is enabled besides other MIPS SIMD extensions (notably,
Loongson MMI).
Bootstrapped and tested on mips64el-linux-gnu. OK to commit?
gcc/
On 2021-02-16 11:59 +0800, Xi Ruoyao wrote:
> On 2021-02-15 16:16 -0700, Jeff Law wrote:
> >
> >
> > On 2/12/21 7:17 AM, Xi Ruoyao wrote:
> > > On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> > > > Hi Jeff and Jakub,
> > > >
> > > >
On 2021-02-15 16:16 -0700, Jeff Law wrote:
>
>
> On 2/12/21 7:17 AM, Xi Ruoyao wrote:
> > On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> > > Hi Jeff and Jakub,
> > >
> > > On 2021-01-04 14:19 -0700, Jeff Law wrote:
> > > > On 1/4/21 2:00 P
Nope. I can't reach Robert, so CC MIPS maintainer.
On 2021-02-12 22:57 +0800，Xi Ruoyao wrote:
> Well, it just dislike my mail server :(. Switch to the mail server of my
> university.
>
> On 2021-02-12 22:54 +0800, Xi Ruoyao wrote:
> > Resend the mail. I had to fill in a
Well, it just dislike my mail server :(. Switch to the mail server of my
university.
On 2021-02-12 22:54 +0800, Xi Ruoyao wrote:
> Resend the mail. I had to fill in a form to send mail to Robert.
>
> On 2021-02-12 22:17 +0800, Xi Ruoyao wrote:
> > On 2021-01-11 01:01 +0800,
Resend the mail. I had to fill in a form to send mail to Robert.
On 2021-02-12 22:17 +0800, Xi Ruoyao wrote:
> On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> > Hi Jeff and Jakub,
> >
> > On 2021-01-04 14:19 -0700, Jeff Law wrote:
> > > On 1/4/21 2:00 PM, Jakub Jeli
On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> Hi Jeff and Jakub,
>
> On 2021-01-04 14:19 -0700, Jeff Law wrote:
> > On 1/4/21 2:00 PM, Jakub Jelinek wrote:
> > > On Mon, Jan 04, 2021 at 01:51:59PM -0700, Jeff Law via Gcc-patches wrote:
> > > > > S
On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> CC Robert to get some help.
Unfortunately Robert's mail in MAINTAINER file seems no longer valid :(.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
gcc/ChangeLog:
> > > >
> > > > 2020-12-31 Xi Ruoyao
> > > >
> > > > PR target/98491
> > > > * config/mips/mips.c (mips_symbol_insns): Do not use
> > > > MSA_SUPPORTED_MODE_P
On 2021-01-01 07:29 +0800, Xi Ruoyao wrote:
> An invalid use of MSA_SUPPORTED_MODE_P is causing ICE on mips64el with -mmsa.
> The detailed analysis is posted on bugzilla:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491
>
> The attached patch fixes this issue by handlin
since I'm not a subscriber.
And, I don't have GIT write access.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 58e474e063d..8f80dcfada8 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
suite/ext/pb_ds/example/tree_order_statistics_join.cc:
Likewise.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
From c0ee85f492872ba164ad3c1c9636aace1de02e96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?X=E2=84=B9=20Ruoyao?=
Date: Sun, 12 Jul 2020 16:12:18 +080
_::operator[]): Likewise.
(bin_search_tree_const_it_::iterator_category):
Change to std::random_access_iterator_tag.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
From 5149d3156b0b1ae5d8cf82c54d041bd47451c995 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?X=E2=84=B9=20Ruoyao?=
ee_/split_join_fn_imps.hpp
(split_finish): Use maintained size, instead of calling
std::distance.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
From 4434da1b2b45797204f4fd978dcc4fbba4b17c6e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?X=E2=84=B9=20Ruoyao?=
D
AME::update_subtree_size): Declare new member
function.
* include/ext/pb_ds/detail/bin_search_tree_/rotate_fn_imps.hpp
(update_subtree_size): Define.
(apply_update, update_to_top): Call update_subtree_size.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xid
stdc++-v3/ChangeLog:
* include/ext/pb_ds/detail/bin_search_tree_/insert_fn_imps.hpp
(insert_leaf_new, insert_imp_empty): remove redundant statements.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
From 4eea45261ebf974ddf02f6154166c5cb6aa180da Mon Sep 17
rch_tree_/insert_fn_imps.hpp
(insert_leaf_new, insert_imp_empty): remove redundant statements.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
From 4eea45261ebf974ddf02f6154166c5cb6aa180da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?X=E2=84=B9=20Ruoyao?=
Date: Fri, 10 Jul 2
. GCC
does not use pb_ds so it should be unnecessary to run a bootstrap.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On 2019-12-19 19:12 +0800, Xi Ruoyao wrote:
> On 2019-12-19 11:06 +0100, Jan Hubicka wrote:
> > - /* See if we have linker information about symbol not being used or
> > - if we need to make guess based on the declaration.
> > + /* Limitation of gas requires us to out
r clams the symbol is unused, never bring internal
> - symbols that are declared by user as used or externally visible.
> - This is needed for i.e. references from asm statements. */
> - if (used_from_object_file_p ())
> -return true;
Are these two lines removed intentionally?
>if (reso
2. Add some mangled symbol name in GCC (like ".LSYMVERx" or
"foo_v2.symver_export").
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ymbol, it will inline
> calls to it and do other things), while in the second case we need to
> treat foo_v2 specially.
> > So if it's safe we can force a ".globl foo_v2" before ".symver foo_v2,
> > foo@@VERS_2". But I can't prove it's safe so I think it's better to
> > consider
> > this case in cgraph_externally_visible_p.
>
> It sort of makes things work, but for example it will prevent gcc from
> inlining calls to foo_v2. I think we will still need to do something
> about -fvisibility=hidden.
>
> It is sad that we do not have way to produce symbol version without a
> corresponding symbol of global visiblity. If we had we could support
> multiple symver aliases from one symbol and avoid the need to explicitly
> hide the unnecesary symbols in the map files...
Explicitly hiding the unnecessary symbols in map files is now how we handle this
[with __asm__(".symver foo_v2, foo@@VERS_2")]. We can continue to do in this
way and leave it as an enhancement.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
believe we should consider symver targets to be externally visible in
cgraph_externally_visible_p. There is a comment saying "if linker counts on us,
we must preserve the function". That's true in our case.
And, I think
.globl .LSYMVER0
.set.LSYMVER0, foo_v2
.symver .LSYMVER0, foo@@VERS_2
is
erminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:4: obj/test.so] Error 1
The change to lto/lto-common.c makes sense. I tried it instead of my change to
cgraph.h and everything is OK. I'll investigate the change to varasm.c a
little.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
sion
script). And foo (VERS_2) would be missing. With this patch foo (VERS_2) would
show up.
We can't mark "foo_v2" to be "global" because it should not be a part of DSO
ABI.
The other 1% chance would be a regression in Binutils.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
pr48200.tar.gz
Description: application/compressed-tar
an be built with LTO enabled and no problem.
I'll test symver patch and this patch with more packages.
Bootstrapped/regtested x86_64-linux. I'm not a maintainer.
gcc/ChangeLog:
2019-12-17 Xi Ruoyao
* cgraph.h (symtab_node::used_from_object_file_p): Symver nodes are
part of DS
On 2017-08-24 20:17 +0800, Xi Ruoyao wrote:
> On 2017-08-22 10:17 +0200, Richard Biener wrote:
> >
> > Ok for the gcc 7 branch.
> >
>
> Well, I think I should say I don't have SVN write access...
Still not installed. Make a rediff.
We don't have a Cilk mainta
On 2017-08-22 10:17 +0200, Richard Biener wrote:
>
> Ok for the gcc 7 branch.
>
Well, I think I should say I don't have SVN write access...
--
Xi Ruoyao <r...@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
On 2017-08-21 23:37 +0800, Xi Ruoyao wrote:
> On 2017-04-25 09:30 -0600, Jeff Law wrote:
> > On 04/14/2017 06:44 PM, Xi Ruoyao wrote:
> > > On 2017-04-14 15:00 +0800, Xi Ruoyao wrote:
> > > > On 2017-04-13 09:05 +0200, Richard Biener wrote:
> > > >
&g
On 2017-04-25 09:30 -0600, Jeff Law wrote:
> On 04/14/2017 06:44 PM, Xi Ruoyao wrote:
> > On 2017-04-14 15:00 +0800, Xi Ruoyao wrote:
> > > On 2017-04-13 09:05 +0200, Richard Biener wrote:
> > >
> > > > Did you verify LTO bootstrap still works with the p
On 2017-06-19 12:44 -0600, Martin Sebor wrote:
> On 06/19/2017 11:28 AM, Xi Ruoyao wrote:
> > On 2017-06-19 10:51 -0600, Martin Sebor wrote:
> > > On 06/11/2017 07:32 PM, Xi Ruoyao wrote:
> > > > This patch adds warning option -Wstring-plus-int for C/C++.
On 2017-06-19 12:44 -0600, Martin Sebor wrote:
> On 06/19/2017 11:28 AM, Xi Ruoyao wrote:
> > On 2017-06-19 10:51 -0600, Martin Sebor wrote:
> > > On 06/11/2017 07:32 PM, Xi Ruoyao wrote:
> > > > This patch adds warning option -Wstring-plus-int for C/C++.
801 - 900 of 936 matches
Mail list logo
