;, Kind::F32_RUNTIME},
{"f64_runtime", Kind::F64_RUNTIME},
+
+ {"Some", Kind::OPTION_SOME},
+ {"None", Kind::OPTION_NONE},
+
+ {"into_iter", Kind::INTOITER_INTOITER},
+ {"next", Kind::ITERATOR_NEXT},
}};
tl::optional
diff --git a/gcc/rust/ut
): File "/usr/lib/python3.13/site-packages/git/cmd.py",
line 790, in __del__ File
"/usr/lib/python3.13/site-packages/git/cmd.py", line 781, in _terminate
File "/usr/lib64/python3.13/subprocess.py", line 2227, in terminate
ImportError: sys.meta_path is None, Python is lik
target/loongarch/pr118843.c
@@ -0,0 +1,6 @@
+/* { dg-do preprocess } */
+/* { dg-options "-mfrecipe -mfpu=none" } */
+
+#ifdef __loongarch_frecipe
+#error __loongarch_frecipe should not be avaliable here
+#endif
--
2.34.1
000..30372b8ffe6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/pr118843.c
@@ -0,0 +1,6 @@
+/* { dg-do preprocess } */
+/* { dg-options "-mfrecipe -mfpu=none" } */
+
+#ifdef __loongarch_frecipe
+#error __loongarch_frecipe should not be avaliable here
+#endif
--
2.34.1
ed to explicitly pass
-ffreestanding.
Tested in a x86_64-linux-gnu host with target bpf-unknown-none.
gcc/ChangeLog:
* config.gcc: install a wrapping stdint.h in bpf targets.
gcc/testsuite/ChangeLog:
* gcc.target/bpf/diag-funargs-2.c: Use -ffreestanding.
* gcc.target/bpf/h
On 26/09/2024 18:14, Matthieu Longo wrote:
> A previous patch ([1]) introduced a build regression on aarch64-none-elf
> target. The changes were primarilly tested on aarch64-unknown-linux-gnu,
> so the issue was missed during development.
> The includes are slighly different bet
On 2024-09-26 18:41, Andrew Pinski wrote:
On Thu, Sep 26, 2024 at 10:28 AM Andrew Pinski wrote:
On Thu, Sep 26, 2024 at 10:15 AM Matthieu Longo wrote:
A previous patch ([1]) introduced a build regression on aarch64-none-elf
target. The changes were primarilly tested on aarch64-unknown
On Thu, Sep 26, 2024 at 10:28 AM Andrew Pinski wrote:
>
> On Thu, Sep 26, 2024 at 10:15 AM Matthieu Longo
> wrote:
> >
> > A previous patch ([1]) introduced a build regression on aarch64-none-elf
> > target. The changes were primarilly tested on aarch64-unknown-linu
On Thu, Sep 26, 2024 at 10:15 AM Matthieu Longo wrote:
>
> A previous patch ([1]) introduced a build regression on aarch64-none-elf
> target. The changes were primarilly tested on aarch64-unknown-linux-gnu,
> so the issue was missed during development.
> The includes are slighly di
A previous patch ([1]) introduced a build regression on aarch64-none-elf
target. The changes were primarilly tested on aarch64-unknown-linux-gnu,
so the issue was missed during development.
The includes are slighly different between the two targets, and due to some
include rules ([2]), "aa
$ ./cc1plus -quiet g.C -fhardened -O2 -fstack-protector
> cc1plus: warning: '-fstack-protector-strong' is not enabled by '-fhardened'
> because it was specified on the command line [-Whardened]
>
> but it doesn't work as expected with -fcf-protection=none:
>
s specified on the command line [-Whardened]
> >
> > but it doesn't work as expected with -fcf-protection=none:
> >
> > $ ./cc1plus -quiet g.C -fhardened -O2 -fcf-protection=none
> >
> > because we're checking == CF_NONE which doesn't distinguis
>
> $ ./cc1plus -quiet g.C -fhardened -O2 -fstack-protector
> cc1plus: warning: '-fstack-protector-strong' is not enabled by '-fhardened'
> because it was specified on the command line [-Whardened]
>
> but it doesn't work as expected with -fcf-protectio
ack-protector-strong' is not enabled by '-fhardened'
because it was specified on the command line [-Whardened]
but it doesn't work as expected with -fcf-protection=none:
$ ./cc1plus -quiet g.C -fhardened -O2 -fcf-protection=none
because we're checking == CF_NONE which doesn&
n the _host-device_, through a
function pointer (C/C++), a pointer to a member function (C++), a dummy
procedure (Fortran), or a procedure pointer (Fortran) that refers to the
host version of the _procedure_."
OpenMP/Fortran: Fix defaultmap(none) issue with dummy procedures [PR1142
On Mon, Mar 11, 2024 at 11:07:46AM +0100, Tobias Burnus wrote:
> Using dummy procedures in a target region with 'defaultmap(none)' leads to:
>
> Error: 'g' not specified in enclosing 'target'
>
> and this cannot be fixed by using 'firstprivat
Using dummy procedures in a target region with 'defaultmap(none)' leads to:
Error: 'g' not specified in enclosing 'target'
and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines
are rejected as "Error: Object 'g' i
On 2024-03-01 15:58, Richard Earnshaw (lists) wrote:
On 19/02/2024 09:13, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-13?
Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
Jakub has just
On 19/02/2024 09:13, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-13?
> Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
>
> Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
Jakub has just pushed a different fix for this, so I do
On Mon, Feb 19, 2024 at 1:14 AM Torbjörn SVENSSON
wrote:
>
> Ok for trunk and releases/gcc-13?
> Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
>
> Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
>
Ok for trunk and releases/gcc-13?
Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
--
In commit 4fe34cdcc80ac225b80670eabc38ac5e31ce8a5a, -std=c23 support was
introduced to support functions without any
Even if !HAVE_AS_SUPPORT_CALL36, const_call_insn_operand should still
return false when -mexplict-relocs=none -mcmodel=medium to make
loongarch_legitimize_call_address emit la.local or la.global.
gcc/ChangeLog:
* config/loongarch/predicates.md (const_call_insn_operand):
Remove
gcc/ChangeLog:
* doc/invoke.texi (-mexplicit-relocs=style): Document.
(-mexplicit-relocs): Document as an alias of
-mexplicit-relocs=always.
(-mno-explicit-relocs): Document as an alias of
-mexplicit-relocs=none.
(-mcmodel=extreme): Mention
On Tue, 3 Oct 2023, 23:55 Jonathan Wakely, wrote:
>
>
> On Tue, 3 Oct 2023, 19:27 Tom Tromey, wrote:
>
>> Some code in the pretty-printers seems to assume that the
>> _versioned_namespace global might be None (or the empty string).
>> However, doesn't occur,
On Tue, 3 Oct 2023, 19:27 Tom Tromey, wrote:
> Some code in the pretty-printers seems to assume that the
> _versioned_namespace global might be None (or the empty string).
> However, doesn't occur, as the variable is never reassigned.
>
ok for trunk, but we should just rem
Some code in the pretty-printers seems to assume that the
_versioned_namespace global might be None (or the empty string).
However, doesn't occur, as the variable is never reassigned.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py: Assume that
_versioned_namespa
On Fri, 27 Jan 2023, Martin Liška wrote:
> We wrongly report:
>
> $ echo "int main () {}" | gcc -xc -gz=none -
> gcc: error: -gz=zstd is not supported in this configuration
>
> if zstd compression is not supported by binutils. We should emit the
> error message
We wrongly report:
$ echo "int main () {}" | gcc -xc -gz=none -
gcc: error: -gz=zstd is not supported in this configuration
if zstd compression is not supported by binutils. We should emit the
error message only if -gz=zstd.
PR driver/108572
Ready to be installed?
Thanks,
M
> Hi,
>
> I'm re-posting patches which I have posted at the end of stage 1 but
> which have not passed review yet.
>
> 8<
>
> While modifying the code, I realized that we do look into statements
> even when there are no replacem
Hi,
I'm re-posting patches which I have posted at the end of stage 1 but
which have not passed review yet.
8<
While modifying the code, I realized that we do look into statements
even when there are no replacements. This patch
Hi,
while modifying the code, I realized that we do look into statements
even when there are no replacements. This patch adds the necessary
early bail-outs to avoid that.
ipa_param_body_adjustments::modify_call_stmt cannot have the same at
the very beginning because calls can still contain other
This adjusts the assert guard to include -flto-partition=none which
behaves as WPA.
Bootstrapped & tested on x86_64-unknown-linux-gnu, pushed.
PR lto/106334
* dwarf2out.cc (dwarf2out_register_external_die): Adjust
assert.
---
gcc/dwarf2out.cc | 11 ++-
1
s can add the 'cf_check'
> > > function attribute to functions which can be reached by indirect branch.
> > >
> > > Add -fcf-check-attribute=[yes|no|none] to imply "cf_check" or "nocf_check"
> > > function attributes so that GCC can produc
"legal" forward edges than necessary. -mmanual-endbr
> > provides a way to insert ENDBR instruction at function entry only via
> > the 'cf_check' function attribute and programmers can add the 'cf_check'
> > function attribute to functions which can b
a way to insert ENDBR instruction at function entry only via
> the 'cf_check' function attribute and programmers can add the 'cf_check'
> function attribute to functions which can be reached by indirect branch.
>
> Add -fcf-check-attribute=[yes|no|none] to imply "cf_c
'cf_check' function attribute and programmers can add the 'cf_check'
function attribute to functions which can be reached by indirect branch.
Add -fcf-check-attribute=[yes|no|none] to imply "cf_check" or "nocf_check"
function attributes so that GCC can produce
'cf_check' function attribute and programmers can add the 'cf_check'
function attribute to functions which can be reached by indirect branch.
Add -fcf-check-attribute=[yes|no|none] to imply "cf_check" or "nocf_check"
function attributes so that GCC can produce
-cmi
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++17 (internal compiler error:
tree check: expected none of template_decl, have template_decl in
add_specializations, at cp/module.cc:12979)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std
en-sls=
+Target RejectNegative Joined Enum(harden_sls) Var(ix86_harden_sls)
Init(harden_sls_none)
+Generate code to mitigate against straight line speculation.
+
+Enum
+Name(harden_sls) Type(enum harden_sls)
+Known choices for mitigation against straight line speculation with
-mharden-sls=:
+
+E
eader-5_a.H module-cmi
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++17 (internal compiler error:
tree check: expected none of template_decl, have template_decl in
add_specializations, at cp/module.cc:12969)
FAIL: g++.dg/modules/x
/modules/xtreme-header-5_a.H -std=c++17 (internal compiler error:
tree check: expected none of template_decl, have template_decl in
add_specializations, at cp/module.cc:12968)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a
-5_a.H -std=c++17 (internal compiler error:
tree check: expected none of template_decl, have template_decl in
add_specializations, at cp/module.cc:12966)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (internal compiler
make it possible
to detect past-the-end accesses in calls to functions that
only take a pointer (and not a size).
This logic has proved to be overly restrictive for the "none"
access mode applied to void* pointer arguments as a signal
that a function doesn't access the object. Th
functions that
only take a pointer (and not a size).
This logic has proved to be overly restrictive for the "none"
access mode applied to void* pointer arguments as a signal
that a function doesn't access the object. The use case that
brought this to light is a function that only sto
kewise.
>
> OK, with a small nit below.
>
> Thanks,
> Uros.
>
> +mharden-sls=
> +Target RejectNegative Joined Enum(harden_sls) Var(ix86_harden_sls)
> Init(harden_sls_none)
> +Generate code to mitigate against straight line speculation.
> +
> +Enum
>
6/harden-sls-4.c: Likewise.
> > > * gcc.target/i386/harden-sls-5.c: Likewise.
OK, with a small nit below.
Thanks,
Uros.
+mharden-sls=
+Target RejectNegative Joined Enum(harden_sls) Var(ix86_harden_sls)
Init(harden_sls_none)
+Generate code to mitigate against straight line speculation.
+
r current function if needed. */
> > @@ -16277,10 +16281,10 @@ ix86_output_function_return (bool long_p)
> >return "";
> > }
> >
> > - if (!long_p)
> > -return "%!ret";
> > -
> > - return "rep%; ret";
>
sls & harden_sls_indirect_branch))
> + return "int3";
> + }
>return "";
> }
>
> diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
> index 46fad3cc038..8d499a5a4df 100644
> --- a/gcc/config/i386/i386.opt
> +++ b/g
harden_sls & harden_sls_return))
> > > > +return "%!ret\n\tint3";
> > > > + else
> > > > +{
> > > > + if (!long_p)
> > > > + return "%!ret";
> > > >
> > > > - re
harden-sls=
+Target RejectNegative Joined Enum(harden_sls) Var(ix86_harden_sls)
Init(harden_sls_none)
+Generate code to mitigate against straight line speculation.
+
+Enum
+Name(harden_sls) Type(enum harden_sls)
+Known choices for mitigation against straight line speculation with
-mharden-sls=:
> Also here.
>
> But fputs doesn't know "%!".
>
> >
> > >
> > > /* Output indirect function return. RET_OP is the function return
> > > @@ -16381,7 +16394,12 @@ ix86_output_call_insn (rtx_insn *insn, rtx
> > > call_op)
>
urn
> > @@ -16381,7 +16394,12 @@ ix86_output_call_insn (rtx_insn *insn, rtx call_op)
> >if (output_indirect_p && !direct_p)
> > ix86_output_indirect_branch (call_op, xasm, true);
> >else
> > - output_asm_insn (xasm, &call_op);
return "int3";
> + }
>return "";
> }
>
> diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
> index b38ac13fc91..c5452c49597 100644
> --- a/gcc/config/i386/i386.opt
> +++ b/gcc/config/i386/i386.opt
> @@ -1121,6 +1121,2
/i386.opt
@@ -1121,6 +1121,26 @@ mrecord-return
Target Var(ix86_flag_record_return) Init(0)
Generate a __return_loc section pointing to all return instrumentation code.
+mharden-sls=
+Target RejectNegative Joined Enum(harden_sls) Var(ix86_harden_sls)
Init(harden_sls_none)
+Generate code to mitigate agai
Le 31/10/2021 à 18:25, Bernhard Reutner-Fischer via Fortran a écrit :
As Gerhard Steinmetz noticed, gfc_match_implicit_none() had a notify_std
that mentioned IMPORT instead of IMPLICIT. Fix that typo.
IMPLICIT NONE (external) is supposed to require external procedures to
be explicitly declared
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/100972
* decl.c (gfc_match_implicit_none): Fix typo in warning.
* resolve.c (resolve_unknown_f): Reject external procedures
without explicit EXTERNAL attribute whe IMPLICIT none (external
rn true;
+ }
+}
return false;
}
--- gcc/testsuite/c-c++-common/ubsan/pr64888.c.jj 2021-10-20
11:48:18.715240008 +0200
+++ gcc/testsuite/c-c++-common/ubsan/pr64888.c 2021-10-20 11:47:57.670539595
+0200
@@ -0,0 +1,27 @@
+/* PR middle-end/64888 */
+/* { dg-do compile { tar
On 04.06.21 13:20, Tobias Burnus wrote:
This adds a bunch of 'implicit none' to the testcases,
a missing 'integer i' and fixes a typo in a loop variable,
which permitted to remove an xfail.
Or actually it didn't, as I seemingly did a last-minute change in the
wr
This adds a bunch of 'implicit none' to the testcases,
a missing 'integer i' and fixes a typo in a loop variable,
which permitted to remove an xfail.
Currently, there are two classes of xfail:
* !$omp parallel master taskloop (simd)
→ parallel misses shared(...)
Joern Rennecke writes:
> At the moment, for a match_dup in a define_cond_exec, you'd have to
> give the number in the
> resulting pattern(s) rather than in the substitute pattern. That's
> not only wrong, but can also
> be impossible when the pattern should apply to multiple patterns with
> diffe
tomic_flag/test_and_set/explicit-hle.cc (test for excess
errors)
Add -fcf-protection=none to -march=i486 to compile explicit-hle.cc.
Checked it in as an obvious fix.
* testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc:
Add -fcf-protection=none to -march=i486.
---
.../
On 9/23/20 3:10 PM, Richard Biener wrote:
On Wed, 23 Sep 2020, Richard Biener wrote:
LTRANS usually makes the symbols hidden, not local.
Could also be – whatever the 'nm' output means.
So are you
sure this isn't a target bug (hidden symbols not implemented
but the host compiler obviously havi
On Wed, 23 Sep 2020, Richard Biener wrote:
> On Wed, 23 Sep 2020, Tobias Burnus wrote:
>
> > (Pre-remark: the following applies to the host; the offloading
> > is only involved as otherwise the (.gnu.)offload_{vars,funcs}
> > global variable/table wouldn't exist.)
> >
> > Due to partitioning, it
On Wed, 23 Sep 2020, Tobias Burnus wrote:
> (Pre-remark: the following applies to the host; the offloading
> is only involved as otherwise the (.gnu.)offload_{vars,funcs}
> global variable/table wouldn't exist.)
>
> Due to partitioning, it can happen that the offloading table
> and the functions
On Wed, Sep 23, 2020 at 02:53:54PM +0200, Tobias Burnus wrote:
> (Pre-remark: the following applies to the host; the offloading
> is only involved as otherwise the (.gnu.)offload_{vars,funcs}
> global variable/table wouldn't exist.)
>
> Due to partitioning, it can happen that the offloading table
ning if the code has offloading.
OK for mainline? — Or better suggestions how to handle this?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
lto-wrapper.c: Use
irst.
> -fcf-protection=none is added to avoid false negative when -fcf-protection
> is enabled by default.
>
> OK for master?
OK.
> H.J.
> ---
> config/
>
> PR bootstrap/94739
> * cet.m4 (GCC_CET_HOST_FLAGS): Add -fcf-protection=none to
> -Wl,-z
GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host
has Intel CET enabled by introducing an Intel CET violation on purpose.
To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first.
-fcf-protection=none is added to avoid false negative when -fcf-protection
is
Backported to GCC 9, cf. attachment.
Tobias
On 1/20/20 3:55 PM, Tobias Burnus wrote:
Using "implicit none" multiple times in a scoping unit is not
permitted – and checked for.
However, using one in the parent name space and re-confirming it in
the current name space is permitted
Hi Bernhard,
On 1/21/20 12:43 PM, Bernhard Reutner-Fischer wrote:
+ if (sym->attr.proc == PROC_UNKNOWN)
+ for (gfc_namespace *ns = sym->ns; ns; ns = ns->parent)
+ if (ns->has_implicit_none_export)
+has_implicit_none_export = true;
s/;/, break;/
If we don't do th
On 20 January 2020 15:55:23 CET, Tobias Burnus wrote:
>Using "implicit none" multiple times in a scoping unit is not permitted
>
>– and checked for.
>
>However, using one in the parent name space and re-confirming it in the
>
>current name space is permitted – but w
Using "implicit none" multiple times in a scoping unit is not permitted
– and checked for.
However, using one in the parent name space and re-confirming it in the
current name space is permitted – but was before rejected.
OK for the trunk?
Tobias
PR fortran/93309
* i
Hi!
When building offloading cross-compiler from x86_64-linux to nvptx-none, the
build fails with:
../../gcc/cp/coroutines.cc: In function 'tree_node*
get_fn_local_identifier(tree, const char*)':
../../gcc/cp/coroutines.cc:2255:12: error: expected ';' before
Hi!
The following patch makes array or derived type module parameters from other
TUs predetermined shared, so that they aren't rejected with default(none) or
copied with default(firstprivate). I went through all the spots in the
Fortran FE that set TREE_READONLY, most of them are on PARM_
On 18/09/18 14:59, Rainer Orth wrote:
Hi Kyrill,
This new test has some difficulties on the fabsl function.
On arm this is because we don't support the _Float128 type which the test uses.
This is handled in the patch by requiring a float128 target selector.
On aarch64-none-elf, a N
Hi Kyrill,
> This new test has some difficulties on the fabsl function.
> On arm this is because we don't support the _Float128 type which the test
> uses.
> This is handled in the patch by requiring a float128 target selector.
>
> On aarch64-none-elf, a Newlib target, it
On 9/18/18 7:45 AM, Kyrill Tkachov wrote:
> Hi all,
>
> This new test has some difficulties on the fabsl function.
> On arm this is because we don't support the _Float128 type which the
> test uses.
> This is handled in the patch by requiring a float128 target selector.
&
Hi all,
This new test has some difficulties on the fabsl function.
On arm this is because we don't support the _Float128 type which the test uses.
This is handled in the patch by requiring a float128 target selector.
On aarch64-none-elf, a Newlib target, it fails because fabsl is not avai
Hi!
While we explicitly firstprivatize temporaries used in VLA size
computations, if the VLAs are indirect (pointer to VLA) or struct element
pointer to VLA etc., the temporaries are just handled using the default
sharing. For C/C++ that works fine as long as default(none) isn't used, at
On Wed, Apr 18, 2018 at 1:59 AM, Tsimbalist, Igor V
wrote:
>> -Original Message-
>> From: Lu, Hongjiu
>> Sent: Sunday, April 15, 2018 12:59 PM
>> To: gcc-patches@gcc.gnu.org; Uros Bizjak ; Tsimbalist,
>> Igor V
>> Subject: [PATCH] x86: Compil
> -Original Message-
> From: Lu, Hongjiu
> Sent: Sunday, April 15, 2018 12:59 PM
> To: gcc-patches@gcc.gnu.org; Uros Bizjak ; Tsimbalist,
> Igor V
> Subject: [PATCH] x86: Compile with -fcf-protection=none -mno-cet
>
> These tests must be compiled with -fcf-protec
On Sun, Apr 15, 2018 at 12:59 PM, H.J. Lu wrote:
> These tests must be compiled with -fcf-protection=none -mno-cet.
Required for correctness or just to make the dump scannings happy?
In that case I'd prefer the more descriptive dg-skip-if
> OK for trunk?
>
> H.J.
>
>
These tests must be compiled with -fcf-protection=none -mno-cet.
OK for trunk?
H.J.
* c-c++-common/attr-nocf-check-1.c: Compile with
-fcf-protection=none -mno-cet for x86 targets.
* c-c++-common/attr-nocf-check-3.c: Likewise.
* gcc.dg/march-generic.c
On 12/06/2017 03:58 PM, Jeff Law wrote:
On 12/06/2017 12:41 PM, Jeff Law wrote:
On 12/06/2017 12:27 PM, Martin Sebor wrote:
For reference, I committed r255450 to avoid the test failure
reported on the arm-none-eabi target. The warning is valid
but unrelated to the purpose of the test so I
On 12/06/2017 12:41 PM, Jeff Law wrote:
> On 12/06/2017 12:27 PM, Martin Sebor wrote:
>> For reference, I committed r255450 to avoid the test failure
>> reported on the arm-none-eabi target. The warning is valid
>> but unrelated to the purpose of the test so I pruned
On 12/06/2017 12:58 PM, Martin Sebor wrote:
> On 12/06/2017 12:41 PM, Jeff Law wrote:
>> On 12/06/2017 12:27 PM, Martin Sebor wrote:
>>> For reference, I committed r255450 to avoid the test failure
>>> reported on the arm-none-eabi target. The warning is valid
>>
On 12/06/2017 12:41 PM, Jeff Law wrote:
On 12/06/2017 12:27 PM, Martin Sebor wrote:
For reference, I committed r255450 to avoid the test failure
reported on the arm-none-eabi target. The warning is valid
but unrelated to the purpose of the test so I pruned it from
its output.
Martin
Index
On 12/06/2017 12:27 PM, Martin Sebor wrote:
> For reference, I committed r255450 to avoid the test failure
> reported on the arm-none-eabi target. The warning is valid
> but unrelated to the purpose of the test so I pruned it from
> its output.
>
> Martin
>
> Index:
For reference, I committed r255450 to avoid the test failure
reported on the arm-none-eabi target. The warning is valid
but unrelated to the purpose of the test so I pruned it from
its output.
Martin
Index: gcc/testsuite/ChangeLog
-mprefer-avx[128|256] options into common
> -mprefer-vector-width=[none|128|256|512]
>
> On Tue, Nov 21, 2017 at 4:50 PM, Shalnov, Sergey
> wrote:
>> Uros,
>> I did new patch with all comments addressed as proposed.
>> 1. old option -mprefer-avx128 is Alias(mprefer-vector
, Julia
; Senkevich, Andrew ; Peryt,
Sebastian ; Ivchenko, Alexander
; Joseph Myers
Subject: Re: [PATCH, i386] Refactor -mprefer-avx[128|256] options into common
-mprefer-vector-width=[none|128|256|512]
On Tue, Nov 21, 2017 at 4:50 PM, Shalnov, Sergey
wrote:
> Uros,
> I did new patch wi
On Tue, Nov 21, 2017 at 4:50 PM, Shalnov, Sergey
wrote:
> Uros,
> I did new patch with all comments addressed as proposed.
> 1. old option -mprefer-avx128 is Alias(mprefer-vector-width=, 128, none)
> 2. Simplified default initialization (as Bernhard proposed)
> 3. Fixed documentati
Uros,
I did new patch with all comments addressed as proposed.
1. old option -mprefer-avx128 is Alias(mprefer-vector-width=, 128, none)
2. Simplified default initialization (as Bernhard proposed)
3. Fixed documentation (proposed by Sandra)
4. Several tests are changed to use new style of the
-vectorizer.
+@table @samp
+@item none
+No extra limitations applied to GCC over than defined by the selected platform.
+
s/over than/other than/ ???
-Sandra
x128" form.]
>
> It's used in that form in various testcases that otherwise fail when GCC
> is configured --with-arch= some CPU that defaults to -mprefer-avx128.
In this case, an even better choice would be:
Alias(mprefer-vector-width=, 128, none)
So, -mno-prefer-avx128 would just set the default back to none.
Uros.
On Mon, 13 Nov 2017, Uros Bizjak wrote:
> [BTW: --mprefer-avx128 should be marked RejectNegative from the
> beginning; let's just assume nobody uses it in its (somehow weird)
> negative "-mno-prefer-avx128" form.]
It's used in that form in various testcases that otherwise fail when GCC
is config
fer-avx512", "-mprefer-avx1024", etc. I propose to implement
>> the option "-mprefer-vector-width=[none|128|256|512]".
>>
>> Also I propose to remove recently added -mprefer-avx256 option in favor
>> of -mprefer-vector-width=256 and consider also make -mp
r-avx128" and "-mprefer-avx256" options to limit
> maximum
> vector register width in vectorizer. To avoid feature implementation of
> further options
> like "-mprefer-avx512", "-mprefer-avx1024", etc. I propose to implement
> the option "-mprefer
th in vectorizer. To avoid feature implementation of further
options
like "-mprefer-avx512", "-mprefer-avx1024", etc. I propose to implement
the option "-mprefer-vector-width=[none|128|256|512]".
Also I propose to remove recently added -mprefer-avx256 option in fa
On Fri, Sep 1, 2017 at 3:01 PM, Martin Liška wrote:
> On 09/01/2017 12:57 PM, Richard Biener wrote:
>> On Fri, Sep 1, 2017 at 12:44 PM, Martin Liška wrote:
>>> On 09/01/2017 10:26 AM, Richard Biener wrote:
On Fri, Sep 1, 2017 at 10:07 AM, Martin Liška wrote:
> On 08/30/2017 02:56 PM, Ri
1 - 100 of 192 matches
Mail list logo
