From: Ju-Zhe Zhong
gcc/ChangeLog:
* config.gcc: Add riscv_vector.h.
* config/riscv/riscv-builtins.cc: Add RVV builtin types support.
* config/riscv/riscv-c.cc (riscv_pragma_intrinsic): New function.
(riscv_register_pragmas): Ditto.
* config/riscv/riscv-pro
This change is based on commit 9fa26998a63d4b22b637ed8702520819e408a694
by Dehao Chen in vendors/google/heads/gcc-4_8.
gcc/ChangeLog:
* dwarf2out.cc (add_call_src_coords_attributes): Emit discriminators
for inlined call sites.
---
gcc/dwarf2out.cc | 6 +-
1 file changed, 5 insertion
On Fri, Sep 30, 2022 at 12:11 AM Lewis Hyatt via Gcc-patches
wrote:
>
> Warnings issued for -Wuninitialized have been using the spelling location of
> the problematic usage, discarding any information on the location of the macro
> expansion point if such usage was in a macro. This makes the warni
On Thu, Sep 29, 2022 at 6:54 PM Richard Sandiford via Gcc-patches
wrote:
>
> Thanks for posting the patch.
>
> juzhe.zh...@rivai.ai writes:
> > From: Ju-Zhe Zhong
> >
> > gcc/ChangeLog:
> >
> > * tree-vect-loop.cc (vect_phi_first_order_recurrence_p): New
> > function.
> > (vect_a
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_tunes): New.
(riscv_get_valid_option_values): New.
(TARGET_GET_VALID_OPTION_VALUES): New.
* config/riscv/riscv-cores.def (RISCV_TUNE): New, define options
for tune here.
(RISCV_CORE): Fix co
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
An experiment led me to notice that in some cases we were ending up with
TARGET_EXPR initialized by TARGET_EXPR, which isn't useful.
The target_expr_needs_replace change won't make a difference in most cases,
since cp_genericize_init will h
C2x adds a standard [[noreturn]] attribute (which can also be spelt
[[_Noreturn]] for use with ), so allowing non-returning
functions to be declared in a manner compatible with C++; the
_Noreturn function specifier remains available but is marked
obsolescent.
Implement this attribute. It's more r
On Linux/x86_64,
8ace67ddb97698709a622b2f8ba2718524aa5eeb is the first bad commit
commit 8ace67ddb97698709a622b2f8ba2718524aa5eeb
Author: Julian Brown
Date: Tue Sep 27 17:39:59 2022 +
OpenACC: whole struct vs. component mappings (PR107028)
caused
FAIL: c-c++-common/goacc/struct-compo
When getting the name of an attribute, we ought to use
get_attribute_name, which handles both [[ ]] and __attribute__(())
forms. Failure to do so may result in an ICE, like here.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/106937
gcc/c-family/ChangeLog:
If a relation is available, calculate overflow and normal ranges. Then
apply as appropriate.
This patch implements operator_plus::op1/op2_range and
operator_minus::op1_range to utilize any relation passed into properly
reflect the range.
If the relation between the LHS and the operand being
This allows GORI to recognize when a relation passed in applies to the 2
operands of the current statement. Check to see if further range
refinement is possible before proceeding.
There are 2 primary ways this can happen.
1) The relation record indicates there is a relation between the LHS
On 9/29/22 11:05, Patrick Palka wrote:
Adding a new builtin trait currently involves some boilerplate (as can
be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
CPTK_ enumerators and adding them to various switch statements across
many files. The exact switch statements we n
This patch allows GORI to recognize and pass relations along the
calculation chain. This will allow relations between the LHS and the
operand being calculated to be utilized in op1_range and op2_range.
compute_operand_range will look to see if the current statement creates
a relation between
On 9/28/22 2:15 PM, Guillermo E. Martinez via Gcc-patches wrote:
Hello GCC team,
The following is patch v2 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v1:
+ Fix typo in commit message.
+ Fix changelog entries.
Comments will be welcomed and appreciated!,
Kind
Class value_relation was private within the value-relation.cc file.
This class simply represents a relation between 2 ssa-names, and can
perform various operations on them. The oracle uses it under the
covers to maintains its tables.
It can be used in other places as well, so lets just exp
If the LHS is undefined, GORI should not proceed further. There are a
few places where this happens, and a few potential traps. Most haven't
been an issue up until now, but forthcoming changes tend to cause them
to trigger more often.
Bootstrapped on x86_64-pc-linux-gnu with no regressions.
There was a patch posted to remove the undefined behaviour from this
testcase, but it appears to never have been applied.
Pushed.
Andrew
From 73e41228fc8f7f2b6e6a631192533abb2110ba2b Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 27 Sep 2022 18:42:33 -0400
Subject: [PATCH 1/6] Remove
Warnings issued for -Wuninitialized have been using the spelling location of
the problematic usage, discarding any information on the location of the macro
expansion point if such usage was in a macro. This makes the warnings
impossible to control reliably with #pragma GCC diagnostic, and also disc
Yeah, frankly, I already noticed this situation.
If we can manually rewrite some codes, GCC can solve data dependency in scalar
passes
by introducing repeating statement (It will remove PHI nodes) before loop
vectorizer.
Which approach is winner, GCC or LLVM ? This is not point that I care about
On 9/29/22 03:37, Richard Sandiford wrote:
Jeff Law writes:
On 9/28/22 09:04, Richard Sandiford wrote:
Tamar Christina writes:
Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh.
But then I'd still need to change the expansion code. I suppose this could
prevent the issue
On 9/27/22 09:12, Andrea Corallo via Gcc-patches wrote:
Hi all
this is to address PR 99723.
In the PR GCC crashes as the initialization of common trees is not
performed as no compilation is happening, this is because we raise an
error earlier while processing the arch flags.
This patch chang
Hi!
On Wed, Aug 24, 2022 at 04:17:07PM +0800, Kewen.Lin wrote:
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -14771,18 +14771,9 @@ rs6000_print_patchable_function_entry (FILE *file,
> unsigned HOST_WIDE_INT patch_area_size,
>
On Thu, Sep 29, 2022 at 3:28 AM Martin Liška wrote:
> Sending V2 where I included new -gz=zstd option value.
>
> Cheers,
> Martin
At some point binutils will want to remove
--compress-debug-sections=zlib-gnu support as well.
I think the message can drop mentioning of
--compress-debug-sections=z
On Thu, 29 Sep 2022, Nathan Sidwell wrote:
>
> This adds smarts to the module machinery to handle NTTP object
> VAR_DECLs. Like typeinfo objects, these must be ignored in the symbol
> table, streamed specially and recreated on stream in.
>
> Patrick, thanks for the testcase, I don't know how to
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
cxx20_pair is trivially copyable because it has a trivial copy constructor
and only a deleted copy assignment operator; the non-triviality of the
unsatisfied copy assignment overload is not considered.
gcc/cp/ChangeLog:
* class.cc
Hi!
On Thu, Sep 29, 2022 at 02:16:04PM +0800, Kewen.Lin wrote:
> >> +/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target
> >> powerpc*-*-linux* powerpc-*-rtems* } 0 } */
> >
> > Everything except AIX even? So it will include Darwin as well (and the
> > BSDs, and powerpc*-elf, et
On Thu, 29 Sep 2022, Marek Polacek wrote:
> On Thu, Sep 29, 2022 at 11:05:04AM -0400, Patrick Palka via Gcc-patches wrote:
> > Adding a new builtin trait currently involves some boilerplate (as can
> > be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> > CPTK_ enumerators an
On Thu, Sep 29, 2022 at 07:33:14PM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 18:18, Segher Boessenkool
> > wrote:
> > On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
> >>> On 28 Sep 2022, at 22:30, Segher Boessenkool
> >>> wrote:
> >>> That works on Linux as well. What stil
Hi!
On Thu, Sep 29, 2022 at 07:25:44PM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 18:04, Segher Boessenkool
> > wrote:
> > On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
> >> Which means that we do not report an error, but a warning, and then we
> >> force 64b on (taking
> >
Hi Segher
> On 29 Sep 2022, at 18:18, Segher Boessenkool
> wrote:
>
> On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
>>> On 28 Sep 2022, at 22:30, Segher Boessenkool
>>> wrote:
>>> That works on Linux as well. What still does not work is user-mode
>>> context switches in 32-bit
Hi Segher
> On 29 Sep 2022, at 18:04, Segher Boessenkool
> wrote:
> On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
>> OK. So one small wrinkle,
>>
>> Darwin already has
>>
>> if (TARGET_64BIT && ! TARGET_POWERPC64)
>>{
>> rs6000_isa_flags |= OPTION_MASK_POWERPC64;
>>
When the mapper can't be executed, Windows report the error like:
.../bad-mapper-1.C: error: failed CreateProcess mapper 'this-will-not-work'
On Linux, the same error is reported this way:
.../bad-mapper-1.C: error: failed execvp mapper 'this-will-not-work'
This patch allows both output forms to
Hello,
This change augments the comment attached to the use of auto-host.h
in vxcrtstuff.c to better describe the reason for including it and
for the associated series of #undef directives.
It also augments the comment on dso_handle and removes a redundant
guard on HAVE_INITFINI_ARRAY_SUPPORT for
On Thu, Sep 29, 2022 at 11:05:04AM -0400, Patrick Palka via Gcc-patches wrote:
> Adding a new builtin trait currently involves some boilerplate (as can
> be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> CPTK_ enumerators and adding them to various switch statements across
>
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
We were overlooking non-potentially-constant bits in variable initializer
because we didn't walk into DECL_INITIAL.
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1): Look into
DECL_INITIAL. Use location w
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
When the gimplifier encounters the same TARGET_EXPR twice, it evaluates
TARGET_EXPR_INITIAL the first time and clears it so that the later
evaluation is just the temporary. With this testcase, using the extension
to treat an omitted middle
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
When the sides of ?: are class prvalues, we wrap the COND_EXPR in a
TARGET_EXPR so that both sides will initialize the same temporary. But in
this case we were stripping the outer TARGET_EXPR and conditionally creating
different temporaries
This introduces an ICE building libgcc for ia64-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088
https://sourceware.org/pipermail/libc-testresults/2022q3/010294.html
--
Joseph S. Myers
jos...@codesourcery.com
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-e
On Thu, Sep 29, 2022 at 12:16:38AM +0100, Iain Sandoe wrote:
> > On 29 Sep 2022, at 00:04, Iain Sandoe wrote:
> > adding —with-tune=G5 to the configure line .. the cross-build then succeeded
> > (at "-O1 -g" as I was building to debug) - maybe that will provide a clue,
> > but I’m
> > out of time
On Thu, Sep 29, 2022 at 12:04:05AM +0100, Iain Sandoe wrote:
> > On 28 Sep 2022, at 22:30, Segher Boessenkool
> > wrote:
> > That works on Linux as well. What still does not work is user-mode
> > context switches in 32-bit processes (so setjmp and getcontext stuff).
>
> AFAIU the Darwin impl. i
On Thu, Sep 29, 2022 at 01:45:16PM +0800, Kewen.Lin wrote:
> I found this flag is mainly related to tune setting and spotted that we have
> some code
> for tune setting when no explicit cpu is given.
>
> ...
>
> else
> {
> size_t i;
> enum processor_type tune_proc
> = (T
Hi!
On Thu, Sep 29, 2022 at 09:16:33AM +0100, Iain Sandoe wrote:
> OK. So one small wrinkle,
>
> Darwin already has
>
> if (TARGET_64BIT && ! TARGET_POWERPC64)
> {
> rs6000_isa_flags |= OPTION_MASK_POWERPC64;
> warning (0, "%qs requires PowerPC64 architecture, enabling", "-m6
Thanks for posting the patch.
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * tree-vect-loop.cc (vect_phi_first_order_recurrence_p): New function.
> (vect_analyze_scalar_cycles_1): Classify first-order recurrence phi.
> (vect_analyze_loop_operati
Hello,
This change prepares the ground prior to the reintroduction of
shared libs support for VxWorks.
On this platform, the use of shared libraries involves unusual
steps compared to standard native systems and enforcing static
links by default improves user experience.
This change arranges for
On Mon, 26 Sep 2022, Lulu Cheng wrote:
> +GTM_longjmp:
> +cfi_startproc
> +GPR_L $s0, $r5, 3*SZ_GPR
> +GPR_L $s1, $r5, 4*SZ_GPR
> +GPR_L $s2, $r5, 5*SZ_GPR
> +GPR_L $s3, $r5, 6*SZ_GPR
> +GPR_L $s4, $r5, 7*SZ_GPR
> +GPR_L $s5, $r5, 8*SZ_
I've committed this small clean up. It silences a warning.
Andrewamdgcn: remove unused variable
This was left over from a previous version of the SIMD clone patch.
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_simd_clone_compute_vecsize_and_simdlen):
Remove unused elt_bits variable.
On 27/09/2022 14:16, Tobias Burnus wrote:
@@ -422,6 +428,12 @@ struct agent_info
if it has been. */
bool initialized;
+ /* Flag whether the HSA program that consists of all the modules has been
+ finalized. */
+ bool prog_finalized;
+ /* Flag whether the HSA OpenMP's requires
Hi Kewen,
> On 29 Sep 2022, at 10:12, Kewen.Lin via Gcc-patches
> wrote:
> on 2022/9/29 16:16, Iain Sandoe wrote:
>>>
>>> I'm testing the attached diff which can be applied on top of the previous
>>> proposed patch
>>> on ppc64 and ppc64le, could you help to test it can fix the issue?
>>
>>
Hello,
Preparing a set of changes to support shared libs for VxWorks (again),
this patch makes sure that shared libraries for this family of targets
are only built on explicit request, when configured with --enable-shared
(by passing down --disable-shared to subdirs otherwise).
This provides us w
Hi!
Here is more complete patch to add std::bfloat16_t support on
x86, AArch64 and (only partially) on ARM 32-bit. No BFmode optabs
are added by the patch, so for binops/unops it extends to SFmode
first and then truncates back to BFmode.
For {HF,SF,DF,XF,TF}mode -> BFmode conversions libgcc has i
Kyrylo Tkachov writes:
> Hi Andrea,
[...]
> diff --git a/gcc/config/arm/aarch-bti-insert.cc
> b/gcc/config/arm/aarch-bti-insert.cc
> index 2d1d2e334a9..8f045c247bf 100644
> --- a/gcc/config/arm/aarch-bti-insert.cc
> +++ b/gcc/config/arm/aarch-bti-insert.cc
> @@ -41,6 +41,7 @@
> #include "cfgr
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, September 29, 2022 4:24 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: Andre Simoes Dias Vieira
> Subject: Re: [PATCH] testsuite: [arm] Relax expected register names in MVE
> tests
>
>
>
> On 9/29/22 17:01, Kyryl
On 9/29/22 17:01, Kyrylo Tkachov wrote:
Hi Christophe,
-Original Message-
From: Christophe Lyon
Sent: Thursday, September 29, 2022 3:57 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Andre Simoes Dias Vieira
; Christophe Lyon
Subject: [PATCH] testsuite: [arm] Relax expected re
On Thu, 29 Sep 2022, Patrick Palka wrote:
> Adding a new builtin trait currently involves some boilerplate (as can
> be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> CPTK_ enumerators and adding them to various switch statements across
> many files. The exact switch state
Hello,
This change simply adds a comment in vxworks.h, describing
our expectations wrt our use of HAVE_INITFINI_ARRAY_SUPPORT
from this header.
Committing to mainline shortly.
Cheers,
Olivier
2022-09-29 Olivier Hainque
gcc/
* config/vxworks.h: Add comment on our use of
HAVE
Adding a new builtin trait currently involves some boilerplate (as can
be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
CPTK_ enumerators and adding them to various switch statements across
many files. The exact switch statements we need to change is determined
by whether th
Hi Christophe,
> -Original Message-
> From: Christophe Lyon
> Sent: Thursday, September 29, 2022 3:57 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Andre Simoes Dias Vieira
> ; Christophe Lyon
>
> Subject: [PATCH] testsuite: [arm] Relax expected register names in MVE tests
>
>
These two tests have hardcoded q0 as destination/source of load/store
instructions, but it is actually used only under
-mfloat-abi=hard. When using -mfloat-abi=softfp, other registers
(eg. q3) can be used to transfer function arguments from core
registers to MVE registers, making the expected regex
This was found when testing buildroot with linuxthreads enabled. In
this case, the build passes --disable-tls to the toolchain during
configuration. After building the OpenRISC toolchain it was still
generating TLS code sequences and causing linker failures such as:
/or1k-buildroot-linux-uc
From: Sören Tempel
On glibc-based systems, off_t is a 32-bit type on 32-bit systems and a
64-bit type on 64-bit systems by default. However, on systems using musl
libc off_t is unconditionally a 64-bit type. As such, it is insufficient
to use a uintptr type for the mmap offset parameter.
Present
Hi Torbjörn,
On 9/23/22 10:43, Torbjörn SVENSSON via Gcc-patches wrote:
The cmse-15.c testcase fails at -Os because ICF means that we
generate
secure3:
b secure1
which is OK, but does not match the currently expected
secure3:
...
bx r[0-3]
gcc/testsuite/ChangeLog:
On Thu, Sep 29, 2022 at 1:07 PM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * tree-vect-loop.cc (vect_phi_first_order_recurrence_p): New function.
> (vect_analyze_scalar_cycles_1): Classify first-order recurrence phi.
> (vect_analyze_loop_operations): Add first-or
Hello,
This adjusts vx-common.h to #define DWARF2_UNWIND_INFO to 0
when ARM_UNWIND_INFO is set, preventing defaults.h from
possibly setting DWARF2_UNWIND_INFO to 1 (as well) on its own
afterwards if the macro isn't defined.
We have been using this for a while in gcc-11 development
toolchains for
On Thu, Sep 29, 2022 at 12:17 PM Richard Sandiford
wrote:
>
> Andrew Stubbs writes:
> > On 29/09/2022 10:24, Richard Sandiford wrote:
> >> Otherwise:
> >>
> >>operand0[0] = operand1 < operand2;
> >>for (i = 1; i < operand3; i++)
> >> operand0[i] = operand0[i - 1] && (operand1 + i < o
Hello,
This makes good sense in general anyway, and in particular
with forthcoming support for shared shared libraries, which will
work for mrtp alone but not yet for mrtp+mcmodel=large.
We have been using this in gcc-11 based development toolchains
for a while.
Committing to mainline.
Regards,
Hello,
We have, in vxworks.h:
/* linux64.h enables this, not supported in vxWorks. */
#undef TARGET_FLOAT128_ENABLE_TYPE
#define TARGET_FLOAT128_ENABLE_TYPE 0
We inherit linux64.h for a few reasons, but don't really support
float128 for vxworks, so the setting made sense.
Many tests rely
On 29.09.22 14:59, Julian Brown wrote:
On Wed, 28 Sep 2022 17:17:30 +0200 Tobias Burnus
wrote:
I don't see immediately whether some cases can still reach
omp_accumulate_sibling_list – if so, a testcase would be nice, or
whether that error_at can now be removed.
This version of the patch remov
On Wed, 28 Sep 2022 17:17:30 +0200
Tobias Burnus wrote:
> On 28.09.22 15:20, Julian Brown wrote:
>
> This patch fixes an ICE when both a complete struct variable and
> components of that struct are mapped on the same directive for
> OpenACC, using a modified version of the scheme used for OpenMP
This fixes libstdc++ for Clang and other non-GCC compilers.
Tested powerpc64le-linux. Pushed to trunk as r13-2954-gdf7f2736509cfe.
-- >8 --
I forgot that non-GCC compilers don't have this built-in yet.
For Clang we could do something like the check below (as described in
P2255), but for now I'm
This adds smarts to the module machinery to handle NTTP object
VAR_DECLs. Like typeinfo objects, these must be ignored in the symbol
table, streamed specially and recreated on stream in.
Patrick, thanks for the testcase, I don't know how to attribute that to
you in the changelog anymore.
nat
> On 8/5/22 05:41, Jose E. Marchesi via Gcc-patches wrote:
>> [Changes from V1:
>> - Added a test.]
>>
>> It is common for C BPF programs to use variables that are implicitly
>> set by the BPF loader and run-time. It is also necessary for these
>> variables to be stored in read-only storage so t
> Am 29.09.2022 um 12:23 schrieb Tamar Christina via Gcc-patches
> :
>
>
>>
>> -Original Message-
>> From: Richard Biener
>> Sent: Thursday, September 29, 2022 10:41 AM
>> To: Richard Sandiford
>> Cc: Jeff Law ; Tamar Christina
>> ; gcc-patches@gcc.gnu.org; nd
>> Subject: Re: [PA
From: Ju-Zhe Zhong
gcc/ChangeLog:
* tree-vect-loop.cc (vect_phi_first_order_recurrence_p): New function.
(vect_analyze_scalar_cycles_1): Classify first-order recurrence phi.
(vect_analyze_loop_operations): Add first-order recurrence
autovectorization support.
(ve
dr_may_alias_p rightly used poly_int_tree_p to guard a use of
ranges_maybe_overlap_p, but used the non-poly extractors.
This caused a few failures in the SVE ACLE asm tests.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. Pushed as obvious.
Richard
gcc/
* tree-data-ref.cc (dr_may_ali
After previous patches, it's possible to remove TARGET_*
options that are redundant due to (IMO) obvious dependencies.
gcc/
* config/aarch64/aarch64.h (TARGET_CRYPTO, TARGET_SHA3, TARGET_SM4)
(TARGET_DOTPROD): Don't depend on TARGET_SIMD.
(TARGET_AES, TARGET_SHA2): Likewise
Some of the option structures have all-const member variables.
That doesn't seem necessary: we can just use const on the objects
that are supposed to be read-only.
Also, with the new, more C++-heavy option handling, it seems
better to use constexpr for the static data, to make sure that
we're not
aarch64-common.cc has two arrays, one maintaining the original
definition order and one sorted by population count. Sorting
by population count was a way of ensuring topological ordering,
taking advantage of the fact that the entries are partially
ordered by the subset relation. However, the sort
-mgeneral-regs-only is effectively "+nofp for the compiler without
changing the assembler's ISA flags". Currently that's implemented
by making TARGET_FLOAT, TARGET_SIMD and TARGET_SVE depend on
!TARGET_GENERAL_REGS_ONLY and then making any feature that needs FP
registers depend (directly or indire
A previous patch added a aarch64_feature_flags typedef, to abstract
the representation of the feature flags. This patch makes existing
code use the typedef too. Hope I've caught them all!
gcc/
* common/config/aarch64/aarch64-common.cc: Use aarch64_feature_flags
for feature flags
Currently the aarch64-option-extensions.def entries, the
aarch64-cores.def entries, and the AARCH64_FL_FOR_* macros
have a transitive closure of dependencies that is maintained by hand.
This is a bit error-prone and is becoming less tenable as more features
are added. The main point of this patch
After previous changes, it's more convenient if the flags_on and
flags_off fields of all_extensions include the feature flag itself.
gcc/
* common/config/aarch64/aarch64-common.cc (all_extensions):
Include the feature flag in flags_on and flags_off.
(aarch64_parse_extension
aarch64-option-extensions.def requires us to maintain the transitive
closure of options by hand. This patch fixes a few cases where a
flag was missed.
+noaes and +nosha2 now disable +crypto, which IMO makes more
sense and is consistent with the Clang behaviour.
gcc/
* config/aarch64/aarc
Just a minor patch to avoid having to construct std::strings
in static data.
gcc/
* common/config/aarch64/aarch64-common.cc (processor_name_to_arch)
(arch_to_arch_name): Use const char * instead of std::string.
---
gcc/common/config/aarch64/aarch64-common.cc | 4 ++--
1 file chang
aarch64-option-extensions.def was topologically sorted except
for one case: crypto came before its aes and sha2 dependencies.
This patch moves crypto after sha2 instead.
gcc/
* config/aarch64/aarch64-option-extensions.def: Move crypto
after sha2.
gcc/testsuite/
* gcc.targe
The flags fields of the aarch64-cores.def always start with
AARCH64_FL_FOR_. After previous changes, is always
identical to the previous field, so we can drop the explicit
AARCH64_FL_FOR_ and derive it programmatically.
This isn't a big saving in itself, but it helps with later patches.
gcc/
AARCH64_FL_RCPC8_4 is an odd-one-out in that it has no associated
entry in aarch64-option-extensions.def. This means that, although
it is internally separated from AARCH64_FL_V8_4A, there is no
mechanism for turning it on and off individually, independently
of armv8.4-a.
The only place that the f
The aarch64-option-extensions.def parsing in config.gcc had
some code left over from when it tried to parse the whole
macro definition. Also, config.gcc now only looks at the
first fields of the aarch64-arches.def entries.
gcc/
* config.gcc: Remove dead aarch64-option-extensions.def code.
This patch renames AARCH64_FL_FOR_ARCH* macros to follow the
same V names that we (now) use elsewhere.
The names are only temporary -- a later patch will move the
information to the .def file instead. However, it helps with
the sequencing to do this first.
gcc/
* config/aarch64/aarch64.h
This patch completes the renaming of architecture-level related
things by adding "V" to the name of the architecture in
aarch64-arches.def. Since the "V" is predictable, we can easily
drop it when we don't need it (as when matching /proc/cpuinfo).
Having a valid C identifier is necessary for late
Following on from the previous AARCH64_ISA patch, this one adds the
profile name directly to the end of architecture-level AARCH64_FL_*
macros.
gcc/
* config/aarch64/aarch64.h (AARCH64_FL_V8_1, AARCH64_FL_V8_2)
(AARCH64_FL_V8_3, AARCH64_FL_V8_4, AARCH64_FL_V8_5, AARCH64_FL_V8_6)
All AARCH64_ISA_* architecture-level macros except AARCH64_ISA_V8_R
are for the A profile: they cause __ARM_ARCH_PROFILE to be set to
'A' and they are associated with architecture names like armv8.4-a.
It's convenient for later patches if we make this explicit
by adding an "A" to the name. Also,
This series of patches supposedly cleans up the definition of
the AArch64 ISA features. The main aims are:
- to make the naming more consistent
- to reduce the amount of boilerplate needed
- to avoid the need to maintain transitive closures by hand
- to enforce a sensible (topological) order on t
On Wed, 28 Sep 2022 16:44:29 -0400
Nathan Sidwell via Gcc-patches wrote:
> + else if (TREE_CODE (arg) == VAR_DECL && DECL_NTTP_OBJECT_P (arg))
Cosmetics, but I think the first part of the condition could be spelled
as VAR_P (arg)
thanks,
Sending V2 where I included new -gz=zstd option value.
Cheers,
MartinFrom 770ba230b34f698ec477dcef7ad207ab4e6be557 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 22 Sep 2022 15:03:34 +0200
Subject: [PATCH] changes: mentioned ignore -gz=zlib-gnu option
---
htdocs/gcc-13/changes.html | 5
> -Original Message-
> From: Richard Biener
> Sent: Thursday, September 29, 2022 10:41 AM
> To: Richard Sandiford
> Cc: Jeff Law ; Tamar Christina
> ; gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> branches, give hint if argument is a
Andrew Stubbs writes:
> On 29/09/2022 10:24, Richard Sandiford wrote:
>> Otherwise:
>>
>>operand0[0] = operand1 < operand2;
>>for (i = 1; i < operand3; i++)
>> operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
>>
>> looks like a "length and mask" operation, which IIUC is a
Hi!
The following testcase ICEs on x86 as well as ppc64le (the latter
with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
DF64x but e or u9__ieee128 instead.
Those are the mangling that should be used for the non-standard
types with the same mode or for long double, but not for _F
On 29/09/2022 10:24, Richard Sandiford wrote:
Otherwise:
operand0[0] = operand1 < operand2;
for (i = 1; i < operand3; i++)
operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
looks like a "length and mask" operation, which IIUC is also what
RVV wanted? (Wasn't at the Cauldro
On 29/09/2022 08:52, Richard Biener wrote:
On Wed, Sep 28, 2022 at 5:06 PM Andrew Stubbs wrote:
This patch is a prerequisite for some amdgcn patches I'm working on to
support shorter vector lengths (having fixed 64 lanes tends to miss
optimizations, and masking is not supported everywhere yet)
1 - 100 of 119 matches
Mail list logo
