This just replies with "OK".
c++tools/ChangeLog:
* resolver.cc (module_resolver::ModuleCompiledRequest):
Add a simple handler.
* resolver.h: Declare handler for ModuleCompiledRequest.
Fwprop will happily optimize two xxsetaccz instructions into one xxsetaccz
by propagating the results of the first to the uses of the second.
We really don't want that to happen given the late priming/depriming of
accumulators. I fixed this by making the xxsetaccz source operand an
unspec volatile. I also removed the mma_xxsetaccz define_expand and
define_insn_and_split and replaced it with a simple define_insn.
The expand and splitter patterns were leftovers from the pre opaque mode
code when the xxsetaccz code was part of the movpxi pattern, and we don't
need them now.
Rather than a new test case, I was able to just modify the current test case
to add another __builtin_mma_xxsetaccz call which shows the bad code gen
with unpatched compilers.
2021-09-14 Peter Bergner <bergner@linux.ibm.com>
gcc/
* config/rs6000/mma.md (unspec): Delete UNSPEC_MMA_XXSETACCZ.
(unspecv): Add UNSPECV_MMA_XXSETACCZ.
(*mma_xxsetaccz): Delete.
(mma_xxsetaccz): Change to define_insn. Remove operand 1.
Use UNSPECV_MMA_XXSETACCZ. Update comment.
* config/rs6000/rs6000.c (rs6000_rtx_costs): Use UNSPECV_MMA_XXSETACCZ.
gcc/testsuite/
* gcc.target/powerpc/mma-builtin-6.c: Add second call to xxsetacc
built-in. Update instruction counts.
The executables for GCC's c-family compilers must be built with no-PIE
because they use PCH and the current model for this requires that the
exe is always lauched at the same address. Since the other language
compilers share code with the c-family this constraint is also applied
to them.
However, the executables that run on $build (generators, and parsers
for md and def files) need not have any such constraint they do not
consume PCH files.
This change simplifies the configuration and Makefile content by
removing the code enforcing no-PIE on these exes. This also fixes a
bootstrap issue with some Darwin versions and clang as the bootstrap
compiler, where -no-PIE causes the correct relocation model to be
switched off leading to invalid user-space code.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/ChangeLog:
* Makefile.in: Remove variables related to applying no-PIE
to the exes on $build.
* configure: Regenerate.
* configure.ac: Remove configuration related to applying
no-PIE to the exes on $build.
This adds top level proxy variables for the coroutine frame
copies of the original function args. These are then available
in the debugger to refer to the frame copies. We rewrite the
function body to use the copies, since the original parms will
no longer be in scope when the coroutine is running.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/cp/ChangeLog:
* coroutines.cc (struct param_info): Add copy_var.
(build_actor_fn): Use simplified param references.
(register_param_uses): Likewise.
(rewrite_param_uses): Likewise.
(analyze_fn_parms): New function.
(coro_rewrite_function_body): Add proxies for the fn
parameters to the outer bind scope of the rewritten code.
(morph_fn_to_coro): Use simplified version of param ref.
In the process of transforming a coroutine into the separate representation
as the ramp function and a state machine, we generate some variables that
are of interest to a user during debugging. Any variable that is persistent
for the execution of the coroutine is placed into the coroutine frame.
In particular:
The promise object.
The function pointers for the resumer and destroyer.
The current resume index (suspend point).
The handle that represents this coroutine 'self handle'.
Any handle provided for a continuation coroutine.
Whether the coroutine frame is allocated and needs to be freed.
Visibility of some of these has already been requested by end users.
This patch ensures that such variables have names that are usable in a
debugger, but are in the reserved namespace for the implementation (they
all begin with _Coro_). The identifiers are generated lazily when the
first coroutine is encountered.
We place the variables into the outermost bind expression and then add a
DECL_VALUE_EXPR to each that points to the frame entry.
These changes simplify the handling of the variables in the body of the
function (in particular, the use of the DECL_VALUE_EXPR means that we now
no longer need to rewrite proxies for the promise and coroutine handles into
the frame->offset form).
Partial improvement to debugging (PR c++/99215).
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/cp/ChangeLog:
* coroutines.cc (coro_resume_fn_id, coro_destroy_fn_id,
coro_promise_id, coro_frame_needs_free_id, coro_resume_index_id,
coro_self_handle_id, coro_actor_continue_id,
coro_frame_i_a_r_c_id): New.
(coro_init_identifiers): Initialize new name identifiers.
(coro_promise_type_found_p): Use pre-built identifiers.
(struct await_xform_data): Remove unused fields.
(transform_await_expr): Delete code that is now unused.
(build_actor_fn): Simplify interface, use pre-built identifiers and
remove transforms that are no longer needed.
(build_destroy_fn): Use revised field names.
(register_local_var_uses): Use pre-built identifiers.
(coro_rewrite_function_body): Simplify interface, use pre-built
identifiers. Generate proxy vars in the outer bind expr scope for the
implementation state that we wish to expose.
(morph_fn_to_coro): Adjust comments for new variable names, use pre-
built identifiers. Remove unused code to generate frame entries for
the implementation state. Adjust call for build_actor_fn.
Here, the union's constructor is defined to activate its empty data
member _M_rest, but during constexpr evaluation of this constructor the
subobject constructor call O::O(&_M_rest, 42) doesn't produce a side
effect that actually activates the member, so the union still appears
uninitialized after its constructor has run. This patch fixes this by
using a dummy MODIFY_EXPR in this situation, whose evaluation ensures
the member gets activated.
PR c++/102163
gcc/cp/ChangeLog:
* constexpr.c (cxx_eval_call_expression): After evaluating a
subobject constructor call for an empty union member, produce a
side effect that makes sure the member gets activated.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-empty17.C: New test.
The C FE updates DECL_*SIZE for vars which have initializers for flexible
array members for many years, but C++ FE kept DECL_*SIZE the same as the
type size (i.e. as if there were zero elements in the flexible array
member). This results e.g. in ELF symbol sizes being too small.
Note, if the flexible array member is initialized only with non-constant
initializers, we have a worse bug that this patch doesn't solve, the
splitting of initializers into constant and dynamic initialization removes
the initializer and we don't have just wrong DECL_*SIZE, but nothing is
emitted when emitting those vars into assembly either and so the dynamic
initialization clobbers other vars that may overlap the variable.
I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
flexible array member in that case.
2021-09-14 Jakub Jelinek <jakub@redhat.com>
PR c++/102295
* decl.c (layout_var_decl): For aggregates ending with a flexible
array member, add the size of the initializer for that member to
DECL_SIZE and DECL_SIZE_UNIT.
* g++.target/i386/pr102295.C: New test.
is_xible_helper returns error_mark_node (i.e. false from the traits)
for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early.
Unfortunately, as the testcase shows, that doesn't work on class templates
that haven't been instantiated yet, ABSTRACT_CLASS_TYPE_P for them is false
until it is instantiated, which is done when the routine later constructs
a dummy object with that type.
The following patch fixes this by calling complete_type first, so that
ABSTRACT_CLASS_TYPE_P test will work properly, while keeping the handling
of arrays with unknown bounds, or incomplete types where it is done
currently.
2021-09-14 Jakub Jelinek <jakub@redhat.com>
PR c++/102305
* method.c (is_xible_helper): Call complete_type on to.
* g++.dg/cpp0x/pr102305.C: New test.
This is a regression present on the mainline and 11 branch in the form of an
ICE for an enumeration type with a full signed representation for its size.
gcc/ada/
PR ada/101970
* exp_attr.adb (Expand_N_Attribute_Reference) <Attribute_Enum_Rep>:
Use an unchecked conversion instead of a regular conversion in the
enumeration case and remove Conversion_OK flag in the integer case.
<Attribute_Pos>: Remove superfluous test.
gcc/testsuite/
* gnat.dg/enum_rep2.adb: New test.
The ZOL pattern is missing modes which may lead to errors during
var_tracking. Add them.
gcc/
* config/arc/arc.md (doloop_end): Add missing mode.
(loop_end): Likewise.
Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>
The error is to be issued when objects of the type are declared instead.
gcc/ada/
* gcc-interface/decl.c (validate_size): Do not issue an error if the
old size has overflowed.
They should not be 0-based, unless the array type itself is.
gcc/ada/
* gcc-interface/decl.c (gnat_to_gnu_entity): For vector types, make
the representative array the debug type.
The change also makes small adjustments to warning messages for intrinsics.
gcc/ada/
* gcc-interface/decl.c (gnat_to_gnu_subprog_type): Turn variable
into constant. Capitalize GCC in warning message.
(intrin_arglists_compatible_p): Change parameter to pointer-to-const
Adjust warning messages. Turn warning into error for vector types.
(intrin_return_compatible_p): Likewise.
(intrin_profiles_compatible_p): Change parameter to pointer-to-const
This is necessary for vector builtins, which are picky about the
signedness of the element type.
gcc/ada/
* libgnat/s-atopri.ads (bool): Delete.
(Atomic_Test_And_Set): Replace bool with Boolean.
(Atomic_Always_Lock_Free): Likewise.
* libgnat/s-aoinar.adb (Is_Lock_Free): Adjust.
* libgnat/s-aomoar.adb (Is_Lock_Free): Likewise.
* libgnat/s-aotase.adb (Atomic_Test_And_Set): Likewise.
* libgnat/s-atopex.adb (Atomic_Compare_And_Exchange): Likewise.
* gcc-interface/decl.c: Include gimple-expr.h.
(intrin_types_incompatible_p): Delete.
(intrin_arglists_compatible_p): Call types_compatible_p.
(intrin_return_compatible_p): Likewise.
As discussed, the test tests atomics on doubles which are 64-bit and so we
should use sync_long_long effective target instead of sync_int_long that
covers 64-bit atomics only on 64-bit arches. I've added -march=pentium
to follow what is documented for sync_long_long, I guess -march=zarch should
be added for s390* too, but haven't tested that.
And using sync_long_long found a syntax error in that effective target
implementation, so I've fixed that too.
2021-09-14 Jakub Jelinek <jakub@redhat.com>
* c-c++-common/gomp/atomic-29.c: Add -march=pentium
dg-additional-options for ia32. Use sync_long_long effective target
instead of sync_int_long.
* lib/target-supports.exp (check_effective_target_sync_long_long): Fix
a syntax error.
This patch adds testing checks (goa_stabilize_expr with NULL pre_p) for more
tree codes, so that we don't gimplify their operands individually unless lhs
appears in them. Also, so that we don't have exponential compile time complexity
with the added checks, I've added a depth computation, we don't expect lhs
to be found in depth 8 or above as all the atomic forms must have x expression
in specific places in the expressions.
2021-09-14 Jakub Jelinek <jakub@redhat.com>
* gimplify.c (goa_stabilize_expr): Add depth argument, propagate
it to recursive calls, for depth above 7 just gimplify or return.
Perform a test even for MODIFY_EXPR, ADDR_EXPR, COMPOUND_EXPR with
__builtin_clear_padding and TARGET_EXPR.
(gimplify_omp_atomic): Adjust goa_stabilize_expr callers.
For consistency's sake with -Wall & -w, this makes -Werror imply -gnatwe.
gcc/ada/
PR ada/101385
* doc/gnat_ugn/building_executable_programs_with_gnat.rst
(-Wall): Minor fixes.
(-w): Likewise.
(-Werror): Document that it also sets -gnatwe by default.
* gcc-interface/lang-specs.h (ada): Expand -gnatwe if -Werror is
passed and move expansion of -gnatw switches to before -gnatez.
Recent compilers enforce more strictly the RM C.6(18) clause, which says
that volatile record types are by-reference types. This changes the typical
error message now given in these cases.
gcc/ada/
* gcc-interface/decl.c (gnat_to_gnu_entity) <is_type>: Declare new
constant. Adjust error message issued by validate_size in the case
of by-reference types.
(validate_size): Always use the error strings passed by the caller.
My C++17 hardware interference sizes patch caused a bogus warning on 32-bit
x86, where we have a default L1 cache line size of 0, and the front end
complained that the default constructive interference size of 64 was larger
than that.
gcc/cp/ChangeLog:
* decl.c (cxx_init_decl_processing): Don't warn if L1 cache line
size is smaller than maxalign.
gcc/fortran/ChangeLog:
PR fortran/82314
* decl.c (add_init_expr_to_sym): For proper initialization of
array-valued named constants the array bounds need to be
simplified before adding the initializer.
gcc/testsuite/ChangeLog:
PR fortran/82314
* gfortran.dg/pr82314.f90: New test.
gcc/fortran/ChangeLog:
PR fortran/85130
* expr.c (find_substring_ref): Handle given substring start and
end indices as signed integers, not unsigned.
gcc/testsuite/ChangeLog:
PR fortran/85130
* gfortran.dg/substr_6.f90: Revert commit r8-7574, adding again
test that was erroneously considered as illegal.
This resolves PR101574 "gcc/sparseset.h:215:20: error: suggest parentheses
around assignment used as truth value [-Werror=parentheses]", as (bogusly)
reported at commit a61f6afbee370785cf091fe46e2e022748528307:
In file included from [...]/source-gcc/gcc/lra-lives.c:43:
[...]/source-gcc/gcc/lra-lives.c: In function ‘void make_hard_regno_dead(int)’:
[...]/source-gcc/gcc/sparseset.h:215:20: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
215 | && (((ITER) = sparseset_iter_elm (SPARSESET)) || 1); \
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]/source-gcc/gcc/lra-lives.c:304:3: note: in expansion of macro ‘EXECUTE_IF_SET_IN_SPARSESET’
304 | EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, i)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc/
PR bootstrap/101574
* diagnostic-spec.c (warning_suppressed_at, copy_warning): Handle
'RESERVED_LOCATION_P' locations.
* warning-control.cc (get_nowarn_spec, suppress_warning)
(copy_warning): Likewise.
To make it obvious what exactly the key type is. No change in behavior.
gcc/
* diagnostic-spec.h (typedef xint_hash_t): Use 'location_t' instead of...
(typedef key_type_t): ... this. Remove.
(nowarn_map): Document.
* diagnostic-spec.c (nowarn_map): Likewise.
* warning-control.cc (convert_to_key): Evolve functions into...
(get_location): ... these. Adjust all users.
The last missing piece of the C++17 standard library is the hardware
intereference size constants. Much of the delay in implementing these has
been due to uncertainty about what the right values are, and even whether
there is a single constant value that is suitable; the destructive
interference size is intended to be used in structure layout, so program
ABIs will depend on it.
In principle, both of these values should be the same as the target's L1
cache line size. When compiling for a generic target that is intended to
support a range of target CPUs with different cache line sizes, the
constructive size should probably be the minimum size, and the destructive
size the maximum, unless you are constrained by ABI compatibility with
previous code.
From discussion on gcc-patches, I've come to the conclusion that the
solution to the difficulty of choosing stable values is to give up on it,
and instead encourage only uses where ABI stability is unimportant: in
particular, uses where the ABI is shared at most between translation units
built at the same time with the same flags.
To that end, I've added a warning for any use of the constant value of
std::hardware_destructive_interference_size in a header or module export.
Appropriate uses within a project can disable the warning.
A previous iteration of this patch included an -finterference-tune flag to
make the value vary with -mtune; this iteration makes that the default
behavior, which should be appropriate for all reasonable uses of the
variable. The previous default of "stable-ish" seems to me likely to have
been more of an attractive nuisance; since we can't promise actual
stability, we should instead make proper uses more convenient.
JF Bastien's implementation proposal is summarized at
https://github.com/itanium-cxx-abi/cxx-abi/issues/74
I implement this by adding new --params for the two sizes. Targets can
override these values in targetm.target_option.override() to support a range
of values for the generic target; otherwise, both will default to the L1
cache line size.
64 bytes still seems correct for all x86.
I'm not sure why he proposed 64/64 for generic 32-bit ARM, since the Cortex
A9 has a 32-byte cache line, so I'd think 32/64 would make more sense.
He proposed 64/128 for generic AArch64, but since the A64FX now has a 256B
cache line, I've changed that to 64/256.
Other arch maintainers are invited to set ranges for their generic targets
if that seems better than using the default cache line size for both values.
With the above choice to reject stability as a goal, getting these values
"right" is now just a matter of what we want the default optimization to be,
and we can feel free to adjust them as CPUs with different cache lines
become more and less common.
gcc/ChangeLog:
* params.opt: Add destructive-interference-size and
constructive-interference-size.
* doc/invoke.texi: Document them.
* config/aarch64/aarch64.c (aarch64_override_options_internal):
Set them.
* config/arm/arm.c (arm_option_override): Set them.
* config/i386/i386-options.c (ix86_option_override_internal):
Set them.
gcc/c-family/ChangeLog:
* c.opt: Add -Winterference-size.
* c-cppbuiltin.c (cpp_atomic_builtins): Add __GCC_DESTRUCTIVE_SIZE
and __GCC_CONSTRUCTIVE_SIZE.
gcc/cp/ChangeLog:
* constexpr.c (maybe_warn_about_constant_value):
Complain about std::hardware_destructive_interference_size.
(cxx_eval_constant_expression): Call it.
* decl.c (cxx_init_decl_processing): Check
--param *-interference-size values.
libstdc++-v3/ChangeLog:
* include/std/version: Define __cpp_lib_hardware_interference_size.
* libsupc++/new: Define hardware interference size variables.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Winterference.H: New file.
* g++.dg/warn/Winterference.C: New test.
* g++.target/aarch64/interference.C: New test.
* g++.target/arm/interference.C: New test.
* g++.target/i386/interference.C: New test.
As mentioned in the PR, we do miss supports target micro-architectures
in target and target_clone attribute. While the levels
x86-64 x86-64-v2 x86-64-v3 x86-64-v4 are supported values by -march
option, they are actually only aliases for k8 CPU. That said, they are more
closer to __builtin_cpu_supports function and we decided to implement
it there.
PR target/101696
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (cpu_indicator_init): Add support
for x86-64 micro levels for __builtin_cpu_supports.
* common/config/i386/i386-cpuinfo.h (enum feature_priority):
Add priorities for the micro-arch levels.
(enum processor_features): Add new features.
* common/config/i386/i386-isas.h: Add micro-arch features.
* config/i386/i386-builtins.c (get_builtin_code_for_version):
Support the micro-arch levels by callsing
__builtin_cpu_supports.
* doc/extend.texi: Document that the levels are support by
__builtin_cpu_supports.
gcc/testsuite/ChangeLog:
* g++.target/i386/mv30.C: New test.
* gcc.target/i386/mvc16.c: New test.
* gcc.target/i386/builtin_target.c (CHECK___builtin_cpu_supports):
New.
Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
we are not going to error out. It fixes the problem by the removal
of the function from the IR.
OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
PR target/95969
* config/aarch64/aarch64-builtins.c (aarch64_fold_builtin_lane_check):
New function.
(aarch64_general_fold_builtin): Handle AARCH64_SIMD_BUILTIN_LANE_CHECK.
(aarch64_general_gimple_fold_builtin): Likewise.
gcc/testsuite/ChangeLog:
PR target/95969
* gcc.target/aarch64/lane-bound-1.c: New test.
* gcc.target/aarch64/lane-bound-2.c: New test.
m32r support never made it to glibc and the support for the Linux kernel
was removed with 4.18. It does not remove much but no reason to keep
around a port which never worked or one which the support in other
projects is gone.
OK? Checked to make sure m32r-linux and m32rle-linux were rejected
when building.
contrib/ChangeLog:
* config-list.mk: Remove m32r-linux and m32rle-linux
from the list.
gcc/ChangeLog:
* config.gcc: Add m32r-*-linux* and m32rle-*-linux*
to the Unsupported targets list.
Remove support for m32r-*-linux* and m32rle-*-linux*.
* config/m32r/linux.h: Removed.
* config/m32r/t-linux: Removed.
libgcc/ChangeLog:
* config.host: Remove m32r-*-linux* and m32rle-*-linux*.
* config/m32r/libgcc-glibc.ver: Removed.
* config/m32r/t-linux: Removed.
So right now liblto_plugin.so exports many libiberty symbols and
simple_object file symbols but really it just needs to export onload.
This fixes the problem by using "-export-symbols-regex onload" on
the libtool link line.
lto-plugin/ChangeLog:
PR lto/49664
* Makefile.am: Export only onload.
* Makefile.in: Regenerate.
In the testcase we generate invalid assembly for an SVE load predicate instruction.
The RTL for the insn is:
(insn 9 8 10 (set (reg:VNx16BI 68 p0)
(mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
(const_int 8 [0x8]))
(reg/f:DI 0 x0 [92])) [2 work_3(D)->array[offset_4(D)]+0 S8 A16]))
That addressing mode is not valid for the instruction [1] as it only accepts the addressing mode:
[<Xn|SP>{, #<imm>, MUL VL}]
This patch rejects the register index form for SVE predicate modes.
Bootstrapped and tested on aarch64-none-linux-gnu.
[1] https://developer.arm.com/documentation/ddi0602/2021-06/SVE-Instructions/LDR--predicate---Load-predicate-register-
gcc/ChangeLog:
PR target/102252
* config/aarch64/aarch64.c (aarch64_classify_address): Don't allow
register index for SVE predicate modes.
gcc/testsuite/ChangeLog:
PR target/102252
* g++.target/aarch64/sve/pr102252.C: New test.
Now that the jump thread back registry has been split into the generic
copier and the custom (old) copier, it becomes trivial to remove the
FSM bits from the jump threaders.
First, there's no need for an EDGE_FSM_THREAD type. The only reason
we were looking at the threading type was to determine what type of
copier to use, and now that the copier has been split, there's no need
to even look. However, there is one check in register_jump_thread
where we verify that only the generic copier can thread through
back-edges. I've removed that check in favor of a flag passed to the
constructor.
I've also removed all the FSM references from the code and tests.
Interestingly, some tests weren't even testing the right thing. They
were testing for "FSM" which would catch jump thread paths as well as
the backward threader *failing* on registering a path. *big eye roll*
The only remaining code that was actually checking for EDGE_FSM_THREAD
was adjust_paths_after_duplication, and the checks could be written
without looking at the edge type at all. For the record, the code
there is horrible: it's convoluted, hard to read, and doesn't have any
tests. I'd smack myself if I could go back in time.
All that remains are the FSM references in the --param's themselves.
I think we should s/fsm/threader/, since I envision a day when we can
share the cost basis code between the threaders. However, I don't
know what the proper procedure is for renaming existing compiler
options.
By the way, param_fsm_maximum_phi_arguments is no longer relevant
after the rewrite. We can nuke that one right away.
Tested on x86-64 Linux.
gcc/ChangeLog:
* tree-ssa-threadbackward.c
(back_threader_profitability::profitable_path_p): Remove FSM
references.
(back_threader_registry::register_path): Same.
* tree-ssa-threadedge.c
(jump_threader::simplify_control_stmt_condition): Same.
* tree-ssa-threadupdate.c (jt_path_registry::jt_path_registry):
Add backedge_threads argument.
(fwd_jt_path_registry::fwd_jt_path_registry): Pass
backedge_threads argument.
(back_jt_path_registry::back_jt_path_registry): Same.
(dump_jump_thread_path): Adjust for FSM removal.
(back_jt_path_registry::rewire_first_differing_edge): Same.
(back_jt_path_registry::adjust_paths_after_duplication): Same.
(back_jt_path_registry::update_cfg): Same.
(jt_path_registry::register_jump_thread): Same.
* tree-ssa-threadupdate.h (enum jump_thread_edge_type): Remove
EDGE_FSM_THREAD.
(class back_jt_path_registry): Add backedge_threads to
constructor.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr21417.c: Adjust for FSM removal.
* gcc.dg/tree-ssa/pr66752-3.c: Same.
* gcc.dg/tree-ssa/pr68198.c: Same.
* gcc.dg/tree-ssa/pr69196-1.c: Same.
* gcc.dg/tree-ssa/pr70232.c: Same.
* gcc.dg/tree-ssa/pr77445.c: Same.
* gcc.dg/tree-ssa/ranger-threader-4.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-18.c: Same.
* gcc.dg/tree-ssa/ssa-dom-thread-6.c: Same.
* gcc.dg/tree-ssa/ssa-thread-12.c: Same.
* gcc.dg/tree-ssa/ssa-thread-13.c: Same.
Here when partially instantiating the first pack expansion, substitution
into the condition of the constexpr if yields a still-dependent tree, so
tsubst_expr returns an IF_STMT with an unsubstituted IF_COND and with
IF_STMT_EXTRA_ARGS added to. Hence after partial instantiation the pack
expansion pattern still refers to the unlowered parameter pack 'ts' of
level 2, and it's thusly recorded in the new PACK_EXPANSION_PARAMETER_PACKS.
During the subsequent final instantiation of the regenerated lambda we
crash in tsubst_pack_expansion because it can't find an argument pack
for this unlowered 'ts', due to the level mismatch. (Likewise when the
constexpr if is replaced by a requires-expr, which also uses the extra
args mechanism for avoiding partial instantiation.)
So essentially, a pack expansion pattern that contains an "extra args"
tree doesn't play well with partial instantiation. This patch fixes
this by forcing such pack expansions to use the extra args mechanism as
well.
PR c++/101764
gcc/cp/ChangeLog:
* cp-tree.h (PACK_EXPANSION_FORCE_EXTRA_ARGS_P): New accessor
macro.
* pt.c (has_extra_args_mechanism_p): New function.
(find_parameter_pack_data::found_extra_args_tree_p): New data
member.
(find_parameter_packs_r): Set ppd->found_extra_args_tree_p
appropriately.
(make_pack_expansion): Set PACK_EXPANSION_FORCE_EXTRA_ARGS_P if
ppd.found_extra_args_tree_p.
(use_pack_expansion_extra_args_p): Return true if there were
unsubstituted packs and PACK_EXPANSION_FORCE_EXTRA_ARGS_P.
(tsubst_pack_expansion): Pass the pack expansion to
use_pack_expansion_extra_args_p.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-if35.C: New test.
GCC Administrator
Harald Anlauf
Iain Sandoe
Peter Bergner
Patrick Palka
Jakub Jelinek
Tobias Burnus
Martin Liska
Eric Botcazou
Claudiu Zissulescu
liuhongt
Jason Merrill
Thomas Schwinge
Andrew Pinski
Kyrylo Tkachov
Aldy Hernandez
H.J. Lu