[PATCH 4/4] xtensa: Improve constant synthesis for both integer and floating-point

2022-06-09 Thread Takayuki 'January June' Suwa via Gcc-patches
This patch revises the previous implementation of constant synthesis. First, changed to use define_split machine description pattern and to run after reload pass, in order not to interfere some optimizations such as the loop invariant motion. Second, not only integer but floating-point is

[PATCH 2/4] xtensa: Consider the Loop Option when setmemsi is expanded to small loop

2022-06-09 Thread Takayuki 'January June' Suwa via Gcc-patches
Now apply to almost any size of aligned block under such circumstances. gcc/ChangeLog: * config/xtensa/xtensa.cc (xtensa_expand_block_set_small_loop): Pass through the block length / loop count conditions if zero-overhead looping is configured and active, ---

[PATCH 3/4] xtensa: Improve instruction cost estimation and suggestion

2022-06-09 Thread Takayuki 'January June' Suwa via Gcc-patches
This patch implements a new target-specific relative RTL insn cost function because of suboptimal cost estimation by default, and fixes several "length" insn attributes (related to the cost estimation). And also introduces a new machine-dependent option "-mextra-l32r-costs=" that tells

[PATCH 1/4] xtensa: Tweak some widen multiplications

2022-06-09 Thread Takayuki 'January June' Suwa via Gcc-patches
umulsidi3 is faster than umuldi3 even if library call, and is also prerequisite for fast constant division by multiplication. gcc/ChangeLog: * config/xtensa/xtensa.md (mulsidi3, umulsidi3): Split into individual signedness, in order to use libcall "__umulsidi3" but not

Re: [PATCH] or1k: Add support for a little-endian target variant

2022-06-09 Thread Samuel Holland
Hi Stafford, On 6/9/22 6:29 AM, Stafford Horne wrote: >> diff --git a/gcc/config.gcc b/gcc/config.gcc >> index c5064dd37666..0c3a09dfe810 100644 >> --- a/gcc/config.gcc >> +++ b/gcc/config.gcc >> @@ -2866,6 +2866,11 @@ or1k*-*-*) >> done >> TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG |

