Jonathan Wakely [Thu, 10 Sep 2020 17:48:25 +0000 (18:48 +0100)]
libstdc++: Fix -Wdeprecated-declarations warnings
libstdc++-v3/ChangeLog:
* include/experimental/bits/shared_ptr.h (shared_ptr(auto_ptr&&))
(operator=(auto_ptr&&)): Add diagnostic pragmas to suppress
warnings for uses of std::auto_ptr.
* include/experimental/type_traits (is_literal_type_v):
Likewise, for use of std::is_literal_type.
* include/std/condition_variable (condition_variable_any::_Unlock):
Likewise, for use of std::uncaught_exception.
Jonathan Wakely [Tue, 11 Aug 2020 15:16:21 +0000 (16:16 +0100)]
libstdc++: Fix net::system_context stop condition
libstdc++-v3/ChangeLog:
* include/experimental/executor (system_context::_M_run()):
Fix predicate.
(system_context::join()): Do not join unless joinable.
* testsuite/experimental/net/system_context/1.cc: New test.
Alex Coplan [Mon, 22 Mar 2021 14:43:15 +0000 (14:43 +0000)]
arm: Fix MVE ICEs with vector moves and -mpure-code [PR97252]
This fixes around 500 ICEs in the testsuite which can be seen when
testing with -march=armv8.1-m.main+mve -mfloat-abi=hard -mpure-code
(leaving the testsuite free of ICEs in this configuration). All of the
ICEs are in arm_print_operand (which is expecting a mem and gets another
rtx, e.g. a const_vector) when running the output code for
*mve_mov<mode> in alternative 4.
The issue is that MVE vector moves were relying on the arm_reorg pass to
move constant vectors that we can't easily synthesize to the literal
pool. This doesn't work for -mpure-code where the literal pool is
disabled. LLVM puts these in .rodata: I've chosen to do the same here.
With this change, for -mpure-code, we no longer want to allow a constant
on the RHS of a vector load in RA. To achieve this, I added a new
constraint which matches constants only if the literal pool is
available.
gcc/ChangeLog:
PR target/97252
* config/arm/arm-protos.h (neon_make_constant): Add generate
argument to guard emitting insns, default to true.
* config/arm/arm.c (arm_legitimate_constant_p_1): Reject
CONST_VECTORs which neon_make_constant can't handle.
(neon_vdup_constant): Add generate argument, avoid emitting
insns if it's not set.
(neon_make_constant): Plumb new generate argument through.
* config/arm/constraints.md (Ui): New. Use it...
* config/arm/mve.md (*mve_mov<mode>): ... here.
* config/arm/vec-common.md (movv8hf): Use neon_make_constant to
synthesize constants.
Marek Polacek [Wed, 10 Mar 2021 00:23:48 +0000 (19:23 -0500)]
c++: Fix bogus warning in deprecated namespace [PR99318]
In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can
handle attribute deprecated on a namespace declaration. This
function walks the decl's contexts so that we warn for code like
namespace [[deprecated]] N { struct S { }; }
N::S s;
We call cp_warn_deprecated_use_scopes when we encounter a TYPE_DECL.
But in the following testcase we have a TYPE_DECL whose context is
a deprecated function; that itself is not a reason to warn. This
patch limits for which entities we call cp_warn_deprecated_use;
essentially it's what can follow ::.
I noticed that we didn't test that
struct [[deprecated]] S { static void fn(); };
S::fn();
produces the expected warning, so I've added gen-attrs-73.C.
gcc/cp/ChangeLog:
PR c++/99318
* decl2.c (cp_warn_deprecated_use_scopes): Only call
cp_warn_deprecated_use when decl is a namespace, class, or enum.
gcc/testsuite/ChangeLog:
PR c++/99318
* g++.dg/cpp0x/attributes-namespace6.C: New test.
* g++.dg/cpp0x/gen-attrs-73.C: New test.
Marek Polacek [Wed, 10 Feb 2021 20:24:25 +0000 (15:24 -0500)]
c-family: ICE with assume_aligned attribute [PR99062]
We ICE in handle_assume_aligned_attribute since r271338 which added
@@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name, tree args, int,
/* The misalignment specified by the second argument
must be non-negative and less than the alignment. */
warning (OPT_Wattributes,
- "%qE attribute argument %E is not in the range [0, %E)",
- name, val, align);
+ "%qE attribute argument %E is not in the range [0, %wu]",
+ name, val, tree_to_uhwi (align) - 1);
*no_add_attrs = true;
return NULL_TREE;
}
because align is INT_MIN and tree_to_uhwi asserts tree_fits_uhwi_p -- which
ALIGN does not and the prior tree_fits_shwi_p check is fine with it, as
well as the integer_pow2p check.
Since neither of the arguments to assume_aligned can be negative, I've
hoisted the tree_int_cst_sgn check. And add the missing "argument"
word to an existing warning.
gcc/c-family/ChangeLog:
PR c++/99062
* c-attribs.c (handle_assume_aligned_attribute): Check that the
alignment argument is non-negative. Tweak a warning message.
gcc/testsuite/ChangeLog:
PR c++/99062
* gcc.dg/attr-assume_aligned-4.c: Adjust dg-warning.
* g++.dg/ext/attr-assume-aligned.C: New test.
David Edelsohn [Sun, 28 Mar 2021 17:11:50 +0000 (13:11 -0400)]
aix: TLS DWARF symbol decorations.
GCC currently emits TLS relocation decorations on symbols in DWARF sections.
Recent changes to the AIX linker cause it to reject such symbols.
This patch removes the decorations (@ie, @le, @m) and emit only the
qualified symbol name.
gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_output_dwarf_dtprel): Do not add
XCOFF TLS reloc decorations.
Iain Buclaw [Sat, 13 Mar 2021 16:05:52 +0000 (17:05 +0100)]
Fix ICE: in function_and_variable_visibility, at ipa-visibility.c:795 [PR99466]
In get_emutls_init_templ_addr, only thread-local declarations that were
DECL_ONE_ONLY would have a public initializer symbol, ignoring variables
that were declared with __attribute__((weak)).
gcc/ChangeLog:
PR ipa/99466
* tree-emutls.c (get_emutls_init_templ_addr): Mark initializer of weak
TLS declarations as public.
gcc/testsuite/ChangeLog:
PR ipa/99466
* gcc.dg/tls/pr99466-1.c: New test.
* gcc.dg/tls/pr99466-2.c: New test.
tree-optimization/96974 - avoid ICE by replacing assert with standard failure
Minor patch to add a graceful exit in the rare case where an invalid
combination of TYPE_VECTOR_SUBPARTS for nunits_vectype and
*stmt_vectype_out is reached in vect_get_vector_types_for_stmt.
This resolves the ICE seen in PR tree-optimization/96974, however the issue
of correctly handling this rare vectorization combination is left for a
later patch.
Thomas Schwinge [Thu, 25 Jun 2020 09:59:42 +0000 (11:59 +0200)]
libgomp HSA/GCN plugins: don't prepend the 'HSA_RUNTIME_LIB' path to 'libhsa-runtime64.so'
For unknown reasons, this had gotten added for the libgomp HSA plugin in commit b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove build dependence on
HSA run-time", and later propagated into the GCN plugin.
Xionghu Luo [Thu, 25 Mar 2021 04:45:58 +0000 (23:45 -0500)]
rs6000: Correct Power8 cost of l2 cache size [PR97329]
This patch is a backport to gcc 10 from master.
L2 cache size for Power8 is 512kB, it was copied from Power7 before
public. Tested no performance change for SPEC2017.
gcc/
2021-03-25 Xionghu Luo <luoxhu@linux.ibm.com>
PR target/97329
* config/rs6000/rs6000.c (power8_costs): Change l2 cache
from 256 to 512.
Iain Sandoe [Wed, 17 Mar 2021 13:05:47 +0000 (13:05 +0000)]
testsuite, Darwin : Fix the asan/strncpy-overflow-1 test.
1. To be more compatible with Linux, Darwin testcases that include
string.h should set _FORTIFY_SOURCE=0 since, otherwise, it will be
defaulted on and the _chk versions of the string builtins will be
used. This testcase fails otherwise because there's no convenient
way to disable the _chk builtins.
2. The system tool that handles symbolization (atos) is not reliable
with GCC's DWARF-2 output but, fortunately, all the platform
versions that support the current sanitizers are able to handle
dwarf-3 for this testcase.
gcc/testsuite/ChangeLog:
PR sanitizer/96318
* c-c++-common/asan/strncpy-overflow-1.c: Add _FORTIFY_SOURCE=0 and
-gdwarf-3 to the command line options. Adjust the expected line
numbers for the revised options header.
Iain Sandoe [Wed, 17 Mar 2021 12:56:49 +0000 (12:56 +0000)]
testsuite, Darwin : Fix match output for asan/memcmp-1.c.
The Darwin part of libasan produces different output for memcmp
cases from other ports. The GCC implementation does produce the
same output for this test as the clang one (modulo the two points
below).
1. To be more compatible with Linux, Darwin testcases that include
string.h should set _FORTIFY_SOURCE=0 since, otherwise, it will be
defaulted on and the _chk versions of the string builtins will be
used.
2. The system tool that handles symbolization (atos) is not reliable
with GCC's DWARF-2 output but, fortunately, all the platform
versions that support the current sanitizers are able to handle
dwarf-3 for this testcase.
gcc/testsuite/ChangeLog:
* c-c++-common/asan/memcmp-1.c: Add _FORTIFY_SOURCE=0 and
-gdwarf-3 to the command line options. Provide Darwin-
specific match lines for the expected output.
Where three of the message params have no selector name.
If fact, although it might be unintentional, Objective-C/C++ can
accept message selectors with all the parms unnamed (this applies
to the clang implementation too, which is taken as the reference
for the language).
For regular C++, the pattern x:x is not valid in that position an
an error is emitted with a fixit for the expected scope token.
If we simply made that error conditional on !c_dialect_objc()
that would regress Objective-C++ diagnostics for cases outside a
message selector, so we add a state flag for this.
gcc/cp/ChangeLog:
PR objc++/49070
* parser.c (cp_debug_parser): Add Objective-C++ message
state flag.
(cp_parser_nested_name_specifier_opt): Allow colon to
terminate an assignment-expression when parsing Objective-
C++ messages.
(cp_parser_objc_message_expression): Set and clear message
parsing state on entry and exit.
* parser.h (struct cp_parser): Add a context flag for
Objective-C++ message state.
gcc/testsuite/ChangeLog:
PR objc++/49070
* obj-c++.dg/pr49070.mm: New test.
* objc.dg/unnamed-parms.m: New test.
* obj-c++.dg/gnu-api-2-class-meta.mm: Add a flag to cause NeXT
headers to expose prototypes for messaging.
* obj-c++.dg/gnu-api-2-class.mm: Likewise.
* obj-c++.dg/gnu-api-2-objc.mm: Skip this because of the extra
protocols pulled in by system headers.
* obj-c++.dg/cxx-ivars-3.mm: Skip for macOS >= 10.7.
* obj-c++.dg/objc-gc-3.mm:i Skip for Darwin >= 16.
* objc-obj-c++-shared/TestsuiteObject.h: Add dummy retain and
release method declarations.
* objc-obj-c++-shared/TestsuiteObject.m: Add dummy retain and
release implementations.
* obj-c++.dg/plugin/diagnostic-test-expressions-1.mm:
Adjust testcase to include expressions for @selector and
@protocol. XFAIL where this is still not sufficient to obtain
a disgnostic range.
* objc.dg/objc-gc-4.m: Disable for macOS 10.15 and 11.x.
* objc.dg/gnu-api-2-class-meta.m: Add a flag to cause NeXT
headers to expose prototypes for messaging. Mark the root
class if the objc_root_class attribute is available. Use
char ** as the second arg to main.
* objc.dg/gnu-api-2-class.m: Use dispatch prototype.
* objc.dg/gnu-api-2-objc.m: Skip on NeXT because of extra
prototypes pulled in by headers.
* objc.dg/ivar-scope-4.m: Add inititialize method to the
root class.
* objc.dg/torture/forward-1.m: Implement forwarding using the
native NeXT (NSInvocation) method for Darwin.
* objc.dg/call-super-2.m: Remove inclusion of runtime.h.
Add a FIXME about the test portability.
* objc.dg/plugin/diagnostic-test-expressions-1.m: Use assignment
expressions for @selector and @protocol to obtain a useful
diagnostic range.
* objc.dg/pr23214.m: Use Object as the root object before
Darwin12 (and NSObject after).
Iain Sandoe [Sat, 3 Oct 2020 23:03:54 +0000 (00:03 +0100)]
testsuite, Objective-C : Compatibility fixes.
Changes to deal with warnings and/or errors seen when compiling the
tests with clang.
gcc/testsuite/ChangeLog:
* objc-obj-c++-shared/TestsuiteObject.h: If the compiler
supports objc_root_object attributes, then mark the testsuite
object accordingly.
* objc-obj-c++-shared/TestsuiteObject.m: Avoid direct access
to isa, which is an error for modern Objective-C.
* objc/execute/class-tests-1.h: Declare a string function we
use locally (avoid pulling in the whole of string.h).
Iain Sandoe [Fri, 30 Oct 2020 19:24:07 +0000 (19:24 +0000)]
Objective-C/C++ : Fix rejects valid fails for properties.
This amends the property handling to fix missing cases and improve
diagnostics.
1. Address a FIXME.
We can avoid the spurious additional complaint about a closing
')' by short-circuiting the test in the case we know there's a
syntax error already reported.
2. Improve '@' keyword locations.
When we are lexing tokens for Objective-C, we combine '@' tokens
with a following keyword (when that keyword is a valid Objective-C
one or, for Objective-C, one of the C++ keywords that can appear in
this position). The responsibility is passed on to the parser to
validate the resulting combination.
The combination of tokens was being done without applying the rule
to their locations - so that we get:
@property
^
instead of what the user might expect:
@property
^~~~~~~~~
This patch combines the source range of the keyword with that of the
'@' sign - which improves diagnostics.
3. Update @property attribute parsing
At present, we are missing parsing and checking for around
half of the property attributes in use. The existing ad hoc scheme
for the parser's communication with the Objective C validation
is not suitable for extending to cover all the missing cases.
We are not adding the new cases in the backport, but covering the
missing 'atomic' one.
4. Add missing 'atomic' property attribute.
This is the default, but it is still legal in user code and therefore
we should handle it in parsing. Fix whitespace issues in the lines
affected.
* parser.c (cp_parser_objc_at_property_declaration): Use any
exisiting syntax error to suppress complaints about a missing
closing parenthesis in parsing property attributes.
gcc/testsuite/ChangeLog:
* obj-c++.dg/property/at-property-1.mm: Adjust test after
fixing spurious error output.
gcc/c-family/ChangeLog:
* c-lex.c (c_lex_with_flags): When combining '@' with a
keyword for Objective-C, combine the location ranges too.
gcc/c-family/ChangeLog:
* c-objc.h (enum objc_property_attribute_group): New
(enum objc_property_attribute_kind): New.
(OBJC_PROPATTR_GROUP_MASK): New.
(struct property_attribute_info): Small class encapsulating
parser output from property attributes.
(objc_prop_attr_kind_for_rid): New
(objc_add_property_declaration): Simplify interface.
* stub-objc.c (enum rid): Dummy type.
(objc_add_property_declaration): Simplify interface.
(objc_prop_attr_kind_for_rid): New.
gcc/c/ChangeLog:
* c-parser.c (c_parser_objc_at_property_declaration):
Improve parsing fidelity. Associate better location info
with @property attributes. Clean up the interface to
objc_add_property_declaration ().
gcc/cp/ChangeLog:
* parser.c (cp_parser_objc_at_property_declaration):
Improve parsing fidelity. Associate better location info
with @property attributes. Clean up the interface to
objc_add_property_declaration ().
gcc/objc/ChangeLog:
* objc-act.c (objc_prop_attr_kind_for_rid): New.
(objc_add_property_declaration): Adjust to consume the
parser output using a vector of parsed attributes.
Iain Sandoe [Sat, 10 Oct 2020 10:14:47 +0000 (11:14 +0100)]
Objective-C++ : Fix bitfield ivars regression.
This fixes a regression present from 8.x; It used to be OK
to test for a DECL_INITIAL value to flag that an ivar was a
bitfield (the initial value was the width). This still works
on C / Objective-C, but no longer on C++. Replace the test
with DECL_C_BIT_FIELD() which is set for both C and C++.
gcc/objc/ChangeLog:
* objc-next-runtime-abi-02.c (objc_v2_build_ivar_ref): Test
DECL_C_BIT_FIELD to detect that an ivar is a bitfield.
Iain Sandoe [Sat, 3 Oct 2020 12:51:29 +0000 (13:51 +0100)]
Darwin, Objective-C/C++ : Fix code-gen for NeXT runtimes.
This addresses regressions in the handling of the NeXT runtime on Darwin
platforms which result from changes in the codegen requirements over different
OS versions and system toolchains.
1. Only emit Objective-C section switches for older linkers.
At one time, the system linkers needed to have at least a dummy entry for
every Objective-C section in use. This removes the extra emitted code when
it is not needed by the linker.
2. Pick up super refs directly.
The current code assumed that super refs could be computed indirectly, i.e.
that the meta-data generated by the compiler was treated as read-only by the
runtime. This does not always hold (it depends on the NeXT runtime version).
So, compute super refs directly.
3. Update protocol metadata to current version.
Later versions of the NeXT runtime protocol metadata contain additional
fields. This patch adds these fields and populates a new list of method
types.
4. Make meta-data 'extern "C"'.
For current system toolchains NeXT runtime meta-data symbols are not
mangled for Objective-C++ (i.e. they are considered to be 'extern "C"').
5. Revise the runtime selection options.
For the NeXT/Darwin runtime as installed on macOS, we now need to deal with
changes in ABI and APIs over the range of system versions supported. So
arrange to keep track of this.
6. Update message call codegen.
Platform compilers based on LLVM do not use the objc_sendMsg_fixit
and friends for newer editions of the OS (runtimes for Arm64 do not even
have those entries). However, the _fixit versions are needed for some OS
versions (at least, up to 10.6) since the super2 call is not implemented
there.
7. Update meta-data linkage.
Newer versions of ld64 require that some meta-data symbols are
global, and that a larger set are linker-visible...
8. Adjust objective-c symbol linkage with version.
.. but earlier linkers cannot handle publicly-visible (or linker-visible)
metadata, so we need to make the output of these conditional on version.
9. Make protocols private extern and weak.
Newer linkers want protocols to be private-extern and weak.
* config/darwin.c (output_objc_section_asm_op): Avoid extra
objective-c section switches unless the linker needs them.
* config/darwin.c (darwin_objc2_section): Allow for
values > 1 to represent the next runtime.
(darwin_objc1_section): Likewise.
* config/darwin.c (darwin_globalize_label): Add protocol
meta-data labels to the set that are global. Make a subset of
metadate symbols global.
(darwin_label_is_anonymous_local_objc_name): Make a subset of
metadata symbols linker-visible.
(darwin_override_options): Track more target OS versions, make
the next_runtime version track this (unless it's set to 0 for
GNU runtime).
* config/darwin.h (NEXT_OBJC_RUNTIME): Set the default
next runtime value to be 10.5.8.
gcc/objc/ChangeLog:
* objc-next-runtime-abi-02.c
(objc_get_superclass_ref_decl): Split this code out.
(next_runtime_abi_02_get_class_super_ref): Compute
super refs using the objc_get_superclass_ref_decl().
(next_runtime_abi_02_get_category_super_ref): Likewise.
(build_v2_super_template): Add new
fields to the template.
(build_v2_protocol_template): Build new field entries.
(generate_v2_meth_descriptor_table): Adjust to allow recording all
method types.
(generate_v2_meth_type_list): New.
(build_v2_protocol_initializer): Initialize the additional fields.
(generate_v2_protocols): Record method types for all entries and
generate the additional method type table.
* objc-runtime-shared-support.c (start_var_decl): Make the
decl_assembler_name follow the metadata name for C++ on NeXT
runtime platforms.
(TAG_MSGSENDSUPER, TAG_MSGSENDID, TAG_MSGSENDSUPER_STRET,
TAG_MSGSENDID_STRET, FIXUP_NEEDED): Revised spelling.
(TAG_FIXUP): New.
Rename FIXUP_NEEDED to USE_FIXUP_BEFORE
(next_runtime_02_initialize): Adjust message calls to use
fixup variants only when required. Use renamed macros.
(next_runtime_abi_02_get_arg_type_list_base): Likewise.
(next_runtime_abi_02_build_objc_method_call): Likewise.
(next_runtime_abi_02_get_arg_type_list_base): Correct indent.
(build_v2_build_objc_method_call): New.
(build_v2_objc_method_fixup_call): Split out from ...
(next_runtime_abi_02_build_objc_method_call): ... here.
Arrange to adjust the call on the basis of the target
runtime.
(create_global_decl): Update to allow the caller to
specify declaration or definition.
(create_hidden_decl): Likewise.
(next_runtime_abi_02_protocol_decl): Make the symbol
weak and hidden for later OS runtime versions.
(build_v2_protocol_list_address_table): Likewise.
aarch64: Make aarch64_add_offset work with -ftrapv [PR99540]
aarch64_add_offset uses expand_mult to multiply the SVE VL by an
out-of-range constant. expand_mult takes an argument to indicate
whether the multiplication is signed or unsigned, but in this
context the multiplication is effectively signless and so the
choice seemed arbitrary.
However, one of the things that the signedness input does is
indicate whether signed overflow should be trapped for -ftrapv.
We don't want that here, so we must treat the multiplication
as unsigned.
gcc/
2021-03-24 Jakub Jelinek <jakub@redhat.com>
PR target/99540
* config/aarch64/aarch64.c (aarch64_add_offset): Tell
expand_mult to perform an unsigned rather than a signed
multiplication.
gcc/testsuite/
2021-03-24 Richard Sandiford <richard.sandiford@arm.com>
PR target/99540
* gcc.dg/vect/pr99540.c: New test.
Richard Biener [Mon, 8 Feb 2021 08:52:56 +0000 (09:52 +0100)]
lto/96591 - walk VECTOR_CST elements in walk_tree
This implements walking of VECTOR_CST elements in walk_tree, mimicing
the walk of COMPLEX_CST elements. Without this free-lang-data fails
to see some types in case they are only refered to via tree constants
used only as VECTOR_CST elements.
2021-02-08 Richard Biener <rguenther@suse.de>
PR lto/96591
* tree.c (walk_tree_1): Walk VECTOR_CST elements.
This avoids endless cycling when a PHI node with unchanged backedge
value (the PHI result appearing there) is subject to CSE since doing
that effectively alters the hash entry. The way to avoid this is
to ignore such edges when processing the PHI node.
2021-03-22 Richard Biener <rguenther@suse.de>
PR tree-optimization/99694
* tree-ssa-sccvn.c (visit_phi): Ignore edges with the
PHI result.
Iain Sandoe [Sat, 3 Oct 2020 12:40:03 +0000 (13:40 +0100)]
Objective-C, Darwin : Update metadata section uses.
Newer versions of ld64 are more picky about adherence to placement
rules for objective c metadata. This adds protocol refs and uses
the ivar refs for all targets.
gcc/ChangeLog:
* config/darwin-sections.def (objc2_data_section): New.
(objc2_ivar_section): New.
* config/darwin.c (darwin_objc2_section): Act on Protocol and
ivar refs.
gcc/objc/ChangeLog:
* objc-next-runtime-abi-02.c
(next_runtime_abi_02_init_metadata_attributes): Make protocol
refs a distinct section.
Objective-C, Darwin : Use special string sections for V2 NeXT runtime.
Newer versions of the runtime expect to find strings for class, method
and method types in set-aside sections rather than the general c_strings
one.
gcc/ChangeLog:
* config/darwin-sections.def (objc2_class_names_section,
objc2_method_names_section, objc2_method_types_section): New
* config/darwin.c (output_objc_section_asm_op): Output new
sections. (darwin_objc2_section): Select new sections where
used.
gcc/objc/ChangeLog:
* objc-next-runtime-abi-02.c
(next_runtime_abi_02_init_metadata_attributes): Attach metadata
for the special string sections to class, method and method type
string sections.
Iain Sandoe [Thu, 11 Mar 2021 17:04:14 +0000 (17:04 +0000)]
coroutines : Handle rethrow from unhandled_exception [PR98704].
Although there is still some discussion in CWG 2451 on this, the
implementors are agreed on the intent.
When promise.unhandled_exception () is entered, the coroutine is
considered to be still running - returning from the method will
cause the final await expression to be evaluated.
If the method throws, that action is considered to make the
coroutine suspend (since, otherwise, it would be impossible to
reclaim its resources, since one cannot destroy a running coro).
The wording issue is to do with how to represent the place at
which the coroutine should be considered suspended.
For the implementation here, that place is immediately before the
promise life-time ends. A handler for the rethrown exception, can
thus call xxxx.destroy() which will run DTORs for the promise and
any parameter copies [as needed] then the coroutine frame will be
deallocated.
At present, we also set "done=true" in this case (for compatibility
with other current implementations). One might consider 'done()'
to be misleading in the case of an abnormal termination - that is
also part of the CWG 2451 discussion.
gcc/cp/ChangeLog:
PR c++/98704
* coroutines.cc (build_actor_fn): Make destroy index 1
correspond to the abnormal unhandled_exception() exit.
Substitute the proxy for the resume index.
(coro_rewrite_function_body): Arrange to reset the resume
index and make done = true for a rethrown exception from
unhandled_exception ().
(morph_fn_to_coro): Adjust calls to build_actor_fn and
coro_rewrite_function_body.
gcc/testsuite/ChangeLog:
PR c++/98704
* g++.dg/coroutines/torture/pr98704.C: New test.
Iain Sandoe [Thu, 11 Mar 2021 14:22:37 +0000 (14:22 +0000)]
coroutines : Handle for await expressions in for stmts [PR98480].
The handling of await expressions in the init, condition and iteration
expressions of for loops had been omitted. Fixed thus.
gcc/cp/ChangeLog:
PR c++/98480
* coroutines.cc (replace_continue): Rewrite continue into
'goto label'.
(await_statement_walker): Handle await expressions in the
initializer, condition and iteration expressions of for
loops.
gcc/testsuite/ChangeLog:
PR c++/98480
* g++.dg/coroutines/pr98480.C: New test.
* g++.dg/coroutines/torture/co-await-24-for-init.C: New test.
* g++.dg/coroutines/torture/co-await-25-for-condition.C: New test.
* g++.dg/coroutines/torture/co-await-26-for-iteration-expr.C: New test.
In the compiler-only idiom:
" a = (target expr creats temp, op uses temp) "
the target expression variable needs to be promoted to a frame one
(if the expression has a suspend point). However, the only uses of
the var are in the second part of the compound expression - and we
were creating an empty statement corresponding to the (now unused)
first arm. This then produces the spurious warnings noted.
Fixed by avoiding generation of a separate variable nest for
isolated target expressions (or similarly isolated co_awaits used
in a function call).
gcc/cp/ChangeLog:
PR c++/96749
* coroutines.cc (flatten_await_stmt): Allow for the case
where a target expression variable only has uses in the
second part of a compound expression.
(maybe_promote_temps): Avoid emiting empty statements.
gcc/testsuite/ChangeLog:
PR c++/96749
* g++.dg/coroutines/pr96749-1.C: New test.
* g++.dg/coroutines/pr96749-2.C: New test.
Iain Sandoe [Wed, 17 Feb 2021 15:13:57 +0000 (15:13 +0000)]
coroutines : Adjust constraints on when to build ctors [PR98118].
PR98118 shows that TYPE_NEEDS_CONSTRUCTING is necessary but not
sufficient. Use type_build_ctor_call() instead.
gcc/cp/ChangeLog:
PR c++/98118
* coroutines.cc (build_co_await): Use type_build_ctor_call()
to determine cases when a CTOR needs to be built.
(flatten_await_stmt): Likewise.
(morph_fn_to_coro): Likewise.
gcc/testsuite/ChangeLog:
PR c++/98118
* g++.dg/coroutines/pr98118.C: New test.
Iain Sandoe [Mon, 15 Feb 2021 17:11:31 +0000 (17:11 +0000)]
coroutines : Do not accept throwing final await expressions [PR95616].
From the PR:
The wording of [dcl.fct.def.coroutine]/15 states:
* The expression co_await promise.final_suspend() shall not be
potentially-throwing ([except.spec]).
See http://eel.is/c++draft/dcl.fct.def.coroutine#15
and http://eel.is/c++draft/except.spec#6
ie. all of the following must be declared noexcept (if they form part of the await-expression):
- promise_type::final_suspend()
- finalSuspendObj.operator co_await()
- finalSuspendAwaiter.await_ready()
- finalSuspendAwaiter.await_suspend()
- finalSuspendAwaiter.await_resume()
- finalSuspedObj destructor
- finalSuspendAwaiter destructor
This implements the checks for these cases and rejects such code with
a diagnostic if exceptions are enabled.
PR c++/95616
* coroutines.cc (coro_diagnose_throwing_fn): New helper.
(coro_diagnose_throwing_final_aw_expr): New helper.
(build_co_await): Diagnose throwing final await expression
components. Look through NOP_EXPRs inbuild_special_member_call
return value to find the CALL_EXPR. Simplify.
(build_init_or_final_await): Diagnose a throwing promise
final_suspend() call.
gcc/testsuite/ChangeLog:
PR c++/95616
* g++.dg/coroutines/pr95616-0-no-exceptions.C: New test.
* g++.dg/coroutines/pr95616-0.C: New test.
* g++.dg/coroutines/pr95616-1-no-exceptions.C: New test.
* g++.dg/coroutines/pr95616-1.C: New test.
* g++.dg/coroutines/pr95616-2.C: New test.
* g++.dg/coroutines/pr95616-3-no-exceptions.C: New test.
* g++.dg/coroutines/pr95616-3.C: New test.
* g++.dg/coroutines/pr95616-4.C: New test.
* g++.dg/coroutines/pr95616-5.C: New test.
* g++.dg/coroutines/pr95616-6.C: New test.
Iain Sandoe [Mon, 15 Feb 2021 15:09:27 +0000 (15:09 +0000)]
coroutines : Handle exceptions throw before the first await_resume() [PR95615].
The coroutine body is wrapped in a try-catch block which is responsible for
handling any exceptions thrown by the original function body. Originally, the
initial suspend expression was outside this, but an amendement to the standard
places the await_resume call inside and eveything else outside.
This means that any exception thrown prior to the initial suspend expression
await_resume() will propagate to the ramp function. However, some portion of
the coroutine state will exist at that point (how much depends on where the
exception is thrown from). For example, we might have some frame parameter
copies, or the promise object or the return object any of which might have a
non-trivial DTOR. Also the frame itself needs to be deallocated. This patch
fixes the handling of these cases.
gcc/cp/ChangeLog:
PR c++/95615
* coroutines.cc (struct param_info): Track parameter copies that need
a DTOR.
(coro_get_frame_dtor): New helper function factored from build_actor().
(build_actor_fn): Use coro_get_frame_dtor().
(morph_fn_to_coro): Track parameters that need DTORs on exception,
likewise the frame promise and the return object. On exception, run the
DTORs for these, destroy the frame and then rethrow the exception.
gcc/testsuite/ChangeLog:
PR c++/95615
* g++.dg/coroutines/torture/pr95615-01.C: New test.
* g++.dg/coroutines/torture/pr95615-02.C: New test.
* g++.dg/coroutines/torture/pr95615-03.C: New test.
* g++.dg/coroutines/torture/pr95615-04.C: New test.
* g++.dg/coroutines/torture/pr95615-05.C: New test.
Iain Sandoe [Mon, 15 Feb 2021 16:13:36 +0000 (16:13 +0000)]
coroutines : Call promise CTOR with parm copies [PR97587].
As the PR notes, we were calling the promise CTOR with the original
function parameters, not the copy (as pointed, a previous wording of
the section was unambiguous). Fixed thus.
gcc/cp/ChangeLog:
PR c++/97587
* coroutines.cc (struct param_info): Track rvalue refs.
(morph_fn_to_coro): Track rvalue refs, and call the promise
CTOR with the frame copy of passed parms.
gcc/testsuite/ChangeLog:
PR c++/97587
* g++.dg/coroutines/coro1-refs-and-ctors.h: Add a CTOR with two
reference parms, to distinguish the rvalue ref. variant.
* g++.dg/coroutines/pr97587.C: New test.
Iain Sandoe [Tue, 16 Feb 2021 09:07:32 +0000 (09:07 +0000)]
coroutines : Remove throwing_cleanup marks from the ramp [PR95822].
The FE contains a mechanism for cleaning up return expressions if a
function throws during the execution of cleanups prior to the return.
If the original function has a return value with a non-trivial DTOR
and the body contains a var with a DTOR that might throw, the function
decl is marked "throwing_cleanup".
However, we do not [in the coroutine ramp function, which is
synthesised], use any body var types with DTORs that might throw.
The original body [which will then contain the type with the throwing
DTOR] is transformed into the actor function which only contains void
returns, and is also wrapped in a try-catch block.
So (a) the 'throwing_cleanup' is no longer correct for the ramp and
(b) we do not need to transfer it to the actor which only contains
void returns.
gcc/cp/ChangeLog:
PR c++/95822
* coroutines.cc (morph_fn_to_coro): Unconditionally remove any
set throwing_cleanup marker.
gcc/testsuite/ChangeLog:
PR c++/95822
* g++.dg/coroutines/pr95822.C: New test.
Iain Sandoe [Mon, 15 Feb 2021 16:56:52 +0000 (16:56 +0000)]
testsuite, coroutines : Make final_suspend calls noexcept.
The wording of [dcl.fct.def.coroutine]/15 states:
The expression co_await promise.final_suspend() shall not be
potentially-throwing. A fair number of testcases are not correctly
marked. Fixed here.
David Edelsohn [Wed, 27 Jan 2021 21:47:22 +0000 (16:47 -0500)]
aix: Permit use of AIX Vector extended ABI mode
AIX only permits use of Altivec VSRs 20-31 in a Vector Extended ABI mode.
This patch explicitly enables use of the VSRs using the new -mabi=vec-extabi
command line option also implemented in LLVM for AIX.
Bootstrapped on powerpc-ibm-aix7.2.3.0 and powerpc64le-linux-gnu.
gcc/ChangeLog:
* config/rs6000/rs6000.opt (mabi=vec-extabi): New.
(mabi=vec-default): New.
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
__EXTABI__ for AIX Vector extended ABI.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Print AIX Vector
extabi info.
(conditional_register_usage): If AIX vec_extabi enabled, vs20-vs31
are non-volatile.
* doc/invoke.texi (PowerPC mabi): Add AIX vec-extabi and vec-default.
Iain Sandoe [Tue, 23 Feb 2021 12:54:26 +0000 (12:54 +0000)]
coroutines : Adjust error handling for type-dependent coroutines [PR96251].
Although coroutines are not permitted to be constexpr, generic lambdas
are implicitly from C++17 and, because of this, a generic coroutine lambda
can be marked as potentially constexpr. As per the PR, this then fails when
type substitution is attempted because the check disallowing constexpr in
the coroutines code was overly restrictive.
This changes the error handing to mark the function as 'invalid_constexpr'
but suppresses the error in the case that we are instantiating a constexpr.
gcc/cp/ChangeLog:
PR c++/96251
* coroutines.cc (coro_common_keyword_context_valid_p): Suppress
error reporting when instantiating for a constexpr.
gcc/testsuite/ChangeLog:
PR c++/96251
* g++.dg/coroutines/pr96251.C: New test.
Iain Sandoe [Mon, 18 Jan 2021 20:09:10 +0000 (20:09 +0000)]
dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097].
This address one of the more long-standing and serious regressions
for Darwin. GCC emits unwind code by default on the assumption that
the unwinder will be (of have the same capability) as the one in the
current libgcc_s. For Darwin platforms, this is not the case - some
of them are based on the libgcc_s from GCC-4.2.1 and some are using
the unwinder provided by libunwind (part of the LLVM project). The
latter implementation has gradually adopted a section that deals with
GNU unwind.
The most serious problem for some of the platform versions is in
handling DW_CFA_remember/restore_state pairs. The DWARF description
talks about these in terms of saving/restoring register rows; this is
what GCC originally did (and is what the unwinders do for the Darwin
versions based on libgcc_s).
However, in r118068, this was changed so that not only the registers
but also the current frame address expression were saved. The unwind
code assumes that the unwinder will do this; some of Darwin's unwinders
do not, leading to lockups etc. To date, the only solution has been
to replace the system libgcc_s with a newer one which is not a viable
solution for many end-users (since that means overwritting the one
provided with the system installation).
The fix here provides a target hook that allows the target to specify
that the CFA should be reinstated after a DW_CFA_restore. This fixes
the issue (and also the closed WONTFIX of 44107).
(As a matter of record, it also fixes reported Java issues if
backported to GCC-5).
gcc/ChangeLog:
PR target/44107
PR target/48097
* config/darwin-protos.h (darwin_should_restore_cfa_state): New.
* config/darwin.c (darwin_should_restore_cfa_state): New.
* config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New.
* doc/tm.texi: Regenerated.
* doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE.
* dwarf2cfi.c (connect_traces): If the target requests, restore
the CFA expression after a DW_CFA_restore.
* target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook.
Iain Sandoe [Wed, 30 Dec 2020 16:56:12 +0000 (16:56 +0000)]
Darwin : Simplify headers.
This is a NFC patch, but needed to make follow-on patches apply
cleanly.
The darwinN.h headers were (presumably) introduced to allow specs to be
adjusted when there was no mmacosx-version-min handling, or that was
considered unreliable.
We have version-specific specs for the values that have configuration
data, and the version is set in the driver (so may be considered
reliably present).
Some of the 'darwinN.h' content has become dead code, and the reminder
is either conditionalised on version information (or is setting values
used as fall-backs in cross-compilations).
With the changes needed for Darwin20 / macOS 11 the 'darwnN.h' headers
are now too unwieldy to be useful - so this series moves the relevant
specs definitons to the common 'darwin.h' header and then finally uses
the config.gcc script to supply the fall-back defaults for cross-
compilations.
We can then delete all but the main header, since the darwinN.h are
unused.
There is no need to make the LINK_GCC_C_SEQUENCE_SPEC conditional on
configuration parameters, it is adequately conditionalized on the
macosx-version-min.
We now need a modern C++ toolchain to bootstrap GCC, so there's no
need to skip the stack protect for Darwin < 9.
Darwin defines ASM_OUTPUT_ALIGNED_DECL_COMMON which is used in
preference to ASM_OUTPUT_ALIGNED_COMMON, which makes the latter
definition dead code. Remove this.
The darwinN.h headers (with the sole exception of darwin7.h,
which contains a target macro definition) now only contain
values that set fall-backs for cross-compilations, these can
be provided from the config.gcc script which means we no longer
need the darwinN.h - so delete them.
* config/darwin10.h (LINK_GCC_C_SEQUENCE_SPEC): Move the spec
for the Darwin10 unwinder stub from here ..
* config/darwin.h (LINK_COMMAND_SPEC_A): ... to here.
here...
* config/darwin10.h (LINK_GCC_C_SEQUENCE_SPEC): Move from here..
* config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): ... to here.
* config/darwin9.h (STACK_CHECK_STATIC_BUILTIN): Move from here..
* config/darwin.h (STACK_CHECK_STATIC_BUILTIN): .. to here.
* config.gcc: Compute default version information
from the configured target. Likewise defaults for
ld64. Delete reference to the now removed darwin8.h
* config/darwin10.h: Removed.
* config/darwin12.h: Removed.
* config/darwin9.h: Removed.
* config/rs6000/darwin8.h: Removed.
Iain Sandoe [Wed, 30 Dec 2020 10:36:52 +0000 (10:36 +0000)]
Darwin : Adjust defaults for current bootstrap constraints.
The toolchain now requires a C++11 compiler to bootstrap and
none of the older Darwin toolchains which were based on stabs
debugging are suitable. We can simplify the debug setup now.
gcc/ChangeLog:
* config/darwin.h (DSYMUTIL_SPEC): Default to DWARF
(ASM_DEBUG_SPEC):Only define if the assembler supports
stabs.
(PREFERRED_DEBUGGING_TYPE): Default to DWARF.
(DARWIN_PREFER_DWARF): Define.
* config/darwin9.h (PREFERRED_DEBUGGING_TYPE): Remove.
(DARWIN_PREFER_DWARF): Likewise
(DSYMUTIL_SPEC): Likewise.
(COLLECT_RUN_DSYMUTIL): Likewise.
(ASM_DEBUG_SPEC): Likewise.
(ASM_DEBUG_OPTION_SPEC): Likewise.
Iain Sandoe [Sun, 2 Aug 2020 15:44:02 +0000 (16:44 +0100)]
Darwin: Guard two macros in darwin.h.
Work on the Arm64 port shows that these two macros can be declared
ahead of the version in darwin.h which needs to override (for X86
and PPC this wasn't needed).
gcc/ChangeLog:
* config/darwin.h (ASM_DECLARE_FUNCTION_NAME): UNDEF before
use.
(DEF_MIN_OSX_VERSION): Only define if there's no existing
def.
Iain Sandoe [Sun, 22 Nov 2020 11:19:32 +0000 (11:19 +0000)]
Darwin : Avoid a C++ ODR violation seen with LTO.
We have a similar code pattern in darwin-c.c to one in c-pragmas
(most likely a cut & paste) with a struct type used locally to the
TU. With C++ we need to rename the type to avoid an ODR violation.
gcc/ChangeLog:
* config/darwin-c.c (struct f_align_stack): Rename
to type from align_stack to f_align_stack.
(push_field_alignment): Likewise.
(pop_field_alignment): Likewise.
Iain Sandoe [Sat, 22 Aug 2020 16:40:20 +0000 (17:40 +0100)]
Darwin : Begin rework of zero-fill sections.
Much of the existing work in the Darwin BSS and common sections
was to accommodate the PowerPC section anchors. We want to segregate
this, since it might become desirable to support section anchors for
arm64.
First revision (here) is to use the same section conventions as the Xcode
toochains for BSS and COMMON.
We also drop the constraint about putting small items into data/static data
that was a work-around for Java issues (irrelevant for several editions).
gcc/ChangeLog:
* config/darwin.c (darwin_emit_local_bss): Amend section names to
match system tools. (darwin_output_aligned_bss): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/darwin-sections.c: Adjust test for renamed BSS and common
sections. Cater for 64 and 128 bit long doubles.
testsuite, Darwin: XFAIL runs for two timode conversion tests.
X86 Darwin fails these at present, because (to work around PR80556)
we insert libSystem ahead of libgcc. The libSystem implementation
has a similar bug to one that was fixed for GCC. We need to fix
80556 properly, and then this issue will go away - we will be able
to use the libgcc impl as intended.
Iain Sandoe [Sat, 1 Aug 2020 15:44:10 +0000 (16:44 +0100)]
Darwin: Handle poly_int machine_modes.
The common code that selects suitable sections for literals needs
to inspect the machine_mode. For some sub-targets that might be
represented as a poly-int.
There was a workaround in place that allowed for cases where the poly
int had only one component. This removes the workaround and handles
the cases where we care about the machine_mode size.
Jakub Jelinek [Thu, 18 Mar 2021 15:14:47 +0000 (16:14 +0100)]
testsuite: Fix up strlenopt-80.c on powerpc [PR99636]
Similar issue as in strlenopt-73.c, various spots in this test rely
on MOVE_MAX >= 8, this time it uses a target selector to pick up a couple
of targets, and all of them but powerpc 32-bit satisfy it, but powerpc
32-bit have MOVE_MAX just 4.
2021-03-18 Jakub Jelinek <jakub@redhat.com>
PR testsuite/99636
* gcc.dg/strlenopt-80.c: For powerpc*-*-*, only enable for lp64.
Jakub Jelinek [Thu, 18 Mar 2021 15:11:46 +0000 (16:11 +0100)]
testsuite: Fix up strlenopt-73.c on powerpc [PR99626]
As mentioned in the testcase as well as in the PR, this testcase relies on
MOVE_MAX being sufficiently large that the memcpy call is folded early into
load + store. Some popular targets define MOVE_MAX to 8 or even 16 (e.g.
x86_64 or some options on s390x), but many other targets define it to just 4
(e.g. powerpc 32-bit), or even 2.
The testcase has already one test routine guarded on one particular target
with MOVE_MAX 16 (but does it incorrectly, __i386__ is only defined on
32-bit x86 and __SIZEOF_INT128__ is only defined on 64-bit targets), this
patch fixes that, and guards another test that relies on memcpy (, , 8)
being folded that way (which therefore needs MOVE_MAX >= 8) on a couple of
common targets that are known to have such MOVE_MAX.
2021-03-18 Jakub Jelinek <jakub@redhat.com>
PR testsuite/99626
* gcc.dg/strlenopt-73.c: Ifdef out test_copy_cond_unequal_length_i64
on targets other than x86, aarch64, s390 and 64-bit powerpc. Use
test_copy_cond_unequal_length_i128 for __x86_64__ with int128 support
rather than __i386__.
Jakub Jelinek [Tue, 16 Mar 2021 20:17:44 +0000 (21:17 +0100)]
c++: Ensure correct destruction order of local statics [PR99613]
As mentioned in the PR, if end of two constructions of local statics
is strongly ordered, their destructors should be run in the reverse order.
As we run __cxa_guard_release before calling __cxa_atexit, it is possible
that we have two threads that access two local statics in the same order
for the first time, one thread wins the __cxa_guard_acquire on the first
one but is rescheduled in between the __cxa_guard_release and __cxa_atexit
calls, then the other thread is scheduled and wins __cxa_guard_acquire
on the second one and calls __cxa_quard_release and __cxa_atexit and only
afterwards the first thread calls its __cxa_atexit. This means a variable
whose completion of the constructor strongly happened after the completion
of the other one will be destructed after the other variable is destructed.
The following patch fixes that by swapping the __cxa_guard_release and
__cxa_atexit calls.
2021-03-16 Jakub Jelinek <jakub@redhat.com>
PR c++/99613
* decl.c (expand_static_init): For thread guards, call __cxa_atexit
before calling __cxa_guard_release rather than after it. Formatting
fixes.
Jakub Jelinek [Tue, 16 Mar 2021 10:16:15 +0000 (11:16 +0100)]
i386: Fix up _mm256_vzeroupper() handling [PR99563]
My r10-6451-gb7b3378f91c0641f2ef4d88db22af62a571c9359 fix for
vzeroupper vs. ms ABI apparently broke the explicit vzeroupper handling
when the implicit vzeroupper handling is disabled.
The epilogue_completed splitter for vzeroupper now adds clobbers for all
registers which don't have explicit sets in the pattern and the sets are
added during vzeroupper pass. Before my changes, for explicit user
vzeroupper, we just weren't modelling its effects at all, it was just
unspec that didn't tell that it clobbers the upper parts of all XMM < %xmm16
registers. But now the splitter will even for those add clobbers and as
it has no sets, it will add clobbers for all registers, which means
we optimize away anything that lived across that vzeroupper.
The vzeroupper pass has two parts, one is the mode switching that computes
where to put the implicit vzeroupper calls and puts them there, and then
another that uses df to figure out what sets to add to all the vzeroupper.
The former part should be done only under the conditions we have in the
gate, but the latter as this PR shows needs to happen either if we perform
the implicit vzeroupper additions, or if there are (or could be) any
explicit vzeroupper instructions. As that function does df_analyze and
walks the whole IL, I think it would be too expensive to run it always
whenever TARGET_AVX, so this patch remembers if we've expanded at least
one __builtin_ia32_vzeroupper in the function and runs that part of the
vzeroupper pass both when the old condition is true or when this new
flag is set.
2021-03-16 Jakub Jelinek <jakub@redhat.com>
PR target/99563
* config/i386/i386.h (struct machine_function): Add
has_explicit_vzeroupper bitfield.
* config/i386/i386-expand.c (ix86_expand_builtin): Set
cfun->machine->has_explicit_vzeroupper when expanding
IX86_BUILTIN_VZEROUPPER.
* config/i386/i386-features.c (rest_of_handle_insert_vzeroupper):
Do the mode switching only when TARGET_VZEROUPPER, expensive
optimizations turned on and not optimizing for size.
(pass_insert_vzeroupper::gate): Enable even when
cfun->machine->has_explicit_vzeroupper is set.
Jakub Jelinek [Tue, 16 Mar 2021 09:34:44 +0000 (10:34 +0100)]
aarch64: Fix up aarch64_simd_clone_compute_vecsize_and_simdlen [PR99542]
As the patch shows, there are several bugs in
aarch64_simd_clone_compute_vecsize_and_simdlen.
One is that unlike for function declarations that aren't definitions
it completely ignores argument types. Such decls don't have DECL_ARGUMENTS,
but we can walk TYPE_ARG_TYPES instead, like the i386 backend does or like
the simd cloning code in the middle end does too.
Another problem is that it checks types of uniform arguments. That is
unnecessary, uniform arguments are passed the way it normally is, it is
a scalar argument rather than vector, so there is no reason not to support
uniform argument of different size, or long double, structure etc.
2021-03-16 Jakub Jelinek <jakub@redhat.com>
PR target/99542
* config/aarch64/aarch64.c
(aarch64_simd_clone_compute_vecsize_and_simdlen): If not a function
definition, walk TYPE_ARG_TYPES list if non-NULL for argument types
instead of DECL_ARGUMENTS. Ignore types for uniform arguments.
* gcc.dg/gomp/pr99542.c: New test.
* gcc.dg/gomp/pr59669-2.c (bar): Don't expect a warning on aarch64.
* gcc.dg/gomp/simd-clones-2.c (setArray): Likewise.
* g++.dg/vect/simd-clone-7.cc (bar): Likewise.
* g++.dg/gomp/declare-simd-1.C (f37): Expect a different warning
on aarch64.
* gcc.dg/declare-simd.c (fn2): Expect a new warning on aarch64.
Jakub Jelinek [Fri, 12 Mar 2021 09:11:24 +0000 (10:11 +0100)]
c++: Fix up calls to immediate functions returning reference [PR99507]
build_cxx_call calls convert_from_reference at the end, so if an immediate
function returns a reference, we were constant evaluating not just that
call, but that call wrapped in an INDIRECT_REF. That unfortunately means
it can constant evaluate to something non-addressable, so if code later
needs to take its address it will fail.
The following patch fixes that by undoing the convert_from_reference
wrapping for the cxx_constant_value evaluation and readdding it ad the end.
2021-03-12 Jakub Jelinek <jakub@redhat.com>
PR c++/99507
* call.c (build_over_call): For immediate evaluation of functions
that return references, undo convert_from_reference effects before
calling cxx_constant_value and call convert_from_reference
afterwards.
Jakub Jelinek [Thu, 11 Mar 2021 09:59:18 +0000 (10:59 +0100)]
icf: Check return type of internal fn calls [PR99517]
The following testcase is miscompiled, because IPA-ICF considers the two
functions identical. They aren't, the types of the .VEC_CONVERT call
lhs is different. But for calls to internal functions, there is no
fntype nor callee with a function type to compare, so all we compare
is just the ifn, arguments and some call flags.
The following patch fixes it by checking the internal fn calls like e.g. gimple
assignments where the type of the lhs is checked too.
2021-03-11 Jakub Jelinek <jakub@redhat.com>
PR ipa/99517
* ipa-icf-gimple.c (func_checker::compare_gimple_call): For internal
function calls with lhs fail if the lhs don't have compatible types.
* gcc.target/i386/avx2-pr99517-1.c: New test.
* gcc.target/i386/avx2-pr99517-2.c: New test.
Jakub Jelinek [Thu, 4 Mar 2021 18:38:08 +0000 (19:38 +0100)]
expand: Fix ICE in store_bit_field_using_insv [PR93235]
The following testcase ICEs on aarch64. The problem is that
op0 is (subreg:HI (reg:HF ...) 0) and because we can't create a SUBREG of a
SUBREG and aarch64 doesn't have HImode insv, only SImode insv,
store_bit_field_using_insv tries to create (subreg:SI (reg:HF ...) 0)
which is not valid for the target and so gen_rtx_SUBREG ICEs.
The following patch fixes it by punting if the to be created SUBREG
doesn't validate, callers of store_bit_field_using_insv can handle
the fallback.
2021-03-04 Jakub Jelinek <jakub@redhat.com>
PR middle-end/93235
* expmed.c (store_bit_field_using_insv): Return false of xop0 is a
SUBREG and a SUBREG to op_mode can't be created.
Jakub Jelinek [Thu, 4 Mar 2021 15:04:48 +0000 (16:04 +0100)]
c++: Fix up [[nodiscard]] on ctors on targetm.cxx.cdtor_returns_this targets [PR99362]
In the P1771R1 changes JeanHeyd reverted part of Alex' PR88146 fix,
but that seems to be incorrect to me.
Where P1771R1 suggests warnings for [[nodiscard]] on constructors is
handled in a different place - in particular the TARGET_EXPR handling
of convert_to_void. When we have CALL_EXPR of a ctor, on most arches
that call has void return type and so returns early, and on arm where
the ctor returns the this pointer it is undesirable to warn as it warns
about all ctor calls, not just the ones where it should warn.
The P1771R1 changes added a test for this, but as it was given *.c
extension rather than *.C, the test was never run and so this didn't get
spotted immediately. The test also had a bug, (?n) can't be used
in dg-warning/dg-error because those are implemented by prepending
some regexp before the user provided one and (?n) must come at the start
of the regexp. Furthermore, while -ftrack-macro-expansion=0 is useful
in one nodiscard test which uses macros, I don't see how it would be
relevant to all the other cpp2a/nodiscard* tests which don't use any
macros.
2021-03-04 Jakub Jelinek <jakub@redhat.com>
PR c++/88146
PR c++/99362
gcc/cp/
* cvt.c (convert_to_void): Revert 2019-10-17 changes. Clarify
comment.
gcc/testsuite/
* g++.dg/cpp2a/nodiscard-constructor.c: Renamed to ...
* g++.dg/cpp2a/nodiscard-constructor1.C: ... this. Remove
-ftrack-macro-expansion=0 from dg-options. Don't use (?n) in
dg-warning regexps, instead replace .* with \[^\n\r]*.
* g++.dg/cpp2a/nodiscard-constructor2.C: New test.
* g++.dg/cpp2a/nodiscard-reason-only-one.C: Remove
-ftrack-macro-expansion=0 from dg-options.
* g++.dg/cpp2a/nodiscard-reason-nonstring.C: Likewise.
* g++.dg/cpp2a/nodiscard-once.C: Likewise.
Jakub Jelinek [Wed, 3 Mar 2021 15:12:23 +0000 (16:12 +0100)]
c++: Fix -fstrong-eval-order for operator &&, || and , [PR82959]
P0145R3 added
"However, the operands are sequenced in the order prescribed for the built-in
operator" rule for overloaded operator calls when using the operator syntax.
op_is_ordered follows that, but added just the overloaded operators
added in that paper. &&, || and comma operators had rules that
lhs is sequenced before rhs already in C++98.
The following patch adds those cases to op_is_ordered.
2021-03-03 Jakub Jelinek <jakub@redhat.com>
PR c++/82959
* call.c (op_is_ordered): Handle TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR
and COMPOUND_EXPR.
Jakub Jelinek [Wed, 3 Mar 2021 08:55:19 +0000 (09:55 +0100)]
c-family: Avoid ICE on va_arg [PR99324]
build_va_arg calls the middle-end mark_addressable, which e.g. requires that
cfun is non-NULL. The following patch calls instead c_common_mark_addressable_vec
which is the c-family variant similarly to the FE c_mark_addressable and
cxx_mark_addressable, except that it doesn't error on addresses of register
variables. As the taking of the address is artificial for the .VA_ARG
ifn and when that is lowered goes away, it is similar case to the vector
subscripting for which c_common_mark_addressable_vec has been added.
2021-03-03 Jakub Jelinek <jakub@redhat.com>
PR c/99324
* c-common.c (build_va_arg): Call c_common_mark_addressable_vec
instead of mark_addressable. Fix a comment typo -
neutrallly -> neutrally.
Jakub Jelinek [Wed, 3 Mar 2021 08:51:54 +0000 (09:51 +0100)]
cfgrtl: Fix up fixup_partitions caused ICE [PR99085]
fixup_partitions sometimes changes some basic blocks from hot partition to
cold partition, in particular if after unreachable block removal or other
optimizations a hot partition block is dominated by cold partition block(s).
It fixes up the edges and jumps on those edges, but when after reorder
blocks and in rtl (non-cfglayout) mode that is clearly not enough, because
it keeps the block order the same and so we can end up with more than
1 hot/cold section transition in the same function.
So, this patch fixes that up too.
2021-03-03 Jakub Jelinek <jakub@redhat.com>
PR target/99085
* cfgrtl.c (fixup_partitions): When changing some bbs from hot to cold
partitions, if in non-layout mode after reorder_blocks also move
affected blocks to ensure a single partition transition.
Jakub Jelinek [Fri, 26 Feb 2021 09:43:28 +0000 (10:43 +0100)]
c++: Fix operator() lookup in lambdas [PR95451]
During name lookup, name-lookup.c uses:
if (!(!iter->type && HIDDEN_TYPE_BINDING_P (iter))
&& (bool (want & LOOK_want::HIDDEN_LAMBDA)
|| !is_lambda_ignored_entity (iter->value))
&& qualify_lookup (iter->value, want))
binding = iter->value;
Unfortunately as the following testcase shows, this doesn't work in
generic lambdas, where we on the auto b = ... lambda ICE and on the
auto d = lambda reject it even when it should be valid. The problem
is that the binding doesn't have a FUNCTION_DECL with
LAMBDA_FUNCTION_P for the operator(), but an OVERLOAD with
TEMPLATE_DECL for such FUNCTION_DECL.
The following patch fixes that in is_lambda_ignored_entity, other
possibility would be to do that before calling is_lambda_ignored_entity
in name-lookup.c.
2021-02-26 Jakub Jelinek <jakub@redhat.com>
PR c++/95451
* lambda.c (is_lambda_ignored_entity): Before checking for
LAMBDA_FUNCTION_P, use OVL_FIRST. Drop FUNCTION_DECL check.
Jakub Jelinek [Wed, 24 Feb 2021 11:10:25 +0000 (12:10 +0100)]
fold-const: Fix up ((1 << x) & y) != 0 folding for vectors [PR99225]
This optimization was written purely with scalar integers in mind,
can work fine even with vectors, but we can't use build_int_cst but
need to use build_one_cst instead.
2021-02-24 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99225
* fold-const.c (fold_binary_loc) <case NE_EXPR>: In (x & (1 << y)) != 0
to ((x >> y) & 1) != 0 simplifications use build_one_cst instead of
build_int_cst (..., 1). Formatting fixes.
Jakub Jelinek [Tue, 23 Feb 2021 08:49:48 +0000 (09:49 +0100)]
fold-const: Fix ICE in fold_read_from_constant_string on invalid code [PR99204]
fold_read_from_constant_string and expand_expr_real_1 have code to optimize
constant reads from string (tree vs. rtl).
If the STRING_CST array type has zero low bound, index is fold converted to
sizetype and so the compare_tree_int works fine, but if it has some other
low bound, it calls size_diffop_loc and that function from 2 sizetype
operands creates a ssizetype difference. expand_expr_real_1 then uses
tree_fits_uhwi_p + compare_tree_int and so works fine, but fold-const.c
only checked if index is INTEGER_CST and calls compare_tree_int, which means
for negative index it will succeed and result in UB in the compiler.
2021-02-23 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99204
* fold-const.c (fold_read_from_constant_string): Check that
tree_fits_uhwi_p (index) rather than just that index is INTEGER_CST.
Jakub Jelinek [Tue, 23 Feb 2021 08:30:18 +0000 (09:30 +0100)]
libstdc++: Fix up constexpr std::char_traits<char>::compare [PR99181]
Because of LWG 467, std::char_traits<char>::lt compares the values
cast to unsigned char rather than char, so even when char is signed
we get unsigned comparision. std::char_traits<char>::compare uses
__builtin_memcmp and that works the same, but during constexpr evaluation
we were calling __gnu_cxx::char_traits<char_type>::compare. As
char_traits::lt is not virtual, __gnu_cxx::char_traits<char_type>::compare
used __gnu_cxx::char_traits<char_type>::lt rather than
std::char_traits<char>::lt and thus compared chars as signed if char is
signed.
This change fixes it by inlining __gnu_cxx::char_traits<char_type>::compare
into std::char_traits<char>::compare by hand, so that it calls the right
lt method.
2021-02-23 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/99181
* include/bits/char_traits.h (char_traits<char>::compare): For
constexpr evaluation don't call
__gnu_cxx::char_traits<char_type>::compare but do the comparison loop
directly.
* testsuite/21_strings/char_traits/requirements/char/99181.cc: New
test.
Jakub Jelinek [Fri, 19 Feb 2021 11:14:39 +0000 (12:14 +0100)]
tree-cfg: Fix up gimple_merge_blocks FORCED_LABEL handling [PR99034]
The verifiers require that DECL_NONLOCAL or EH_LANDING_PAD_NR
labels are always the first label if there is more than one label.
When merging blocks, we don't honor that though.
On the following testcase, we try to merge blocks:
<bb 13> [count: 0]:
<L2>:
S::~S (&s);
and
<bb 15> [count: 0]:
<L0>:
resx 1
where <L2> is landing pad and <L0> is FORCED_LABEL. And the code puts
the FORCED_LABEL before the landing pad label, violating the verification
requirements.
The following patch fixes it by moving the FORCED_LABEL after the
DECL_NONLOCAL or EH_LANDING_PAD_NR label if it is the first label.
2021-02-19 Jakub Jelinek <jakub@redhat.com>
PR ipa/99034
* tree-cfg.c (gimple_merge_blocks): If bb a starts with eh landing
pad or non-local label, put FORCED_LABELs from bb b after that label
rather than before it.
Jakub Jelinek [Thu, 18 Feb 2021 21:17:52 +0000 (22:17 +0100)]
c: Fix ICE with -fexcess-precision=standard [PR99136]
The following testcase ICEs on i686-linux, because c_finish_return wraps
c_fully_folded retval back into EXCESS_PRECISION_EXPR, but when the function
return type is void, we don't call convert_for_assignment on it that would
then be fully folded again, but just put the retval into RETURN_EXPR's
operand, so nothing removes it anymore and during gimplification we
ICE as EXCESS_PRECISION_EXPR is not handled.
This patch fixes it by not adding that EXCESS_PRECISION_EXPR in functions
returning void, the return value is ignored and all we need is evaluate any
side-effects of the expression.
2021-02-18 Jakub Jelinek <jakub@redhat.com>
PR c/99136
* c-typeck.c (c_finish_return): Don't wrap retval into
EXCESS_PRECISION_EXPR in functions that return void.
Jakub Jelinek [Wed, 17 Feb 2021 14:03:25 +0000 (15:03 +0100)]
c++: Fix up build_zero_init_1 once more [PR99106]
My earlier build_zero_init_1 patch for flexible array members created
an empty CONSTRUCTOR. As the following testcase shows, that doesn't work
very well because the middle-end doesn't expect CONSTRUCTOR elements with
incomplete type (that the empty CONSTRUCTOR at the end of outer CONSTRUCTOR
had).
The following patch just doesn't add any CONSTRUCTOR for the flexible array
members, it doesn't seem to be needed.
2021-02-17 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/99106
* init.c (build_zero_init_1): For flexible array members just return
NULL_TREE instead of returning empty CONSTRUCTOR with non-complete
ARRAY_TYPE.
Jakub Jelinek [Mon, 15 Feb 2021 08:16:06 +0000 (09:16 +0100)]
match.pd: Fix up A % (cast) (pow2cst << B) simplification [PR99079]
The (mod @0 (convert?@3 (power_of_two_cand@1 @2))) simplification
uses tree_nop_conversion_p (type, TREE_TYPE (@3)) condition, but I believe
it doesn't check what it was meant to check. On convert?@3
TREE_TYPE (@3) is not the type of what it has been converted from, but
what it has been converted to, which needs to be (because it is operand
of normal binary operation) equal or compatible to type of the modulo
result and first operand - type.
I could fix that by using && tree_nop_conversion_p (type, TREE_TYPE (@1))
and be done with it, but actually most of the non-nop conversions are IMHO
ok and so we would regress those optimizations.
In particular, if we have say narrowing conversions (foo5 and foo6 in
the new testcase), I think we are fine, either the shift of the power of two
constant after narrowing conversion is still that power of two (or negation
of that) and then it will still work, or the result of narrowing conversion
is 0 and then we would have UB which we can ignore.
Similarly, widening conversions where the shift result is unsigned are fine,
or even widening conversions where the shift result is signed, but we sign
extend to a signed wider divisor, the problematic case of INT_MIN will
become x % (long long) INT_MIN and we can still optimize that to
x & (long long) INT_MAX.
What doesn't work is the case in the pr99079.c testcase, widening conversion
of a signed shift result to wider unsigned divisor, where if the shift
is negative, we end up with x % (unsigned long long) INT_MIN which is
x % 0xffffffff80000000ULL where the divisor is not a power of two and
we can't optimize that to x & 0x7fffffffULL.
So, the patch rejects only the single problematic case.
Furthermore, when the shift result is signed, we were introducing UB into
a program which previously didn't have one (well, left shift into the sign
bit is UB in some language/version pairs, but it is definitely valid in
C++20 - wonder if I shouldn't move the gcc.c-torture/execute/pr99079.c
testcase to g++.dg/torture/pr99079.C and use -std=c++20), by adding that
subtraction of 1, x % (1 << 31) in C++20 is well defined, but
x & ((1 << 31) - 1) triggers UB on the subtraction.
So, the patch performs the subtraction in the unsigned type if it isn't
wrapping.
2021-02-15 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99079
* match.pd (A % (pow2pcst << N) -> A & ((pow2pcst << N) - 1)): Remove
useless tree_nop_conversion_p (type, TREE_TYPE (@3)) check. Instead
require both type and TREE_TYPE (@1) to be integral types and either
type having smaller or equal precision, or TREE_TYPE (@1) being
unsigned type, or type being signed type. If TREE_TYPE (@1)
doesn't have wrapping overflow, perform the subtraction of one in
unsigned type.
* gcc.dg/fold-modpow2-2.c: New test.
* gcc.c-torture/execute/pr99079.c: New test.
Jakub Jelinek [Fri, 12 Feb 2021 08:55:46 +0000 (09:55 +0100)]
c++: Fix endless errors on invalid requirement seq [PR97742]
As the testcase shows, if we reach CPP_EOF during parsing of requirement
sequence, we end up with endless loop where we always report invalid
requirement expression, don't consume any token (as we are at eof) and
repeat.
This patch stops the loop when we reach CPP_EOF.
2021-02-12 Jakub Jelinek <jakub@redhat.com>
PR c++/97742
* parser.c (cp_parser_requirement_seq): Stop iterating after reaching
CPP_EOF.
Jakub Jelinek [Thu, 11 Feb 2021 16:24:17 +0000 (17:24 +0100)]
c++: Fix zero initialization of flexible array members [PR99033]
array_type_nelts returns error_mark_node for type of flexible array members
and build_zero_init_1 was placing an error_mark_node into the CONSTRUCTOR,
on which e.g. varasm ICEs. I think there is nothing erroneous on zero
initialization of flexible array members though, such arrays should simply
get no elements, like they do if such classes are constructed (everything
except when some larger initializer comes from an explicit initializer).
So, this patch handles [] arrays in zero initialization like [0] arrays
and fixes handling of the [0] arrays - the
tree_int_cst_equal (max_index, integer_minus_one_node) check
didn't do what it thought it would do, max_index is typically unsigned
integer (sizetype) and so it is never equal to a -1.
What the patch doesn't do and maybe would be desirable is if it returns
error_mark_node for other reasons let the recursive callers not stick that
into CONSTRUCTOR but return error_mark_node instead. But I don't have a
testcase where that would be needed right now.
2021-02-11 Jakub Jelinek <jakub@redhat.com>
PR c++/99033
* init.c (build_zero_init_1): Handle zero initialiation of
flexible array members like initialization of [0] arrays.
Use integer_minus_onep instead of comparison to integer_minus_one_node
and integer_zerop instead of comparison against size_zero_node.
Formatting fixes.
Jakub Jelinek [Wed, 10 Feb 2021 18:52:37 +0000 (19:52 +0100)]
varasm: Fix ICE with -fsyntax-only [PR99035]
My FE change from 2 years ago uses TREE_ASM_WRITTEN in -fsyntax-only
mode more aggressively to avoid "expanding" functions multiple times.
With -fsyntax-only nothing is really expanded, so I think it is acceptable
to adjust the assert and allow declare_weak at any time, with -fsyntax-only
we know it is during parsing only anyway.
2021-02-10 Jakub Jelinek <jakub@redhat.com>
PR c++/99035
* varasm.c (declare_weak): For -fsyntax-only, allow even
TREE_ASM_WRITTEN function decls.
Jakub Jelinek [Wed, 10 Feb 2021 18:31:15 +0000 (19:31 +0100)]
c++: Consider addresses of heap artificial vars always non-NULL [PR98988, PR99031]
With -fno-delete-null-pointer-checks which is e.g. implied by
-fsanitize=undefined or default on some embedded targets, the middle-end
folder doesn't consider addresses of global VAR_DECLs to be non-NULL, as one
of them could have address 0. Still, I think malloc/operator new (at least
the nonthrowing) relies on NULL returns meaning allocation failure rather
than success. Furthermore, the artificial VAR_DECLs we create for
constexpr new never actually live in the address space of the program,
so we can pretend they will never be NULL too.
> I'm surprised that nonzero_address has such a limited set of things it will
> actually believe have non-zero addresses with
> -fno-delete-null-pointer-checks. But it seems that we should be able to
> arrange to satisfy
>
> > if (definition && !DECL_EXTERNAL (decl)
>
> since these "variables" are indeed defined within the current translation
> unit.
Doing that seems to work and as added benefit it fixes another PR that has
been filed recently. I need to create the varpool node explicitly and call
a method that sets the definition member in there, but I can also unregister
those varpool nodes at the end of constexpr processing, as the processing
ensured they don't leak outside of the processing.
2021-02-10 Jakub Jelinek <jakub@redhat.com>
PR c++/98988
PR c++/99031
* constexpr.c: Include cgraph.h.
(cxx_eval_call_expression): Call varpool_node::finalize_decl on
heap artificial vars.
(cxx_eval_outermost_constant_expr): Remove varpool nodes for
heap artificial vars.
* g++.dg/cpp2a/constexpr-new16.C: New test.
* g++.dg/cpp2a/constexpr-new17.C: New test.
Jakub Jelinek [Wed, 10 Feb 2021 09:34:58 +0000 (10:34 +0100)]
openmp: Temporarily disable into_ssa when gimplifying OpenMP reduction clauses [PR99007]
gimplify_scan_omp_clauses was already calling gimplify_expr with false as
last argument to make sure it is not an SSA_NAME, but as the testcases show,
that is not enough, SSA_NAME temporaries created during that gimplification
can be reused too and we can't allow SSA_NAMEs to be used across OpenMP
region boundaries, as we can only firstprivatize decls.
Fixed by temporarily disabling into_ssa.
2021-02-10 Jakub Jelinek <jakub@redhat.com>
PR middle-end/99007
* gimplify.c (gimplify_scan_omp_clauses): For MEM_REF on reductions,
temporarily disable gimplify_ctxp->into_ssa around gimplify_expr
calls.
* g++.dg/gomp/pr99007.C: New test.
* gcc.dg/gomp/pr99007-1.c: New test.
* gcc.dg/gomp/pr99007-2.c: New test.
* gcc.dg/gomp/pr99007-3.c: New test.
Jakub Jelinek [Fri, 5 Feb 2021 09:22:07 +0000 (10:22 +0100)]
c++: Fix ICE with structured binding initialized to incomplete array [PR97878]
We ICE on the following testcase, for incomplete array a on auto [b] { a }; without
giving any kind of diagnostics, with auto [c] = a; during error-recovery.
The problem is that we get too far through check_initializer and e.g.
store_init_value -> constexpr stuff can't deal with incomplete array types.
As the type of the structured binding artificial variable is always deduced,
I think it is easiest to diagnose this early, even if they have array types
we'll need their deduced type to be complete rather than just its element
type.
2021-02-05 Jakub Jelinek <jakub@redhat.com>
PR c++/97878
* decl.c (check_array_initializer): For structured bindings, require
the array type to be complete.
git://gcc.gnu.org / gcc.git / log