On Tue, 2023-08-15 at 20:03 +, Joseph Myers wrote:
> On Tue, 15 Aug 2023, chenxiaolong wrote:
>
> > In the implementation process, the "q" suffix function is
> > Re-register and associate the "__float128" type with the
> > "long double" type so that the compiler can han
On Fri, 2023-08-18 at 14:39 +0800, chenxiaolong wrote:
> 在 2023-08-17四的 15:08 +，Joseph Myers写道：
> > On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> >
> > > So I guess we just need
> > >
> > > builtin_define ("__builtin_fabsq=__builtin_fa
On Fri, 2023-08-18 at 14:58 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2023-08-18 at 14:39 +0800, chenxiaolong wrote:
> > 在 2023-08-17四的 15:08 +，Joseph Myers写道：
> > > On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> > >
>
On Fri, 2023-08-18 at 15:05 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2023-08-18 at 14:58 +0800, Xi Ruoyao via Gcc-patches wrote:
> > On Fri, 2023-08-18 at 14:39 +0800, chenxiaolong wrote:
> > > 在 2023-08-17四的 15:08 +，Joseph Myers写道：
> > > > On Thu,
On Thu, 2023-08-17 at 15:20 +0800, Chenghui Pan wrote:
> Seems ARMv8-A only guarantees to preserve low 64-bit value of
> NEON/floating-point register value. I'm not sure that I modify the
> testcase in the right way and maybe we need more investigations. Any
> ideas or suggestion?
Sorry, the follo
On Fri, 2023-06-16 at 15:53 +0800, YunQiang Su wrote:
> Ohh, sorry. I forget it. I commented there.
> I have no permission to close this bug report. Can you help to close
> it?
Modify the email address of your Bugzilla account to your @gcc.gnu.org
address, then you should be able to close it.
--
On Tue, 2023-06-20 at 12:22 -0400, Jason Merrill via Gcc-patches wrote:
> diff --git a/htdocs/bugs/index.html b/htdocs/bugs/index.html
> index aaef8915..6dbe5d45 100644
> --- a/htdocs/bugs/index.html
> +++ b/htdocs/bugs/index.html
> @@ -122,6 +122,9 @@ three of which can be obtained from the output
Please use [PATCH v3 1/2] next time, now it's not easy to find the
latest version of the series (I'm not sure if the number "3" is
correct).
On Sat, 2023-06-24 at 03:38 -0700, Ken Matsui via Gcc-patches wrote:
> This patch implements built-in trait for std::is_const.
>
> gcc/cp/ChangeLog:
>
>
On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote:
> These tests fail when the testsuite is executed with -fstack-
> protector-strong.
> To avoid this, this patch adds -fno-stack-protector to dg-options.
>
> Tested on x86_64-pc-linux-gnu, ok for trunk?
LGTM, we've noticed the
On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote:
> On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote:
> > These tests fail when the testsuite is executed with -fstack-
> > protector-strong.
> > To avoid this, this patch adds -fno-stack-protector to dg-options.
> >
> > Teste
On Fri, 2023-06-30 at 10:16 +0800, Chenghui Pan wrote:
> These patches add the Loongson SX/ASX instruction support to the
> LoongArch
> target, and can be utilized by using the new "-mlsx" and
> "-mlasx" option.
>
> Patches are bootstrapped and tested on loongarch64-linux-gnu target.
>
> Lulu Che
On Fri, 2023-06-30 at 10:16 +0800, Chenghui Pan wrote:
>
> + int use_vecarg_p = TARGET_VECARG
> + && LSX_SUPPORTED_MODE_P (mode);
> +
> memset (info, 0, sizeof (*info));
> info->gpr_offset = cum->num_gprs;
> info->fpr_offset = cum->num_fprs;
> @@ -535,7 +546,7 @@ loongarch_get_arg_in
On Fri, 2023-06-30 at 10:16 +0800, Chenghui Pan wrote:
> +(define_c_enum "unspec" [
> + UNSPEC_LSX_ASUB_S
> + UNSPEC_LSX_VABSD_U
> + UNSPEC_LSX_VAVG_S
/* ... */
To me many of them can be modeled using RTL templates, instead of an
unspec.
--
Xi Ruoyao
School of Aerospace Science and Technolog
A question: is vld/vst guaranteed to be atomic if the accessed address
is aligned? If true we can use them to implement lock-free 128-bit
atomic load and store. See https://gcc.gnu.org/bugzilla/PR104688 for
the background, and some people really hate using a lock for atomics.
On Fri, 2023-06-30
If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended. But this was not handled
correctly.
For example:
int x : 8;
long y : 55;
bool z : 1;
The vectorized extraction of y was:
vect__ifc__49.29_110 =
MEM [(struct I
On Fri, 2023-07-07 at 08:15 +0200, Richard Biener wrote:
/* snip */
> > + bool sign_ext = (!TYPE_UNSIGNED (TREE_TYPE (bf_ref)) &&
> > + TYPE_PRECISION (ret_type) > mask_width);
> > + bool widening = ((TYPE_PRECISION (TREE_TYPE (container)) <
> > + TYPE_PRECISI
If a bit-field is signed and it's wider than the output type, we must
ensure the extracted result sign-extended. But this was not handled
correctly.
For example:
int x : 8;
long y : 55;
bool z : 1;
The vectorized extraction of y was:
vect__ifc__49.29_110 =
MEM [(struct I
On Mon, 2023-07-10 at 10:33 +, Richard Biener wrote:
> On Fri, 7 Jul 2023, Xi Ruoyao wrote:
>
> > If a bit-field is signed and it's wider than the output type, we
> > must
> > ensure the extracted result sign-extended. But this was not handled
> > correctly.
> >
> > For example:
> >
> >
On Tue, 2023-07-11 at 13:04 +0530, Prathamesh Kulkarni wrote:
/* snip */
> Hi Xi,
> Your commit:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=63ae6bc60c0f67fb2791991bf4b6e7e0a907d420,
>
> seems to cause following regressions on arm-linux-gnueabihf:
> FAIL: g++.dg/vect/pr110557.cc -std=c++98
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and "--target=loongarch64-linux-gnusf" should both set multiarch tuple
to "loongarch64-linux-gnusf".
On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
> Like la264 only has 40 effective bits of virtual address space.
I'm OK with the change. But the VA length is configurable building the
kernel. Is there any specific reason LA264 has to use the 40-bit
configuration, or should we reword the co
If GCC is built with --enable-default-pie, a lot of aapcs64 tests fail
because relocation unsupported in PIE is used.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/aapcs64/aapcs64.exp (additional_flags):
Add -fno-pie -no-pie.
---
gcc/testsuite/gcc.targe
Hi,
This patch series fixes a lot of test failures with --enable-default-pie
or --enable-default-ssp for AArch64 target. Only test files are changed
to disable PIE or SSP to satisify the expectation of the developer who
programmed the test.
Bootstrapped and regtested on aarch64-linux-gnu. Ok fo
If GCC is configured with --enable-default-ssp, the stack protector can
make many sve-pcs tests fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp (sve_flags):
Add -fno-stack-protector.
---
.../gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp |
The test scans for "const_int 0" in the RTL dump, but stack protector
can produce more "const_int 0". To avoid a failure with
--enable-default-ssp, disable stack protector for this.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/auto-init-7.c (dg-options): Add
-fno-stack-protector
In PIE, symbol "fixed_regs" is addressed via GOT. It will break the
scan-assembler pattern and cause test failure with --enable-default-pie.
gcc/testsuite/ChangeLog:
PR testsuite/70150
* gcc.target/aarch64/fuse_adrp_add_1.c (dg-options): Add
-fno-pie.
---
gcc/testsuite/g
Storing stack guarding variable need one stp instruction, breaking the
scan-assembler-not pattern in the test. Disable stack protector to
avoid a test failure with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr104005.c (dg-options): Add
-fno-stack-protecto
These tests set large code model with -mcmodel=large or target pragma for
AArch64. But if GCC is configured with --enable-default-pie, it triggers
"sorry: unimplemented: code model large with -fpic". Disable PIE to make
avoid the issue.
gcc/testsuite/ChangeLog:
PR testsuite/70150
Stack protector influence code generation and cause function body checks
fail.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr103147-10.c (dg-options): Add
-fno-stack-protector.
* g++.target/aarch64/pr103147-10.C: Likewise.
---
gcc/testsuite/g++.target/aarch64/pr103147-1
Stack protector needs a guard value on the stack and change the stack
layout. So we need to disable it for those tests, to avoid test failure
with --enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/shrink_wrap_1.c (dg-options): Add
-fno-stack-protector.
*
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling convention
unless it's necessary."
Though not explicitly stated, the rationale of this rule is to allow
combinations like "
On Fri, 2023-03-03 at 10:12 +0800, Yujie Yang wrote:
> However, "loongarch64" is defined to include the "fpu64" ISA module[1]
> (i.e. enable "-mfpu=64" when -mfpu is not explicitly used). So I believe
> the above behavior you observed is expected.
Ah this make things much simpler and aligns with m
Please don't use the same title for all the patches. This will puzzle
people running "git log" once they are committed.
And when you send 01-07, use "reply" instead of "new" so they will show
up in the correct location in a mail client. Or use git send-email
which is much eaiser to use.
On Thu,
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling convention
unless it's necessary."
Though not explicitly stated, the rationale of this rule is to allow
combinations like "
Some trivial test case fixes. Ok for trunk?
Xi Ruoyao (2):
LoongArch: testsuite: Disable stack protector for some tests
LoongArch: testsuite: Adjust stack offsets in stack-check-cfa tests
gcc/testsuite/gcc.target/loongarch/prolog-opt.c| 2 +-
gcc/testsuite/gcc.target/loongarch/stack
Stack protector will affect stack layout and break the expectation of
these tests, causing test failures if GCC is configured with
--enable-default-ssp.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/prolog-opt.c (dg-options): Add
-fno-stack-protector.
* gcc.target/loonga
Once upon the time we used to save two registers unnecessarily, costing
16 bytes. Now the issue seems fixed (not sure by which commit though),
adjust the stack offsets to reflex the change.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/stack-check-cfa-1.c (dg-final): Adjust
exp
The driver emits a warning when -fstack-check and
-fstack-clash-protection are used together, but the message refers to
"-fstack-clash_protection" (underline instead of dash).
gcc/ChangeLog:
* toplev.cc (process_options): Fix the spelling of
"-fstack-clash-protection".
---
gcc/to
On Fri, 2023-03-03 at 16:54 +0800, Xi Ruoyao wrote:
> The driver emits a warning when -fstack-check and
> -fstack-clash-protection are used together, but the message refers to
> "-fstack-clash_protection" (underline instead of dash).
Forgot: Ok for trunk? Though I think it's obvious but let's fol
On Sat, 2023-01-07 at 06:52 +, Jonathan Yong via Gcc-patches wrote:
> On 1/6/23 18:10, Jakub Jelinek wrote:
> > On Sat, Jan 07, 2023 at 02:01:05AM +0800, LIU Hao via Gcc-patches
> > wrote:
> > > libgomp/
> > >
> > > PR middle-end/108300
> > > * config/mingw32/proc.c: Define `WI
Wrong subject: the library is libstdc++, not "cc++".
On Fri, 2022-12-30 at 10:30 +, Jonny Grant wrote:
> 2022-12-30 Jonathan Grant
> * libstdc++-v3/doc/xml/faq.xml: update copyright year in
> libstdcc++ manual
Wrong ChangeLog format, see
https://gcc.gnu.org/codingconventions.html#Ch
On Fri, 2023-03-03 at 08:21 -0800, Mike Stump wrote:
> On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches
> wrote:
> >
> > Some trivial test case fixes. Ok for trunk?
>
> Ok.
Lulu: if you don't object I'll push these two in this week.
I tried to bisect
On Mon, 2023-03-06 at 09:15 +0800, Lulu Cheng wrote:
>
> 在 2023/3/6 上午12:21, Xi Ruoyao 写道:
> > On Fri, 2023-03-03 at 08:21 -0800, Mike Stump wrote:
> > > On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches
> > > wrote:
> > > > Some trivial test cas
On Mon, 2023-03-06 at 10:48 +0800, Xi Ruoyao wrote:
> On Mon, 2023-03-06 at 09:15 +0800, Lulu Cheng wrote:
> >
> > 在 2023/3/6 上午12:21, Xi Ruoyao 写道:
> > > On Fri, 2023-03-03 at 08:21 -0800, Mike Stump wrote:
> > > > On Mar 3, 2023, at 12:40 AM, Xi R
On Sun, 2023-03-05 at 22:13 -0500, Michael Collison wrote:
/* snip */
> - Fixed ChangeLog email formatting
Unfortunately it's not fixed. We expect one tab, but now you have 16
whitespaces.
To me it looks like your email client is being too smart and destroying
the patch . Try "git send-email"
On Mon, 2023-03-06 at 11:16 +0800, Xi Ruoyao wrote:
/* snip */
> > > Sorry for the late reply, the first patch I think is fine. But I haven't
> > > reproduced the problem of the second mail.
> > >
> > > Is there any special option in the configuration?
> >
> > Oh some strange thing might be ha
Pushed r13-6500 and r12-9225.
On Mon, 2023-03-06 at 15:21 +0800, Lulu Cheng wrote:
>
> 在 2023/3/3 下午4:16, Xi Ruoyao 写道:
> > In the toolchain convention, we describe -mfpu= as:
> >
> > "Selects the allowed set of basic floating-point instructions and
> > registers. This option should not change t
On Mon, 2023-03-06 at 13:59 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Mon, 2023-03-06 at 11:16 +0800, Xi Ruoyao wrote:
>
> /* snip */
>
> > > > Sorry for the late reply, the first patch I think is fine. But I
> > > > haven't
> >
On Mon, 2023-03-06 at 16:12 +0800, Lulu Cheng wrote:
> Has the first patch been merged into the main branch yet?
>
> I think there is one more test case that needs to be modified:
>
> --- a/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
> +++ b/gcc/testsuite/gcc.target/loongarch/prolog-opt.c
> @
On Thu, 2023-03-02 at 10:26 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > Hi,
> >
> > This patch series fixes a lot of test failures with --enable-default-pie
> > or --enable-default-ssp for AArch64 target. Only test files are changed
> > to disable PIE or SSP to satisify the expectati
On Mon, 2023-03-13 at 11:52 +0800, Lulu Cheng wrote:
> diff --git a/gcc/config/loongarch/larchintrin.h
> b/gcc/config/loongarch/larchintrin.h
> index e571ed27b37..09f9a5db846 100644
> --- a/gcc/config/loongarch/larchintrin.h
> +++ b/gcc/config/loongarch/larchintrin.h
> @@ -145,6 +145,7 @@ __asrtgt_
On Mon, 2023-03-13 at 12:40 +0800, WANG Xuerui wrote:
> This is ugly. The fact all current LA32 models don't support CRC ops is
> just a coincidence; it's entirely possible for a future product
> iteration to introduce such functionality. It's not like the CRC*.W.W.W
> ops require anything wider
On Mon, 2023-03-13 at 12:58 +0800, Lulu Cheng wrote:
>
> 在 2023/3/13 下午12:54, Xi Ruoyao 写道:
> > On Mon, 2023-03-13 at 12:40 +0800, WANG Xuerui wrote:
> > > This is ugly. The fact all current LA32 models don't support CRC
> > > ops is
> > > just a coincidence; it's entirely possible for a future pr
Already approved in bugzilla and bootstrapped on x86_64-linux-gnu.
Pushed.
expand_simple_binop() is allowed to allocate a new pseudo-register and
return it, instead of forcing the result into the provided
pseudo-register. This can cause a problem when we expand the unrolled
loop for __builtin_str
On Wed, 2023-05-10 at 22:02 +0200, Thomas Koenig wrote:
> On 10.05.23 21:29, Bernhard Reutner-Fischer via Fortran wrote:
> > On Mon, 27 Jun 2022 14:10:36 +0800
> > Xi Ruoyao wrote:
> >
> > > fgrep has been deprecated in favor of grep -F for a long time, and the
> > > next grep release (3.8 or 4.0
On Tue, 2023-05-16 at 07:55 +, Li, Pan2 via Gcc-patches wrote:
> I see, thanks Richard for reminding. I am sorry I failed to locate
> anywhere(doc or something else) mentioned such convention about ping,
https://gcc.gnu.org/contribute.html suggests two week.
> will follow the below convention
On Wed, 2023-05-24 at 14:04 +0800, Lulu Cheng wrote:
> An empty struct type that is not non-trivial for the purposes of calls
> will be treated as though it were the following C type:
>
> struct {
> char c;
> };
>
> Before this patch was added, a structure parameter containing an empty
> struc
en we pass "Test" via registers, we may only allocate the registers
for Test::a and Test::b, and complete ignore Test::empty because there
is no addresses of registers. Is this correct or not?
On Wed, 2023-05-24 at 14:45 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Wed, 2023-05-24 at
On Wed, 2023-05-24 at 16:47 +0800, Lulu Cheng wrote:
>
> 在 2023/5/24 下午2:45, Xi Ruoyao 写道:
> > On Wed, 2023-05-24 at 14:04 +0800, Lulu Cheng wrote:
> > > An empty struct type that is not non-trivial for the purposes of
> > > calls
> > > will be treated as though it were the following C type:
> > >
On Wed, 2023-05-24 at 18:07 +0800, Lulu Cheng wrote:
>
> 在 2023/5/24 下午5:25, Xi Ruoyao 写道:
> > On Wed, 2023-05-24 at 16:47 +0800, Lulu Cheng wrote:
> > > 在 2023/5/24 下午2:45, Xi Ruoyao 写道:
> > > > On Wed, 2023-05-24 at 14:04 +0800, Lulu Cheng wrote:
> > > > > An empty struct type that is not non-tr
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:
> > > > > Sorry, I forgot to include the ChangeLog:
> > > > >
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 Jelinek wrote:
> > > > On Mon, Jan 0
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 form to send mail to Ro
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 PM, Jakub Jelinek wrote:
> > > > > On Mon, Jan 04, 2021 at
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-01-04 14:19 -0700, Jeff Law wrote:
> > > > > On 1/4/21 2:
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 tar
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
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 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 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 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 lo
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:28 -0600, Jeff Law via Gcc-patches wrote:
>
>
> On 8/26/2021 10:58 PM, YunQiang Su wrote:
> > for some instructions, MIPS r6 uses different encoding other than
> > the previous releases.
> >
> > 1. mips/n32.S disable .set mips4: since it casuses old insn encoding
> >
On Sat, 2021-08-28 at 08:05 -0400, YunQiang Su wrote:
> Currently, the enums from define_c_enum and define_enum can only
> has values one by one from 0.
>
> In fact we can support the behaviour just like C, aka like
> (define_enum "mips_isa" [mips1=1 mips2 mips32=32 mips32r2]),
> then we can get
On Sat, 2021-08-28 at 08:05 -0400, YunQiang Su wrote:
> Currently mips-cpu.defs and mips.h are using hardcoded numbers
> for isa level.
>
> Let's replace them with more readable enum mips_isa.
Good, but there is something like "mips_isa_rev >= 32 && mips_isa_rev <
64" in mips.h and netbsd.h. Not
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.
>
> gcc/
Hi hj,
libffi-3.4.2's new static trampoline feature is known to break some
downstream packages with some specific use (or misuse?) of libffi,
unexpected by the libffi developers. For example
https://gitlab.gnome.org/GNOME/gjs/-/issues/428.
I've not use gccgo recently, so I don't know if it might
Static PIE allows us to extend the ASLR to cover static executables and
it's not too difficult to support it. On GCC side, we just pass a group
of options to the linker, like other ports with static PIE support.
The real implementation of static PIE (rcrt1.o) will be added into Glibc
later.
gcc/
On Wed, 2022-09-21 at 11:31 +, YunQiang Su wrote:
> On platforms that support multiarch, such as Debian,
> the filesystem hierarchy doesn't fellow the old Irix style:
> lib & lib/ for native
> lib64 for N64 on N32/O32 systems
> lib32 for N32 on N64/O32 systems
>
I made a mistake defining fmin/fmax RTL patterns in r13-2085: I used
smin and smax in the definition mistakenly. This causes the optimizer
to perform constant folding as if fmin/fmax was "really" smin/smax
operations even with -fsignaling-nans. Then pr105414.c fails.
We don't have fmin/fmax RTL
The test pr106397.c fails on LoongArch because we don't have defined
prefetch instruction. We can silence the test for LoongArch, but it's
not too difficult to add the prefetch instruction so add it now.
-- >8 --
gcc/ChangeLog:
* config/loongarch/constraints.md (ZD): New address constra
On Mon, 2022-09-26 at 10:00 +0800, Lulu Cheng wrote:
> Co-Authored-By: qijingwen
>
> include/ChangeLog:
>
> * vtv-change-permission.h (defined):
> (VTV_PAGE_SIZE): 16k pages under loongarch64.
We have 4KB, 16KB, and 64KB page configurations, so is it possible to
support all of t
Currently our cache information from -mtune is not really used, pass it
to the optimizer so it will be really in-effect.
gcc/ChangeLog:
* config/loongarch/loongarch.cc
(loongarch_option_override_internal): Set the corresponding
params for L1D cache line size, L1D cache siz
+ Caroline (the author or libvtv, I hope the email address is still
active).
On Tue, 2022-09-27 at 10:37 +0800, Lulu Cheng wrote:
> I asked my colleagues in the kernel group, this page size may change.
>
> That there is a macro BIG_PAGE_SIZE comment in vtv-change-permission.h
>
> written like th
On Mon, 2022-09-26 at 15:04 +0800, Lulu Cheng wrote:
> This change may have to wait for the test results to determine whether
> to merge.
With this patch and my other pending patches
- https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602172.html
- https://gcc.gnu.org/pipermail/gcc-patches
On Tue, 2022-09-27 at 15:49 +0800, Lulu Cheng wrote:
> #if defined (__CYGWIN__) || defined (__MINGW32__)
> if (VTV_PAGE_SIZE != sysconf_SC_PAGE_SIZE())
> +#elif defined (__loongarch_lp64)
> + /* I think that under the LoongArch 64-bit system, VTV_PAGE_SIZE is set
> + to the maximum value o
On Wed, 2022-09-28 at 16:31 +0800, Lulu Cheng wrote:
> Hi,
>
> My colleague is testing the performance data of prefetch and
> prefetchx.
>
> And will submit both supports together if there is no problem.
Ok, so mark this one as "superseded".
>
> 在 2022/9/25 下午7:25, Xi Ruoyao 写道:
> > The test p
I don't really understand MinGW, but some "non-technical" things:
On Tue, 2022-10-04 at 20:44 +0800, LIU Hao via Gcc-patches wrote:
> After applying these patches, configure scripts in these
> subdirectories need to be regenerated:
>
> * gcc
> * libgcc
> * libatomic
> * libstdc++-v3
On Tue, 2022-10-04 at 21:45 +0800, LIU Hao wrote:
> 在 2022-10-04 21:13, Xi Ruoyao 写道:
> >
> > In GCC development we usually include the configure regeneration in the
> > patch because the scripts are also version controlled.
> >
>
> There is a reason for not doing that: Generated contents can't
On Mon, 2022-10-10 at 10:49 -0700, Caroline Tice via Gcc-patches wrote:
> Is "if (VTV_PAGE_SIZE != sysconf (_SC_PAGE_SIZE))" going to fail for
> loongarch?
Because LoongArch systems may have 4KB, 16KB, or 64KB pages.
> If not, why do you need to insert anything here at all? If so,
> perhaps you
On Fri, 2022-03-04 at 15:17 +0800, xucheng...@loongson.cn wrote:
> The binutils has been merged into trunk:
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307
>
> Note: We split -mabi= into -mabi=lp64d/f/s, the new options not support by
> upstre
On Sat, 2022-03-05 at 09:36 +0800, Paul Hua wrote:
> >
> > And based on the history of RISC-V port
> > (https://gcc.gnu.org/pipermail/gcc/2017-January/222595.html) the
> > process
> > for a new port seems:
> >
> > 1. Get a permission from the Steering Committee.
> > 2. Add one or two port maintai
On Fri, 2022-03-04 at 15:18 +0800, xucheng...@loongson.cn wrote:
> * config/loongarch/loongarch.md: New file.
An ICE happens building OpenSSH-8.9p1. Investigation shows it's caused
by the flag "-fzero-call-used-regs=". It's because the compiler
attempts to clear FCCx registers but can't
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 "c.f.
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 a/gcc/config/mips/m
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 cha
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
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) | 0x7fff) == 0x7fff
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 (compute_co
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 0x7fff
101 - 200 of 548 matches
Mail list logo
