[PING^5][PATCH] Alpha: Fix base block alignment calculation regression

On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: > Address this issue by recursing into COMPONENT_REF tree nodes until the > outermost one has been reached, which is supposed to be a MEM_REF one, > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > Also use

[PING^4][PATCH] Alpha: Fix base block alignment calculation regression

On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: > Address this issue by recursing into COMPONENT_REF tree nodes until the > outermost one has been reached, which is supposed to be a MEM_REF one, > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > Also use

Re: [PATCH v2 04/18] Add microMIPS R6 support

On Mon, 17 Mar 2025, Aleksandar Rakic wrote: > * config/mips/mips.h: > (TARGET_MICROMIPS_R6): Define. Umm, this change can't go forward I'm afraid without microMIPSr6 support landing in binutils first. Otherwise we have no consumer for compiled code available. Also is there a way

[PING^3][PATCH] Alpha: Fix base block alignment calculation regression

On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: > Address this issue by recursing into COMPONENT_REF tree nodes until the > outermost one has been reached, which is supposed to be a MEM_REF one, > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > Also use

Re: [PING][PATCH v3 0/4] Fix data races with sub-longword accesses on Alpha

On Sat, 22 Mar 2025, Maciej W. Rozycki wrote: > > This is v3 of the series comprising the final 4 outstanding changes. I > > note that the corresponding v2 patches have been approved, but concerns > > were discussed, which this update has addressed. > &

[PING][PATCH v3 0/4] Fix data races with sub-longword accesses on Alpha

On Tue, 11 Mar 2025, Maciej W. Rozycki wrote: > This is v3 of the series comprising the final 4 outstanding changes. I > note that the corresponding v2 patches have been approved, but concerns > were discussed, which this update has addressed. Ping for: <https://inbox.source

[PING^2][PATCH] Alpha: Fix base block alignment calculation regression

On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: > Address this issue by recursing into COMPONENT_REF tree nodes until the > outermost one has been reached, which is supposed to be a MEM_REF one, > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > Also use

[PING][PATCH] Alpha: Fix base block alignment calculation regression

On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: > Address this issue by recursing into COMPONENT_REF tree nodes until the > outermost one has been reached, which is supposed to be a MEM_REF one, > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > Also use

[PATCH v3 3/4] Alpha: Add option to avoid data races for sub-longword memory stores [PR117759]

With non-BWX Alpha implementations we have a problem of data races where a 8-bit byte or 16-bit word quantity is to be written to memory in that in those cases we use an unprotected RMW access of a 32-bit longword or 64-bit quadword width. If contents of the longword or quadword accessed outsi

[PATCH v3 0/4] Fix data races with sub-longword accesses on Alpha

Hi, This is v3 of the series comprising the final 4 outstanding changes. I note that the corresponding v2 patches have been approved, but concerns were discussed, which this update has addressed. This series has come out of a discussion[1] around the removal of non-BWX Alpha support from th

[PATCH v3 4/4] Alpha: Add option to avoid data races for partial writes [PR117759]

Similarly to data races with 8-bit byte or 16-bit word quantity memory writes on non-BWX Alpha implementations we have the same problem even on BWX implementations with partial memory writes produced for unaligned stores as well as block memory move and clear operations. This happens at the bo

[PATCH v2 2/4] IRA+LRA: Also split basic blocks if number of labels changed

The next change for Alpha will produce extra labels and branches in reload, which in turn requires basic blocks to be split at completion. We do this already for functions that can trap, so just extend the arrangement with a check for the changed number of labels necessarily implied by the extr

[PATCH v3 1/4] Alpha: Export `emit_unlikely_jump' for a subsequent change to use

Rename `emit_unlikely_jump' function to `alpha_emit_unlikely_jump', so as to avoid namespace pollution, updating callers accordingly and export it for use in the machine description. Make it return the insn emitted. gcc/ * config/alpha/alpha-protos.h (alpha_emit_unlikely_jump):

Re: [PATCH v2 5/7] IRA+LRA: Let the backend request to split basic blocks

On Mon, 6 Jan 2025, Richard Sandiford wrote: > > This was approved by Richard Sandiford in v1, so I'll commit it along with > > 6/7, which relies on it. > > Still stands, but I didn't think of this before, so thought I'd ask: Sure, it's never wrong to revisit things as new ideas pop in. > Wou

Re: [PATCH v2 7/7] Alpha: Add option to avoid data races for partial writes [PR117759]

