This patch moves prototype of char_type_p into c-common.h, so we can
use it in c-family/*.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao <r...@stu.xidian.edu.cn>
* c-family/c-common.h (char_type_p): New prototype
* c/c-typeck.c (char_type_p): Make the function extern
*
Hi,
I've implemented -Wstring-plus-int (like the one in CLANG) for GCC. I've
bootstrapped GCC with my patches and runned dejaGNU tests.
My patches are for both C and C++ (like CLANG).
Unlike CLANG, this option is not enabled by default (or GCC won't
bootstrap with -Werror).
Xi Ruoyao (5
This patch adds warning option -Wstring-plus-int for C.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao <r...@stu.xidian.edu.cn>
* c/c-typeck.c (parser_build_binary_op, build_modify_expr): checking
for -Wstring-plus-int
---
gcc/c/c-typeck.c | 28
1 file chang
This patch adds document of -Wstring-plus-int.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao <r...@stu.xidian.edu.cn>
* doc/invoke.texi (Warning Options): Document -Wstring-plus-int
---
gcc/doc/invoke.texi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/g
This patch adds tests for -Wstring-plus-int.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao <r...@stu.xidian.edu.cn>
* testsuite/c-c++-common/Wstring-plus-int.c: New test
* testsuite/g++.dg/Wstring-plus-int-1.C: New test
* testsuite/g++.dg/Wstring-plus-int-2.C: Ne
This patch adds warning option -Wstring-plus-int for C++.
gcc/ChangeLog:
2017-02-22 Xi Ruoyao <r...@stu.xidian.edu.cn>
* c-family/c-common.h (maybe_warn_string_plus_int): new prototype
* c-family/c-warn.h (maybe_warn_string_plus_int): new function
* c-family/c-op
lly
> the description is correct, since character constants are integers.
>
> Perhaps add something like
>
> "A typical example this warns about is @samp{"abc" + 'd'}."
>
> ?
Thanks for the advise. I'll make it clear and resubmit the patches
in early s
and copying with function call).
The pedigree operations are merged into built-in __cilkrts_detach (just like
libcilkrts cilk_fake.h).
Bootstrapped and regtested on x86_64-linux-gnu.
The patch has 500+ lines so I attach it. ChangeLog is pasted here:
2017-03-24 Xi Ruoyao <r...@stu.xidian.edu.cn
On 2017-03-24 05:26 +0800, Xi Ruoyao wrote:
> The patch has 500+ lines so I attach it. ChangeLog is pasted here:
Damn it... I attached the draft of patch where some useless functions had
not been removed.
This time the attachment is correct.
> 2017-03-24 Xi Ruoyao <r...@stu.xidi
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 patch?
>
> I've just done a LTO bootstrapp (boarding a train :) ).
> It works with my patch.
I've done dejagnu tests
On 2017-04-13 09:05 +0200, Richard Biener wrote:
> Did you verify LTO bootstrap still works with the patch?
I've just done a LTO bootstrapp (boarding a train :) ).
It works with my patch.
--
Xi Ruoyao <r...@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
Hi,
The ill-formed checking in binary_heap::push_heap has made it
O(n). Remove this checking.
Since assert_valid also checks if (*this) is a legal heap, we can
remove is_heap and the assertions using it completely.
Bootstrapped and tested on x86_64-linux-gnu.
2017-03-09 Xi Ruoyao &l
and tested on x86_64-linux-gnu.
2017-03-09 Xi Ruoyao <r...@stu.xidian.edu.cn>
PR libstdc++/62045:
* include/ext/pb_ds/qdetail/binary_heap_/binary_heap_.hpp
(is_heap): Remove.
(push_heap): Remove the wrong checking using is_heap.
(make_heap):
.
Bootstrapped/regtested on x86_64-linux-gnu. Is this ok for trunk?
2017-03-06 Xi Ruoyao <r...@stu.xidian.edu.cn>
PR rtl-optimization/79728
* reginfo.c (init_reg_sets_1): Use fixed_nonglobal_reg_set
(instead of fixed_regs) to deduce ok_regs.
* gcc.targe
ot;middle-end".
Maybe we should reclassify PR 80038 and modify the ChangeLog as well.
This patch has been bootstrapped and regtested in x86_64-linux-gnu. Is it
OK for trunk?
--
Xi Ruoyao <r...@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
From dfbce2c4
my patch ICEed with _Cilk_spawn and
-flto -O3 -fcilkplus since __cilkrts_stack_frame.ctx's type (array of void *)
was not TYPE_STRUCTURAL_EQUALITY_P in lto stage.
If this change is not proper, I'll work on modifying my patch to work
without touching in_lto_p.
--
Xi Ruoyao <r...@stu.xidian.ed
tch. I'm not keen on
> the way we stash away the arguments into orig_argX. Perhaps he's got a
> better suggestion.
In the recent version of Clang, this warning options has been seperated
into two options -Wstring-plus-int and -Wstring-plus-char. Maybe I should
do the same.
-
On 2017-04-28 08:42 -0600, Jeff Law wrote:
> On 04/28/2017 08:31 AM, Xi Ruoyao wrote:
> > Should I prepare (re-diff) a patch for current trunk?
> If you want for the trunk, yes.
Rediff for current GCC trunk.
--
Xi Ruoyao <r...@stu.xidian.edu.cn>
School of Aerospace Science and
er it's been on the trunk for at least a week.
>
I just noticed GCC 7.0 has been frozen.
--
Xi Ruoyao <r...@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
This patch use ioctl to get entropy of std::random_device using
/dev/random and /dev/urandom.
Regenerated files are mentioned in ChangeLog but not included
in the patch.
2017-03-12 Xi Ruoyao <r...@stu.xidian.edu.cn>
PR libstdc++/67578
* config.h.in: Rege
This UB has been hiding so long...
2017-03-11 Xi Ruoyao <r...@stu.xidian.edu.cn>
PR libstdc++/67214
* include/bits/locale_facets.tcc (_M_extract_int):
Add explicit conversion to avoid signed overflow.
---
libstdc++-v3/include/bits/locale_facets.tcc | 3 ++-
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 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++.
> >
> > gcc/ChangeLog:
> >
> > 2017-06-12 Xi Ruoyao <r...@stu.xidian.edu.cn>
> >
> >
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 10:30 -0600, Martin Sebor wrote:
> On 06/11/2017 07:34 PM, Xi Ruoyao wrote:
> > This patch adds warning option -Wstring-plus-char for C/C++.
> >
>
> +void
> +warn_if_string_plus_char (location_t loc, tree ptrtype, tree inttype)
> +{
>
On 2017-05-19 15:38 +0100, Jonathan Wakely wrote:
> On 18/05/17 19:10 +0800, Xi Ruoyao wrote:
> > This UB has been hiding so long...
>
> Indeed! Thanks for the patch.
>
> > 2017-03-11 Xi Ruoyao <r...@stu.xidian.edu.cn>
> >
> > PR libstdc++/6721
On 2017-05-22 14:00 +0100, Jonathan Wakely wrote:
> On 18/05/17 19:27 +0800, Xi Ruoyao wrote:
> > This patch use ioctl to get entropy of std::random_device using
> > /dev/random and /dev/urandom.
>
> This is a nice addition, thanks.
>
> N.B. I couldn't apply your patc
On 2017-05-22 14:50 +0100, Jonathan Wakely wrote:
> On 22/05/17 21:41 +0800, Xi Ruoyao wrote:
> > On 2017-05-22 14:00 +0100, Jonathan Wakely wrote:
> > > On 18/05/17 19:27 +0800, Xi Ruoyao wrote:
> > > > This patch use ioctl to get entropy of std::random_device usin
On 2017-05-22Mon的 14:50 +0100, Jonathan Wakely wrote:
> On 22/05/17 21:41 +0800, Xi Ruoyao wrote:
> > On 2017-05-22 14:00 +0100, Jonathan Wakely wrote:
> > > On 18/05/17 19:27 +0800, Xi Ruoyao wrote:
> > > > This patch use ioctl to get entropy of std::random_de
or by -Wall/-Wextra later.
Xi Ruoyao (6):
Move char_type_p prototype into c-common.h
New warning option -Wstring-plus-int
New warning option -Wstring-plus-char
New tests for -Wstring-plus-int
New tests for -Wstring-plus-char
Document new warning options
gcc/c-family/c-common.c
This patch adds tests for -Wstring-plus-int.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao <r...@stu.xidian.edu.cn>
* testsuite/c-c++-common/Wstring-plus-int.c: New test.
* testsuite/g++.dg/Wstring-plus-int-1.C: Ditto.
* testsuite/g++.dg/Wstring-plus-int-2.C: Ditto.
--
This patch adds tests for -Wstring-plus-char.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao <r...@stu.xidian.edu.cn>
* testsuite/c-c++-common/Wstring-plus-char.c: New test.
* testsuite/g++.dg/Wstring-plus-char-1.C: Ditto.
* testsuite/g++.dg/Wstring-plus-char-2.C:
This patch adds document of -Wstring-plus-int and -Wstring-plus-char.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao <r...@stu.xidian.edu.cn>
* doc/invoke.texi (Warning Options): Document -Wstring-plus-int
and -Wstring-plus-char.
---
gcc/doc/invoke.texi | 22 +++
This patch moves prototype of char_type_p into c-common.h, so we can
use it in c-family/*.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao <r...@stu.xidian.edu.cn>
* c-family/c-common.h (char_type_p): New prototype.
* c/c-typeck.c (char_type_p): Make the function extern.
*
This patch adds warning option -Wstring-plus-char for C/C++.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao <r...@stu.xidian.edu.cn>
* c-family/c-common.h (warn_if_string_plus_char): New prototype.
* c-family/c-warn.c (warn_if_string_plus_char): New function.
* c-family
This patch adds warning option -Wstring-plus-int for C/C++.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao <r...@stu.xidian.edu.cn>
* c-family/c.opt: New option -Wstring-plus-int.
* c-family/c-common.c (pointer_int_sum): Checking for
-Wstring-plus-int.
---
gcc/c-fa
On 2017-06-12 09:26 +0800, Xi Ruoyao wrote:
> Hi,
>
> I've implemented -Wstring-plus-int and -Wstring-plus-char (like their
> counterpart in Clang) for GCC.
>
> This series of patch has been bootstrapped and regtested. OK for trunk?
>
> Currently these options are not
t; ../../gcc/c-family/cilk.c:115:9: note: in expansion of macro 'EXPR_CILK_SPAWN'
> EXPR_CILK_SPAWN (TREE_OPERAND (fcall, 1)) = 1;
> ^
>
> Andreas.
>
Sorry T_T. I've made a stupid mistake in tree.h.
Let's apply following patch, and alert the RM wh
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
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
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
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
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
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
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
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,
During the review of a LLVM change [1], on LA464 we found that zeroing
a fcc with fcmp.caf.s is much faster than a movgr2cf from $r0.
[1]: https://github.com/llvm/llvm-project/pull/69300
gcc/ChangeLog:
* config/loongarch/loongarch.md (movfcc): Use fcmp.caf.s for
zeroing a fcc.
On Tue, 2023-11-07 at 19:10 +0800, Xi Ruoyao wrote:
> On Tue, 2023-11-07 at 12:06 +0800, chenxiaolong wrote:
> > +__m128i a,b,c;
> > +
> > +__asm__ ("vadd.d %w0,%w1,%w2\n\t"
> > + :"=f" (c)
> > + :"f" (a),"f" (b)
&g
1.c:6:1: error: inconsistent operand constraints in an ‘asm’
6 | __asm__ ("vadd.d %w0,%w1,%w2\n\t"
Please recheck.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Pushed r14-5030. The subject and ChangeLog are updated to include the
PR number. The code change is same as v1.
On Mon, 2023-10-30 at 20:44 +0800, chenglulu wrote:
>
> 在 2023/10/30 下午8:26, Xi Ruoyao 写道:
> > On Mon, 2023-10-30 at 19:50 +0800, chenglulu wrote:
> > > 在
On Mon, 2023-10-30 at 19:50 +0800, chenglulu wrote:
> 在 2023/10/30 下午7:42, Xi Ruoyao 写道:
> > Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure
> > building a cross compiler if the cross assembler is not installed yet.
> >
> > gcc/ChangeLog:
>
Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure
building a cross compiler if the cross assembler is not installed yet.
gcc/ChangeLog:
* config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0
if not defined yet.
---
Ok for trunk?
fld and fst have same address mode as ld.w and st.w, so the same
optimization as r14-4851 should be applied for them too.
gcc/ChangeLog:
* config/loongarch/loongarch.md (LD_AT_LEAST_32_BIT): New mode
iterator.
(ST_ANY): New mode iterator.
(define_peephole2): Use
As the commit message of r14-4674 has indicated, if the assembler does
not support conditional branch relaxation, a relocation overflow may
happen on conditional branches when relaxation is enabled because the
number of NOP instructions inserted by the assembler will be more than
the number
This is isomorphic to the LLVM changes [1-2].
On LoongArch, the LL and SC instructions has memory barrier semantics:
- LL: +
- SC: +
But the compare and swap operation is allowed to fail, and if it fails
the SC instruction is not executed, thus the guarantee of acquiring
semantics cannot be
_push (state.defs_list[0]);
> }
> reinsn_del_list.safe_push (curr_cand->insn);
> state.modified[INSN_UID (curr_cand->insn)].deleted = 1;
> @@ -1345,6 +1483,10 @@ find_and_remove_re (void)
> for (unsigned int i = 0; i < reinsn_copy_list.length (); i +=
sx { } {
> + return [check_no_compiler_messages loongarch_asx assembly {
> + #if !defined(__loongarch_asx)
> + #error "LASX not defined"
> + #endif
> + }]
> +}
> +
> # Appends necessary Python flags to extra-tool-flags if Python.h is
> supported.
> # Otherwise, modifies dg-do-what.
> proc dg-require-python-h { args } {
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
mscratch.org/lfs/view/development/chapter08/gcc.html
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
When I added copysign support for LoongArch (r13-3702), we did not have
a copysign RTL insn, so I had to use UNSPEC to represent the copysign
instruction. Now the copysign RTX code has been added in r14-1586, so
this patch removes those UNSPECs, and it uses the native RTL copysign
insn.
Inspired
gcc/ChangeLog:
* doc/invoke.texi: Update -m[no-]explicit-relocs for r14-4160.
---
I've not regtested this as it's only a doc change. Ok for trunk?
gcc/doc/invoke.texi | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/invoke.texi
On Mon, 2023-09-25 at 16:26 +0800, chenglulu wrote:
> LGTM!
>
> Thank you for your modification!
Pushed r14-4250.
> 在 2023/9/25 下午4:13, Xi Ruoyao 写道:
> > gcc/ChangeLog:
> >
> > * doc/invoke.texi: Update -m[no-]explicit-relocs for r14-4160.
> > ---
>
or isa options, but pr104992.c failed because
> it expected result with "vect_int_mod returns 1" but it was compiled
> without -mlsx/-mlasx. Seems pr104992.c is invoked by gcc.dg/dg.exp,
> pr104992.c is not affected by DEFAULT_CFLAGS, so we still need to check
> if LSX/LASX is available in vect_int_mod.
>
> Other parts of new patch is still WIP.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
using g++ 4.8 as a host compiler.
AFAIK G++ 5.1 also has a bug (https://gcc.gnu.org/PR65801) breaking
building recent GCC. I don't think it's really "maintainable" to ensure
current GCC able to be built with a buggy host compiler.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
o.
>
> P.S. Currently support for "f32" is not active, and it should probably be
> avoided if you want to build a working rootfs.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2023-10-18 at 09:34 +0800, chenglulu wrote:
>
> 在 2023/10/17 下午10:24, WANG Xuerui 写道:
> >
> > On 10/17/23 22:06, Xi Ruoyao wrote:
> > > During the review of a LLVM change [1], on LA464 we found that zeroing
> > "an" LLVM change (because t
The linker does not know how to relax TLS access for LoongArch, so let's
emit machine instructions with explicit relocs for TLS.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_explicit_relocs_p):
Return true for TLS symbol types if -mexplicit-relocs=auto.
gcc/ChangeLog:
* doc/invoke.texi (-mexplicit-relocs=style): Document.
(-mexplicit-relocs): Document as an alias of
-mexplicit-relocs=always.
(-mno-explicit-relocs): Document as an alias of
-mexplicit-relocs=none.
(-mcmodel=extreme): Mention
the compiler to use explicit relocs
for these cases, but assembler macros for other cases. Use it as the
default if the assembler supports both explicit relocs and relaxation.
LTO-bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
Xi Ruoyao (5):
LoongArch: Add enum-style
To take a better balance between scheduling and relaxation when -flto is
enabled, add three-way -mexplicit-relocs={auto,none,always} options.
The old -mexplicit-relocs and -mno-explicit-relocs options are still
supported, they are mapped to -mexplicit-relocs=always and
-mexplicit-relocs=none.
The
If we are performing LTO for a final link and linker plugin is enabled,
then we are sure any GOT access may resolve to a symbol out of the link
unit (otherwise the linker plugin will tell us the symbol should be
resolved locally and we'll use PC-relative access instead).
Produce machine
In these cases, if we use explicit relocs, we end up with 2
instructions:
pcalau12it0, %pc_hi20(x)
ld.d t0, t0, %pc_lo12(x)
If we use la.local pseudo-op, in the best scenario (x is in +/- 2MiB
range) we still have 2 instructions:
pcaddi t0, %pcrel_20(x)
ld.d
external symbol c, the linker may relax "la.global c" to "la.local c"
(if ab.o is linked together with another file c.o which contains the
definition of c) or not. As we cannot exclude the possibility of a
relaxation on la.global for incremental linking, just emit la.global and
let the
Pushed r14-{4848..4852}.
On Thu, 2023-10-19 at 22:02 +0800, Xi Ruoyao wrote:
> For relaxation we are now generating assembler macros for symbolic
> addresses everywhere, but this is limiting scheduling and there are
> known situations where the relaxation cannot improve the code.
>
quot;)
(unspec:DI [(match_dup 2) (pc)] UNSPEC_LA_PCREL_64_PART2))]
With this the buggy REG_UNUSED notes were gone. But it then prevented
the CSE when loading the address of __tls_get_addr (i.e. if we address
10 TLE_LD symbols in a function it would emit 10 instances of "la.global
__tls_get
Binutils 2.42 supports TLS LD/GD relaxation which requires the assembler
macro.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_explicit_relocs_p):
If la_opt_explicit_relocs is EXPLICIT_RELOCS_AUTO, return false
for SYMBOL_TLS_LDM and SYMBOL_TLS_GD.
On Wed, 2024-01-24 at 19:08 +0800, chenxiaolong wrote:
> At 19:00 +0800 on Wednesday, 2024-01-24, Xi Ruoyao wrote：
> > On Wed, 2024-01-24 at 18:32 +0800, chenxiaolong wrote:
> > > On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote：
> > > > The vect_int_mo
On Wed, 2024-01-24 at 18:32 +0800, chenxiaolong wrote:
> On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote：
> > The vect_int_mod target selector is evaluated with the options in
> > DEFAULT_VECTCFLAGS in effect, but these options are not automatically
> > passed to
n __inline float
> __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> __frecipe_s (float _1)
> {
> - __builtin_loongarch_frecipe_s ((float) _1);
> + return (float) __builtin_loongarch_frecipe_s ((float) _1);
I don't think the (float) conversion is needed.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Mon, 2024-02-05 at 09:56 +0800, YunQiang Su wrote:
> Xi Ruoyao 于2024年2月5日周一 02:01写道：
> >
> > We expanded (neg x) to (minus const0 x) for MSA FP vectors, this is
> > wrong because -0.0 is not 0 - 0.0. This causes some Python tests to
> > fail when Pytho
Recently I've fixed two wrong FP vector negate implementation which
caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To
prevent a similar issue from happening again, add a test case.
Tested on x86_64 (with SSE2, AVX, AVX2, and AVX512F), AArch64, MIPS
(with MSA), LoongArch
On Fri, 2024-02-09 at 00:02 +0800, chenglulu wrote:
>
> 在 2024/2/7 上午12:23, Xi Ruoyao 写道:
> > Hi Lulu,
> >
> > I'm proposing to backport r14-4674 "LoongArch: Delete macro definition
> > ASM_OUTPUT_ALIGN_WITH_NOP." to releases/gcc-12 and releases/gcc-13
On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote:
> On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote:
>
> > So I think that without worrying about performance and ensuring that
> > there is no problem
> >
> > with binutils, I think we can ma
test failures due to "excessive
errors" if running the GCC test suite with these earlier GAS versions.
Maybe we'll have to add some autoconf-based probing for the linker
anyway?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2024-02-20 at 19:50 +0800, chenglulu wrote:
>
> 在 2024/2/20 下午7:31, Xi Ruoyao 写道:
> > On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote:
> > > On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote:
> > >
> > > > So I think that witho
The gold linker has never been ported to LoongArch (and it seems
unlikely to be ported in the future as the new architectures are
focusing on lld and/or mold for fast linkers).
ChangeLog:
* configure.ac (ENABLE_GOLD): Remove loongarch*-*-* from target
list.
* configure:
On Tue, 2024-02-06 at 17:55 +0800, Xi Ruoyao wrote:
> Recently I've fixed two wrong FP vector negate implementation which
> caused wrong sign bits in zeros in targets (r14-8786 and r14-8801). To
> prevent a similar issue from happening again, add a test case.
>
> Tested on x86_64
eases/gcc-12 and releases/gcc-13
then?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
n Uecker has pointed out the alignment may be different
with the different order of arguments, per C23 (N2293). With earlier
versions of the standard some people believe the alignment should not be
different, while the other people disagree (as the text is not very
clear).
--
Xi Ruoyao
Sch
gcc/ChangeLog:
* config/loongarch/loongarch.md (rotl3):
New define_expand.
* config/loongarch/simd.md (vrotl3): Likewise.
(rotl3): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/rotl-with-rotr.c: New test.
*
With simplify_gen_unary we end up with a not fully expanded RTX like
(set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63)))
Then it will cause an ICE with unrecognizable insn.
gcc/ChangeLog:
PR middle-end/113033
* expmed.cc (expand_shift_1): When expanding rotate
ac93f execute
> ../../gcc/gcc/ira.cc:6161
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
I've looked e.g. at i386 vec_init and that is exactly what it does,
> see the various tests + force_reg calls in ix86_expand_vector_init*.
Ok, I'm abandoning abandon this patch and I'll rework.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Mon, 2023-12-18 at 18:45 +0100, Jakub Jelinek wrote:
> On Tue, Dec 19, 2023 at 12:48:46AM +0800, Xi Ruoyao wrote:
> > > > gcc/ChangeLog:
> > > >
> > > > PR middle-end/113033
> > > > * expmed.cc (expand_shift_1): When expa
On Mon, 2023-12-18 at 08:39 -0700, Jeff Law wrote:
>
>
> On 12/18/23 06:42, Xi Ruoyao wrote:
> > With simplify_gen_unary we end up with a not fully expanded RTX like
> >
> > (set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63)))
> &g
up is separated into the 2nd patch to make reviewing
easier.
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
Xi Ruoyao (2):
LoongArch: Use force_reg instead of gen_reg_rtx + emit_move_insn in
vec_init expander [PR113033]
LoongArch: Clean up vec_init expander
gcc
1 - 100 of 921 matches
Mail list logo
