Re: [PATCH] ipa: Self-DCE of uses of removed call LHSs (PR 108007)

On Tue, 3 Oct 2023, Martin Jambor wrote: > > SSA graph may be deep so this may cause stack overflow, so I think we > > should use worklist here (it is also easy to do). > > > > OK with that change. > > Honza > > I have just committed the following after a bootstrap and testing on > x86_64-linux.

[PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

Despite not defining `vec_pack_trunc_' standard named patterns the backend provides vector pack operations via its own `@pred_trunc' set of patterns and they do trigger in vectorization producing narrowing VNCVT.X.X.W assembly instructions as expected. Enable the `vect_pack_trunc' setting for R

Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

On Tue, 10 Oct 2023, 钟居哲 wrote: >&& [check_effective_target_arm_little_endian]) >|| ([istarget mips*-*-*] >&& [et-is-effective-target mips_msa]) > + || [istarget riscv*-*-*] >|| ([istarget s390*-*-*] >&& [check_effect

Re: 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

On Tue, 10 Oct 2023, 钟居哲 wrote: > Btw, could you rebase to the trunk and run regression again? Full regression-testing takes roughly 40 hours here and I do not normally update the tree midway through my work so as not to add variables and end up chasing a moving target, especially with such an

Re: 回复: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

On Mon, 9 Oct 2023, Maciej W. Rozycki wrote: > > Btw, could you rebase to the trunk and run regression again? > > Full regression-testing takes roughly 40 hours here and I do not normally > update the tree midway through my work so as not to add variables and end > up chasi

Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

On Tue, 10 Oct 2023, 钟居哲 wrote: > I know you want vect_int to block the test for rv64gc. > But unfortunately it failed. Why? > And I have changed everything to run vect testsuite with "riscv_v". > [PATCH] RISC-V: Enable more tests of "vect" for RVV (gnu.org) > > So to be consistent, plz add "

Re: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'

On Tue, 10 Oct 2023, juzhe.zh...@rivai.ai wrote: > It's weird. Could you give me the FAILs report? I keep forgetting that I have a piece of code in my board description files that makes the testsuite leave output files in place, which helps much when debugging failures (although it's not a per

[PATCH RFA] PR target/111815: VAX: Only accept the index scaler as the RHS operand to ASHIFT

As from commit 9df1ba9a35b8 ("libbacktrace: support zstd decompression") GCC for the `vax-netbsdelf' target fails to complete building, with an ICE: during RTL pass: final .../libbacktrace/elf.c: In function 'elf_zstd_decompress': .../libbacktrace/elf.c:5006:1: internal compiler error: in print

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

On Tue, 23 May 2023, Jin Ma via Gcc-patches wrote: > When testing a extension, it is often necessary for a certain program not to > need some kind of extension, such as the bitmanip extension, to evaluate the > performance or codesize of the extension. However, the current multilib rules > will re

Re: [COMMITTED] ada: Remove the body of System.Storage_Elements

On Mon, 29 May 2023, Jan-Benedict Glaw wrote: > > Can you elaborate how you build GCC? > > My host compileris Debian's "gcc-snapshot", by now some two months > old. (As Eric wrote, it's probably just too old.) That compiler is > given for CC/CXX. The new build is just (as I wrote in the initial >

Re: [PATCH] MIPS: don't expand large block move

On Wed, 24 May 2023, YunQiang Su wrote: > > or even: > > > > if (INTVAL (length) <= MIPS_MAX_MOVE_BYTES_STRAIGHT) > > ... > > else if (INTVAL (length) < 64 && optimize) > > ... > > > > I don't think this is a good option, since somebody may add some code, > and may bre

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

On Mon, 29 May 2023, Jin Ma wrote: > > Can you give me a specific example (compilation options and multilibs > > available) of a failure you refer to? > > A simple example: > 1. Use "--disable-multilib --with-abi =lp64d --with-arch > =rv64imafdc_zba_zbb_zbc_zbs" > to build the toolchain". > 2.

Re: [PATCH v4] MIPS: add speculation_barrier support

On Wed, 31 May 2023, YunQiang Su wrote: > If no objection, I will commit this V4 patch. At first glance it has coding style issues. Maciej

Re: [COMMITTED] MAINTAINERS: Add myself as MIPS port maintainer

On Fri, 2 Jun 2023, YunQiang Su wrote: > diff --git a/MAINTAINERS b/MAINTAINERS > index 4a7c963914b..c8b787b6e1e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -91,7 +91,7 @@ m68k port Andreas Schwab > > m68k-motorola-sysv port Philippe De Muyter > mcore port

Re: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951]

Hi Thomas, > Will you, Maciej, please test that this doesn't break your setting? Umm, this was implemented for my Western Digital development environment, which I don't have access to anymore. I'll see what I can do, but it may be neither easy nor quick. It's been long ago and I don't have a

Re: [PATCH 3/3] testsuite: Require vectors of doubles for pr97428.c

On Wed, 12 Jul 2023, Richard Biener wrote: > > Applied, thanks. OK to backport to the active branches? > > Yes. Now backported, thanks. Maciej

[committed] testsuite: Add 64-bit vector variant for bb-slp-pr95839.c

Add dual-single float vector test complementing bb-slp-pr95839.c. gcc/testsuite/ * gcc.dg/vect/bb-slp-pr95839-v8.c: New test. --- Committed with Richard Biener's approval: . --- gcc/testsuite/gcc.dg/vect/bb-slp-pr95

Re: [PATCH 2/3] testsuite: Require 128-bit vectors for bb-slp-pr95839.c

On Wed, 12 Jul 2023, Richard Biener wrote: > > > That said, we should handle this better so can you file an > > > enhancement bugreport for this? > > > > Filed as PR -optimization/110630. > > Thanks! Thanks for making this improvement. I've checked MIPS results and code produced now is as fo

Re: [PATCH 2/3] testsuite: Require 128-bit vectors for bb-slp-pr95839.c

On Thu, 20 Jul 2023, Richard Biener wrote: > > Thanks for making this improvement. I've checked MIPS results and code > > produced now is as follows: > > > > daddiu $sp,$sp,-64 > > sd $5,24($sp) > > sd $7,40($sp) > > ldc1$f0,24($sp) > > ldc1

Re: [PATCH 2/3] testsuite: Require 128-bit vectors for bb-slp-pr95839.c

On Thu, 20 Jul 2023, Richard Biener wrote: > > There's no such requirement in the psABI and I fail to see a plausible > > justification. And direct GPR<->FPR move patterns are available in the > > backend for the V2SF mode. Also there's no delay slot requirement even > > for these move instruct

Re: [r14-2639 Regression] FAIL: gcc.dg/vect/bb-slp-pr95839-v8.c scan-tree-dump slp2 "optimized: basic block" on Linux/x86_64

On Thu, 20 Jul 2023, Richard Biener wrote: > > c1e420549f2305efb70ed37e693d380724eb7540 is the first bad commit > > commit c1e420549f2305efb70ed37e693d380724eb7540 > > Author: Maciej W. Rozycki > > Date: Wed Jul 19 11:59:29 2023 +0100 > > > > testsuite:

[committed] testsuite: Limit bb-slp-pr95839-v8.c to 64-bit vector targets

Only run bb-slp-pr95839-v8.c with targets that support vectors of 64 bits, removing regressions with 32-bit x86 targets: FAIL: gcc.dg/vect/bb-slp-pr95839-v8.c scan-tree-dump slp2 "optimized: basic block" FAIL: gcc.dg/vect/bb-slp-pr95839-v8.c -flto -ffat-lto-objects scan-tree-dump slp2 "optimiz

Re: [PATCH v1] RISC-V: Fix one typo for emit_mode_set.

On Mon, 3 Jul 2023, Kito Cheng via Gcc-patches wrote: > Lgtm > > > juzhe.zh...@rivai.ai 於 2023年7月3日 週一，19:11寫道： > > > LGTM > > > > > > > > juzhe.zh...@rivai.ai > > > > From: pan2.li > > Date: 2023-07-03 18:57 > > To: gcc-patches > > CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.che

Re: [PATCH] fix pdp11_expand_epilogue (PR target/107841)

On Thu, 13 Jul 2023, Jeff Law via Gcc-patches wrote: > > Question for the experts: how is this handled? Do I need to apply this > > change to my workspace and commit it, with Mikael as the change author? > That's what I usually do for someone without write access. commit it locally > using the -

Re: [PATCH] RISC-V: Return machine_mode rather than opt_machine_mode for get_mask_mode, NFC

On Mon, 31 Jul 2023, Kito Cheng via Gcc-patches wrote: > Pushed, thanks :) This breaks compilation: .../gcc/config/riscv/riscv-v.cc: In function 'void riscv_vector::expand_vec_series(rtx, rtx, rtx)': .../gcc/config/riscv/riscv-v.cc:1251:16: error: unused variable 'mask_mode' [-Werror=unused-v

Re: [PATCH] RISC-V: Return machine_mode rather than opt_machine_mode for get_mask_mode, NFC

On Mon, 31 Jul 2023, Kito Cheng wrote: > Sorry for disturbing, pushed a fix for that, and...added > -Werror=unused-variable to my build script to prevent that happen > again :( I just configure with `--enable-werror-always', which we want to keep our standards up to anyway, but if you find this

Re: [PATCH] RISC-V: Return machine_mode rather than opt_machine_mode for get_mask_mode, NFC

On Mon, 31 Jul 2023, Kito Cheng wrote: > > I just configure with `--enable-werror-always', which we want to keep > > our standards up to anyway, > > I rely on the host GCC which is 11 relatively old compared to the > trunk, so --enable-werror-always will get many -Wformat* warning :( If buildi

Re: [PATCH] RISC-V: Return machine_mode rather than opt_machine_mode for get_mask_mode, NFC

On Mon, 31 Jul 2023, Jeff Law wrote: > > That's a good suggestion! Thanks, let me try to apply myself workflow :) > I'm thinking that as part of the CI POC being done by RISE that the base AMI > image ought to be gcc-13 based and that we should configure the toolchains we > build with -enable-wer

[PATCH v2] RISC-V: Split unordered FP comparisons into individual RTL insns

We have unordered FP comparisons implemented as RTL insns that produce multiple machine instructions. Such RTL insns are hard to match with a processor pipeline description and additionally there is a redundant SNEZ instruction produced on the result of these comparisons even though the FLT.fm

[PING][PATCH v2] RISC-V: Split unordered FP comparisons into individual RTL insns

On Mon, 4 Jul 2022, Maciej W. Rozycki wrote: > These instructions are only produced via an expander already, so change > the expander to emit individual RTL insns for each machine instruction > in the ultimate ultimate sequence produced rather than deferring to a > single RTL in

[committed] RISC-V/doc: Correct the name of `-mriscv-attribute'

Correct the name of the `-mriscv-attribute' invocation option, including a typo in the negated form. gcc/ * doc/invoke.texi (Option Summary): Fix `-mno-riscv-attribute'. (RISC-V Options): Likewise, and `-mriscv-attribute'. --- Hi, Verified with `make info pdf' and commit

[committed] RISC-V/doc: Correct the formatting of `-mstack-protector-guard-reg='

Add missing second space around the `-mstack-protector-guard-reg=' invocation option. gcc/ * doc/invoke.texi (Option Summary): Add missing second space around `-mstack-protector-guard-reg='. --- Hi, Verified with `make info pdf' and committed as obvious. Maciej ---

[committed] RISC-V/doc: Add index references for `mrelax' and `mriscv-attribute'

Add missing index references for the `-mrelax' and `-mriscv-attribute' invocation options. gcc/ * doc/invoke.texi (RISC-V Options): Add index references for `mrelax' and `mriscv-attribute'. --- Hi, Verified with `make info pdf' and committed as obvious. Maciej --- g

[PATCH] RISC-V: Add RTX costs for `if_then_else' expressions

Fix a performance regression from commit 391500af1932 ("Do not ignore costs of jump insns in combine."), a part of the m68k series for MODE_CC conversion (), observed in soft-fp code in libgcc used by some of the embench-iot benchmarks.

Re: [PATCH] ifcvt: Improve noce_try_store_flag_mask [PR105314]

Hi Jakub, On Tue, 26 Apr 2022, Jakub Jelinek via Gcc-patches wrote: > The following testcase regressed on riscv due to the splitting of critical > edges in the sink pass, similarly to x86_64 compared to GCC 11 we now swap > the edges, whether true or false edge goes to an empty forwarded bb. > >F

[PATCH] doc: Clarify FENV_ACCESS pragma semantics WRT `-ftrapping-math'

Our documentation indicates that it is the `-frounding-math' invocation option that controls whether we respect what the FENV_ACCESS pragma would imply, should we implement it, regarding the floating point environment. It is only a part of the picture however, because the `-ftrapping-math' inv

[PATCH] RISC-V: Remove duplicate backslashes from `stack_protect_set_'

Remove redundant duplicate backslash characters from \t sequences in the output pattern of the `stack_protect_set_' RTL insn. gcc/ * gcc/config/riscv/riscv.md (stack_protect_set_): Remove duplicate backslashes. --- Hi, I don't know why it doesn't matter whether the back

[PATCH] RISC-V: Standardize formatting of SFB ALU conditional move

Standardize the formatting of SFB ALU conditional move operations from: beq a2,zero,1f; mv a0,zero; 1: # movcc to: beq a2,zero,1f # movcc mv a0,zero 1: for consistency with other assembly code produced. No functional change. gcc/ * gcc/con

Re: [PATCH] RISC-V: Add RTX costs for `if_then_else' expressions

On Thu, 21 Jul 2022, Kito Cheng wrote: > LGTM, thanks for modeling this in cost model! Patch applied now, thank you for your review. Maciej

Re: [PATCH] RISC-V: Remove duplicate backslashes from `stack_protect_set_'

On Wed, 27 Jul 2022, Kito Cheng wrote: > Ooops, thanks for fixing that, the change was gotten from kernel > folks. I assume they have already used that for a while, but it's > really weird no bug report from those guys... > > OK for trunk and backport for release branch. Change now committed an

Re: [PING][PATCH v2] RISC-V: Split unordered FP comparisons into individual RTL insns

Hi Kito, > I am convinced that is OK for now, I agree modeling fflags would be a > rabbit hole, I tried to build a full GNU toolchain with my quick patch > and saw many ICE during build libraries, that definitely should be a > long-term optimization project. > > Although I'm thinking if we should

Re: [PATCH] doc: Clarify FENV_ACCESS pragma semantics WRT `-ftrapping-math'

On Wed, 27 Jul 2022, Joseph Myers wrote: > > gcc/ > > * doc/implement-c.texi (Floating point implementation): Mention > > `-fno-trapping-math' in the context of FENV_ACCESS pragma. > > * doc/invoke.texi (Optimize Options): Clarify FENV_ACCESS pragma > > implication in the descr

[PATCH] RISC-V/testsuite: Restrict remaining `fmin'/`fmax' tests to hard float

Complement commit 7915f6551343 ("RISC-V/testsuite: constraint some of tests to hard_float") and also restrict the remaining `fmin'/`fmax' tests to hard-float test configurations. gcc/testsuite/ * gcc.target/riscv/fmax-snan.c: Add `dg-require-effective-target hard_float'.

Re: [PATCH] Mips: Fix the ASAN shadow offset hook for the n32 ABI

On Mon, 6 Jun 2022, Dimitrije Milosevic wrote: > * config/mips/mips.cc (mips_asan_shadow_offset): Reformat > to handle the N32 ABI. That's not what the change does. > * config/mips/mips.h (SUBTARGET_SHADOW_OFFSET): Remove > the macro, as it is not needed anymore.

[PATCH] RISC-V: Avoid redundant sign-extension for SImode SGE, SGEU, SLE, SLEU

We produce inefficient code for some synthesized SImode conditional set operations (i.e. ones that are not directly implemented in hardware) on RV64. For example a piece of C code like this: int sleu (unsigned int x, unsigned int y) { return x <= y; } gets compiled (at `-O2') to this: sleu:

Re: [RFC] Combine zero_extract and sign_extend for TARGET_TRULY_NOOP_TRUNCATION

On Thu, 3 Aug 2023, YunQiang Su wrote: > PR #104914 Please don't cc me on MIPS matters, I have told you I have withdrawn my interest in this architecture on the GCC side. Thank you. Maciej

Re: [committed][RISC-V] Fix 20010221-1.c with zicond

On Fri, 4 Aug 2023, Jeff Law via Gcc-patches wrote: > It's also something I kept meaning to resolve and your submission just gave me > the proper motivation to move zicond forward. The target specific bits you > did lined up perfectly with the community feedback on the original VRULL > implementa

Re: [PATCH] RISC-V: Return machine_mode rather than opt_machine_mode for get_mask_mode, NFC

On Mon, 31 Jul 2023, Maciej W. Rozycki wrote: > > > That's a good suggestion! Thanks, let me try to apply myself workflow :) > > I'm thinking that as part of the CI POC being done by RISE that the base AMI > > image ought to be gcc-13 based and that we should c

Re: [committed][RISC-V] Fix 20010221-1.c with zicond

On Tue, 8 Aug 2023, Jeff Law wrote: > > I wonder however why do we need so much more code, including the middle > > end too, to support this ISA extension than we do for the very same set of > > MIPSr6 instructions under ISA_HAS_SEL, hmm... > Because it doesn't handle as many cases as we're hand

[PATCH 0/3] testsuite: Exclude vector tests for unsupported targets

Hi, In the course of verifying an out-of-tree RISC-V target that has a vendor extension providing hardware support for vector operations on pairs of single floating-point values (similar to MIPS paired-single or Power SPE vector types) I have come across a couple of tests that fail just because

[PATCH 1/3] testsuite: Add check for vectors of 128 bits being supported

Similarly to checks for vectors of 32 bits and 64 bits being supported add one for vectors of 128 bits. gcc/testsuite/ * lib/target-supports.exp (check_effective_target_vect128): New procedure. --- gcc/testsuite/lib/target-supports.exp |6 ++ 1 file changed, 6 in

[PATCH 2/3] testsuite: Require 128-bit vectors for bb-slp-pr95839.c

The bb-slp-pr95839.c test assumes quad-single float vector support, but some targets only support pairs of floats, causing this test to fail with such targets. Limit this test to targets that support at least 128-bit vectors then, and add a complementing test that can be run with targets that

[PATCH 3/3] testsuite: Require vectors of doubles for pr97428.c

The pr97428.c test assumes support for vectors of doubles, but some targets only support vectors of floats, causing this test to fail with such targets. Limit this test to targets that support vectors of doubles then. gcc/testsuite/ * gcc.dg/vect/pr97428.c: Limit to `vect_doubl

Re: [PATCH 1/3] testsuite: Add check for vectors of 128 bits being supported

On Fri, 7 Jul 2023, Richard Biener wrote: > > Similarly to checks for vectors of 32 bits and 64 bits being supported > > add one for vectors of 128 bits. > > OK Thanks for the review, however this is only needed for 2/3 at this point, so I'll only push it if 2/3 gets a go-ahead (and still need

Re: [PATCH 2/3] testsuite: Require 128-bit vectors for bb-slp-pr95839.c

On Fri, 7 Jul 2023, Richard Biener wrote: > > The bb-slp-pr95839.c test assumes quad-single float vector support, but > > some targets only support pairs of floats, causing this test to fail > > with such targets. Limit this test to targets that support at least > > 128-bit vectors then, and add

Re: [PATCH 3/3] testsuite: Require vectors of doubles for pr97428.c

On Fri, 7 Jul 2023, Richard Biener wrote: > > The pr97428.c test assumes support for vectors of doubles, but some > > targets only support vectors of floats, causing this test to fail with > > such targets. Limit this test to targets that support vectors of > > doubles then. > > OK. Applied, t

[PING][PATCH RFA] PR target/111815: VAX: Only accept the index scaler as the RHS operand to ASHIFT

On Mon, 16 Oct 2023, Maciej W. Rozycki wrote: > The testcase is generic enough I thought it wouldn't hurt to place it in > a generic part of the testsuite, where it has been verified to pass with > the `powerpc64le-linux-gnu', `riscv64-linux-gnu', and `vax-netbsdelf&#

Re: RISC-V: Add divmod instruction support

On Sat, 18 Feb 2023, Andrew Pinski via Gcc-patches wrote: > > > If we have division and remainder calculations with the same operands: > > > > > > a = b / c; > > > d = b % c; > > > > > > We can replace the calculation of remainder with multiplication + > > > subtraction, using the result from

Re: RISC-V: Add divmod instruction support

On Sat, 18 Feb 2023, Jeff Law wrote: > > Barring the fusion case, which indeed asks for a dedicated `divmod' > > pattern (and then I suppose a post-reload splitter or a peephole so that > > where one of the two results produced has eventually turned out unused, we > > have means to discard the u

Re: [gcc r13-6315] MIPS: Add pattern for clo

On Fri, 24 Feb 2023, YunQiang Su via Gcc-cvs wrote: > https://gcc.gnu.org/g:19aa3900bca808b49417a7aef295b5f1a583c298 > > commit r13-6315-g19aa3900bca808b49417a7aef295b5f1a583c298 > Author: Junxian Zhu > Date: Fri Feb 17 16:35:56 2023 +0800 > > MIPS: Add pattern for clo We are in Stage 4

Re: RISC-V: Add divmod instruction support

On Mon, 20 Feb 2023, Alexander Monakov wrote: > > > That's the kind of stuff I'd expect to happen at the tree level though, > > > before expand. > > > > The GIMPLE pass forming divmod could indeed choose to emit the > > div + mul/sub sequence instead if an actual divmod pattern isn't available.

Re: [RFC PATCH v1 08/10] ifcvt: add if-conversion to conditional-zero instructions

On Mon, 13 Feb 2023, Jeff Law via Gcc-patches wrote: > 3. The canaonical conditional-zero-or-value assumes the target can do a > generic SEQ/SNE of two register values. As you know, on RISC-V we have > SEQZ/SNEZ. So we've added another fallback path to handle that case in > noce_emit_condzero.

Re: [PATCH] Turn on LRA on all targets

On Sun, 23 Apr 2023, Segher Boessenkool wrote: > > There are extra ICEs in regression testing and code quality is poor; cf. > > . > > Do you have something you can show for this? Maybe in a PR? I have filed no PRs as I did

Re: [PATCH v2 0/9] MIPS: Add MIPS16e2 ASE instrucions.

Hi Jie, Thank you for your submission. Since I was a member of the team that developed this ASE in cooperation with the hardware group, I did the binutils part, and it was even myself who came up with the name for the ASE in an internal discussion, I feel somewhat responsible for this featur

Re: [committed] Enable LRA on several ports

On Tue, 2 May 2023, Jeff Law via Gcc-patches wrote: > Well, I'd say that my plan would be to deprecate any target that is not > converted by the end of this development cycle. So the change keeps cris from > falling into that bucket. As I noted in the other thread it is highly unlikely I will m

Re: [PATCH] add glibc-stdint.h to vax and lm32 linux target (PR target/105525)

On Sat, 29 Apr 2023, Jeff Law via Gcc-patches wrote: > > PR target/105525 is a build regression for the vax and lm32 linux > > targets present in gcc-12/13/head, where the builds fail due to > > unsatisfied references to __INTPTR_TYPE__ and __UINTPTR_TYPE__, > > caused by these two targets failing

Re: [PATCH] MIPS: don't expand large block move

On Fri, 19 May 2023, Jeff Law wrote: > > diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc > > index ca491b981a3..00f26d5e923 100644 > > --- a/gcc/config/mips/mips.cc > > +++ b/gcc/config/mips/mips.cc > > @@ -8313,6 +8313,12 @@ mips_expand_block_move (rtx dest, rtx src, rtx > > length

Re: [PATCH] add glibc-stdint.h to vax and lm32 linux target (PR target/105525)

On Fri, 19 May 2023, Mikael Pettersson wrote: > > Hmm, I find it quite insteresting and indeed encouraging that someone > > actually verifies our VAX/Linux target. > > > > Mikael, how do you actually verify it however? > > My vax builds are only cross-compilers without kernel headers or libc.

[committed] MAINTAINERS: Update my e-mail address

Erven Rohou Ira Rosen Yvan Roux -Maciej W. Rozycki +Maciej W. Rozycki Silvius Rus

Re: [PATCH] VAX/testsuite: Remove notsi comparison elimination regressions

On Mon, 11 Jan 2021, Jeff Law wrote: > I think most are posting the stdout from the check run. So we don't > generally get all the pass/xfail messages, but we do get fail/xpass > messages. They don't need to be triaged or anything. I now have the results, though I had to trim them by hand fro

Re: [PATCH 2/3] MIPS: add builtime option for -mcompact-branches

On Tue, 16 Feb 2021, Jeff Law via Gcc-patches wrote: > > diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi > > index 4c38244ae58..6b9520569ba 100644 > > --- a/gcc/doc/install.texi > > +++ b/gcc/doc/install.texi > > @@ -1464,6 +1464,29 @@ systems that support conditional traps). > > Divisio

Re: [PATCH 1/3] MIPS: add -mcompact-branches=prefer option

On Tue, 16 Feb 2021, Jeff Law via Gcc-patches wrote: > I think this will be OK once the wording in patch 2/3 of this series is > fixed. As I noted with 2/3 I would like to know what this extra complication is exactly needed for, and then whether we can't reuse the existing options. Once settl

Re: [PATCH 2/3] MIPS: add builtime option for -mcompact-branches

On Fri, 19 Feb 2021, YunQiang Su wrote: > > My understanding therefore is that the original assumption that `optimal' > > will serve people best is no longer true. > > > > I guess that `optimal' can still produce the best performance, while > the delay slot > make MIPS quite differnent with othe

Re: [PATCH v4 1/2] MIPS: Not trigger error for pre-R6 and -mcompact-branches=always

On Wed, 3 Mar 2021, Jeff Law wrote: > > gcc/testsuite/ChangeLog: > > * gcc.target/mips/compact-branches-1.c: add isa_rev>=6. > > * gcc.target/mips/mips.exp: don't add -mipsXXr6 option for > > -mcompact-branches=always. It is usable for pre-R6 now. > > * gcc.target/mips/compact-bran

Re: dg-options after board/cflags

On Wed, 2 Sep 2020, Jose E. Marchesi via Gcc-patches wrote: > Your patch dealt with board/multilib_flags, but the same problem exists > for board/cflags and many other flag-containing options. What's the use case for that? IIUC board flags are supposed to be ones that are absolutely required f

Re: [PATCH] RISC-V/libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

Hi Jim, > On Sun, Aug 30, 2020 at 11:39 PM Kito Cheng wrote > > Hi Maciej: > > LGTM, thanks for your patch! > > I don't see this patch in the FSF GCC tree. Maciej are you going to > commit it? Or do you want us to commit it for you? Since my departure from WDC I have been largely away, trave

Re: [PATCH] RISC-V: Derive ABI from -march if -mabi is not present.

On Tue, 6 Oct 2020, Kito Cheng wrote: > I think this patch is kind of major change for GCC RISC-V port, so I cc all > RISC-V gcc maintainer to make sure this change is fine with you guys. > > - Motivation of this patch: >1. Sync behavior between clang/llvm. >2. Preparation for -mcpu opti

[PATCH] MIPS/libphobos: Fix switchcontext.S assembly for MIPS I ISA

Correct MIPS I assembly build errors in switchcontext.S: .../libphobos/libdruntime/config/mips/switchcontext.S: Assembler messages: .../libphobos/libdruntime/config/mips/switchcontext.S:50: Error: opcode not supported on this processor: mips1 (mips1) `sdc1 $f20,(0*8-((6*8+4+(-6*8+4&7($sp)'

Re: [PATCH] MIPS: fix building on multiarch platform

On Wed, 21 Sep 2022, Xi Ruoyao wrote: > > diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h > > index 74b6e11aabb..fe7f5b274b9 100644 > > --- a/gcc/config/mips/mips.h > > +++ b/gcc/config/mips/mips.h > > @@ -3427,6 +3427,7 @@ struct GTY(())  machine_function { > >   > >  /* If we are *n

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

On Sat, 12 Mar 2022, Xi Ruoyao via Gcc-patches wrote: > I'm now thinking: is there always at least one *GPR* which need to be > cleared? If it's true, let's say GPR $12, and fcc0 & fcc2 needs to be > cleared, we can use something like: > > cfc1 $12, $25 > andi $25, 5 > ctc1 $12, $25 > move $12,

Re: [PATCH v3] MIPS: IPL is 8bit in Cause and Status registers if TARGET_MCU

On Tue, 15 Mar 2022, YunQiang Su wrote: > If MIPS MCU extension is enable, the IPL section in Cause and Status > registers has been expand to 8bit instead of 6bit. > > In Cause: the bits are 10-17. > In Status: the bits are 10-16 and 18. > > MD00834-2B-MUCON-AFP-01.03.pdf: P49 and P61. I can s

[PATCH] RISC-V: Fix use-after-free error in `parse_multiletter_ext'

Avoid undefined arithmetic involving a pointer to a heap allocation that has been freed and move a problematic calculation ahead of the following call to `free' in `riscv_subset_list::parse_multiletter_ext', removing a compilation error: .../gcc/common/config/riscv/riscv-common.cc: In member fu

Re: [PATCH] RISC-V: Fix use-after-free error in `parse_multiletter_ext'

On Wed, 19 Jan 2022, Kito Cheng wrote: > LGTM, thanks :) > > > Avoid undefined arithmetic involving a pointer to a heap allocation that > > has been freed and move a problematic calculation ahead of the following > > call to `free' in `riscv_subset_list::parse_multiletter_ext', removing a > > com

Re: [PATCH] mips: Improved RTL representation of wsbh/dsbh/dshd

Hi Roger, > This patch to the mips backend updates the representations used > internally for MIPS' wsbh, dsbh and dshd instructions. These were > previously described using an UNSPEC rtx, which prevents simplification > at the RTL level. In addition to now being able to eliminate rotate > instru

[PATCH][GCC13?] RISC-V: Replace `smin'/`smax' RTL patterns with `fmin'/`fmax'

RISC-V FMIN and FMAX machine instructions are IEEE-754-conformant[1]: "For FMIN and FMAX, if at least one input is a signaling NaN, or if both inputs are quiet NaNs, the result is the canonical NaN. If one operand is a quiet NaN and the other is not a NaN, the result is the non-NaN operand."

Re: [PATCH][GCC13?] RISC-V: Replace `smin'/`smax' RTL patterns with `fmin'/`fmax'

On Thu, 20 Jan 2022, Joseph Myers wrote: > > The old formulation of the instructions were never ratified as a > > RISC-V standard. I don't think we need to hamstring ourselves here by > > assuming the possibility of their implementation. > > If you ignore the old version, then the instructions c

Re: [PATCH] riscv: fix -Wformat-diag errors.

On Tue, 18 Jan 2022, Palmer Dabbelt wrote: > Yep. Seeing this go by, though, I think there's some English issues with the > original messages. I'd write it more like this, but I'm never 100% sure on > these things: > >diff --git a/gcc/common/config/riscv/riscv-common.cc > b/gcc/common/confi

Re: [PATCH][GCC13?] RISC-V: Replace `smin'/`smax' RTL patterns with `fmin'/`fmax'

On Mon, 24 Jan 2022, Joseph Myers wrote: > > I think we have consensus that we can ignore pre-r2.2 hardware. What we > > actually support is `-misa-spec=<2.2|20190608|20191213>', so we can assume > > r2.2 semantics as the absolute minimum, matching the description in my > > submission. > > W

Re: [PATCH] MIPS: use 8bit for IPL in Cause register

On Wed, 26 Jan 2022, YunQiang Su wrote: > Since MIPS r2, the IPL section in Cause register has been expand > to 8bit instead of 6bit. Hmm, I cannot see it in my copy of the architecture manual I'm afraid. The interpretation may have changed, but the field is still 6-bit (not counting the soft

[PATCH v2][GCC13] RISC-V: Provide `fmin'/`fmax' RTL patterns

As at r2.2 of the RISC-V ISA specification[1] the FMIN and FMAX machine instructions fully match our requirement for the `fminM3' and `fmaxM3' standard RTL patterns: "For FMIN and FMAX, if at least one input is a signaling NaN, or if both inputs are quiet NaNs, the result is the canonical NaN.

Re: [PATCH][GCC13?] RISC-V: Replace `smin'/`smax' RTL patterns with `fmin'/`fmax'

On Wed, 26 Jan 2022, Joseph Myers wrote: > fmin and fmax: > > * Treat quiet NaN as missing data and return the other argument (if a > number). > > * Treat signaling NaN like most functions (raise invalid, return quiet > NaN). > > fminimum and fmaximum: > > * Treat quiet NaN like most functio

[PATCH][GCC13] Don't force side effects for hardware vector element broadcast

Do not mark vector element broadcast resulting from OpenCL operations as having side effects for targets that have a suitable hardware operation, so that the `vec_duplicateM' standard RTL pattern can be directly used for them. This does not happen currently, because any RTL pattern named `vec_

Re: [PATCH][GCC13] Don't force side effects for hardware vector element broadcast

On Thu, 27 Jan 2022, Richard Biener wrote: > > Index: gcc/gcc/c/c-typeck.cc > > === > > --- gcc.orig/gcc/c/c-typeck.cc > > +++ gcc/gcc/c/c-typeck.cc > > @@ -49,6 +49,7 @@ along with GCC; see the file COPYING3. > > #include "gomp-cons

Re: [PATCH][GCC13] Don't force side effects for hardware vector element broadcast

On Thu, 27 Jan 2022, Richard Biener wrote: > > > > Index: gcc/gcc/c/c-typeck.cc > > > > === > > > > --- gcc.orig/gcc/c/c-typeck.cc > > > > +++ gcc/gcc/c/c-typeck.cc > > > > @@ -49,6 +49,7 @@ along with GCC; see the file COPYING3. > >

[PATCH] RISC-V: Document `auipc' and `bitmanip' `type' attributes

Document new `auipc' and `bitmanip' `type' attributes added respectively with commit 88108b27dda9 ("RISC-V: Add sifive-7 pipeline description.") and commit 283b1707f237 ("RISC-V: Implement instruction patterns for ZBA extension.") but not listed so far. gcc/ * config/riscv/riscv

Re: [PATCH] RISC-V: Document `auipc' and `bitmanip' `type' attributes

On Thu, 27 Jan 2022, Andrew Waterman wrote: > LGTM, thanks for correcting this oversight in my patch. Committed, thanks for your review! Maciej

Re: [PATCH][GCC13] Don't force side effects for hardware vector element broadcast

On Fri, 28 Jan 2022, Richard Biener wrote: > > that's not what it does. It treats it like > > > > float tem = f; > > return x + { tem, tem, tem, tem }; > > > > avoiding, like for x + (1.0f + f) creating > > > > return x + { 1.0+f, 1.0+f, 1.0+f ...} > > > > it's more CSE than volatile qualif

[PATCH] RISC-V: Add target machine headers as a dependency for riscv-sr.o

Make riscv-sr.o depend on target machine headers, removing spurious test failures: FAIL: gcc.target/riscv/save-restore-3.c scan-assembler-not call[ \t]*t0,__riscv_save_0 FAIL: gcc.target/riscv/save-restore-3.c scan-assembler-not tail[ \t]*__riscv_restore_0 FAIL: gcc.target/riscv/save-restore-3.c

[PATCH] RISC-V/testsuite: Run target testing over all the usual optimization levels

Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the RISC-V testsuite as several targets already do. Adjust test options across individual test cases accordingly where required. As some tests want to be run at `-Og', add a suitable optimization variant via ADDITIONAL_TORTURE_OP

[PATCH v3][GCC13] RISC-V: Provide `fmin'/`fmax' RTL patterns

As at r2.2 of the RISC-V ISA specification[1] (equivalent to version 2.0 of the "F" and "D" standard architecture extensions for single-precision and double-precision floating-point respectively) the FMIN and FMAX machine instructions fully match our requirement for the `fminM3' and `fmaxM3' st

  1   2   3   4   5   6   7   8   9   >