> - ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)
> -#define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
> - ((VALUE) = GET_MODE_UNIT_BITSIZE (MODE), 2)
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
ption{-fno-trapping-math}.
> +Note that while the throughput of the sequence is higher than the throughput
> of
> +the non-reciprocal instruction, the precision of the sequence can be
> decreased
> +by up to 2 ulp (i.e. the inverse of 1.0 equals 0.9994).
> +
> +@opindex mreci
On Wed, 2023-11-29 at 10:23 +0800, Jiahao Xu wrote:
>
> 在 2023/11/29 上午10:08, Xi Ruoyao 写道:
> > On Tue, 2023-11-28 at 11:29 +0800, Jiahao Xu wrote:
> > > diff --git a/gcc/config/loongarch/predicates.md
> > > b/gcc/config/loongarch/predicates.md
> > >
On Mon, 2023-11-20 at 08:47 +0800, Xi Ruoyao wrote:
> The [1/5] patch is the PR112578 fix at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html.
> It has been changed to remove the nearbyint pattern (because nearbyint
> should not raise FE_INEXACT even if -ffp
extend.c.
Should I change something in LoongArch backend in order to make ext_dce
work for mem-extend.c too? If yes then any pointers?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
> (loongarch_try_expand_lsx_vshuf_const): Adjust.
> (loongarch_is_extraction_permutation): Adjust.
> (loongarch_expand_vec_perm_const_2): Adjust.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/loongarch/lasx-extract-even_odd-opt.c: New test.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2023-11-29 at 17:33 +0800, Xi Ruoyao wrote:
> On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote:
> > This has (of course) been tested on rv64. It's also been bootstrapped
> > and regression tested on x86. Bootstrap and regression tested (C only)
> > for m68k, s
On Wed, 2023-11-29 at 20:37 +0800, Xi Ruoyao wrote:
> On Wed, 2023-11-29 at 17:33 +0800, Xi Ruoyao wrote:
> > On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote:
> > > This has (of course) been tested on rv64. It's also been bootstrapped
> > > and regressi
Recently there are some people building GCC with srcdir == objdir and
the attempts just failed [1]. So stop to say "it should work". OTOH
objdir as a subdirectory of srcdir works (at least for LFS [2] and BLFS
[3]).
[1]: https://gcc.gnu.org/pipermail/gcc-help/2023-November/143068.html
[2]: https
copy_list.safe_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_c
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
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 b/gcc/doc/invoke.tex
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
://www.linuxfromscratch.org/lfs/view/development/chapter08/gcc.html
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
slow.
Could you suggest how to fix this issue?
On Thu, 2024-06-20 at 14:34 +0100, Richard Sandiford wrote:
> This series is a resubmission of the late-combine work. I've fixed
> some bugs that Jeff's cross-target CI found last time and some others
> that I hit since then.
/* s
On Fri, 2024-06-28 at 20:34 +0800, chenglulu wrote:
>
> 在 2024/6/28 下午8:25, Xi Ruoyao 写道:
> > Hi Richard,
> >
> > The late combine pass has triggered some FAILs on LoongArch and I'm
> > investigating. One of them is movcf2gr-via-fr.c. In
> > 315r.
cmp = gen_rtx_NE (SImode, tmp, const0_rtx);
emit_insn (gen_cstoresi4 (operands[0], cmp, tmp, const0_rtx));
DONE;
})
and remove the necessity of UNSPEC_ISFINITE.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
h_cost->movgr2cf;
Then we don't need to check TARGET_uARCH_LA464.
> + }
> + }
> + return cost;
> +}
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
anyway: https://godbolt.org/z/bnnGf3a38 and the
standards only require a non-zero return value if the input is infinite
(positive or negative).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
doc SImode is required. At least the doc should be updated
to say "operand 0 has an integer mode" or something if doing so is
intentionally allowed.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Ping^5 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let's fix them.
>
> Tested on x86_
On Tue, 2024-07-09 at 16:33 -0700, Vineet Gupta wrote:
>
>
> On 7/9/24 16:23, Jeff Law wrote:
> >
> > On 7/9/24 5:08 PM, Vineet Gupta wrote:
> > > On 7/3/24 12:08, Xi Ruoyao wrote:
> > > > On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
> &
On Tue, 2024-07-09 at 16:10 -0700, Vineet Gupta wrote:
> On 7/3/24 21:35, Xi Ruoyao wrote:
> > On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote:
> > > - Don't hardcode SI in patterns, try to keep X to avoid potential
> > > sign extension pitfalls. Imple
ass.s$f0,$f0
movfr2gr.s $r4,$f0
andi$r12,$r4,136
andi$r13,$r4,952
sltu$r12,$r0,$r12
sltu$r13,$r0,$r13
slli.w $r13,$r13,2
andi$r4,$r4,68
slli.w $r12,$r12,1
or $r12,$r12,$r13
sltu$r4,$r0,$r4
or $r4,$r4,$r12
andi$r4,$r4,7 # < Why we need this?!
jr $r1
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Tue, 2024-07-09 at 20:21 -0600, Jeff Law wrote:
>
>
> On 7/9/24 8:14 PM, Xi Ruoyao wrote:
> > On Tue, 2024-07-09 at 16:10 -0700, Vineet Gupta wrote:
> > > On 7/3/24 21:35, Xi Ruoyao wrote:
> > > > On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote:
lic:
> private:
> auto_vec> m_stack;
> auto_vec m_replacements;
> - const std::pair m_marker = std::make_pair (NULL, NULL);
> + const std::pair m_marker = std::make_pair(nullptr, nullptr);
> };
AFAIK we prefer NULL_TREE for this.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Mon, 2024-07-01 at 09:11 +0800, HAO CHEN GUI wrote:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
I guess you can add PR114678 into the subject and the ChangeLog, and
also mention the patch in the bugzilla.
--
Xi Ruoyao
School of
On Wed, 2024-07-10 at 21:54 +0800, Xi Ruoyao wrote:
> On Mon, 2024-07-01 at 09:11 +0800, HAO CHEN GUI wrote:
> > Hi,
> > Gently ping it.
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
>
> I guess you can add PR114678 into the subject and the Change
This is per the request from the kernel developers. For generating the
ORC unwind info, the objtool program needs to analysis the control flow
of a .o file. If a jump table is used, objtool has to correlate the
jump instruction with the table.
On x86 (where objtool was initially developed) it's
Doing so can avoid loading FP constants from the memory. It also
partially fixes PR 66462 as fclass does not signal on sNaN.
gcc/ChangeLog:
* config/loongarch/loongarch.md (extendsidi2): Add ("=r", "f")
alternative and use movfr2gr.s for it. The spec clearly states
movfr
This is per the request from the kernel developers. For generating the
ORC unwind info, the objtool program needs to analysis the control flow
of a .o file. If a jump table is used, objtool has to correlate the
jump instruction with the table.
On x86 (where objtool was initially developed) it's
On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote:
>
>
> On 7/9/24 8:35 PM, Xi Ruoyao wrote:
> > On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote:
> > > So I would use tmp (or another word_mode pseudo register) for the
> > > destination of that
On Thu, 2024-07-18 at 19:54 +0800, Xi Ruoyao wrote:
> On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote:
> >
> >
> > On 7/9/24 8:35 PM, Xi Ruoyao wrote:
> > > On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote:
> > > > So I would use tmp (or
On Thu, 2024-07-18 at 20:41 +0800, Xi Ruoyao wrote:
> On Thu, 2024-07-18 at 19:54 +0800, Xi Ruoyao wrote:
> > On Tue, 2024-07-09 at 22:29 -0600, Jeff Law wrote:
> > >
> > >
> > > On 7/9/24 8:35 PM, Xi Ruoyao wrote:
> > > > On Mon, 2024-07-08 at 1
sns -fno-guess-branch-probability
> -fno-tree-fre -fno-tree-ch -Wno-format" } */
>
> int printf(const char *, ...);
> int a[6], b, c;
>
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Sat, 2024-07-20 at 07:16 +0100, Sam James wrote:
> Xi Ruoyao writes:
>
> > On Sat, 2024-07-20 at 06:52 +0100, Sam James wrote:
> > > Some distributions like Gentoo make -Wformat and -Wformat-security
> > > enabled by default. Pass -Wno-format to the test to avoid
Ping.
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let's fix them.
>
> Tested on x86_64-linux-gnu. Ok for trunk and releases/gcc-14?
>
>
Revert "[PATCH v2 1/3] RISC-V: movmem for RISCV with V extension"
>
> This reverts commit df15eb15b5f820321c81efc75f0af13ff8c0dd5b.
Revert is OK, but revert revert is not.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651144.html
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
gcc/ChangeLog:
PR target/115169
* config/loongarch/loongarch.cc
(loongarch_expand_conditional_move): Guard REGNO with REG_P.
---
Bootstrapped with --enable-checking=all. Ok for trunk and 14?
gcc/config/loongarch/loongarch.cc | 17 -
1 file changed, 12 in
Ping again.
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let's fix them.
>
> Tested on x86_64-linux-gnu. Ok for trunk and releases/gcc-14?
>
>
f a patch posted on the
list breaks aarch64. It complained some of my patches and I fixed them
before commit. Why this case was not caught?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2024-07-31 at 21:58 +, Joseph Myers wrote:
> On Mon, 22 Jul 2024, Xi Ruoyao wrote:
>
> > On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> > > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> > > the build is configured --enabl
fixed.
Pushed r15-2931. The ranger is already fixed at r15-2924. The
redundant andi is fixed at r15-2426.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
After fixing PR116142 some code started to trigger an ICE with -O3
-march=znver4. Per Richard Biener who actually made this fix:
"supportable_widening_operation fails at transform time - that's likely
because vectorizable_reduction "puns" defs to internal_def"
so the check should use STMT_VINFO_
---
Pushed as obvious.
htdocs/gcc-14/changes.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 6447898e..7a5eb449 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -1218,9 +1218,9 @
A move/bstrins pair is as fast as a (addi.w|lu12i.w|lu32i.d|lu52i.d)/and
pair, and twice fast as a srli/slli pair. When the src reg and the dst
reg happens to be the same, the move instruction can be optimized away.
gcc/ChangeLog:
* config/loongarch/predicates.md (high_bitmask_operand):
Ping https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
again, adding more reviewers into CC...
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let'
On Sat, 2024-05-11 at 17:16 +0200, FX Coudert wrote:
> * libgccjit.h: Include
Per the C standard size_t should be provided by stddef.h.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
We were comparing a mode size with word_mode, but word_mode is an enum
value thus this does not really make any sense. (Un)luckily E_DImode
happens to be 8 so this seemed to work, but let's make it correct so it
won't blow up when we add LA32 support or add another machine mode...
gcc/ChangeLog:
e in either lines, and your commit has
removed the spaces. But those spaces are completely missing in the
patch sent to gcc-patches. Maybe your mail client has eaten them?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
) << 31) - 1 + (((off_t) 1 << 31) <<
> 31))
> int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
> && LARGE_OFF_T % 2147483647 == 1)
> ? 1 : -1];
This shouldn't happen. Please regenerate using *vanilla* autoconf-2.69.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
> I know riscv doesn't implement any of the legacy optabs. But less
> maintained vector targets might need adjustments.
No new test failures on LoongArch.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Consider
c &= 0xfff;
a &= ~0xfff;
b &= ~0xfff;
a |= c;
b |= c;
This can be done with 2 bstrins instructions. But we need to recognize
it in loongarch_rtx_costs or the compiler will not propagate "c & 0xfff"
forward.
gcc/ChangeLog:
* config/loongarch/loongarch.cc:
The first form has a lower latency (due to the special handling of
"move" in LA464 and LA664) despite it's longer.
gcc/ChangeLog:
* config/loongarch/loongarch.md (define_peephole2): Require
optimize_insn_for_size_p () for move/move/bstrins =>
srai/bstrins transform.
---
B
On Sat, 2024-06-15 at 21:44 +0800, Xi Ruoyao wrote:
> + for (int i = 0; i < 2; i++)
> + *total += set_src_cost (XEXP (op0, i), mode,
> speed);
Oops this is wrong. I need to fix this and regtest again.
--
Xi Ruoyao
School of Aerospace Science an
Consider
c &= 0xfff;
a &= ~0xfff;
b &= ~0xfff;
a |= c;
b |= c;
This can be done with 2 bstrins instructions. But we need to recognize
it in loongarch_rtx_costs or the compiler will not propagate "c & 0xfff"
forward.
gcc/ChangeLog:
* config/loongarch/loongarch.cc:
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_print_operand_reloc):
Dedup and sort the comment describing modifiers.
---
It's a non-functional change thus I've not tested it. Ok for trunk?
gcc/config/loongarch/loongarch.cc | 10 +-
1 file changed, 1 insertio
Ping^4 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let's fix them.
>
> Tested on x86_
gcc/ChangeLog:
* doc/rtl.texi (jump_table_data): Fix typos.
---
Pushed as obvious.
gcc/doc/rtl.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index c1717ab5f6b..a1ede418c21 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.
Ping.
On Sun, 2024-06-16 at 01:50 +0800, Xi Ruoyao wrote:
> Consider
>
> c &= 0xfff;
> a &= ~0xfff;
> b &= ~0xfff;
> a |= c;
> b |= c;
>
> This can be done with 2 bstrins instructions. But we need to
> recognize
> it in loongarch
Ping.
On Sat, 2024-06-15 at 21:47 +0800, Xi Ruoyao wrote:
> The first form has a lower latency (due to the special handling of
> "move" in LA464 and LA664) despite it's longer.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongar
; function is fixed.
Oops https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656937.html
won't be enough for pr107569.C. For pr107569.C I guess we need to add
range ops for __builtin_isfinite but the patch only handles
__builtin_isinf.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Ping^6 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
I'm quite frustrated why no response to such simple test case fixes.
Are people on vacation or something?
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13)
On Sun, 2024-07-21 at 22:46 -0700, Andrew Pinski wrote:
> On Sun, Jul 21, 2024 at 3:57 AM Xi Ruoyao wrote:
> >
> > On Mon, 2024-07-15 at 15:53 +0800, Lulu Cheng wrote:
> > > Hi,
> > >
> > > g++.dg/opt/pr107569.C and range-sincos.c vrp-fl
We already had "si3_extend" insns and we hoped the fwprop or combine
passes can use them to remove unnecessary sign extensions. But this
does not always work: for cases like x << 1 | y, the compiler
tends to do
(sign_extend:DI
(ior:SI (ashift:SI (reg:SI $r4)
(co
+1668,7 @@ (define_insn "*norsi3_internal"
> [(set_attr "type" "logical")
> (set_attr "mode" "SI")])
>
> -(define_insn "n"
> +(define_insn "n3"
> [(set (match_operand:X 0 "register_operand" "=r&q
Per a gcc-help thread we are generating sub-optimal code for
__builtin_bswap{32,64}. To fix it:
- Use a single revb.d instruction for bswapdi2.
- Use a single revb.2w instruction for bswapsi2 for TARGET_64BIT,
revb.2h + rotri.w for !TARGET_64BIT.
- Use a single revb.2h instruction for bswapsi2
In r15-1207 I was too stupid to realize we just need to relax
ins_zero_bitmask_operand to allow using bstrins for aligning, instead of
adding a new split. And, "> 12" in ins_zero_bitmask_operand also makes
no sense: it rejects bstrins for things like "x & ~4l" with no good
reason.
So fix my error
On Wed, 2024-07-31 at 16:57 +0800, Lulu Cheng wrote:
>
> 在 2024/7/29 下午3:58, Xi Ruoyao 写道:
> > Per a gcc-help thread we are generating sub-optimal code for
> > __builtin_bswap{32,64}. To fix it:
> >
> > - Use a single revb.d instruction for bswapdi2.
> > -
The check was implemented incorrectly, so vec_widen_smult_{even,odd}_M
was never used. This is not good for targets with native even/odd
widening multiplication but not lo/hi multiplication.
The fix is actually developed by Richard Biener.
gcc/ChangeLog:
PR tree-optimization/116142
On Wed, 2024-08-07 at 07:01 +0100, Sam James wrote:
> Xi Ruoyao writes:
>
> > The check was implemented incorrectly, so
> > vec_widen_smult_{even,odd}_M
> > was never used. This is not good for targets with native even/odd
> > widening multiplication but not lo/h
ventions, which
> the LoongArch GCC port aims to conform to.
The links seems broken. Do you mean la-softdev-convention?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
A version 1.1.
IMO it's better to use a wording like LA664, i.e. "a CPU implementing
all LoongArch v1.1 unprivileged features" (emphasising "all", as the
v1.1 manual allows to only implement a subset of v1.1 features).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
uot;+Generate instructions for the machine type
> @var{arch-type}.",
>
> so is there no need to write it like this here?
Then maybe just say "all LoongArch v1.1 instructions" instead of
"features" here as well?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
not support HPTW, which
**is** a v1.1 feature.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
error: could not split insn
(insn:TI 1764 67 1745
(set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
On Sat, 2024-04-27 at 11:04 +0800, Lulu Cheng wrote:
> LGTM!
>
> Thanks.
Pushed r15-11 and r14-10142.
> 在 2024/4/26 下午9:52, Xi Ruoyao 写道:
> > Without the constrants, the compiler attempts to use a stack slot as the
> > target, causing an ICE building the kernel with -O
For a --enable-default-pie build, using -fno-pic (for compiler) but
not -no-pie (for linker) triggers some linker warnings counted as
excess errors:
/usr/bin/ld: /tmp/cc8MgxiR.o: warning: relocation in read-only
section `.text.startup'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
After r14-811 "call *nop@GOTPCREL(%rip)" is only generated with
-mno-direct-extern-access even if --enable-default-pie. So the r13-1614
change to this file is not valid anymore.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/i386/fentryname3.c (dg-final): Revert r13-161
In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
the build is configured --enable-default-pie. Let's fix them.
Tested on x86_64-linux-gnu. Ok for trunk and releases/gcc-14?
Xi Ruoyao (2):
i386: testsuite: Add -no-pie for pr113689-1.c [PR70150]
i386: testsuite:
;cpu_tune)
> > {
> > - case CPU_LOONGARCH64:
> > - case CPU_LA464:
> > - case CPU_LA664:
> > + case TUNE_GENERIC:
> > + case TUNE_LOONGARCH64:
> > + case TUNE_LA464:
> > + case TUNE_LA664:
> > /*
On Tue, 2024-05-07 at 17:07 +0800, Xi Ruoyao wrote:
> Hmm, after this change the default (-march=la64v1.0) is enabling LSX:
>
> $ echo "int dummy;" | cc -c -v |& tail -n1
> COLLECT_GCC_OPTIONS='-c' '-v' '-mabi=lp64d' '-march=la64v1.0&#x
On Tue, 2024-05-07 at 18:01 +0800, Lulu Cheng wrote:
>
> 在 2024/5/7 下午5:42, Xi Ruoyao 写道:
> > On Tue, 2024-05-07 at 17:07 +0800, Xi Ruoyao wrote:
> > > Hmm, after this change the default (-march=la64v1.0) is enabling LSX:
> > >
> > > $ e
In GCC 14 we started to emit URLs for "command-line option is
valid for but not " and "-Werror= argument
'-Werror=' is not valid for " warnings. So we should
have moved -fdiagnostics-urls= early like -fdiagnostics-color=, or
-fdiagnostics-urls= wouldn't be able to control URLs in these warnings.
On Thu, 2024-05-09 at 20:21 +, Joseph Myers wrote:
> On Wed, 8 May 2024, Xi Ruoyao wrote:
>
> > In GCC 14 we started to emit URLs for "command-line option is
> > valid for but not " and "-Werror= argument
> > '-Werror=' is not valid for "
;
}
is compiled to:
test:
li a5,1048576
sllia0,a0,12
and a0,a0,a5
ret
So why must we spend an instruction to load the single-bit immediate?
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
cuit=1 was actually faster than the code
generated with -Ofast --param logical-op-non-short-circuit=0.
AFAIK 2 isn't an issue for RISC-V (where FP comparison result is just in
GPR) but 1 and 3 may still need to be considered.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
on of https://gcc.gnu.org/contribute.html for
how to refer to a PR correctly, instead of putting an URL here.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
>= 6"
+ "rint.\t%0,%1")
+
+
;; Synchronization instructions.
it works for me:
$ cat t.c
double test(double x)
{
return __builtin_rint(x);
}
$ ./gcc/cc1 t.c -nostdinc -O2 -mips64r6 -mexplicit-relocs -mabi=64
$ grep rint t.s
rint.d $f0,$f12
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On Wed, 2024-09-11 at 16:17 +0800, 梅杰 wrote:
> 在 2024/9/10 17:30, Xi Ruoyao 写道:
> > On Tue, 2024-09-10 at 16:50 +0800, 梅杰 wrote:
> > > As for the function `__builtin_rint`, although it exists, however, after
> > > defining the instruction in `mips.md`, GCC still won&
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-com
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
* c-family/c-common.h (char_type_p): New prototype.
* c/c-typeck.c (char_type_p): Make the function extern.
* cp/cp-tree.h (char_type_p
This patch adds warning option -Wstring-plus-int for C/C++.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao
* c-family/c.opt: New option -Wstring-plus-int.
* c-family/c-common.c (pointer_int_sum): Checking for
-Wstring-plus-int.
---
gcc/c-family/c-common.c | 25
This patch adds warning option -Wstring-plus-char for C/C++.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao
* 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/c.opt: New option -Wstring-plus
This patch adds tests for -Wstring-plus-int.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao
* 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.
---
gcc/testsuite/c-c++-common
This patch adds tests for -Wstring-plus-char.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao
* 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: Ditto.
* testsuite/g++.dg
This patch adds document of -Wstring-plus-int and -Wstring-plus-char.
gcc/ChangeLog:
2017-06-12 Xi Ruoyao
* doc/invoke.texi (Warning Options): Document -Wstring-plus-int
and -Wstring-plus-char.
---
gcc/doc/invoke.texi | 22 +-
1 file changed, 21
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 ar
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
> >
> > * c-family/c.opt: New o
301 - 400 of 1155 matches
Mail list logo