On Mon, 13 Jan 2025, Jeff Law wrote: > > + For non-BWX targets we need to load data from memory, mask it such as > > + to keep any part outside the area written, insert data to be stored, > > + and write the result back atomically. For sizes that are not a power > > + of 2 there are no by

Re: [PATCH v2 6/7] Alpha: Add option to avoid data races for sub-longword memory stores [PR117759]

On Mon, 6 Jan 2025, Jeff Law wrote: > > I note that the atomic sequences emitted are suboptimal performance-wise > > as the looping branch for the unsuccessful completion of the sequence > > points backwards, which means it will be predicted as taken despite that > > in most cases it will fall thr

[committed][wwwdocs] Correct the MIPS O64 floating-point argument passing convention

Update according to the amendment made for GCC 4.0.0 with commit b11a9d5f3f90 back in 2004: (mips_arg_info): Don't allow fpr_p to affect the register or stack alignment. Remove o64 silliness. Retain the description of the former semantics for reference. --- htdocs/projects/mipso

[PATCH] Alpha: Fix base block alignment calculation regression

In determination of base block alignment we only examine a COMPONENT_REF tree node at hand without ever checking if its ultimate alignment has been reduced by the combined offset going back to the outermost object. Consequently cases have been observed where quadword accesses have been produce

Re: [committed] libphobos: Add MIPS64 implementation of fiber_switchContext [PR118584]

On Thu, 23 Jan 2025, Maciej W. Rozycki wrote: > > This patch adds a MIPS64 implementation of `fiber_switchContext', > > replacing the generic implementation. The `core.thread.fiber' module > > already defines version=AsmExternal on mips64el-linux-gnuabi64 targets.

Re: [committed] libphobos: Add MIPS64 implementation of fiber_switchContext [PR118584]

On Tue, 21 Jan 2025, Iain Buclaw wrote: > This patch adds a MIPS64 implementation of `fiber_switchContext', > replacing the generic implementation. The `core.thread.fiber' module > already defines version=AsmExternal on mips64el-linux-gnuabi64 targets. Don't you need similar code for n32 MIPS64

Re: [PATCH] MIPS: Add conditions for use of the -mmips16e2 and -mips16 option.

On Thu, 16 Jan 2025, Jie Mei wrote: > Make -mmips16e2 imply -mips16 as the ASE requires, so users won't > be surprised even if they expect it to. Meanwhile, check if > mips_isa_rev <= 5 when -mips16 is effective and >= 1 when -mmips16e2 > is effective. MIPSr1 is incompatible with MIPS16e2, and t

Re: [PATCH v2 3/7] Alpha: Fix a block move pessimisation with zero-extension after LDWU

On Mon, 6 Jan 2025, Jeff Law wrote: > > gcc/ > > * config/alpha/alpha.cc (alpha_expand_block_move): Use a HImode > > subreg of a DImode register to hold data from an aligned HImode > > load. > Generally OK. > > > > + data_regs[nregs++] = gen_rtx_SUBREG (HImode, tmp, 0); > W

Re: [PATCH v2 2/7] Alpha: Optimize block moves coming from longword-aligned source

On Mon, 6 Jan 2025, Jeff Law wrote: > > gcc/ > > * config/alpha/alpha.cc (alpha_expand_block_move): Merge loaded > > data from pairs of SImode registers into single DImode registers > > if to be used with unaligned stores. > > > > gcc/testsuite/ > > * gcc.target/alpha/memc

Re: [PATCH v2 1/7] Alpha: Always respect -mbwx, -mcix, -mfix, -mmax, and their inverse

On Mon, 6 Jan 2025, Jeff Law wrote: > > gcc/ > > * config/alpha/alpha.cc (alpha_option_override): Ignore CPU > > flags corresponding to features the enabling or disabling of > > which has been requested with an individual feature option. > > > > gcc/testsuite/ > > * gcc.ta

Re: [PATCH 1/2] Alpha: Add memory clobbers to `builtin_longjmp' expansion

On Mon, 6 Jan 2025, Jeff Law wrote: > > gcc/ > > * config/alpha/alpha.md (builtin_longjmp): Add memory clobbers. > OK Applied now, thanks for your review. Maciej

Re: [PATCH 2/2] Alpha: Restore frame pointer last in `builtin_longjmp' [PR64242]

