[PATCH] Make flag_trapping_math a non-binary Boolean.
Normally Boolean options/flags in GCC take the values zero or one.
This patch tweaks flag_trapping_math to take the values 0 or 65535.
More accurately it introduces a new trapping_math_model enumeration in
flag-types.h, and uses this to allow front-ends to (potentially) control
which expressions may be constant folded at compile-time by the middle-end.
Floating point/language experts may recognize these flags (bits) as being
modelled upon (extended) FENV_ACCESS.
This instalment simply introduces the necessary infrastructure without
yet changing any functionality. The test "if (flag_trapping_math)" will
remain perfectly valid (but pessimistic). The goal is to allow time
for out-of-tree front-ends (modula-2, rust, etc.) to update themselves,
if required, and to confirm that this change doesn't introduce problems
for LTO, or elsewhere.
This patch has been tested on x86_64-pc-linux-gnu with "make bootstrap"
and "make -k check", all languages including Ada, with no new failures.
Ok for mainline?
2021-09-25 Roger Sayle
gcc/ChangeLog
* flag-types.h (trapping_math_model): New enumeration (of bits)
specifying possible floating-point (and integer) exceptions/traps.
* common.opt (ftrapping-math): Specify UInteger and initialize to
flag_trapping_math to TRAPPING_MATH_DEFAULT.
* toplev.c (process_options): The option -fsignaling-nans should
set flag_trapping_math to TRAPPING_MATH_DEFAULT.
gcc/ada/ChangeLog
* gcc-interface/misc.c (gnat_init_gcc_fp): Set flag_trapping_math
to TRAPPING_MATH_DEFAULT (instead of 1) if S'Machine_Overflow.
Roger
--
diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index 96199bd..93cbc71 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -451,7 +451,7 @@ gnat_init_gcc_fp (void)
/* Assume that FP operations can trap if S'Machine_Overflow is true,
but don't override the user if not. */
if (Machine_Overflows_On_Target)
-flag_trapping_math = 1;
+flag_trapping_math = TRAPPING_MATH_DEFAULT;
else if (!global_options_set.x_flag_trapping_math)
flag_trapping_math = 0;
}
diff --git a/gcc/common.opt b/gcc/common.opt
index b921f5e..314f9a7 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2750,7 +2750,7 @@ generate them instead of using descriptors.
; (user-visible) trap. This is the case, for example, in nonstop
; IEEE 754 arithmetic.
ftrapping-math
-Common Var(flag_trapping_math) Init(1) Optimization SetByCombined
+Common Var(flag_trapping_math) Init(TRAPPING_MATH_DEFAULT) Optimization
SetByCombined UInteger
Assume floating-point operations can trap.
ftrapv
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 5bd1f77..98b9ff0 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -481,6 +481,33 @@ enum openacc_privatization
OPENACC_PRIVATIZATION_NOISY
};
+/* Trapping math exception classes. */
+enum trapping_math_model
+{
+ TRAPPING_MATH_NONE = 0,
+ TRAPPING_MATH_QNANOP = 1UL << 0,
+ TRAPPING_MATH_SNANOP = 1UL << 1,
+ TRAPPING_MATH_QNANCMP = 1UL << 2,
+ TRAPPING_MATH_SNANCMP = 1UL << 3,
+ TRAPPING_MATH_INTCONV = 1UL << 4,
+ TRAPPING_MATH_SQRTNEG = 1UL << 5,
+ TRAPPING_MATH_LIBMFUN = 1UL << 6,
+ TRAPPING_MATH_FDIVZERO = 1UL << 7,
+ TRAPPING_MATH_IDIVZERO = 1UL << 8,
+ TRAPPING_MATH_FPDENORM = 1UL << 9,
+ TRAPPING_MATH_OVERFLOW = 1UL << 10,
+ TRAPPING_MATH_UNDERFLOW = 1UL << 11,
+ TRAPPING_MATH_INFDIVINF = 1UL << 12,
+ TRAPPING_MATH_INFSUBINF = 1UL << 13,
+ TRAPPING_MATH_INFMULZERO = 1UL << 14,
+ TRAPPING_MATH_ZERODIVZERO = 1UL << 15,
+
+ TRAPPING_MATH_DEFAULT = (1UL << 16) - 1,
+
+ TRAPPING_MATH_INEXACT = 1UL << 16,
+ TRAPPING_MATH_TRAPV = 1UL << 17
+};
+
#endif
#endif /* ! GCC_FLAG_TYPES_H */
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 14d1335..6cd71cc 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1664,7 +1664,7 @@ process_options (void)
/* The presence of IEEE signaling NaNs, implies all math can trap. */
if (flag_signaling_nans)
-flag_trapping_math = 1;
+flag_trapping_math = TRAPPING_MATH_DEFAULT;
/* We cannot reassociate if we want traps or signed zeros. */
if (flag_associative_math && (flag_trapping_math || flag_signed_zeros))
[PATCH] Introduce sh_mul and uh_mul RTX codes for high-part multiplications
This patch introduces new RTX codes to allow the RTL passes and
backends to consistently represent high-part multiplications.
Currently, the RTL used by different backends for expanding
smul3_highpart and umul3_highpart varies greatly,
with many but not all choosing to express this something like:
(define_insn "smuldi3_highpart"
[(set (match_operand:DI 0 "nvptx_register_operand" "=R")
(truncate:DI
(lshiftrt:TI
(mult:TI (sign_extend:TI
(match_operand:DI 1 "nvptx_register_operand" "R"))
(sign_extend:TI
(match_operand:DI 2 "nvptx_register_operand" "R")))
(const_int 64]
""
"%.\\tmul.hi.s64\\t%0, %1, %2;")
One complication with using this "widening multiplication" representation
is that it requires an intermediate in a wider mode, making it difficult
or impossible to encode a high-part multiplication of the widest supported
integer mode. A second is that it can interfere with optimization; for
example simplify-rtx.c contains the comment:
case TRUNCATE:
/* Don't optimize (lshiftrt (mult ...)) as it would interfere
with the umulXi3_highpart patterns. */
Hopefully these problems are solved (or reduced) by introducing a
new canonical form for high-part multiplications in RTL passes.
This also simplifies insn patterns when one operand is constant.
Whilst implementing some constant folding simplifications and
compile-time evaluation of these new RTX codes, I noticed that
this functionality could also be added for the existing saturating
arithmetic RTX codes. Then likewise when documenting these new RTX
codes, I also took the opportunity to silence the @xref warnings in
invoke.texi.
This patch has been tested on x86_64-pc-linux-gnu with "make bootstrap"
and "make -k check" with no new failures. Ok for mainline?
2021-09-25 Roger Sayle
gcc/ChangeLog
* gcc/rtl.def (SH_MULT, UH_MULT): New RTX codes for representing
signed and unsigned high-part multiplication respectively.
* gcc/simplify-rtx.c (simplify_binary_operation_1) [SH_MULT,
UH_MULT]: Simplify high-part multiplications by zero.
[SS_PLUS, US_PLUS, SS_MINUS, US_MINUS, SS_MULT, US_MULT,
SS_DIV, US_DIV]: Similar simplifications for saturating
arithmetic.
(simplify_const_binary_operation) [SS_PLUS, US_PLUS, SS_MINUS,
US_MINUS, SS_MULT, US_MULT, SH_MULT, UH_MULT]: Implement
compile-time evaluation for constant operands.
* gcc/dwarf2out.c (mem_loc_descriptor): Skip SH_MULT and UH_MULT.
* doc/rtl.texi (sh_mult, uhmult): Document new RTX codes.
* doc/md.texi (smul@var{m}3_highpart, umul@var{m3}_highpart):
Mention the new sh_mul and uh_mul RTX codes.
* doc/invoke.texi: Silence @xref "compilation" warnings.
Roger
--
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4acb941..2de7d99 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -3125,7 +3125,7 @@ errors if these functions are not inlined everywhere they
are called.
@itemx -fno-modules-ts
@opindex fmodules-ts
@opindex fno-modules-ts
-Enable support for C++20 modules (@xref{C++ Modules}). The
+Enable support for C++20 modules, see @xref{C++ Modules}. The
@option{-fno-modules-ts} is usually not needed, as that is the
default. Even though this is a C++20 feature, it is not currently
implicitly enabled by selecting that standard version.
@@ -33553,7 +33553,7 @@ version selected, although in pre-C++20 versions, it is
of course an
extension.
No new source file suffixes are required or supported. If you wish to
-use a non-standard suffix (@xref{Overall Options}), you also need
+use a non-standard suffix, see @xref{Overall Options}, you also need
to provide a @option{-x c++} option too.@footnote{Some users like to
distinguish module interface files with a new suffix, such as naming
the source @code{module.cppm}, which involves
@@ -33615,8 +33615,8 @@ to be resolved at the end of compilation. Without
this, imported
macros are only resolved when expanded or (re)defined. This option
detects conflicting import definitions for all macros.
-@xref{C++ Module Mapper} for details of the @option{-fmodule-mapper}
-family of options.
+For details of the @option{-fmodule-mapper} family of options,
+see @xref{C++ Module Mapper}.
@menu
* C++ Module Mapper:: Module Mapper
@@ -33833,8 +33833,8 @@ dialect used and imports of the module.@footnote{The
precise contents
of this output may change.} The timestamp is the same value as that
provided by the @code{__DATE__} & @code{__TIME__} macros, and may be
explicitly specified with the environment variable
-@code{SOURCE_DATE_EPOCH}. @xref{Environment Variables} for further
-details.
+@code{SOURCE_DATE_EPOCH}. For further details see
+@xref{Environment Variables}.
A set of related CMIs may be copied, provided the relative pathnames
are preserved.
diff --git a/gcc/doc/md.texi b/gcc/doc/m
Re: [PATCH] Introduce sh_mul and uh_mul RTX codes for high-part multiplications
On Sep 25 2021, Roger Sayle wrote:
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 4acb941..2de7d99 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -3125,7 +3125,7 @@ errors if these functions are not inlined everywhere
> they are called.
> @itemx -fno-modules-ts
> @opindex fmodules-ts
> @opindex fno-modules-ts
> -Enable support for C++20 modules (@xref{C++ Modules}). The
> +Enable support for C++20 modules, see @xref{C++ Modules}. The
Or (@pxref{...}).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
On 23.09.21 21:47, Harald Anlauf via Fortran wrote: Dear Fortranners, we missed certain intrinsics as being disallowed in constant expressions, which lead to an ICE when these intrinsics were used in a specification expression with an initializer. The intrinsics in question are listed in F2018:10.1.2. As discussed in the PR, Steve recommended to omit TRANSFER from that list, as it is special and might need separate treatment. I also could not come up with a case where TRANSFER should not have simplified to a constant and we would run into an issue. (We could leave that job to Gerhard... ;-). However, in testing I encountered a case involving TRANSFER that is not properly simplified, which seems orthogonal to the present case. I would like to handle this separately. This case is mentioned in the testcase, but commented out. Regtested on x86_64-pc-linux-gnu. OK for mainline? It was actually 10.1.12 :-) OK for trunk. Thanks for the patch! Best regards Thomas
*PING* [PATCH] libiberty: allow comments in option file
Hello,
Sorry for bumping it again but I guess it was getting overlooked.
I am very junior with mailing list open source contributions so please feel
free to point out if I have inadvertantly done something in an incorrect way.
The archive of the original email can be found at
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579232.html
and is also appended below.
Best regards,
Hu Jialun
> Enables putting line comments into option files included using '@'.
>
> Comments begin with a ';' followed by whitespace, and terminates at the
> end of the line. Backward compability should be satisfactory since ';'
> is a character disallowed in DOS filenames and rarely used in filenames
> or options anywhere else as well.
>
> Related discussion: https://gcc.gnu.org/legacy-ml/gcc/2011-02/msg00422.html
> ---
> libiberty/argv.c | 5 +
> libiberty/testsuite/test-expandargv.c | 12
> 2 files changed, 17 insertions(+)
>
> diff --git a/libiberty/argv.c b/libiberty/argv.c
> index 48dcd102461..2bc7569b718 100644
> --- a/libiberty/argv.c
> +++ b/libiberty/argv.c
> @@ -194,6 +194,11 @@ char **buildargv (const char *input)
> {
> /* Pick off argv[argc] */
> consume_whitespace (&input);
> + if (*input == ';')
> + {
> + for (; *input != '\n' && *input != EOS; ++input);
> + continue;
> + }
>
> if ((maxargc == 0) || (argc >= (maxargc - 1)))
> {
> diff --git a/libiberty/testsuite/test-expandargv.c
> b/libiberty/testsuite/test-expandargv.c
> index 56c170f9ec6..5640b2b41cf 100644
> --- a/libiberty/testsuite/test-expandargv.c
> +++ b/libiberty/testsuite/test-expandargv.c
> @@ -142,6 +142,18 @@ const char *test_data[] = {
>"b",
>0,
>
> + /* Test 7 - Check for comments in option file. */
> + "abc\n;def\nxy \\;z \\ ;gh",/* Test 7 data */
> + ARGV0,
> + "@test-expandargv-7.lst",
> + 0,
> + ARGV0,
> + "abc",
> + "xy",
> + ";z",
> + " ;gh",
> + 0,
> +
>0 /* Test done marker, don't remove. */
> };
>
> --
> 2.33.0
[COMMITTED][PATCH v2] pru: Named address space for R30/R31 I/O access
I have committed the below patch. I've made only cosmetic updates since version 1 (https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579420.html). The PRU architecture provides single-cycle access to GPIO pins via special designated CPU registers - R30 and R31. These two registers can of course be accessed in C code using inline assembly, but that can be intimidating to users. The TI proprietary compiler [1] can expose these I/O registers as global volatile registers: volatile register unsigned int __R31; Consequently, accessing them in user programs is as straightforward as using a regular global variable: __R31 |= (1 << 2); Unfortunately, global volatile registers are not supported by GCC [2]. I decided to implement convenient access to __R30 and __R31 using a new named address space: extern volatile __regio_symbol unsigned int __R30; Unlike global registers, volatile global memory variables are well supported in GCC. Memory writes and reads to the __regio_symbol address space are converted to writes and reads to R30 and R31 CPU registers. The declared variable name determines which of the two registers it is representing. With an ifdef for the __R30/__R31 declarations, user programs can now be source-compatible with both TI and GCC toolchains. [1] https://www.ti.com/lit/ug/spruhv7c/spruhv7c.pdf , "Global Register Variables" [2] https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02241.html gcc/ChangeLog: * config/pru/constraints.md (Rrio): New constraint. * config/pru/predicates.md (regio_operand): New predicate. * config/pru/pru-pragma.c (pru_register_pragmas): Register the __regio_symbol address space. * config/pru/pru-protos.h (pru_symref2ioregno): Declaration. * config/pru/pru.c (pru_symref2ioregno): New helper function. (pru_legitimate_address_p): Remove. (pru_addr_space_legitimate_address_p): Use the address space aware hook variant. (pru_nongeneric_pointer_addrspace): New helper function. (pru_insert_attributes): New function to validate __regio_symbol usage. (TARGET_INSERT_ATTRIBUTES): New macro. (TARGET_LEGITIMATE_ADDRESS_P): Remove. (TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P): New macro. * config/pru/pru.h (enum reg_class): Add REGIO_REGS class. * config/pru/pru.md (*regio_readsi): New pattern to read I/O registers. (*regio_nozext_writesi): New pattern to write to I/O registers. (*regio_zext_write_r30): Ditto. * doc/extend.texi: Document the new PRU Named Address Space. gcc/testsuite/ChangeLog: * gcc.target/pru/regio-as-pointer.c: New negative test. * gcc.target/pru/regio-as-pointer-2.c: New negative test. * gcc.target/pru/regio-decl-2.c: New negative test. * gcc.target/pru/regio-decl-3.c: New negative test. * gcc.target/pru/regio-decl-4.c: New negative test. * gcc.target/pru/regio-decl.c: New negative test. * gcc.target/pru/regio-di.c: New negative test. * gcc.target/pru/regio-hi.c: New negative test. * gcc.target/pru/regio-qi.c: New negative test. * gcc.target/pru/regio.c: New test. * gcc.target/pru/regio.h: New helper header. Signed-off-by: Dimitar Dimitrov --- gcc/config/pru/constraints.md | 5 + gcc/config/pru/predicates.md | 19 +++ gcc/config/pru/pru-pragma.c | 2 + gcc/config/pru/pru-protos.h | 3 + gcc/config/pru/pru.c | 156 +- gcc/config/pru/pru.h | 5 + gcc/config/pru/pru.md | 102 +++- gcc/doc/extend.texi | 19 ++- .../gcc.target/pru/regio-as-pointer-2.c | 11 ++ .../gcc.target/pru/regio-as-pointer.c | 11 ++ gcc/testsuite/gcc.target/pru/regio-decl-2.c | 13 ++ gcc/testsuite/gcc.target/pru/regio-decl-3.c | 19 +++ gcc/testsuite/gcc.target/pru/regio-decl-4.c | 17 ++ gcc/testsuite/gcc.target/pru/regio-decl.c | 15 ++ gcc/testsuite/gcc.target/pru/regio-di.c | 9 + gcc/testsuite/gcc.target/pru/regio-hi.c | 9 + gcc/testsuite/gcc.target/pru/regio-qi.c | 9 + gcc/testsuite/gcc.target/pru/regio.c | 58 +++ gcc/testsuite/gcc.target/pru/regio.h | 7 + 19 files changed, 478 insertions(+), 11 deletions(-) create mode 100644 gcc/testsuite/gcc.target/pru/regio-as-pointer-2.c create mode 100644 gcc/testsuite/gcc.target/pru/regio-as-pointer.c create mode 100644 gcc/testsuite/gcc.target/pru/regio-decl-2.c create mode 100644 gcc/testsuite/gcc.target/pru/regio-decl-3.c create mode 100644 gcc/testsuite/gcc.target/pru/regio-decl-4.c create mode 100644 gcc/testsuite/gcc.target/pru/regio-decl.c create mode 100644 gcc/testsuite/gcc.target/pru/regio-di.c create mode 100644 gcc/testsuite/gcc.target/pru/regio-hi.c create mode 100644 gcc/testsuite/gc
Re: [Patch] Fortran: Fix associated intrinsic with assumed rank [PR101334] [was: [PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)]
On 23.09.21 21:13, Tobias Burnus wrote: On 20.09.21 09:58, Tobias Burnus wrote: On 20.09.21 06:01, Sandra Loosemore wrote: This patch fixes some bugs in handling of assumed-rank arguments revealed by the TS29113 testsuite, ... giving a bogus error when passing one as the first argument to the ASSOCIATED intrinsic. ... ... if I try the following testcase, which is now permitted, I get two ICEs. Can you check? * The first one seems to be a bug in gfc_conv_intrinsic_function, which assumes also for assumed rank that if the first argument is an array, the second argument must also be an array. * For the second one, I see in the dump: p->dim[p->dtype.rank + -1].stride is seems as '-1' is gfc_array_index_type while 'dtype.rank' is signed_char_type_node. I fixed that issue + extended the testcase. OK for mainline? Hi Tobias, looks good to me. Thanks for the patch! Best regards Thomas
Re: [PATCH] [i386] Remove storage only description for _Float16 w/o avx512fp16.
On 9/24/2021 8:39 PM, liuhongt via Gcc-patches wrote: [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580207.html gcc/ChangeLog: * doc/extend.texi (Half-Precision): Remove storage only description for _Float16 w/o avx512fp16. OK jeff
Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping cv-qualifier of function parameter of type of typename or decltype[PR101402,PR102033,PR102034,PR102039,PR102044]
Hi Jason,
Sorry for not noticing your response.
>>Unfortunately, your patch breaks
>>
>>template
>>struct A
>>{
>> void f(T);
>>};
>>template
>>void A::f(const T)
>>{ }
1. Perhaps I misunderstand your comment, but my patch does NOT fix this issue.
Neither does current GCC fix this code, if it is incorrect grammatically. In
other words, tested in www.godbolt.org and all major compilers accept it. And
my patch does NOT affects GCC current behavior, meaning my patched GCC still
accepts it like now. So, I don't think my patch breaks it because this code is
never fixed. (Whether this code is correct or not, I keep an open mind.)
>>which is certainly questionable code, but is currently also accepted by
>>clang and EDG compilers.
2. Like I said above, I am not even sure if it is an issue since most compilers
accept it. But my patch does NOT touch this issue at all. In essential, my
patch ONLY deals with dependent type starting with keyword "typename" or
"decltype". Just like my email subject, my patch only fixes one particular case
of this "family" of bugs, that is "typename" or "decltype" cases.
>>Why doesn't the PR92010 fix address these testcases as well?
3. PR92010 creates new functions of "rebuild_function_or_method_type" and by
using gdb to trace PR101402 code as following:
template struct A {
typedef T arr[3];
};
template void f(const typename A::arr) { }// #1
template void f(const A::arr); // #2
I added some print function declaration code before and after calling
"maybe_rebuild_function_decl_type" to print out its parameter "r" which is
function declaration inside "tsubst_function_decl".
Here is the result:
a) Before calling, the function declaration is "void f(int*)" and after
calling, it is adjusted to correct one as "void f(const int*)". However, after
this line "SET_DECL_IMPLICIT_INSTANTIATION (r);", it fallback to original
dependent type as "void f(typename A::arr) [with T = int; typename A::arr
= int [3]]" till end. This completely defeats the purpose of template
substitution effort.
b) On the other hand, by screening input parameter of
"rebuild_function_or_method_type", I can see it is using an incorrect function
type as "void(typename A::arr)" which already drops "const" prematurely.
This is due to previous #1 template function declaration parsing. So, This
gives us the clear idea of the root cause of this kind of bugs. It happens
during template function declaration stage #1 when producing template
declarator. Instead of doing a later-correction-effort in PR92010, my patch
tries to at least avoid dropping "const" in case of "typename" and "decltype"
during template function declaration stage in #1.
Best regards,
Qingzhe Huang
From: Jason Merrill
Sent: September 24, 2021 3:11 PM
To: nick huang ; gcc-patches@gcc.gnu.org
Subject: Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping
cv-qualifier of function parameter of type of typename or
decltype[PR101402,PR102033,PR102034,PR102039,PR102044]
I already responded to this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579527.html
Re: [PATCH] Replace VRP threader with a hybrid forward threader.
On Fri, 24 Sep 2021 17:46:53 +0200
Aldy Hernandez via Gcc-patches wrote:
> p.s. "Did I say 5 weeks? My bad, I meant 5 months."
heh. units (.oO~"xkcd.com/1047/")
> +static unsigned int
> +execute_vrp_threader (function *fun)
> +{
> + hybrid_threader threader;
> + threader.thread_jumps (fun);
> + threader.thread_through_all_blocks ();
> + return 0;
> +}
> +
> +namespace {
> +
> +const pass_data pass_data_vrp_threader =
> +{
> + GIMPLE_PASS, /* type */
> + "vrp-thread", /* name */
> + OPTGROUP_NONE, /* optinfo_flags */
> + TV_TREE_VRP, /* tv_id */
> + PROP_ssa, /* properties_required */
> + 0, /* properties_provided */
> + 0, /* properties_destroyed */
> + 0, /* todo_flags_start */
> + ( TODO_cleanup_cfg | TODO_update_ssa ), /* todo_flags_finish */
> +};
So shouldn't non-jumpy or flat code avoid the cleanup_cfg or
update_ssa iff neither the function nor anything else was threaded?
thanks,
[PATCH] Enable auto-vectorization at O2 with very-cheap cost model.
Hi:
> Please don't add the -fno- option to the warning tests. As I said,
> I would prefer to either suppress the vectorization for the failing
> cases by tweaking the test code or xfail them. That way future
> regressions won't be masked by the option. Once we've moved
> the warning to a more suitable pass we'll add a new test to verify
> it works as intended or remove the xfails.
Remove -fno-tree-vectorize from the warning tests, and add xfails to them.
The warning information is mainly affected by vectorization of 4 or 2 char
store. Some targets support both, some targets only support one of them,
and some targets supported neither, which means the warning information
would differ from targets to targets.
I only added xfail { x86_64-*-* i?86-*-* }, other backends may need to
re-adjust these xfail.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
gcc/ChangeLog:
* common.opt (ftree-vectorize): Add Var(flag_tree_vectorize).
* doc/invoke.texi (Options That Control Optimization): Update
documents.
* opts.c (default_options_table): Enable auto-vectorization at
O2 with very-cheap cost model.
(finish_options): Use cheap cost model for
explicit -ftree{,-loop}-vectorize.
gcc/testsuite/ChangeLog:
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase.
* g++.dg/tree-ssa/pr81408.C: Ditto.
* g++.dg/warn/Wuninitialized-13.C: Ditto.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
* gcc.dg/Wstringop-overflow-14.c: Ditto.
* gcc.dg/Wstringop-overflow-21.c: Ditto.
* gcc.dg/Wstringop-overflow-68.c: Ditto.
* gcc.dg/Wstringop-overflow-76.c: Ditto.
* gcc.dg/gomp/pr46032-2.c: Ditto.
* gcc.dg/gomp/pr46032-3.c: Ditto.
* gcc.dg/gomp/simd-2.c: Ditto.
* gcc.dg/gomp/simd-3.c: Ditto.
* gcc.dg/graphite/fuse-1.c: Ditto.
* gcc.dg/pr67089-6.c: Ditto.
* gcc.dg/pr82929-2.c: Ditto.
* gcc.dg/pr82929.c: Ditto.
* gcc.dg/store_merging_1.c: Ditto.
* gcc.dg/store_merging_11.c: Ditto.
* gcc.dg/store_merging_15.c: Ditto.
* gcc.dg/store_merging_16.c: Ditto.
* gcc.dg/store_merging_19.c: Ditto.
* gcc.dg/store_merging_24.c: Ditto.
* gcc.dg/store_merging_25.c: Ditto.
* gcc.dg/store_merging_28.c: Ditto.
* gcc.dg/store_merging_30.c: Ditto.
* gcc.dg/store_merging_5.c: Ditto.
* gcc.dg/store_merging_7.c: Ditto.
* gcc.dg/store_merging_8.c: Ditto.
* gcc.dg/strlenopt-85.c: Ditto.
* gcc.dg/tree-ssa/dump-6.c: Ditto.
* gcc.dg/tree-ssa/pr19210-1.c: Ditto.
* gcc.dg/tree-ssa/pr47059.c: Ditto.
* gcc.dg/tree-ssa/pr86017.c: Ditto.
* gcc.dg/tree-ssa/pr91482.c: Ditto.
* gcc.dg/tree-ssa/predcom-1.c: Ditto.
* gcc.dg/tree-ssa/predcom-dse-3.c: Ditto.
* gcc.dg/tree-ssa/prefetch-3.c: Ditto.
* gcc.dg/tree-ssa/prefetch-6.c: Ditto.
* gcc.dg/tree-ssa/prefetch-8.c: Ditto.
* gcc.dg/tree-ssa/prefetch-9.c: Ditto.
* gcc.dg/tree-ssa/ssa-dse-18.c: Ditto.
* gcc.dg/tree-ssa/ssa-dse-19.c: Ditto.
* gcc.dg/uninit-40.c: Ditto.
* gcc.dg/unroll-7.c: Ditto.
* gcc.misc-tests/help.exp: Ditto.
* gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c: Ditto.
* gcc.target/i386/pr34012.c: Ditto.
* gcc.target/i386/pr49781-1.c: Ditto.
* gcc.target/i386/pr95798-1.c: Ditto.
* gcc.target/i386/pr95798-2.c: Ditto.
* gfortran.dg/pr77498.f: Ditto.
---
gcc/common.opt| 2 +-
gcc/doc/invoke.texi | 8
gcc/opts.c| 17 +---
.../c-c++-common/Wstringop-overflow-2.c | 20 +--
gcc/testsuite/g++.dg/tree-ssa/pr81408.C | 2 +-
gcc/testsuite/g++.dg/warn/Wuninitialized-13.C | 2 +-
gcc/testsuite/gcc.dg/Warray-bounds-51.c | 2 +-
gcc/testsuite/gcc.dg/Warray-parameter-3.c | 4 ++--
gcc/testsuite/gcc.dg/Wstringop-overflow-14.c | 4 ++--
gcc/testsuite/gcc.dg/Wstringop-overflow-21.c | 8
gcc/testsuite/gcc.dg/Wstringop-overflow-68.c | 10 +-
gcc/testsuite/gcc.dg/Wstringop-overflow-76.c | 20 +--
gcc/testsuite/gcc.dg/gomp/pr46032-2.c | 2 +-
gcc/testsuite/gcc.dg/gomp/pr46032-3.c | 2 +-
gcc/testsuite/gcc.dg/gomp/simd-2.c| 2 +-
gcc/testsuite/gcc.dg/gomp/simd-3.c| 2 +-
gcc/testsuite/gcc.dg/graphite/fuse-1.c| 2 +-
gcc/testsuite/gcc.dg/pr67089-6.c | 2 +-
gcc/testsuite/gcc.dg/pr82929-2.c | 2 +-
gcc/testsuite/gcc.dg/pr82929.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_1.c| 2 +-
gcc/testsuite/gcc.dg/store_merging_11.c | 2 +-
gcc/testsuite/gcc.dg/store_merging_15.c | 2 +-
gcc/testsuite/gcc.dg/store_merging_16.c | 2 +-