Re: [PATCH v4, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-06-09 Thread HAO CHEN GUI via Gcc-patches
On 9/6/2022 下午 11:07, Segher Boessenkool wrote: > Ah, good. Should we then have an assert that there is no fast-math if > we ever get the rtl fmin/fmax stuff? Sure, I will add a condition for it. Thanks a lot. Gui Haochen

Re: [PATCH 4/4] xtensa: Add clrsbsi2 insn pattern

2022-06-09 Thread Max Filippov via Gcc-patches
On Sun, May 29, 2022 at 4:00 AM Takayuki 'January June' Suwa wrote: > > > (clrsb:m x) > > Represents the number of redundant leading sign bits in x, represented > > as an integer of mode m, starting at the most significant bit position. > > This explanation is just what the NSA instruction

Re: [PATCH 3/4] xtensa: Optimize '(~x & y)' to '((x & y) ^ y)'

2022-06-09 Thread Max Filippov via Gcc-patches
On Sun, May 29, 2022 at 4:00 AM Takayuki 'January June' Suwa wrote: > > In Xtensa ISA, there is no single machine instruction that calculates unary > bitwise negation. > > gcc/ChangeLog: > > * config/xtensa/xtensa.md (*andsi3_bitcmpl): > New insn_and_split pattern. > >

Re: [PATCH 2/4] xtensa: Make one_cmplsi2 optimizer-friendly

2022-06-09 Thread Max Filippov via Gcc-patches
On Sun, May 29, 2022 at 4:00 AM Takayuki 'January June' Suwa wrote: > > In Xtensa ISA, there is no single machine instruction that calculates unary > bitwise negation. But a few optimizers assume that bitwise negation can be > done by a single insn. > > As a result, '((x < 0) ? ~x : x)' cannot

Re: [PATCH 1/4] xtensa: Implement bswaphi2 insn pattern

2022-06-09 Thread Max Filippov via Gcc-patches
On Sun, May 29, 2022 at 4:00 AM Takayuki 'January June' Suwa wrote: > > This patch adds bswaphi2 insn pattern that is one instruction less than the > default expansion. > > gcc/ChangeLog: > > * config/xtensa/xtensa.md (bswaphi2): New insn pattern. > --- > gcc/config/xtensa/xtensa.md |

New Swedish PO file for 'gcc' (version 12.1.0)

2022-06-09 Thread Translation Project Robot
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-12.1.0.sv.po', has

[PING][PATCH][WIP] have configure probe prefix for gmp/mpfr/mpc [PR44425]

2022-06-09 Thread Eric Gallager via Gcc-patches
Hi, I'd like to ping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596126.html (cc-ing the build machinery maintainers listed in MAINTAINERS this time) On Thu, Jun 2, 2022 at 11:53 AM Eric Gallager wrote: > > So, I'm working on fixing PR bootstrap/44425, and have this patch to

[PATCH] rs6000: Delete FP_ISA3

2022-06-09 Thread Segher Boessenkool
FP_ISA3 is exactly the same as SFDF, just a less obvious name. So, let's delete it. Tested, committed, the works. Segher 2022-06-09 Segher Boessenkool * config/rs6000/rs6000.md (FP_ISA3): Delete. (float2): Rename to... (float2): ... this. Adjust.

Re: [PATCH 2/1] c++: optimize specialization of templated member functions

2022-06-09 Thread Patrick Palka via Gcc-patches
On Thu, 9 Jun 2022, Jason Merrill wrote: > On 6/9/22 09:00, Patrick Palka wrote: > > This performs one of the optimizations added by the previous > > patch to lookup_template_class, to instantiate_template as well. > > (For the libstdc++ ranges tests this optimization appears to be > > effective

Re: [PATCH] c++: optimize specialization of nested class templates

2022-06-09 Thread Patrick Palka via Gcc-patches
On Thu, 9 Jun 2022, Jason Merrill wrote: > On 6/8/22 14:21, Patrick Palka wrote: > > When substituting a class template specialization, tsubst_aggr_type > > substitutes the TYPE_CONTEXT before passing it to lookup_template_class. > > This appears to be unnecessary, however, because the the

[r13-1021 Regression] FAIL: gcc.target/i386/pr84101.c scan-tree-dump-not slp2 "optimized: basic block" on Linux/x86_64

2022-06-09 Thread skpandey--- via Gcc-patches
On Linux/x86_64, 269edf4e5e6ab489730038f7e3495550623179fe is the first bad commit commit 269edf4e5e6ab489730038f7e3495550623179fe Author: Cui,Lili Date: Wed Jun 8 11:25:57 2022 +0800 Update {skylake,icelake,alderlake}_cost to add a bit preference to vector store. caused FAIL:

Re: [committed] openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library

2022-06-09 Thread Jakub Jelinek via Gcc-patches
On Thu, Jun 09, 2022 at 06:07:20PM +0100, Richard Sandiford wrote: > Dunno if this has already been reported, but I'm getting: > > .../libgomp/config/linux/allocator.c:36:10: fatal error: > ../../../allocator.c: No such file or directory >36 | #include "../../../allocator.c" > |

Re: [committed] openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library

2022-06-09 Thread Richard Sandiford via Gcc-patches
Jakub Jelinek via Gcc-patches writes: > Hi! > > This patch adds support for dlopening libmemkind.so on Linux and uses it > for some kinds of allocations (but not yet e.g. pinned memory). > > Bootstrapped/regtested on x86_64-linux and i686-linux (with libmemkind > around) and compile tested with

Re: [PATCH] c++: optimize specialization of nested class templates

2022-06-09 Thread Jason Merrill via Gcc-patches
On 6/8/22 14:21, Patrick Palka wrote: When substituting a class template specialization, tsubst_aggr_type substitutes the TYPE_CONTEXT before passing it to lookup_template_class. This appears to be unnecessary, however, because the the initial value of lookup_template_class's context parameter

Re: [PATCH 2/1] c++: optimize specialization of templated member functions

2022-06-09 Thread Jason Merrill via Gcc-patches
On 6/9/22 09:00, Patrick Palka wrote: This performs one of the optimizations added by the previous patch to lookup_template_class, to instantiate_template as well. (For the libstdc++ ranges tests this optimization appears to be effective around 30% of the time, i.e. 30% of the time context of

Re: [PATCH v4, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-06-09 Thread Segher Boessenkool
On Thu, Jun 09, 2022 at 09:24:00AM +0800, HAO CHEN GUI wrote: > On 8/6/2022 下午 9:24, Segher Boessenkool wrote: > > But it regresses the code quality generated with -ffast-math (because > > the new unspecs arent't optimised like standard rtl is). This can be > > follow-up work of course -- and the

Re: [committed] RISC-V: Use a tab rather than space with FSFLAGS

2022-06-09 Thread Kito Cheng via Gcc-patches
Thanks :) On Thu, Jun 9, 2022 at 9:35 PM Maciej W. Rozycki wrote: > > Consistently use a tab rather than a space as the separator between the > assembly instruction mnemonic and its operand with FSFLAGS instructions > produced with the unordered FP comparison RTL insns. > > gcc/ >

Re: [PATCH] RISC-V: Reset the length to the default of 4 for FP comparisons

2022-06-09 Thread Kito Cheng via Gcc-patches
LGTM, *f_quiet4_default and *f_quiet4_snan has set their own length and the only user of this setting is *cstore4, but apparently the length if 4 for that not 8. Thanks! On Thu, Jun 9, 2022 at 9:36 PM Maciej W. Rozycki wrote: > > The default length for floating-point compare operations is

Re: [PATCH v2 01/11] OpenMP 5.0: Clause ordering for OpenMP 5.0 (topological sorting by base pointer)

2022-06-09 Thread Jakub Jelinek via Gcc-patches
On Wed, Jun 08, 2022 at 04:00:39PM +0100, Julian Brown wrote: > > I think big question is if we do want to do this map clause reordering > > before processing the omp target etc. clauses, or after (during > > gimplify_adjust_omp_clauses, when clauses from the implicit mappings > > are added too

Re: [Patch] OpenMP: Move omp requires checks to libgomp

2022-06-09 Thread Jakub Jelinek via Gcc-patches
On Thu, Jun 09, 2022 at 02:46:34PM +0200, Tobias Burnus wrote: > On 09.06.22 13:40, Jakub Jelinek via Gcc-patches wrote: > > On Wed, Jun 08, 2022 at 05:56:02AM +0200, Tobias Burnus wrote: > > > + && lookup_attribute ("omp declare target", > > > +

[ping][vect-patterns] Refactor widen_plus/widen_minus as internal_fns

2022-06-09 Thread Joel Hutton via Gcc-patches
> Before I make any changes, I'd like to check we're all on the same page. > > richi, are you ok with the gimple_build function, perhaps with a different > name if you are concerned with overloading? we could use gimple_ch_build > or gimple_code_helper_build? > > Similarly are you ok with the

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

2022-06-09 Thread Maciej W. Rozycki
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

[PATCH] RISC-V: Reset the length to the default of 4 for FP comparisons

2022-06-09 Thread Maciej W. Rozycki
The default length for floating-point compare operations is overridden to 8, however the FEQ.fmt, FLT.fmt, FLE.fmt machine instructions and FGE.fmt, FGT.fmt assembly idioms the relevant RTL insns produce are all 4 bytes long each. And all the floating-point compare RTL insns that produce

[committed] RISC-V: Use a tab rather than space with FSFLAGS

2022-06-09 Thread Maciej W. Rozycki
Consistently use a tab rather than a space as the separator between the assembly instruction mnemonic and its operand with FSFLAGS instructions produced with the unordered FP comparison RTL insns. gcc/ * config/riscv/riscv.md (*f_quiet4_default)

c++: Better module initializer code

2022-06-09 Thread Nathan Sidwell
Every module interface needs to emit a global initializer, but it might have nothing to init. In those cases, there's no need for any idempotency boolean to be emitted. nathan -- Nathan SidwellFrom 227ffed7dbbdffeeb5bc013852d61a97aa468c62 Mon Sep 17 00:00:00 2001 From: Nathan Sidwell Date:

[PATCH 2/1] c++: optimize specialization of templated member functions

2022-06-09 Thread Patrick Palka via Gcc-patches
This performs one of the optimizations added by the previous patch to lookup_template_class, to instantiate_template as well. (For the libstdc++ ranges tests this optimization appears to be effective around 30% of the time, i.e. 30% of the time context of 'tmpl' is non-dependent while the context

Re: [PATCH] c++: Fix up ICE on __builtin_shufflevector constexpr evaluation [PR105871]

2022-06-09 Thread Jason Merrill via Gcc-patches
On 6/8/22 02:08, Jakub Jelinek wrote: Hi! As the following testcase shows, BIT_FIELD_REF result doesn't have to have just integral type, it can also have vector type. And in that case cxx_eval_bit_field_ref just ICEs on it because it is unprepared for that case, creates the initial value with

Re: [Patch] OpenMP: Move omp requires checks to libgomp

2022-06-09 Thread Tobias Burnus
On 09.06.22 13:40, Jakub Jelinek via Gcc-patches wrote: On Wed, Jun 08, 2022 at 05:56:02AM +0200, Tobias Burnus wrote: + && lookup_attribute ("omp declare target", + DECL_ATTRIBUTES (current_function_decl))) + omp_requires_mask + = (enum

Re: [PATCH, OpenMP, v4] Implement uses_allocators clause for target regions

2022-06-09 Thread Jakub Jelinek via Gcc-patches
On Thu, Jun 09, 2022 at 02:21:13PM +0800, Chung-Lin Tang wrote: > @@ -15651,6 +15653,213 @@ c_parser_omp_clause_allocate (c_parser *parser, > tree list) >return nl; > } > > +/* OpenMP 5.0: > + uses_allocators ( allocator-list ) > + > + allocator-list: > + allocator > + allocator ,

Re: [Patch] OpenMP: Handle ancestor:1 with discover_declare_target

2022-06-09 Thread Jakub Jelinek via Gcc-patches
On Thu, Jun 09, 2022 at 12:47:17PM +0200, Tobias Burnus wrote: > Another minor step to getting reverse offloading to work ... > > OK for mainline? > > Tobias > > PS: As attached, this patch is a stand-alone patch, which fails > due to the requires sorry (see dg-prune-output). > With the

Re: [committed] openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library

2022-06-09 Thread Jakub Jelinek via Gcc-patches
On Thu, Jun 09, 2022 at 12:11:28PM +0200, Thomas Schwinge wrote: > On 2022-06-09T10:19:03+0200, Jakub Jelinek via Gcc-patches > wrote: > > This patch adds support for dlopening libmemkind.so > > Instead of 'dlopen'ing literally 'libmemkind.so': > > > --- libgomp/allocator.c.jj2022-06-08

Re: [Patch] OpenMP: Move omp requires checks to libgomp

2022-06-09 Thread Jakub Jelinek via Gcc-patches
On Wed, Jun 08, 2022 at 05:56:02AM +0200, Tobias Burnus wrote: > gcc/c/ChangeLog: > > * c-parser.cc (c_parser_declaration_or_fndef): Set > OMP_REQUIRES_TARGET_USED in omp_requires_mask if function has > "omp declare target" attribute. > (c_parser_omp_target_data): Set

Re: [PATCH] or1k: Add support for a little-endian target variant

2022-06-09 Thread Stafford Horne via Gcc-patches
> diff --git a/gcc/config.gcc b/gcc/config.gcc > index c5064dd37666..0c3a09dfe810 100644 > --- a/gcc/config.gcc > +++ b/gcc/config.gcc > @@ -2866,6 +2866,11 @@ or1k*-*-*) > done > TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'` > > + case ${target} in > +

[Patch] OpenMP: Handle ancestor:1 with discover_declare_target

2022-06-09 Thread Tobias Burnus
Another minor step to getting reverse offloading to work ... OK for mainline? Tobias PS: As attached, this patch is a stand-alone patch, which fails due to the requires sorry (see dg-prune-output). With the requires patch, it should fail with the next sorry: 'ancestor' not yet supported"

Re: [committed][nvptx] Add march-map

2022-06-09 Thread Thomas Schwinge
Hi Tom! On 2022-03-29T14:03:22+0200, Tom de Vries via Gcc-patches wrote: > Say we have an sm_50 board, and we want to run a benchmark using the highest > possible march setting. > > Currently there's march=sm_30, march=sm_35, march=sm_53, but no march=sm_50. > > So, we'd need to pick

RE: [PATCH] libgomp, openmp: pinned memory

2022-06-09 Thread Stubbs, Andrew
> For example, it's documented that 'cuMemHostAlloc', > api/group__CUDA__MEM.html#group__CUDA__MEM_1g572ca4011bfcb25034888a14d4e035b > 9>, > "Allocates page-locked host memory". The crucial thing, though, what > makes this different from 'malloc' plus

RE: [PATCH] libgomp, openmp: pinned memory

2022-06-09 Thread Stubbs, Andrew
> The question is only what to do with 'requires unified_shared_memory' – > and a non-multi-device allocator. The compiler emits an error at compile time if you attempt to use both -foffload-memory=pinned and USM, because they’re not compatible. You're fine to use both explicit allocators in

Re: [committed] openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library

2022-06-09 Thread Thomas Schwinge
Hi Jakub! On 2022-06-09T10:19:03+0200, Jakub Jelinek via Gcc-patches wrote: > This patch adds support for dlopening libmemkind.so Instead of 'dlopen'ing literally 'libmemkind.so': > --- libgomp/allocator.c.jj2022-06-08 08:21:03.099446883 +0200 > +++ libgomp/allocator.c 2022-06-08

Re: [PATCH] libgomp, openmp: pinned memory

2022-06-09 Thread Tobias Burnus
On 09.06.22 11:38, Thomas Schwinge wrote: On 2022-06-07T13:28:33+0100, Andrew Stubbs wrote: On 07/06/2022 13:10, Jakub Jelinek wrote: On Tue, Jun 07, 2022 at 12:05:40PM +0100, Andrew Stubbs wrote: The memory pinned via the mlock call does not give the expected performance boost. I had not

Re: aarch64: Fix bitfield alignment in param passing [PR105549]

2022-06-09 Thread Christophe Lyon via Gcc-patches
On 6/8/22 15:19, Richard Sandiford wrote: Christophe Lyon writes: On 6/7/22 19:44, Richard Sandiford wrote: Christophe Lyon via Gcc-patches writes: While working on enabling DFP for AArch64, I noticed new failures in gcc.dg/compat/struct-layout-1.exp (t028) which were not actually caused

Re: [PATCH] libgomp, openmp: pinned memory

2022-06-09 Thread Thomas Schwinge
Hi! I'm not all too familiar with the "newish" CUDA Driver API, but maybe the following is useful still: On 2022-06-07T13:28:33+0100, Andrew Stubbs wrote: > On 07/06/2022 13:10, Jakub Jelinek wrote: >> On Tue, Jun 07, 2022 at 12:05:40PM +0100, Andrew Stubbs wrote: >>> Following some feedback

[PING][Patch] OpenMP, libgomp, gimple: omp_get_max_teams, omp_set_num_teams, and omp_{gs}et_teams_thread_limit on offload devices

2022-06-09 Thread Marcel Vollweiler
Hi, I’d like to ping the patch for the OpenMP runtime routines omp_get_max_teams, omp_set_num_teams, and omp_{gs}et_teams_thread_limit on offload devices: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593260.html This patch builds on the following patch which is currently in

RE: [PATCH]AArch64 relax predicate on load structure load instructions

2022-06-09 Thread Tamar Christina via Gcc-patches
> -Original Message- > From: Richard Sandiford > Sent: Thursday, June 9, 2022 9:22 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > ; Marcus Shawcroft > ; Kyrylo Tkachov > ; rguent...@suse.de; > ro...@nextmovesoftware.com > Subject: Re: [PATCH]AArch64 relax

[PATCH] c++: Add support for __real__/__imag__ modifications in constant expressions [PR88174]

2022-06-09 Thread Jakub Jelinek via Gcc-patches
Hi! We claim we support P0415R1 (constexpr complex), but e.g. #include constexpr bool foo () { std::complex a (1.0, 2.0); a += 3.0; a.real (6.0); return a.real () == 6.0 && a.imag () == 2.0; } static_assert (foo ()); fails with test.C:12:20: error: non-constant condition for static

Re: [PATCH]AArch64 relax predicate on load structure load instructions

2022-06-09 Thread Richard Sandiford via Gcc-patches
Tamar Christina writes: >> -Original Message- >> From: Richard Sandiford >> Sent: Wednesday, June 8, 2022 3:36 PM >> To: Tamar Christina >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw >> ; Marcus Shawcroft >> ; Kyrylo Tkachov >> ; rguent...@suse.de; ro...@eyesopen.com >> Subject:

[committed] doc: Fix up -Waddress documentation

2022-06-09 Thread Jakub Jelinek via Gcc-patches
Hi! When looking up the -Waddress documentation due to some PR that mentioned it, I've noticed some typos and thus I'm fixing them. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as obvious. 2022-06-09 Jakub Jelinek * doc/invoke.texi (-Waddress): Fix a

[committed] openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library

2022-06-09 Thread Jakub Jelinek via Gcc-patches
Hi! This patch adds support for dlopening libmemkind.so on Linux and uses it for some kinds of allocations (but not yet e.g. pinned memory). Bootstrapped/regtested on x86_64-linux and i686-linux (with libmemkind around) and compile tested with LIBGOMP_USE_MEMKIND undefined, committed to trunk.

[PATCH]middle-end Use subregs to expand COMPLEX_EXPR to set the lowpart.

2022-06-09 Thread Tamar Christina via Gcc-patches
Hi All, When lowering COMPLEX_EXPR we currently emit two VEC_EXTRACTs. One for the lowpart and one for the highpart. The problem with this is that in RTL the lvalue of the RTX is the only thing tying the two instructions together. This means that e.g. combine is unable to try to combine the

RE: [PATCH]AArch64 relax predicate on load structure load instructions

2022-06-09 Thread Tamar Christina via Gcc-patches
> -Original Message- > From: Richard Sandiford > Sent: Wednesday, June 8, 2022 3:36 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > ; Marcus Shawcroft > ; Kyrylo Tkachov > ; rguent...@suse.de; ro...@eyesopen.com > Subject: Re: [PATCH]AArch64 relax

Re: [PATCH] Update {skylake,icelake,alderlake}_cost to add a bit preference to vector store.

2022-06-09 Thread Hongtao Liu via Gcc-patches
On Wed, Jun 8, 2022 at 11:44 AM Cui, Lili wrote: > > > -Original Message- > > From: Hongtao Liu > > Sent: Monday, June 6, 2022 1:25 PM > > To: H.J. Lu > > Cc: Cui, Lili ; Liu, Hongtao ; > > GCC > > Patches > > Subject: Re: [PATCH] Update {skylake,icelake,alderlake}_cost to add a bit >

[PATCH, OpenMP, v4] Implement uses_allocators clause for target regions

2022-06-09 Thread Chung-Lin Tang
Hi Jakub, this is v4 of the uses_allocators patch. On 2022/5/31 6:02 PM, Jakub Jelinek wrote: The response I got on omp-lang is that it is intentional that in the new syntax only a single allocator is allowed. So I'd suggest to implement: 1) if has_modifiers (i.e. certainly new syntax), only

[PATCH] or1k: Add support for a little-endian target variant

2022-06-09 Thread Samuel Holland
While not officially sanctioned by the architecture spec, little-endian or1k processors do exist in the wild, for example the Allwinner AR100. Let's add native support for this, instead of hacks like using objcopy to byteswap ELF file contents. gcc/ChangeLog: * config.gcc: Set