On Mon, 6 Jan 2025, Jeff Law wrote: > > gcc/ > > PR middle-end/64242 > > * gcc/config/alpha/alpha.md (`builtin_longjmp'): Restore frame > > pointer last. Add frame clobber and schedule blockage. > OK. Applied now (with an obvious correction to ChangeLog), thanks for your review

Re: [Ada] Fix PR ada/118247

On Tue, 7 Jan 2025, Eric Botcazou wrote: > > The fix feels hackish and I wonder how other frontends handle this, but > > overall thank you for taking care of this peculiarity. > > You're welcome. The main Makefile does the same for xgcc -> gcc-cross and, > as this example shows, every change is

Re: [Ada] Fix PR ada/118247

On Mon, 6 Jan 2025, Eric Botcazou wrote: > This is a regression introduced by > https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/405522.html > in the form of a spurious relinking of the gnatbind executable for the > install > target of cross Ada compilers. The fix feels hackish and I wonder h

Re: [PATCH] Alpha: Always respect -mbwx, -mcix, -mfix, -mmax, and their inverse

On Mon, 30 Dec 2024, Maciej W. Rozycki wrote: > > Contrary to user documentation the `-mbwx', `-mcix', `-mfix', `-mmax' > > feature options and their inverse forms are ignored whenever `-mcpu=' > > option is in effect, either by having been given

[PATCH v2 5/7] IRA+LRA: Let the backend request to split basic blocks

The next change for Alpha will produce extra labels and branches in reload, which in turn requires basic blocks to be split at completion. We do this already for functions that can trap, so just extend the arrangement with a flag for the backend to use whenever it finds it necessary. g

[PATCH v2 4/7] Alpha: Export `emit_unlikely_jump' for a subsequent change to use

Rename `emit_unlikely_jump' function to `alpha_emit_unlikely_jump', so as to avoid namespace pollution, updating callers accordingly and export it for use in the machine description. Make it return the insn emitted. gcc/ * config/alpha/alpha-protos.h (alpha_emit_unlikely_jump):

[PATCH v2 3/7] Alpha: Fix a block move pessimisation with zero-extension after LDWU

For the BWX case we have a pessimisation in `alpha_expand_block_move' for HImode loads where we place the data loaded into a HImode register as well, therefore losing information that indeed the data loaded has already been zero-extended to the full DImode width of the register. Later on when

[PATCH v2 7/7] Alpha: Add option to avoid data races for partial writes [PR117759]

Similarly to data races with 8-bit byte or 16-bit word quantity memory writes on non-BWX Alpha implementations we have the same problem even on BWX implementations with partial memory writes produced for unaligned stores as well as block memory move and clear operations. This happens at the bo

[PATCH v2 6/7] Alpha: Add option to avoid data races for sub-longword memory stores [PR117759]

With non-BWX Alpha implementations we have a problem of data races where a 8-bit byte or 16-bit word quantity is to be written to memory in that in those cases we use an unprotected RMW access of a 32-bit longword or 64-bit quadword width. If contents of the longword or quadword accessed outsi

[PATCH v2 2/7] Alpha: Optimize block moves coming from longword-aligned source

Now that we have proper alignment determination for block moves in place the case of copying a block of longword-aligned data has become real, so implement the merging of loaded data from pairs of SImode registers into single DImode registers for the purpose of using with unaligned stores effic

[PATCH v2 1/7] Alpha: Always respect -mbwx, -mcix, -mfix, -mmax, and their inverse

Contrary to user documentation the `-mbwx', `-mcix', `-mfix', `-mmax' feature options and their inverse forms are ignored whenever `-mcpu=' option is in effect, either by having been given explicitly or where configured as the default such as with the `alphaev56-linux-gnu' target. In the latte

[PATCH v2 0/7] Fix data races with sub-longword accesses on Alpha

Hi, This is v2 of the series updated according to the outcome from testing with a BWX system. Only test cases have been updated and no changes have been made to actual code and obviously only the patches still outstanding have been included. Additionally 1/7 has been folded into this series

[PATCH 1/2] Alpha: Add memory clobbers to `builtin_longjmp' expansion

Add the same memory clobbers to `builtin_longjmp' for Alpha as with commit 41439bf6a647 ("builtins.c (expand_builtin_longjmp): Added two memory clobbers."), to prevent instructions that access memory via the frame or stack pointer from being moved across the write to the frame pointer.

[PATCH 2/2] Alpha: Restore frame pointer last in `builtin_longjmp' [PR64242]

Add similar arrangements to `builtin_longjmp' for Alpha as with commit 71b144289c1c ("re PR middle-end/64242 (Longjmp expansion incorrect)") and commit 511ed59d0b04 ("Fix PR64242 - Longjmp expansion incorrect"), so as to restore the frame pointer last, so that accesses to a local buffer supplie

[PATCH 0/2] Alpha: Fix issues with `builtin_longjmp'

Hi, In the course of verifying my data race fix patch series[1] with a BWX system (credit to Magnus Lindholm for sharing hardware for the purpose of this effort) I came across a suspicious progression triggered with the newly-added `-msafe-partial' option and certain optimisations enabled:

Re: [COMMITTED] Fortran: Grammar/markup fixes in intrinsics documentation

On Tue, 31 Dec 2024, Sandra Loosemore wrote: > diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi > index d11d37761d9..b47180126ca 100644 > --- a/gcc/fortran/intrinsic.texi > +++ b/gcc/fortran/intrinsic.texi > @@ -1577,7 +1577,7 @@ if @var{Y} is present, @var{X} shall be REAL. >

Re: [PATCH] Alpha: Always respect -mbwx, -mcix, -mfix, -mmax, and their inverse

On Sun, 29 Dec 2024, Maciej W. Rozycki wrote: > Contrary to user documentation the `-mbwx', `-mcix', `-mfix', `-mmax' > feature options and their inverse forms are ignored whenever `-mcpu=' > option is in effect, either by having been given explicitly or where

[PATCH] Alpha: Always respect -mbwx, -mcix, -mfix, -mmax, and their inverse

Contrary to user documentation the `-mbwx', `-mcix', `-mfix', `-mmax' feature options and their inverse forms are ignored whenever `-mcpu=' option is in effect, either by having been given explicitly or where configured as the default such as with the `alphaev56-linux-gnu' target. In the latte

Re: [PATCH] COBOL 8/8 bld: "meta" files, such a gcc/cobol/Make-lang.in

On Thu, 12 Dec 2024, James K. Lowden wrote: > ChangeLog > * Makefile.def: Add libgcobol module and cobol language. Since this implies the regeneration of top-level Makefile.in please add a ChangeLog entry to that effect and include the changes to Makefile.in produced along with the rest

Re: [PING][PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Sun, 15 Dec 2024, Jeff Law wrote: > > Ping for: > > > > > > > >

Re: [PING][PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Sat, 14 Dec 2024, Jeff Law wrote: > > Ping for: > > > > > > > > (this will presumably need tweak

Re: [PATCH] testsuite: Mark gcc.c-torture/execute/memcpy-a?.c tests expensive

On Tue, 3 Dec 2024, Mike Stump wrote: > > These tests can take several seconds per compilation to complete, taking > > total elapsed time measured in minutes. Mark them as expensive so as to > > let people skip them where they want to save on testing time. > > > > gcc/testsuite/ > > *

[PING][PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Mon, 18 Nov 2024, Maciej W. Rozycki wrote: > As it happens these data races also apply to BWX Alpha systems, as I have > discovered in the course of this effort, although owing to how the Alpha > backend of GCC has implemented block copy and clear operations rather than > act

Re: [patch,avr,testsuite,applied] gcc.c-torture/execute/memcpy-a*.c

On Sun, 1 Dec 2024, Georg-Johann Lay wrote: > > > > As a matter of interest, is the timeout/memory exhaustion observed with > > > > host compilation or target execution? > > > It happens during link, when the linker observes that the memory regions > > > won't fit: > > > > > > .../avr/bin/ld: mem

[PATCH] testsuite: Mark gcc.c-torture/execute/memcpy-a?.c tests expensive

These tests can take several seconds per compilation to complete, taking total elapsed time measured in minutes. Mark them as expensive so as to let people skip them where they want to save on testing time. gcc/testsuite/ * gcc.c-torture/execute/memcpy-a1.c: Mark as expensive.

Re: [patch,avr,testsuite,applied] gcc.c-torture/execute/memcpy-a*.c

On Sat, 30 Nov 2024, Georg-Johann Lay wrote: > The gcc.c-torture/execute/memcpy-a[1248].c tests consumed more time > than the whole rest of the test suite, just to come up with > a "memory full" even at -Os. Skipped thusly. As a matter of interest, is the timeout/memory exhaustion observed with

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Mon, 25 Nov 2024, Richard Biener wrote: > > The full `-msafe-bwa' feature is required for a fix, as the data race > > comes from *outside* rather than from any lack of atomicity of the store > > to the object itself. As the previous value of the object itself is > > discarded, a plain RMW

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Sat, 23 Nov 2024, Maciej W. Rozycki wrote: > I found no previous bug report, so this is now PR target/117759[1]. An > obvious bug fix has been posted for review as well[2]. I gave this issue some thought as I travelled across Europe over the weekend and I have now withdrawn the pr

Re: [PATCH] Alpha: Respect `_Atomic' keyword for HI and QI data on !BWX [PR117759]

On Sat, 23 Nov 2024, Maciej W. Rozycki wrote: > Correct an issue with 8-bit/16-bit stores to `_Atomic' QI and HI data > objects producing non-BWX assembly such as: > > mb > insql $17,$16,$17 > ldq_u $1,0($16) > mskwl $1,$16,$1 > bis $

Re: [PATCH 13/15] IRA+LRA: Let the backend request to split basic blocks

On Mon, 18 Nov 2024, Richard Sandiford wrote: > > gcc/ > > * function.h (struct function): Add > > `split_basic_blocks_after_reload' member. > > * lra.cc (lra): Handle it. > > * reload1.cc (reload): Likewise. > > OK, thanks. Thank you for your review. I'll commit the chang

Re: [PATCH 02/15] testsuite: Expand coverage for `__builtin_memcpy'

On Tue, 19 Nov 2024, Jeff Law wrote: > > gcc/testsuite/ > > * gcc.c-torture/execute/memcpy-a1.c: New file. > > * gcc.c-torture/execute/memcpy-a2.c: New file. > > * gcc.c-torture/execute/memcpy-a4.c: New file. > > * gcc.c-torture/execute/memcpy-a8.c: New file. > > * gcc.c-to

Re: [PATCH] build: Discard obsolete references to $(GCC_PARTS)

On Tue, 19 Nov 2024, Joseph Myers wrote: > > The $(GCC_PARTS) variable was deleted with the Makefile rework in commit > > fa9585134f6f ("libgcc move to the top level")[1] back in 2007, and yet > > the Ada and Modula 2 frontends added references to this variable later > > on, with commit e972fd5

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

Hi Adrian, > > This has come out of a discussion[1] around the removal of non-BWX Alpha > > support from the Linux kernel due to data races affecting RCU algorithms. > > (...) > > Comments, questions, voices of concern or appreciation, all very welcome. > > Thanks a lot for your work, much ap

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Tue, 19 Nov 2024, Maciej W. Rozycki wrote: > > time I think the RMW sequence on _Atomic variables is a clear > > bug that you'd need to fix also for -mno-safe-bwa. > > That's weird indeed, GCC internals manual clearly says: > > "'atomic_storeMO

[PATCH] Alpha: Respect `_Atomic' keyword for HI and QI data on !BWX [PR117759]

Correct an issue with 8-bit/16-bit stores to `_Atomic' QI and HI data objects producing non-BWX assembly such as: mb insql $17,$16,$17 ldq_u $1,0($16) mskwl $1,$16,$1 bis $17,$1,$17 stq_u $17,0($16) mb for: void atomic_store16 (_Atomic uns

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Mon, 18 Nov 2024, Arnd Bergmann wrote: > >> a) storing an '_Atomic' variable smaller than 8 bytes on non-bwx > >>targets should use ll/sc, but uses a plain rmw cycle. > > > > I think there should be no problem with aligned 4-byte (longword) data > > quantities, given that there are both pl

[PATCH 05/15] Alpha: Permit constant zero source for "insvmisaligndi"

Eliminate a redundant bitwise inclusive OR operation on the insertion of constant zero into a bit-field, improving code produced at `-O2' from an output sequence such as: mov $31,$3 # Redundant! ldq_u $1,7($16) insqh $3,$16,$3

[PATCH 11/15] Alpha: Fix a block move pessimisation with zero-extension after LDWU

For the BWX case we have a pessimisation in `alpha_expand_block_move' for HImode loads where we place the data loaded into a HImode register as well, therefore losing information that indeed the data loaded has already been zero-extended to the full DImode width of the register. Later on when

[PATCH 01/15] Alpha/testsuite: Run target testing over all the usual optimization levels

Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the Alpha testsuite as several targets already do. Add `-Og -g' and `-Oz' as well via ADDITIONAL_TORTURE_OPTIONS to expand coverage. Adjust test options across individual test cases accordingly where required. Discard base-2.c,

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

On Mon, 18 Nov 2024, Arnd Bergmann wrote: > > This patch series addresses these issues in the last two changes, having > > made generic test suite updates to improve coverage in the concerned area > > first and then having addressed a bunch of issues in the code affected I > > discovered in th

[PATCH 00/15] Fix data races with sub-longword accesses on Alpha

Hi, This has come out of a discussion[1] around the removal of non-BWX Alpha support from the Linux kernel due to data races affecting RCU algorithms. As it happens these data races also apply to BWX Alpha systems, as I have discovered in the course of this effort, although owing to how the

[PATCH 12/15] Alpha: Export `emit_unlikely_jump' for a subsequent change to use

Rename `emit_unlikely_jump' function to `alpha_emit_unlikely_jump', so as to avoid namespace pollution, updating callers accordingly and export it for use in the machine description. Make it return the insn emitted. gcc/ * config/alpha/alpha-protos.h (alpha_emit_unlikely_jump):

[PATCH 15/15] Alpha: Add option to avoid data races for partial writes

Similarly to data races with 8-bit byte or 16-bit word quantity memory writes on non-BWX Alpha implementations we have the same problem even on BWX implementations with partial memory writes produced for unaligned stores as well as block memory move and clear operations. This happens at the bo

[PATCH 13/15] IRA+LRA: Let the backend request to split basic blocks

The next change for Alpha will produce extra labels and branches in reload, which in turn requires basic blocks to be split at completion. We do this already for functions that can trap, so just extend the arrangement with a flag for the backend to use whenever it finds it necessary. g

[PATCH 14/15] Alpha: Add option to avoid data races for sub-longword memory stores

With non-BWX Alpha implementations we have a problem of data races where a 8-bit byte or 16-bit word quantity is to be written to memory in that in those cases we use an unprotected RMW access of a 32-bit longword or 64-bit quadword width. If contents of the longword or quadword accessed outsi

[COMMITTED] Alpha: Remove leftover `;;' for "unaligned_store"

Remove stray `;;' from the middle of the introductory comment for the "unaligned_store" expander, clearly a leftover from a previous edition. gcc/ * config/alpha/alpha.md (unaligned_store): Remove stray `;;'. --- Committed as obvious. --- gcc/config/alpha/alpha.md |

[PATCH 08/15] Alpha: Fix offset adjustment in unaligned access helpers

Correct the offset adjustment made in the multi-word unaligned access helpers such that it is actually used by the unaligned load and store instructions, fixing a bug introduced with commit 1eb356b98df2 ("alpha gprel optimizations")[1] back in 2001, which replaced address changes made directly

[PATCH 10/15] Alpha: Optimize block moves coming from longword-aligned source

Now that we have proper alignment determination for block moves in place the case of copying a block of longword-aligned data has become real, so implement the merging of loaded data from pairs of SImode registers into single DImode registers for the purpose of using with unaligned stores effic

[PATCH 09/15] Alpha: Also use tree information to get base block alignment

We hardly ever emit code using machine instructions for aligned memory accesses for block move and clear operation and the reason for this appears to be that suboptimal alignment is often passed by the caller and then we only try to find a better alignment by checking pseudo register pointer al

[PATCH 07/15] Alpha: Adjust MEM alignment for block clear [PR115459]

By inference it appears to me that the same fix for PR target/115459 needs to be applied to the block clear operation that has been done for block move, as implemented by commit ccfe71518039 ("[alpha] adjust MEM alignment for block move [PR115459]"). gcc/ PR target/115459

[PATCH 06/15] Alpha: Remove code duplication in block clear trailer

Remove code duplication in the part of `alpha_expand_block_clear' that handles any aligned trailing part of the block, observing that the two legs of code only differ by the machine mode and that we already take the same approach with handling any unaligned prefix earlier on. No functional cha

[PATCH 02/15] testsuite: Expand coverage for `__builtin_memcpy'

Expand coverage for `__builtin_memcpy', primarily for "cpymemM" block copy pattern, although with smaller sizes open-coded sequences may be produced instead. This verifies block sizes in bytes from 1 to 64, across byte alignments of 1, 2, 4, 8 and byte misalignments within from 0 up to 7 (there

[PATCH 03/15] testsuite: Expand coverage for `__builtin_memset' with 0

Expand coverage for `__builtin_memset' for the special case of clearing a block, primarily for "setmemM" block set pattern, though with smaller sizes open-coded sequences may be produced instead. This verifies block sizes in bytes from 1 to 64 across byte alignments of 1, 2, 4, 8 and byte misal

[PATCH 04/15] testsuite: Expand coverage for unaligned memory stores

Expand coverage for unaligned memory stores, for the "insvmisalignM" patterns, for 2-byte, 4-byte, and 8-byte scalars, across byte alignments of 1, 2, 4 and byte misalignments within from 0 up to 7 (there's some redundancy there for the sake of simplicity of the test case), making sure all data

[PATCH] build: Discard obsolete references to $(GCC_PARTS)

The $(GCC_PARTS) variable was deleted with the Makefile rework in commit fa9585134f6f ("libgcc move to the top level")[1] back in 2007, and yet the Ada and Modula 2 frontends added references to this variable later on, with commit e972fd5281b7 ("[Ada] clean ups in Makefiles")[2] back in 2011 an

Re: [PATCH] regenerate-opt-urls.py: fix transposed values for "vax" and "v850"

Hi Mark, > > I double-checked the GCC internals manual and all it says is: > > > > There files are generated from the '.opt' files and the generated > > HTML documentation by 'regenerate-opt-urls.py', and should be > > regenerated when adding new options, via manually invoking 'mak

Re: [PATCH] regenerate-opt-urls.py: fix transposed values for "vax" and "v850"

On Wed, 12 Jun 2024, Maciej W. Rozycki wrote: > > Hence we decided to check for it in CI instead. > > > > Hope the trade-off sounds reasonable > > I have reviewed the thread referred and I note that a concern such as > mine has already been raised in response

Re: [PATCH v2] alpha: Add -mlra option

On Tue, 15 Oct 2024, Richard Biener wrote: > > FWIW, it *seems* that LRA seems to just work with EV56 as the baseline and > > the > > following replacements in the code: > > > > s/reload_in_progress/reload_in_progress || lra_in_progress/g > > If you can provide -mlra vs. -mno-lra testsui

Re: [PATCH v2] alpha: Add -mlra option

On Tue, 15 Oct 2024, Uros Bizjak wrote: > > PR target/66207 > > * config/alpha/alpha.opt (mlra): New target option. > > * config/alpha/alpha.cc (alpha_use_lra_p): New function. > > (TARGET_LRA_P): Use it. > > * config/alpha/alpha.opt.urls: Regenerate. > > IMO, we should simply deprecate non-BWX t

Re: [to-be-committed][V2][RISC-V] Add splitters to restore condops generation after recent phiopt changes

On Sun, 6 Oct 2024, Jeff Law wrote: > V2: > Fix typo in ChangeLog. > Remove now extraneous comment in cset-sext.c. > Throttle back branch cost to 1 in various tests Thank you for addressing my concerns. There's a bunch of extraneous trailing new lines to remove if you care doing this in

Re: [to-be-committed][RISC-V] Add splitters to restore condops generation after recent phiopt changes

On Fri, 4 Oct 2024, Jeff Law wrote: > > More importantly may I ask you to review the second paragraph of commit > > 6c3365e715fa ("RISC-V: Also handle sign extension in branch costing") to > > see if any of the other issues referred there have also been now sorted > > and mention that in the cha

Re: [to-be-committed][RISC-V] Add splitters to restore condops generation after recent phiopt changes

On Thu, 3 Oct 2024, Jeff Law wrote: > We can remove a couple of XFAILs in the rv32 space as it's behaving much more > like rv64 at this point. I'm glad to see them gone. I have a couple of concerns with your change though. Given: * gcc.target/riscv/cset-sext.c: Similarly. No longer

Re: [PATCH][PR115565] cse: Don't use a valid regno for non-register in comparison_qty

On Mon, 15 Jul 2024, Maciej W. Rozycki wrote: > > > Is it OK to backport now or shall we skip GCC 11 altogether since it's > > > going to be closed after the upcoming 11.5 release later this week? > > > > Yes, please leave 11.5 alone, it's OK for the

Re: [PATCH] [alpha] adjust MEM alignment for block move [PR115459] (was: Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required)

On Mon, 15 Jul 2024, Jakub Jelinek wrote: > > > > for gcc/ChangeLog > > > > > > > > PR target/115459 > > > > * config/alpha/alpha.cc (alpha_expand_block_move): Adjust > > > > MEMs to match inferred alignment. > > > > > > LGTM, based on a successful bootstrap/regtest repor

Re: [PATCH][PR115565] cse: Don't use a valid regno for non-register in comparison_qty

On Mon, 15 Jul 2024, Richard Biener wrote: > > > > The patch is OK for trunk, thanks. I agree that it's a regression > > > > from 08a692679fb8. Since it's fixing such a hard-to-diagnose wrong > > > > code bug, and since it seems very safe, I think it's worth backporting > > > > to all active bra

Re: [PATCH][PR115565] cse: Don't use a valid regno for non-register in comparison_qty

On Sun, 30 Jun 2024, Maciej W. Rozycki wrote: > > The patch is OK for trunk, thanks. I agree that it's a regression > > from 08a692679fb8. Since it's fixing such a hard-to-diagnose wrong > > code bug, and since it seems very safe, I think it's worth backporting

Re: [PATCH] [alpha] adjust MEM alignment for block move [PR115459] (was: Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required)

On Wed, 10 Jul 2024, Uros Bizjak wrote: > > Before issuing loads or stores for a block move, adjust the MEM > > alignments if analysis of the addresses enabled the inference of > > stricter alignment. This ensures that the MEMs are sufficiently > > aligned for the corresponding insns, which avoid

Re: [PATCH 1/1] ada: Make the names of uninstalled cross-gnattools consistent across builds

On Thu, 4 Jul 2024, Arnaud Charlet wrote: > The change is OK, thanks. I have committed it now, thank you for your review. Maciej

[PING][PATCH 1/1] ada: Make the names of uninstalled cross-gnattools consistent across builds

On Tue, 18 Jun 2024, Maciej W. Rozycki wrote: > Fix the problem by moving the renaming of gnattools to a separate 'make' > recipe, pasted into a new 'gnattools-cross-mv' target and the existing > legacy 'cross-gnattools' target. Then invoke the new t

[PING][PATCH] [alpha] adjust MEM alignment for block move [PR115459] (was: Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required)

On Thu, 13 Jun 2024, Alexandre Oliva wrote: > Before issuing loads or stores for a block move, adjust the MEM > alignments if analysis of the addresses enabled the inference of > stricter alignment. This ensures that the MEMs are sufficiently > aligned for the corresponding insns, which avoids tr

Re: [PATCH][PR115565] cse: Don't use a valid regno for non-register in comparison_qty

On Fri, 21 Jun 2024, Richard Sandiford wrote: > > This has passed verification in native `powerpc64le-linux-gnu' and > > `x86_64-linux-gnu' regstraps, as well as with the `alpha-linux-gnu' > > target. OK to apply and backport to the release branches? > > Huh! Nice detective work. Thank you

Re: [PATCH v2] MIPS: Output $0 for conditional trap if !ISA_HAS_COND_TRAPI

On Fri, 28 Jun 2024, YunQiang Su wrote: > > > > Overall ISTM there is no need for distinct insns for ISA_HAS_COND_TRAPI > > > > and !ISA_HAS_COND_TRAPI cases each and this would better be sorted with > > > > predicates and constraints, especially as the output pattern is the same > > > > in both

Re: [PATCH v2] MIPS: Output $0 for conditional trap if !ISA_HAS_COND_TRAPI

On Thu, 27 Jun 2024, YunQiang Su wrote: > > The missed optimisation in GAS, which used not to trigger pre-R6, is > > irrelevant from this change's point of view and just adds noise. I'm > > surprised that it worked even in the first place, as I reckon GCC is > > supposed to emit regular MIPS cod

Re: [PATCH v2] MIPS: Output $0 for conditional trap if !ISA_HAS_COND_TRAPI

On Thu, 20 Jun 2024, YunQiang Su wrote: > MIPSr6 removes condition trap instructions with imm, so the instruction > like `teq $2,imm` will be converted to > li $at, imm > teq $2, $at > > The current version of Gas cannot detect if imm is zero, and output > teq $2, $0 > Let's do it in GCC.

Re: [PATCH] Hard register asm constraint

On Tue, 25 Jun 2024, Paul Koning wrote: > >>> could be rewritten into > >>> > >>> int test (int x, int y) > >>> { > >>> asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y)); > >>> return x; > >>> } > > I like this idea but I'm wondering: regular constraints specify what > sort of value is

  1   2   3   4   5   6   7   8   9   10   >