This patch propagates loop-closed PHIs them out at
loop_optimizer_finalize. For some cases, to clean up loop-closed PHIs
would save efforts of optimization passes after loopdone.
Thanks,
Jiufu Guo.
gcc/ChangeLog:
2020-10-18 Jiufu Guo <guojiufu@linux.ibm.com>
* cfgloop.h (loop_optimizer_finalize): Add flag argument.
* loop-init.c (loop_optimizer_finalize): Call clean_up_loop_closed_phi.
* tree-cfgcleanup.h (clean_up_loop_closed_phi): New declare.
* tree-ssa-loop.c (tree_ssa_loop_done): Call loop_optimizer_finalize
with flag argument.
* tree-ssa-propagate.c (clean_up_loop_closed_phi): New function.
gcc/testsuite/ChangeLog:
2020-10-18 Jiufu Guo <guojiufu@linux.ibm.com>
* gcc.dg/tree-ssa/loopclosedphi.c: New test.
As discussed in the PR, it's incredibly unlikely that a system that
needs to use the SYS_clock_gettime syscall (e.g. glibc 2.16 or older) is
going to define the SYS_clock_gettime64 macro. Ancient systems that need
to use the syscall aren't going to have time64 support.
This reverts the recent changes to try and make clock_gettime syscalls
be compatible with systems that have been updated for time64 (those
changes were wrong anyway as they misspelled the SYS_clock_gettime64
macro). The changes for futex syscalls are retained, because we still
use them on modern systems that might be using time64.
To ensure that the clock_gettime syscalls are safe, configure will fail
if SYS_clock_gettime is needed, and SYS_clock_gettime64 is also defined
(but to a distinct value from SYS_clock_gettime), and the tv_sec member
of timespec is larger than long. This means we will be unable to build
on a hypothetical system where we need the time32 version of
SYS_clock_gettime but where userspace is using a time64 struct timespec.
In the unlikely event that this failure is triggered on any real
systems, we can fix it later. But we probably won't need to.
libstdc++-v3/ChangeLog:
PR libstdc++/93421
* acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Fail if struct
timespec isn't compatible with SYS_clock_gettime.
* configure: Regenerate.
* src/c++11/chrono.cc: Revert changes for time64 compatibility.
Add static_assert instead.
* src/c++11/futex.cc (_M_futex_wait_until_steady): Assume
SYS_clock_gettime can use struct timespec.
gcc/
* config.gcc: add configure flags --with-{cpu,arch,tune}-{32,64}
as alias flags for --with-{cpu,arch,tune} on AArch64.
* doc/install.texi: Document new flags for aarch64.
fixes a configure error on Arm64 when passing --with-tune=... to configure:
```
This target does not support --with-tune.
Valid --with options are: abi cpu arch
```
The missing flag sets target tuning to a different value than generic tuning.
gcc/
* config.gcc: Add --with-tune to AArch64 configure flags.
This modules-related patch extends cache_integer_cst. Currently, when
given a small cst, that cst is added to the type's small and /must
not/ already be there. Large values are fine if they are already in
the large cache. This adds a parameter to indicate small duplicates
are ok, and it returns the cached value -- either what was already
tehre, or the newly inserted const.
gcc/
* tree.h (cache_integer_cst): Add defaulted might_duplicate parm.
* tree.c (cache_integer_cst): Return the integer cst, add
might_duplicate parm to permit finding a small duplicate.
We ICED with a duplicated block-scope extern, as duplicate_decls was
dropping the decl_lang_specific of olddecl. Simplys adding
appropriate retrofitting and copying turned out to be insufficient
because you can get a block-scope using decl also matching the extern.
The latter seems a little suspicious and I have asked CWG for advice.
While there robustified the assert about releasing olddecls'
lang-specific -- if it had one, the new decl better have one.
PR c++/97877
gcc/cp/
* decl.c (duplicate_decls): Deal with duplicated DECL_LOCAL_DECL_P
decls. Extend decl_lang_specific checking assert.
gcc/testsuite/
* g++.dg/lookup/pr97877.C: New.
This reorders the common and c++ global tree arrays. It introduces a
module-specific High Water Mark, below which are the immutable slots
initialized at startup and beyond which are the lazily filled slots
(and a few immutables we need to locate by name lookup anyway).
gcc/c-family/
* c-common.h (enum c_tree_index): Reorder to place lazy fields
after newly-added CTI_MODULE_HWM.
gcc/cp/
* cp-tree.h (enum cp_tree_index): Reorder to place lazy fields
after newly-added CPTI_MODULE_HWM.
Remove zero from IOR ranges with non-zero masks.
gcc/
PR tree-optimization/83072
* range-op.cc (wi_optimize_and_or): Remove zero from IOR range when
mask is non-zero.
gcc/testsuite/
* gcc.dg/pr83072.c: New.
It seems we accept __attribute__(()) without any diagnostic at present,
so my added checking assert fires for something like:
__attribute__ (()) int a;
Fixed by removing the assert; in the case that the user enters something
like:
__attribute__ (()) extern "C" int foo;
The diagnostic about attributes before linkage specs will fire and show
the empty attributes.
gcc/cp/ChangeLog:
PR c++/97871
* parser.c (cp_parser_declaration): Remove checking assert.
TS 18661-1 and 18661-2 have various definitions conditional on
__STDC_WANT_IEC_60559_BFP_EXT__ and __STDC_WANT_IEC_60559_DFP_EXT__
macros. When those TSes were integrated into C2x, most of the feature
test macro conditionals were removed (with declarations for decimal FP
becoming conditional only on whether decimal FP is supported by the
implementation and those for binary FP becoming unconditionally
required).
A few tests of those feature test macros remained for declarations
that appeared only in Annex F and not in the main part of the
standard. A change accepted for C2x at the last WG14 meeting (but not
yet added to the working draft in git) was to replace both those
macros by __STDC_WANT_IEC_60559_EXT__; if __STDC_WANT_IEC_60559_EXT__
is defined, the specific declarations in the headers will then depend
on which features are supported by the implementation, as for
declarations not controlled by a feature test macro at all.
Thus, add a check of __STDC_WANT_IEC_60559_EXT__ for CR_DECIMAL_DIG in
float.h, the only case of this change relevant to GCC.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* ginclude/float.h (CR_DECIMAL_DIG): Also define for
[__STDC_WANT_IEC_60559_EXT__].
gcc/testsuite/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* gcc.dg/cr-decimal-dig-3.c: New test.
C2x adds float.h macros that say whether float, double and long double
match an IEC 60559 (IEEE 754) format and operations. Add these
macros to GCC's float.h.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c-family/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* c-cppbuiltin.c (builtin_define_float_constants): Define
"*_IS_IEC_60559__" macros.
gcc/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* ginclude/float.h [__STDC_VERSION__ > 201710L] (FLT_IS_IEC_60559,
DBL_IS_IEC_60559, LDBL_IS_IEC_60559): New macros.
gcc/testsuite/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* gcc.dg/c11-float-6.c, gcc.dg/c2x-float-10.c: New tests.
PPC64 Linux ELFv1 uses function descriptors with the descriptor
placed in the .opd section. This patch expands the pattern in the testcase
to accept .opd section name associated with the function name.
gcc/testsuite/ChangeLog:
* gcc.dg/pr25376.c: Allow .opd section.
These two callbacks are needed for C++ modules. The first is for
handling macros from header-units. These are resolved lazily. The
second is for include-translation -- whether a #include gets turned
into a header-unit import.
libcpp/
* include/cpplib.h (struct cpp_callbacks): Add
user_deferred_macro & translate_include.
The <span> header is empty unless Concepts are supported, but <version>
defines the __cpp_lib_span feature test macro unconditionally. It should
be guarded by the same conditions as in <span>.
libstdc++-v3/ChangeLog:
PR libstdc++/97869
* include/precompiled/stdc++.h: Include <coroutine>.
* include/std/version (__cpp_lib_span): Check __cpp_lib_concepts
before defining.
This patch adds LC_MODULE as a map kind, used to indicate a c++
module. Unlike a regular source file, it only contains a single
location, and the source locations in that module are represented by
ordinary locations whose 'included_from' location is the module.
It also exposes some entry points that modules will use to create
blocks of line maps.
In the original posting, I'd missed the deletion of the
linemap_enter_macro from internal.h. That's included here.
libcpp/
* include/line-map.h (enum lc_reason): Add LC_MODULE.
(MAP_MODULE_P): New.
(line_map_new_raw): Declare.
(linemap_enter_macro): Move declaration from internal.h
(linemap_module_loc, linemap_module_reparent)
(linemap_module_restore): Declare.
(linemap_lookup_macro_indec): Declare.
* internal.h (linemap_enter_macro): Moved to line-map.h.
* line-map.c (linemap_new_raw): New, broken out of ...
(new_linemap): ... here. Call it.
(LAST_SOURCE_LINE_LOCATION): New.
(liemap_module_loc, linemap_module_reparent)
(linemap_module_restore): New.
(linemap_lookup_macro_index): New, broken out of ...
(linemap_macro_map_lookup): ... here. Call it.
(linemap_dump): Add module dump.
After discussion with Richard Sandiford on IRC, he suggested adding a
new mode class MODE_OPAQUE to deal with the problems (PR 96791) we had
been having with POImode/PXImode in powerpc target. This patch is the
accumulation of changes I needed to make to add this and make it useable
for the purposes of what power10 MMA needed.
MODE_OPAQUE modes allow you to have modes for which you can just
define loads and stores. By design, optimization does not expect to
know how to do arithmetic or subregs on these modes. This allows us to
have modes for multi-register vector operations where we don't want to
open Pandora's Box and define general arithmetic operations.
This patch will be followed by a target specific patch to change the
powerpc power10 MMA builtins to use opaque modes, and will also let use
use the vector pair loads/stores defined with that in the inline expansion
of memcpy/memmove, allowing me to fix PR 96791.
gcc/ChangeLog
PR target/96791
* mode-classes.def: Add MODE_OPAQUE.
* machmode.def: Add OPAQUE_MODE.
* tree.def: Add OPAQUE_TYPE for types that will use
MODE_OPAQUE.
* doc/generic.texi: Document OPAQUE_TYPE.
* doc/rtl.texi: Document MODE_OPAQUE.
* machmode.h: Add OPAQUE_MODE_P().
* genmodes.c (complete_mode): Add MODE_OPAQUE.
(opaque_mode): New function.
* tree.c (tree_code_size): Add OPAQUE_TYPE.
* tree.h: Add OPAQUE_TYPE_P().
* stor-layout.c (int_mode_for_mode): Treat MODE_OPAQUE modes
like BLKmode.
* ira.c (find_moveable_pseudos): Treat MODE_OPAQUE modes more
like integer/float modes here.
* dbxout.c (dbxout_type): Treat OPAQUE_TYPE like VOID_TYPE.
* tree-pretty-print.c (dump_generic_node): Treat OPAQUE_TYPE
like like other types.
My ranges transcription of the std::search_n implementation for random
access iterators missed a crucial part of the algorithm which the
existing tests didn't exercise. When __remainder is less than __count
at the start of an iteration of the outer while loop, it means we're
continuing a partial match of __count - __remainder elements from the
previous iteration. If at the end of the iteration we don't complete
this partial match, we need to reset __remainder so that it's only
offset by the size of the most recent partial match before starting the
next iteration.
This patch fixes this appropriately, mirroring how it's done in the
corresponding std::search_n implementation.
libstdc++-v3/ChangeLog:
PR libstdc++/97828
* include/bits/ranges_algo.h (__search_n_fn::operator()): Check
random_access_iterator before using the backtracking
implementation. When the backwards scan fails prematurely,
reset __remainder appropriately.
* testsuite/25_algorithms/search_n/97828.cc: New test.
As Jakub points out, we only ever pass a single variadic parm (if at
all), so just an optional arg is fine.
PR preprocessor/97858
libcpp/
* mkdeps.c (munge): Drop varadic args, we only ever use one.
this patch is based on Maritn's patch
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg02633.html
however based on new code that track and compare memory accesses
so it can be implemented correctly.
As shown here
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558773.html
the most common reason for function body being streamed in but merging to fail
is the mismatch in base alias set.
This patch collect base and ref types ao_alias_ptr types, stream them to WPA
and at WPA time hash is produced. Now we can use alias_sets since these these
are assumed to be same as ltrans time alias sets. This is currently not always
true - but that is pre-existing issue. I will try to produce a testcase and
make followup patch on this (that will stream out ODR types with TYPE_CANONICAL
that is !ODR as !ODR type). However for this patch this is not a problem since
the real alias sets are finer but definitly not coarser.
We may make it possible to use canonical type hash and save some streaming, but
I think it would be better to wait for next stage1 since it is not completely
trivial WRT ODR types: either we hash ODR type names and then hash values would
be too coarse for cases we got conflict betwen C and C++ type or we do not
stream and will again get into trouble with hash values being too weak. Tried
that - we get a lot of types that are struturally same but distinguished by
ODR names (from template instantiations).
As followup I will add code for merging with mismatched base alias sets. This
makes the aforementioned problem about ODR names less pronounced but it is
still present on pointer loads/stores which requires REF alias set mismatches.
2020-11-13 Jan Hubicka <hubicka@ucw.cz>
Martin Liska <mliska@suse.cz>
* ipa-icf.c: Include data-streamer.h and alias.h.
(sem_function::sem_function): Initialize memory_access_types
and m_alias_sets_hash.
(sem_function::hash_stmt): For memory accesses and when going to
do lto streaming add base and ref types into memory_access_types.
(sem_item_optimizer::write_summary): Stream memory access types.
(sem_item_optimizer::read_section): Likewise and also iniitalize
m_alias_sets_hash.
(sem_item_optimizer::execute): Call
sem_item_optimizer::update_hash_by_memory_access_type.
(sem_item_optimizer::update_hash_by_memory_access_type): Updat.
* ipa-icf.h (sem_function): Add memory_access_types and
m_alias_sets_hash.
This patch fixes profiledbootstrap failure with LTO enabled.
Not refining alias sets from WPA to ltrans time is a good invariant to
maintain and the canonical type hash behaves this way. However I broke
this with the ODR logic.
Normally we define canonical types for C++ ODR types according to their
type names. However to make ODR types compatible with C types we check
if structurally equivalent C type exists and if so, we ignore ODR
names giving up on the precision.
This however is not stable between WPA and ltrans since at ltrans the
type merging does not see as many types as WPA does. To make this
consistent the patch makes WPA ODR_TYPE_P == 0 for ODR types that
conflicted with non-ODR type.
I had to drop one sanity check in ipa-utils.h (that I think is not very
important - I added it while introducing CXX_ODR_P machinery) and also
it now may happen that we query odr_based_tbaa_p before registering
first ODR type so we do not want to ICE here.
ODR type registration happens early to produce ODR violation warings.
Those are not done at ltrans, so dropping the registration is safe. The
type will still be added while computing the type inheritance graph if
needed for devirtualization (and late devirtualization is not very
useful anyway since it won't enable inlining).
gcc/ChangeLog:
PR bootstrap/97857
* ipa-devirt.c (odr_based_tbaa_p): Do not ICE when
odr_hash is not initialized
* ipa-utils.h (type_with_linkage_p): Do not sanity check
CXX_ODR_P.
* tree-streamer-out.c (pack_ts_type_common_value_fields): Set
CXX_ODR_P according to the canonical type.
gcc/lto/ChangeLog:
PR bootstrap/97857
* lto-common.c (gimple_register_canonical_type_1): Only
register types with TYPE_CXX_ODR_P flag; sanity check that no
conflict happens at ltrans time.
This is a slightly modified version of 01-langhooks.def. I realized I
didn't need the deferred macro langhook -- that can be directly
installed into the preprocessor callbacks via preprocess_options lang
hook.
gcc/
* langhooks-def.h (LANG_HOOKS_PREPROCESS_MAIN_FILE)
(LANG_HOOKS_PREPROCESS_OPTIONS, LANG_HOOKS_PREPROCESS_UNDEF)
(LANG_HOOKS_PREPROCESS_TOKEN): New.
(LANG_HOOKS_INITIALIZER): Add them.
* langhooks.h (struct lang_hooks): Add preprocess_main_file,
preprocess_options, preprocess_undef, preprocess_token hooks. Add
enum PT_flags.
gcc/c-family/
* c-lex.c: #include "langhooks.h".
(cb_undef): Maybe call preprocess_undef lang hook.
* c-opts.c (c_common_post_options): Maybe call preprocess_options
lang hook.
(push_command_line_include): Maybe call preprocess_main_file lang
hook.
(cb_file_change): Likewise.
* c-ppoutput.c: #include "langhooks.h.
(scan_translation_unit): Maybe call preprocess_token lang hook.
(class do_streamer): New, derive from token_streamer.
(directives_only_cb): Data pointer is do_streamer, call
preprocess_token lang hook.
(scan_translation_unit_directives_only): Use do_streamer.
(print_line_1): Move src_line recording to after string output.
(cb_undef): Maybe call preprocess_undef lang hook.
This is broken out of modules patch 01-langhooks.diff, I realized that
this part is independent, and removes some duplicated code -- migrated
to the token_streamer class.
gcc/c-family/
* c-ppoutput.c (scan_translation_unit): Use token_streamer, remove
code duplicating that functionality.
Add a testcase for PR target/31799 which was fixed by
commit 4f0473fe89
Author: Uros Bizjak <ubizjak@gmail.com>
Date: Fri May 12 21:04:05 2017 +0200
compare-elim.c (try_eliminate_compare): Canonicalize operation with embedded compare to [(set (reg:CCM) (compare:CCM...
* compare-elim.c (try_eliminate_compare): Canonicalize
operation with embedded compare to
[(set (reg:CCM) (compare:CCM (operation) (immediate)))
(set (reg) (operation)].
* config/i386/i386.c (TARGET_FLAGS_REGNUM): New define.
in GCC 8.
PR target/31799
* gcc.target/i386/pr31799.c: New test.
These tests started passing a while ago, so remove the XFAILs.
gcc/testsuite/
* gcc.target/aarch64/sve/cond_cnot_1.c: Remove XFAIL.
* gcc.target/aarch64/sve/cond_unary_1.c: Likewise.
The vectorizable_call part of r11-1143 dropped the required
vectype when moving from vect_get_vec_def_for_operand to
vect_get_vec_defs_for_operand. This caused an ICE on the
testcase for SVE, because we ended up with a non-predicate
value being passed to a predicate input.
AFAICT this was the only instance of that happening. The types
seemed to get carried forward for all the other converted calls.
gcc/
PR tree-optimization/97693
* tree-vect-stmts.c (vectorizable_call): Pass the required vectype
to vect_get_vec_defs_for_operand.
gcc/testsuite/
PR tree-optimization/97693
* gcc.dg/vect/pr97693.c: New test.
We still fall back to load/store-lanes for slp-46.c, if the target
supports it.
gcc/testsuite/
* gcc.dg/vect/slp-46.c: XFAIL test for SLP on vect_load_lanes targets.
We don't try to increase the alignment of decls if
vect_element_align_preferred.
gcc/testsuite/
* gcc.dg/vect/aligned-section-anchors-nest-1.c: XFAIL alignment
test if vect_element_align_preferred.
Because we disable the cost model, targets with variable-length
vectors can end up vectorising the store to a[0..7] on its own.
With the cost model we do something sensible.
gcc/testsuite/
* gcc.dg/vect/bb-slp-subgroups-3.c: XFAIL for variable-length vectors.
We don't yet support SLP inductions for variable-length vectors,
so this patch XFAILs some associated tests.
(Inductions aren't inherently difficult to support. It just hasn't
been done yet.)
gcc/testsuite/
* gcc.dg/vect/pr97678.c: XFAIL test for SLP vectorization
for variable-length vectors.
* gcc.dg/vect/pr97835.c: Likewise.
* gcc.dg/vect/slp-49.c: Likewise.
* gcc.dg/vect/vect-outer-slp-1.c: Likewise.
* gcc.dg/vect/vect-outer-slp-2.c: Likewise.
* gcc.dg/vect/vect-outer-slp-3.c: Likewise.
For variable-length SVE, we can only use SLP for N scalars of type
T if the number of Ts in a vector is a multiple of N. For ints
this means that N must be 4 or 2, so this patch XFAILs two tests
for N==8.
The exact limit seems inherently target-specific -- variable-length
vectors with a 256-bit granule would work fine -- so I used aarch64_sve
selectors on the XFAILs.
gcc/testsuite/
* gcc.dg/vect/slp-reduc-4.c: XFAIL test for SLP vectorization
for variable-length SVE.
* gcc.dg/vect/slp-reduc-7.c: Likewise.
The XFAIL for variable-length vectors is no longer needed since
we can't build the required constant vector and so fall back to
fixed-length alternatives.
gcc/testsuite/
* gcc.dg/vect/bb-slp-43.c: Remove XFAIL for vect_variable_length.
For variable-length vectors, the N inside “vector(N) T” can
contain the characters ‘[’, ‘]’ and ‘,’.
gcc/testsuite/
* gcc.dg/vect/pr91750.c: Allow "[]," inside a vector(...) lane count.
Previous code abused `FMT_LEN_L` for the `I` modifier. As `L` is a
valid modifier for `f`, `e`, `g`, etc. and `I` has the same semantics
as the C99 `z` modifier, `FMT_LEN_z` is now used instead.
First, in the Microsoft ABI, type `long double` has the same layout as
type `double`, so `%Lg` behaves identically to `%g`. Users should pass
in `double`s instead of `long double`s, as GCC uses the 10-byte format.
Second, with a CRT that is recent enough (MSVCRT since Vista, MSVCR80,
UCRT, or mingw-w64 8.0), `printf`-family functions can handle the `ll`
length modifier correctly. This ability is assumed to be available
universally. A lot of libraries (such as libgomp) that use the
`format(printf, ...)` attribute used to suffer from warnings about
unknown format specifiers.
Reference: https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/tcxf1dw6(v=vs.90)
Reference: https://docs.microsoft.com/en-us/cpp/porting/visual-cpp-what-s-new-2003-through-2015#new-crt-features
Signed-off-by: Liu Hao <lh_mouse@126.com>
gcc/ChangeLog:
* config/i386/msformat-c.c: Add more length modifiers.
gcc/testsuite/ChangeLog:
* gcc.dg/format/ms_c99-printf-3.c: Update tests.
This patch fixes an issue where on systems that are
HAVE_TARGET_EXECUTABLE_SUFFIX the driver calls convert_filename in order to
add the suffix to the filename. However while it excludes `-` it doesn't
exclude the null device. This patches changes the check to exclude anything
that is not a file by calling not_actual_file_p instead.
This also fixes a bug in not_actual_file_p which was accidentally testing
a the global variable output_file instead of the supplied argument. This
hasn't been an issue so far because because not_actual_file_p was only used
on output_file till now.
This fixes the adding of an extension to the nul device which is against
the recommendations on msdn[0] and makes it harder for the next tool in line
to detect it.
Bootstrapped Regtested on x86_64-w64-mingw32 and no issues.
Did do a bootstrap on x86_64-pc-linux-gnu but no regtest as it's not a
HAVE_TARGET_EXECUTABLE_SUFFIX system.
[0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
gcc/ChangeLog:
PR driver/97574
* gcc.c (convert_filename): Don't add suffix to things that are
not files.
(not_actual_file_p): Use supplied argument.
During the __builtin_clear_padding implementation, I've noticed we don't
diagnose _Atomic whatever * as last argument to __builtin_*_overflow.
As the storing by that builtin isn't atomic in any way, I think we should
reject it.
2020-11-17 Jakub Jelinek <jakub@redhat.com>
PR c/90628
* c-common.c (check_builtin_function_arguments)
<case BUILT_IN_ADD_OVERFLOW>: Diagnose when last argument is pointer
to _Atomic. For the TYPE_READONLY case, adjust message to be usable
for more builtins and argument positions.
* gcc.dg/builtin-arith-overflow-4.c: New test.
The test has been added 3 years before noipa attribute has been introduced,
but already at that point I wanted to avoid IPA opts getting into way,
most of the foo function is optimized away and the debug info just points
to the caller\s var. With the recent modref/aliasing changes the caller's
store to the variable whose address it is passing to the function is
optimized away too.
I think we should just use noipa to avoid this, though perhaps longer term
we should think about some debug info improvements how to deal with that.
The caller had before dse1:
# DEBUG BEGIN_STMT
x.f = 5.0e+0;
x.g = 6.0e+0;
# DEBUG BEGIN_STMT
foo (&x);
# DEBUG BEGIN_STMT
x ={v} {CLOBBER};
and the x.f and x.g stores are optimized away. If we had a way to pretend
the memory contains those values anyway...
Tested on x86_64-linux, fixes the guality regressions
+FAIL: gcc.dg/guality/pr59776.c -O1 -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O1 -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O1 -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O1 -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O1 -DPREVENT_OPTIMIZATION line pr59776.c:20 s2.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -DPREVENT_OPTIMIZATION line pr59776.c:20 s2.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line pr59776.c:20 s2.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line pr59776.c:20 s2.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O3 -g -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O3 -g -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O3 -g -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -O3 -g -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -O3 -g -DPREVENT_OPTIMIZATION line pr59776.c:20 s2.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -Os -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -Os -DPREVENT_OPTIMIZATION line pr59776.c:17 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -Os -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.f == 5.0
+FAIL: gcc.dg/guality/pr59776.c -Os -DPREVENT_OPTIMIZATION line pr59776.c:20 s1.g == 6.0
+FAIL: gcc.dg/guality/pr59776.c -Os -DPREVENT_OPTIMIZATION line pr59776.c:20 s2.f == 5.0
introduced in the last 2 days.
2020-11-17 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/guality/pr59776.c (foo): Use noipa attribute instead of
noinline, noclone.
This patch puts absolute jump tables into a relocatable read-only section
if they are on ELF target and relocation is supported.
gcc/ChangeLog:
* final.c (final_scan_insn_1): Set jump table relocatable as the
second argument of targetm.asm_out.function_rodata_section.
* output.h (default_function_rodata_section,
default_no_function_rodata_section): Add the second argument to the
declarations.
* target.def (function_rodata_section): Change the doc and add
the second argument.
* doc/tm.texi: Regenerate.
* varasm.c (jumptable_relocatable): Implement.
(default_function_rodata_section): Add the second argument
and the support for relocatable read only sections.
(default_no_function_rodata_section): Add the second argument.
(function_mergeable_rodata_prefix): Set the second argument to false.
* config/mips/mips.c (mips_function_rodata_section): Add the second
arugment and set it to false.
* config/s390/s390.c (targetm.asm_out.function_rodata_section): Set
the second argument to false.
* config/s390/s390.md: Likewise.
gcc/ChangeLog:
PR target/97194
* config/i386/i386-expand.c (ix86_expand_vector_set_var): New function.
* config/i386/i386-protos.h (ix86_expand_vector_set_var): New Decl.
* config/i386/predicates.md (vec_setm_operand): New predicate,
true for const_int_operand or register_operand under TARGET_AVX2.
* config/i386/sse.md (vec_set<mode>): Support both constant
and variable index vec_set.
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx2-vec-set-1.c: New test.
* gcc.target/i386/avx2-vec-set-2.c: New test.
* gcc.target/i386/avx512bw-vec-set-1.c: New test.
* gcc.target/i386/avx512bw-vec-set-2.c: New test.
* gcc.target/i386/avx512f-vec-set-2.c: New test.
* gcc.target/i386/avx512vl-vec-set-2.c: New test.
C2x adds macros for decimal floating-point signaling NaNs to
<float.h>. Add these macros to GCC's <float.h> implementation.
Note that the current C2x draft has these under incorrect names
D32_SNAN, D64_SNAN, D128_SNAN. The intent was to change the naming
convention to be consistent with other <float.h> macros when they were
moved to <float.h>, so DEC32_SNAN, DEC64_SNAN, DEC128_NAN, which this
patch uses (as does the current draft integration of TS 18661-3 as an
Annex to C2x, for its _Decimal* and _Decimal*x types).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* ginclude/float.h (DEC32_SNAN, DEC64_SNAN, DEC128_SNAN): New C2x
macros.
gcc/testsuite/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* gcc.dg/dfp/c2x-float-dfp-7.c, gcc.dg/dfp/c2x-float-dfp-8.c: New
tests.
* gcc.dg/c2x-float-no-dfp-3.c: Also check that DEC32_SNAN,
DEC64_SNAN and DEC128_SNAN are not defined.
C2x adds macros for NaNs and infinities to <float.h>, some of them
previously in <math.h> (and some still in <math.h> as well in C2x as
an obsolescent feature). Add these macros to GCC's <float.h>
implementation.
This omits the macros for DFP signaling NaNs, leaving those to be
added in a separate patch. However, it includes the _FloatN /
_FloatNx macros (conditional on __STDC_WANT_IEC_60559_TYPES_EXT__) in
the current draft version of the integration of TS 18661-3 into C2x as
an Annex.
As GCC allows duplicate macro definitions with different expansions in
system headers, it should be OK if <math.h> defines INFINITY or NAN
with a slightly different expansion (e.g. different choice of whether
there is whitespace between tokens); tests are added including
<float.h> and <math.h> in either order. Because <float.h> uses #undef
on all macros before defining them, even with -Wsystem-headers there
could only ever be issues when <math.h> is included after <float.h>.
Bootstrapped with no regressions on x86_64-pc-linux-gnu.
gcc/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* ginclude/float.h (INFINITY, NAN, FLT_SNAN, DBL_SNAN, LDBL_SNAN)
(FLT16_SNAN, FLT32_SNAN, FLT64_SNAN, FLT128_SNAN, FLT32X_SNAN)
(FLT64X_SNAN, FLT128X_SNAN, DEC_INFINITY, DEC_NAN): New C2x
macros.
* doc/sourcebuild.texi (Effective-Target Keywords): Document inff.
gcc/testsuite/
2020-11-17 Joseph Myers <joseph@codesourcery.com>
* lib/target-supports.exp (check_effective_target_inff): New.
* gcc.dg/c11-float-4.c, gcc.dg/c11-float-5.c,
gcc.dg/c11-float-dfp-2.c, gcc.dg/c2x-float-2.c,
gcc.dg/c2x-float-3.c, gcc.dg/c2x-float-4.c, gcc.dg/c2x-float-5.c,
gcc.dg/c2x-float-6.c, gcc.dg/c2x-float-7.c, gcc.dg/c2x-float-8.c,
gcc.dg/c2x-float-9.c, gcc.dg/c2x-float-no-dfp-3.c,
gcc.dg/c2x-float-no-dfp-4.c, gcc.dg/dfp/c2x-float-dfp-4.c,
gcc.dg/dfp/c2x-float-dfp-5.c, gcc.dg/dfp/c2x-float-dfp-6.c,
gcc.dg/torture/float128-nan-floath.c,
gcc.dg/torture/float128x-nan-floath.c,
gcc.dg/torture/float16-nan-floath.c,
gcc.dg/torture/float32-nan-floath.c,
gcc.dg/torture/float32x-nan-floath.c,
gcc.dg/torture/float64-nan-floath.c,
gcc.dg/torture/float64x-nan-floath.c,
gcc.dg/torture/floatn-nan-floath.h: New tests.
