where the shift count operand does not trivially fit the scheme of
address operands. Reject those operands, especially since
strip_address_mutations() expects expressions of the form
(and ... (const_int ...)) and fails for (and ... (const_wide_int ...)).
Thus, be more strict here and accept only CONST_INT operands. Done by
replacing immediate_operand() with const_int_operand() which is enough
since the former only additionally checks for LEGITIMATE_PIC_OPERAND_P
and targetm.legitimate_constant_p which are always true for CONST_INT
operands.
While on it, fix indentation of the if block.
gcc/ChangeLog:
PR target/118835
* config/s390/s390.cc (s390_valid_shift_count): Reject shift
count operands which do not trivially fit the scheme of
address operands.
Richard Biener [Fri, 7 Feb 2025 13:42:23 +0000 (14:42 +0100)]
jit/118780 - make sure to include dlfcn.h when plugin support is disabled
The following makes the dlfcn.h explicitly requested which avoids
build failure when JIT is enabled but plugin support disabled as
currently the include is conditional on plugin support.
PR jit/118780
gcc/
* system.h: Check INCLUDE_DLFCN_H for including dlfcn.h instead
of ENABLE_PLUGIN.
* plugin.cc: Define INCLUDE_DLFCN_H.
Richard Biener [Mon, 3 Feb 2025 08:55:50 +0000 (09:55 +0100)]
tree-optimization/118717 - store commoning vs. abnormals
When we sink common stores in cselim or the sink pass we have to
make sure to not introduce overlapping lifetimes for abnormals
used in the ref. The easiest is to avoid sinking stmts which
reference abnormals at all which is what the following does.
PR tree-optimization/118717
* tree-ssa-phiopt.cc (cond_if_else_store_replacement_1):
Do not common stores referencing abnormal SSA names.
* tree-ssa-sink.cc (sink_common_stores_to_bb): Likewise.
Richard Biener [Wed, 8 Jan 2025 08:25:52 +0000 (09:25 +0100)]
tree-optimization/117979 - failed irreducible loop update from DCE
When CD-DCE creates forwarders to reduce false control dependences
it fails to update the irreducible state of edge and the forwarder
block in case the fowarder groups both normal (entry) and edges
from an irreducible region (necessarily backedges). This is because
when we split the first edge, if that's a normal edge, the forwarder
and its edge to the original block will not be marked as part
of the irreducible region but when we then redirect an edge from
within the region it becomes so.
The following fixes this up.
Note I think creating a forwarder that includes backedges is
likely not going to help, but at this stage I don't want to change
the CFG going into DCE. For regular loops we'll have a single
entry and a single backedge by means of loop init and will never
create a forwarder - so this is solely happening for irreducible
regions where it's harder to prove that such forwarder doesn't help.
PR tree-optimization/117979
* tree-ssa-dce.cc (make_forwarders_with_degenerate_phis):
Properly update the irreducible region state.
Richard Biener [Mon, 3 Feb 2025 14:12:52 +0000 (15:12 +0100)]
tree-optimization/117113 - ICE with unroll-and-jam
When there's an inner loop without virtual header PHI but the outer
loop has one the fusion process cannot handle the need to create
an inner loop virtual header PHI. Punt in this case.
PR tree-optimization/117113
* gimple-loop-jam.cc (unroll_jam_possible_p): Detect when
we cannot handle virtual SSA update.
Richard Biener [Mon, 3 Feb 2025 13:27:01 +0000 (14:27 +0100)]
lto/113207 - fix free_lang_data_in_type
When we process function types we strip volatile and const qualifiers
after building a simplified type variant (which preserves those).
The qualified type handling of both isn't really compatible, so avoid
bad interaction by swapping this, first dropping const/volatile
qualifiers and then building the simplified type thereof.
PR lto/113207
* ipa-free-lang-data.cc (free_lang_data_in_type): First drop
const/volatile qualifiers from function argument types,
then build a simplified type.
but since r106 is used we wrongly materialize it using a subreg:
modifying insn i3 10: r106:V4QI=r109:V4SI#0
which of course does not work for modes with more than one component,
specifically vector and complex modes.
PR rtl-optimization/118662
* combine.cc (try_combine): When re-materializing a load
from an extended reg by a lowpart subreg make sure we're
not dealing with vector or complex modes.
Richard Biener [Tue, 28 Jan 2025 11:28:14 +0000 (12:28 +0100)]
tree-optimization/117424 - invalid LIM of trapping ref
The following addresses a bug in tree_could_trap_p leading to
hoisting of a possibly trapping, because of out-of-bound, access.
We only ensured the first accessed byte is within a decl there,
the patch makes sure the whole base of the reference is within it.
This is pessimistic if a handled component would then subset to
a sub-object within the decl but upcasting of a decl to larger
types should be uncommon, questionable, and wrong without
-fno-strict-aliasing.
The testcase is a bit fragile, but I could not devise a (portable)
way to ensure an out-of-bound access to a decl would fault.
PR tree-optimization/117424
* tree-eh.cc (tree_could_trap_p): Verify the base is
fully contained within a decl.
Richard Biener [Tue, 1 Oct 2024 08:37:16 +0000 (10:37 +0200)]
tree-optimization/116906 - unsafe PRE with never executed edges
When we're computing ANTIC for PRE we treat edges to not yet visited
blocks as having a maximum ANTIC solution to get at an optimistic
solution in the iteration. That assumes the edges visted eventually
execute. This is a wrong assumption that can lead to wrong code
(and not only non-optimality) when possibly trapping expressions
are involved as the testcases in the PR show. The following mitigates
this by pruning trapping expressions from ANTIC computed when
maximum sets are involved.
PR tree-optimization/116906
* tree-ssa-pre.cc (prune_clobbered_mems): Add clean_traps
argument.
(compute_antic_aux): Direct prune_clobbered_mems to prune
all traps when any MAX solution was involved in the ANTIC
computation.
(compute_partial_antic_aux): Adjust.
* gcc.dg/pr116906-1.c: New testcase.
* gcc.dg/pr116906-2.c: Likewise.
Richard Biener [Wed, 15 Jan 2025 13:31:57 +0000 (14:31 +0100)]
tree-optimization/115494 - PRE PHI translation and ranges
When we PHI translate dependent expressions we keep SSA defs in
place of the translated expression in case the expression itself
did not change even though it's context did and thus the validity
of ranges associated with it. That eventually leads to simplification
errors given we violate the precondition that used SSA defs fed to
vn_valueize are valid to use (including their associated ranges).
The following makes sure to replace those with new representatives
always, not only when the dependent expression translation changed it.
The fix was originally discovered by Michael Morin.
PR tree-optimization/115494
* tree-ssa-pre.cc (phi_translate_1): Always generate a
representative for translated dependent expressions.
Richard Biener [Wed, 29 Jan 2025 12:25:14 +0000 (13:25 +0100)]
tree-optimization/114052 - consider infinite sub-loops when lowering iter bound
When we walk stmts to find always executed stmts with UB in the last
iteration to be able to reduce the iteration count by one we fail
to consider infinite subloops in the last iteration that would make
such stmt not execute. The following adds this.
PR tree-optimization/114052
* tree-ssa-loop-niter.cc (maybe_lower_iteration_bound): Check
for infinite subloops we might not exit.
Richard Biener [Thu, 23 Jan 2025 12:10:17 +0000 (13:10 +0100)]
tree-optimization/112859 - bogus loop distribution
When we get a zero distance vector we still have to check for the
situation of a common inner loop with zero distance. But we can
still allow a zero distance for the loop we distribute
(gcc.dg/tree-ssa/ldist-33.c is such a case). This is because
zero distances in non-outermost loops are a misrepresentation
of dependence by dependence analysis.
Note that test coverage of loop distribution of loop nests is
very low.
PR tree-optimization/112859
PR tree-optimization/115347
* tree-loop-distribution.cc
(loop_distribution::pg_add_dependence_edges): For a zero
distance vector still make sure to not have an inner
loop with zero distance.
* gcc.dg/torture/pr112859.c: New testcase.
* gcc.dg/torture/pr115347.c: Likewise.
Harald Anlauf [Sat, 15 Feb 2025 19:36:15 +0000 (20:36 +0100)]
Fortran: passing of derived type to VALUE,OPTIONAL dummy argument [PR118080]
For scalar OPTIONAL dummy arguments with the VALUE attribute, gfortran
passes a hidden flag to denote presence or absence of the actual argument
for intrinsic types. Extend this treatment to derived type (user-defined
as well as from intrinsic module ISO_C_BINDING).
PR fortran/118080
gcc/fortran/ChangeLog:
* gfortran.texi: Adjust documentation.
* trans-decl.cc (create_function_arglist): Adjust to pass hidden
presence flag also for derived type dummies with VALUE,OPTIONAL
attribute.
* trans-expr.cc (gfc_conv_expr_present): Expect hidden presence
flag also for derived type dummies with VALUE,OPTIONAL attribute.
(conv_cond_temp): Adjust to allow derived types.
(conv_dummy_value): Extend to handle derived type dummies with
VALUE,OPTIONAL attribute.
(gfc_conv_procedure_call): Adjust for actual arguments passed to
derived type dummies with VALUE,OPTIONAL attribute.
* trans-types.cc (gfc_get_function_type): Adjust fndecl for
hidden presence flag.
Lulu Cheng [Wed, 12 Feb 2025 06:29:58 +0000 (14:29 +0800)]
LoongArch: Fix the issue of function jump out of range caused by crtbeginS.o [PR118844].
Due to the presence of R_LARCH_B26 in
/usr/lib/gcc/loongarch64-linux-gnu/14/crtbeginS.o, its addressing
range is [PC-128MiB, PC+128MiB-4]. This means that when the code
segment size exceeds 128MB, linking with lld will definitely fail
(ld will not fail because the order of the two is different).
Andreas Tobler [Sun, 9 Jun 2024 21:18:04 +0000 (23:18 +0200)]
FreeBSD: Stop linking _p libs for -pg as of FreeBSD 14
As of FreeBSD version 14, FreeBSD no longer provides profiled system
libraries like libc_p and libpthread_p. Stop linking against them if
the FreeBSD major version is 14 or more.
gcc:
* config/freebsd-spec.h: Change fbsd-lib-spec for FreeBSD > 13,
do not link against profiled system libraries if -pg is invoked.
Add a define to note about this change.
* config/aarch64/aarch64-freebsd.h: Use the note to inform if
-pg is invoked on FreeBSD > 13.
* config/arm/freebsd.h: Likewise.
* config/i386/freebsd.h: Likewise.
* config/i386/freebsd64.h: Likewise.
* config/riscv/freebsd.h: Likewise.
* config/rs6000/freebsd64.h: Likewise.
* config/rs6000/sysv4.h: Likeise.
Haochen Jiang [Tue, 11 Feb 2025 03:29:34 +0000 (11:29 +0800)]
i386: Deprecate -m[no-]avx10.1 and make -mno-avx10.1-512 to disable the whole AVX10.1
Based on the feedback we got, we would like to re-alias avx10.x to 512
bit in the future. This leaves the current avx10.1 alias to 256 bit
inconsistent. Since it has been there for GCC 14.1 and GCC 14.2,
we decide to deprecate avx10.1 alias. The current proposal is not
adding it back in the future, but it might change if necessary.
For -mno- options, it is confusing what it is disabling when it comes
to avx10. Since there is barely usage enabling AVX10 with 512 bit
then disabling it, we will only provide -mno-avx10.x options in the
future, disabling the whole AVX10.x. If someone really wants to disable
512 bit after enabling it, -mavx10.x-512 -mno-avx10.x -mavx10.x-256 is
the only way to do that since we also do not want to break the usual
expression on -m- options enabling everything mentioned.
However, for avx10.1, since we deprecated avx10.1, there is no reason
we should have -mno-avx10.1. Thus, we need to keep -mno-avx10.1-[256,512].
To avoid confusion, we will make -mno-avx10.1-512 to disable the
whole AVX10.1 set to match the future -mno-avx10.x.
Haochen Jiang [Mon, 10 Feb 2025 08:53:27 +0000 (16:53 +0800)]
i386: Do not check vector size conflict when AVX512 is not explicitly set [PR 118815]
When AVX512 is not explicitly set, we should not take EVEX512 bit into
consideration when checking vector size. It will solve the intrin header
file reporting warnings when compiling with -Wsystem-headers.
However, there is side effect on the usage for '-march=xxx -mavx10.1-256',
where xxx is with AVX512. It will not report warning on vector size for now.
Since it is a rare usage, we will take it.
gcc/ChangeLog:
PR target/118815
* config/i386/i386-options.cc (ix86_option_override_internal):
Do not check vector size conflict when AVX512 is not explicitly
set.
Gaius Mulley [Fri, 14 Feb 2025 19:17:02 +0000 (19:17 +0000)]
[PATCH] PR modula2/118761: gm2 driver doesnt behave as gcc for -fhelp=BLA
This patch enables the gm2 driver to handle -fsyntax-only -fhelp=optimizers,
for example, correctly without terminating with gm2: fatal error:
no input files.
gcc/m2/ChangeLog:
PR modula2/118761
* gm2spec.cc (lang_specific_driver): Add case clauses for
OPT__help, OPT__help_ set in_added_libraries to 0 and early
return.
Marek Polacek [Tue, 26 Nov 2024 19:37:21 +0000 (14:37 -0500)]
driver: -fhardened and -z lazy/-z norelro [PR117739]
As the manual states, using "-fhardened -fstack-protector" will produce
a warning because -fhardened wants to enable -fstack-protector-strong,
but it can't since it's been overriden by the weaker -fstack-protector.
-fhardened also attempts to enable -Wl,-z,relro,-z,now. By the same
logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should
produce the same warning. But we don't detect this combination, so
this patch fixes it. I also renamed a variable to better reflect its
purpose.
Also don't check warn_hardened in process_command, since it's always
true there.
Also tweak wording in the manual as Jon Wakely suggested on IRC.
PR driver/117739
gcc/ChangeLog:
* doc/invoke.texi: Tweak wording for -Whardened.
* gcc.cc (driver_handle_option): If -z lazy or -z norelro was
specified, don't enable linker hardening.
(process_command): Don't check warn_hardened.
gcc/testsuite/ChangeLog:
* c-c++-common/fhardened-16.c: New test.
* c-c++-common/fhardened-17.c: New test.
* c-c++-common/fhardened-18.c: New test.
* c-c++-common/fhardened-19.c: New test.
* c-c++-common/fhardened-20.c: New test.
* c-c++-common/fhardened-21.c: New test.
Gaius Mulley [Thu, 13 Feb 2025 18:17:17 +0000 (18:17 +0000)]
[PATCH] PR modula2/115112 Incorrect line debugging information occurs during INC builtin
This patch fixes location bugs in BuildDecProcedure,
BuildIncProcedure, BuildInclProcedure, BuildExclProcedure and
BuildThrow. All these procedure functions use the token position
passed as a parameter (rather than from the quad stack). It also
fixes location bugs in CheckRangeIncDec to ensure that the token
position is stored on the quad stack before calling subsidiary
procedure functions.
gcc/m2/ChangeLog:
PR modula2/115112
* gm2-compiler/M2Quads.mod (BuildPseudoProcedureCall): Pass
tokno to each build procedure.
(BuildThrowProcedure): New parameter functok.
(BuildIncProcedure): New parameter proctok.
Pass proctok on the quad stack during every push.
(BuildDecProcedure): Ditto.
(BuildInclProcedure): New parameter proctok.
(BuildExclProcedure): New parameter proctok.
gcc/testsuite/ChangeLog:
PR modula2/115112
* gm2/pim/run/pass/dectest.mod: New test.
* gm2/pim/run/pass/inctest.mod: New test.
Nathaniel Shead [Wed, 12 Feb 2025 12:07:43 +0000 (23:07 +1100)]
c++: Constrain visibility for CNTTPs with internal types [PR118849]
While looking into PR118846 I noticed that we don't currently constrain
the linkage of functions involving CNTTPs of internal-linkage types. It
seems to me that this would be sensible to do.
PR c++/118849
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r): Constrain visibility according to
the type of decl_constant_var_p decls.
This patch builds access to the gcc builtins clz, clzl, clzll,
ctz, ctzl and ctzll within m2builtins.cc. The patch provides
modula2 api access to clz, clzll, ctz and ctzll though the
Builtins definition module. This PR was raised because of
PR118689.
Haochen Jiang [Mon, 10 Feb 2025 06:00:57 +0000 (14:00 +0800)]
i386: Fix AVX512BW intrin header with __OPTIMIZE__ [PR 118813]
When moving intrins around for AVX10 implementation in GCC 14,
the intrin _kshiftli_mask32 and _kshiftri_mask32 are wrongly
wrapped by "#if __OPTIMIZE__" instead of "#ifdef __OPTIMIZE__",
leading to the intrin file not `-Wsystem-headers -Wundef` clean
since r14-4490.
Jakub Jelinek [Sat, 8 Feb 2025 07:54:31 +0000 (08:54 +0100)]
i386: Fix ICE with conditional QI/HI vector maxmin [PR118776]
The following testcase ICEs starting with GCC 12 since r12-4526
although the bug has been introduced already in r12-2751.
The problem was in the addition of cond_<code><mode> define_expand
which uses nonimmediate_operand predicates for both maxmin operands
for all VI1248_AVX512VLBW modes. It works fine with
VI48_AVX512VL modes because the <code><mode>3_mask VI48_AVX512VL
define_expand uses ix86_fixup_binary_operands_no_copy and the
*avx512f_<code><mode>3<mask_name> VI48_AVX512VL define_insn uses
% in constraint and !(MEM_P && MEM_P) check in condition (and
<code><mode>3 define_expand with VI124_256_AVX512F_AVX512BW iterator
does that too), but eventhough the 8-bit and 16-bit element maxmin
is commutative too, the <mask_codefor><code><mode>3<mask_name>
define_insn with VI12_AVX512VL iterator didn't use % in constraint
to make it commutative. So, e.g. cond_umaxv32qi define_expand
allowed nonimmediate_operand for both umax operands, but used
gen_umaxv32qi_mask which wasn't commutative and only allowed
nonimmediate_operand for the second operand.
The following patch fixes it by keeping the <code><mode>3
VI124_256_AVX512F_AVX512BW define_expand as is (it does
ix86_fixup_binary_operands_no_copy) but extending the
<code><mode>3_mask define_expand from VI48_AVX512VL to
VI1248_AVX512VLBW which keeps the current modes with their
ISA conditions and adds the VI12_AVX512VL modes under additional
TARGET_AVX512BW condition, and turning the actual define_insn
into an * prefixed name (which it was before just for the non-masked
case) and having the same commutative operand handling as in other
define_insns.
2025-02-08 Jakub Jelinek <jakub@redhat.com>
PR target/118776
* config/i386/sse.md (<code><mode>3_mask): Use VI1248_AVX512VLBW
iterator rather than VI48_AVX512VL.
(<mask_codefor><code><mode>3<mask_name>): Rename to ...
(*avx512bw_<code><mode>3<mask_name>): ... this. Use
nonimmediate_operand rather than register_operand predicate and %v
rather than v constraint for operand 1 and adjust condition to reject
MEMs in both operand 1 and 2.
Jakub Jelinek [Fri, 7 Feb 2025 16:08:39 +0000 (17:08 +0100)]
c++: Fix up name independent decl in structured binding handling in range for [PR115586]
cp_parser_range_for temporarily reverts IDENTIFIER_BINDING changes
to hide the decls from the structured bindings from lookup during
parsing of the expression after :
If there are 2 or more name independent decls, we undo IDENTIFIER_BINDING
for the same name multiple times, even when just one has been added
(with a TREE_LIST inside of it as decl).
The following patch fixes it by handling the _ name at most once, the
later loop will DTRT then and just reinstall the temporarily hidden
binding with the TREE_LIST in there.
2025-02-07 Jakub Jelinek <jakub@redhat.com>
PR c++/115586
* parser.cc (cp_parser_range_for): For name independent decls in
structured bindings, only push the name/binding once per
structured binding.
* g++.dg/cpp26/name-independent-decl9.C: New test.
* g++.dg/cpp26/name-independent-decl10.C: New test.
Jakub Jelinek [Fri, 7 Feb 2025 13:30:11 +0000 (14:30 +0100)]
c++: Don't use CLEANUP_EH_ONLY for new expression cleanup [PR118763]
The following testcase is miscompiled since r12-6325 stopped
preevaluating the initializers for new expression.
If evaluating the initializers throws, there is a correct cleanup
for that, but it is marked CLEANUP_EH_ONLY. While in standard
C++ that is just fine, if it has statement expressions, it can
return or goto out of the expression and we should delete the
pointer in that case too.
There is already a sentry variable initialized to true and
set to false after everything is initialized and used as a guard
for the cleanup, so just removing the CLEANUP_EH_ONLY flag does
everything we need. And in the normal case of the initializer
not using statement expressions at least with -O2 we get the same code,
while the change changes one
try { sentry = true; ... sentry = false; } catch { if (sentry) delete ...; }
into
try { sentry = true; ... sentry = false; } finally { if (sentry) delete ...; }
optimizations will see that sentry is false when reaching the finally
other than through an exception.
Though, wonder what other CLEANUP_EH_ONLY cleanups might be an issue
with statement expressions.
2025-02-07 Jakub Jelinek <jakub@redhat.com>
PR c++/118763
* init.cc (build_new_1): Don't set CLEANUP_EH_ONLY.
Jakub Jelinek [Fri, 7 Feb 2025 13:27:18 +0000 (14:27 +0100)]
c++: Allow constexpr reads from volatile std::nullptr_t objects [PR118661]
As mentioned in the PR, https://eel.is/c++draft/conv.lval#note-1
says that even volatile reads from std::nullptr_t typed objects actually
don't read anything and https://eel.is/c++draft/expr.const#10.9
says that even those are ok in constant expressions.
So, the following patch adjusts the r9-4793 changes to have an exception
for NULLPTR_TYPE.
As [conv.lval]/3 also talks about accessing to inactive member, I've added
testcase to cover that as well.
2025-02-07 Jakub Jelinek <jakub@redhat.com>
PR c++/118661
* constexpr.cc (potential_constant_expression_1): Don't diagnose
lvalue-to-rvalue conversion of volatile lvalue if it has NULLPTR_TYPE.
* decl2.cc (decl_maybe_constant_var_p): Return true for constexpr
decls with NULLPTR_TYPE even if they are volatile.
* g++.dg/cpp0x/constexpr-volatile4.C: New test.
* g++.dg/cpp0x/constexpr-union9.C: New test.
Jakub Jelinek [Thu, 6 Feb 2025 14:39:18 +0000 (15:39 +0100)]
loop-iv, riscv: Fix get_biv_step_1 for RISC-V [PR117506]
The following test ICEs on RISC-V at least latently since r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
RISC-V specific case to get_biv_step_1 to recognize also
({zero,sign}_extend:DI (plus:SI op0 op1))
The reason for the ICE is that op1 in this case is CONST_POLY_INT
which unlike the really expected VOIDmode CONST_INTs has its own
mode and still satisfies CONSTANT_P.
GET_MODE (rhs) (SImode) is different from outer_mode (DImode), so
the function later does
*inner_step = simplify_gen_binary (code, outer_mode,
*inner_step, op1);
but that obviously ICEs because while *inner_step is either VOIDmode
or DImode, op1 has SImode.
The following patch fixes it by extending op1 using code so that
simplify_gen_binary can handle it. Another option would be
to change the !CONSTANT_P (op1) 3 lines above this to
!CONST_INT_P (op1), I think it isn't very likely that we get something
useful from other constants there.
2025-02-06 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/117506
* loop-iv.cc (get_biv_step_1): For {ZERO,SIGN}_EXTEND
of PLUS apply {ZERO,SIGN}_EXTEND to op1.
* gcc.dg/pr117506.c: New test.
* gcc.target/riscv/pr117506.c: New test.
Jakub Jelinek [Fri, 31 Jan 2025 23:50:24 +0000 (00:50 +0100)]
icf: Compare call argument types in certain cases and asm operands [PR117432]
compare_operand uses operand_equal_p under the hood, which e.g. for
INTEGER_CSTs will just match the values rather regardless of their types.
Now, in many comparing the type is redundant, if we have
x_2 = y_3 + 1;
we've already compared the type for the lhs and also for rhs1, there won't
be any surprises on rhs2.
As noted in the PR, there are cases where the type of the operand is the
sole place of information and we don't want to ICF merge functions if the
types differ.
One case is stdarg functions, arguments passed to ..., it is different
if we pass 1, 1L, 1LL.
Another case are the K&R unprototyped functions (sure, gone in C23).
And yet another case are inline asm operands, "r" (1) is different from "r"
(1L) from "r" (1LL).
So, the following patch determines based on lack of fntype (e.g. for
internal functions), or on !prototype_p, or on stdarg_p (in that case
using number of named arguments) which arguments need to have type checked
and does that, plus compares types on inline asm operands (maybe it would be
enough to do that just for input operands but we have just a routine to
handle both and I didn't feel we need to differentiate).
Furthermore, I've noticed fntype{1,2} isn't actually compared if it is a
direct call (gimple_call_fndecl is non-NULL). That is wrong too, we could
have
void (*fn) (int, long long) = (void (*) (int, long long)) foo;
fn (1, 1LL);
in one case and
void (*fn) (long long, int) = (void (*) (long long, int)) foo;
fn (1LL, 1);
in another, both folded into a direct call of foo with different
gimple_call_fntype. Sure, one of them would be UB at runtime (or both), but
what if we ICF merge it into something that into the one UB at runtime
and the program actually calls the correct one only?
2025-02-01 Jakub Jelinek <jakub@redhat.com>
PR ipa/117432
* ipa-icf-gimple.cc (func_checker::compare_asm_inputs_outputs):
Also return_false if operands have incompatible types.
(func_checker::compare_gimple_call): Check fntype1 vs. fntype2
compatibility for all non-internal calls and assume fntype1 and
fntype2 are non-NULL for those. For calls to non-prototyped
calls or for stdarg_p functions after the last named argument (if any)
check type compatibility of call arguments.
* gcc.c-torture/execute/pr117432.c: New test.
* gcc.target/i386/pr117432.c: New test.
Jakub Jelinek [Fri, 31 Jan 2025 10:02:41 +0000 (11:02 +0100)]
niter: Make build_cltz_expr more robust [PR118689]
Since my r15-7223 the niter analysis can recognize one loop during bootstrap
as being ctz like.
The patch just turned
@@ -2173,7 +2173,7 @@ PROC m2pim_NumberIO_BinToStr (CARDINAL x
_T535_44 = &buf[i.40_2]{lb: 1 sz: 4};
_T536_45 = x_21 & 1;
*_T535_44 = _T536_45;
- _T537_47 = x_21 / 2;
+ _T537_47 = x_21 >> 1;
x_48 = _T537_47;
# DEBUG x => x_48
if (x_48 != 0)
which is not a big deal for the number_of_iterations_cltz optimization, it
recognizes both right shift by 1 and unsigned division by 2 (and similarly
for clz left shift by 1 or multiplication by 2).
But starting with forwprop1 that change also resulted in
@@ -1875,9 +1875,9 @@ PROC m2pim_NumberIO_BinToStr (CARDINAL x
i.40_2 = (INTEGER) _T530_34;
_T536_45 = x_21 & 1;
MEM <CARDINAL[1:64]> [(CARDINAL *)&buf][i.40_2]{lb: 1 sz: 4} = _T536_45;
- _T537_47 = x_21 / 2;
+ _T537_47 = x_21 >> 1;
# DEBUG x => _T537_47
- if (x_21 > 1)
+ if (_T537_47 != 0)
goto <bb 3>; [INV]
else
goto <bb 8>; [INV]
and apparently it is only the latter form that number_of_iterations_cltz
pattern matches, not the former (after all, that was the exact reason
for r15-7223).
The problem is that build_cltz_expr assumes if IFN_C[LT]Z can't be used it
can use the __builtin_c[lt]z{,l,ll} builtins, and while most of the FEs do
create them, modula 2 does not.
The following patch just lets us punt if the FE doesn't build those builtins.
I've filed a PR against modula2 so that they add the builtins too.
2025-01-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118689
PR modula2/115032
* tree-ssa-loop-niter.cc (build_cltz_expr): Return NULL_TREE if fn is
NULL and use_ifn is false.
Arsen Arsenović [Wed, 29 Jan 2025 20:14:33 +0000 (21:14 +0100)]
d: give dependency files better filenames [PR118477]
Currently, the dependency files for root-file.o and common-file.o were
both d/.deps/file.Po, which would cause parallel builds to fail
sometimes with:
make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/build/gcc'
make[3]: Entering directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/build/gcc'
mv: cannot stat 'd/.deps/file.TPo': No such file or directory
make[3]: *** [/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/gcc-14-20240511/gcc/d/Make-lang.in:421: d/root-file.o] Error 1 shuffle=131581365
Also, this means that dependencies of one of root-file or common-file
are missing when developing. After this patch, those two files get
assigned dependency files d/.deps/root-file.Po and
d/.deps/common-file.Po respectively, so match the actual object
files in the d/ subdirectory.
There are other files with similar conflicts (mangle-package.o,
visitor-package.o for instance).
2025-01-29 Arsen Arsenović <arsen@aarsen.me>
Jakub Jelinek <jakub@redhat.com>
PR d/118477
* Make-lang.in (DCOMPILE, DPOSTCOMPILE): Use $(basename $(@F))
instead of $(*F).
Jakub Jelinek [Wed, 29 Jan 2025 08:32:04 +0000 (09:32 +0100)]
c++: Return false from __is_bounded_array for zero-sized arrays [PR118655]
This is basically Marek's PR114479 r14-9759 __is_array fix applied to
__is_bounded_array as well. Similarly to that trait, when not using
the builtin it returned false for zero sized arrays but when using
the builtin it returns true.
Jakub Jelinek [Tue, 28 Jan 2025 09:14:05 +0000 (10:14 +0100)]
combine: Fix up make_extraction [PR118638]
The following testcase is miscompiled at -Os on x86_64-linux.
The problem is during make_compound_operation of
(ashiftrt:SI (ashift:SI (mult:SI (reg:SI 107 [ a_5 ])
(const_int 3 [0x3]))
(const_int 31 [0x1f]))
(const_int 31 [0x1f]))
where it incorrectly returns
(mult:SI (sign_extract:SI (reg:SI 107 [ a_5 ])
(const_int 2 [0x2])
(const_int 0 [0]))
(const_int 3 [0x3]))
which isn't obviously true, the former returns either 0 or -1 depending
on the least significant bit of the multiplication,
the latter returns either 0 or -3 depending on the second least significant
bit of the multiplication argument.
The bug has been introduced in PR96998 r11-4563, which added handling of x
* (2^N) similar to x << N. In the above case, pos is 0 and len is 1,
sign extracting a single least significant bit of the multiplication.
As 3 is not a power of 2, shift_amt is -1.
But IN_RANGE (-1, 1, 1 - 1) is still true, because the basic requirement of
IN_RANGE that LOWER is not greater than UPPER is violated.
The intention of using 1 as LOWER is to avoid matching multiplication by 1,
that really shouldn't appear in the IL. But to avoid violating IN_RANGE
requirement, we need to verify that len is at least 2.
I've added this len > 1 check to the inner if rather than outer because I
think for GCC 16 we should add a further optimization.
In the particular case of 1 least significant bit sign extraction from
multiplication by 3, we could actually say it is equivalent to
(sign_extract:SI (reg:SI 107 [ a_5 ])
(const_int 1 [0x2])
(const_int 0 [0]))
That is because 3 is an odd number and multiplication by 2 will yield the
least significant bit 0 (we are sign extracting just one) and so the
multiplication doesn't change anything on the outcome.
More generally, even for larger len, multiplication by C which is
(1 << X) + 1 where X is >= len should be optimizable just to extraction
of the multiplicand's least significant len bits.
2025-01-28 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/118638
* combine.cc (make_extraction): Only optimize (mult x 2^n) if len is
larger than 1.
Jakub Jelinek [Sat, 25 Jan 2025 09:15:24 +0000 (10:15 +0100)]
c++: Only destruct elts of array for new expression if exception is thrown during the initialization [PR117827]
The following testcase r12-6328, because the elements of the array
are destructed twice, once when the callee encounters delete[] p;
and then second time when the exception is thrown.
The array elts should be only destructed if exception is thrown from
one of the constructors during the build_vec_init emitted code in case of
new expressions, but when the new expression completes, it is IMO
responsibility of user code to delete[] it when it is no longer needed.
So, the following patch uses the cleanup_flags argument to build_vec_init
to get notified of the flags that need to be changed when the expression
is complete and build_disable_temp_cleanup to do the changes.
2025-01-25 Jakub Jelinek <jakub@redhat.com>
PR c++/117827
* init.cc (build_new_1): Pass address of a make_tree_vector ()
initialized gc tree vector to build_vec_init and append
build_disable_temp_cleanup to init_expr from it.
Jakub Jelinek [Thu, 23 Jan 2025 10:46:18 +0000 (11:46 +0100)]
tree-assume: Fix UB in assume_query [PR118605]
The assume_query constructor does
assume_query::assume_query (function *f, bitmap p) : m_parm_list (p),
m_func (f)
where m_parm_list is bitmap &. This is compile time UB, because
as soon as the constructor returns, m_parm_list reference is still
bound to the parameter of the constructor which is no longer in scope.
Now, one possible fix would be change the ctor argument to be bitmap &,
but that doesn't really work because in the only user of that class
we have
auto_bitmap decls;
...
assume_query query (fun, decls);
and auto_bitmap just has
operator bitmap () { return &m_bits; }
Could be perhaps const bitmap &, but why? bitmap is a pointer:
typedef class bitmap_head *bitmap;
and the EXECUTE_IF_SET_IN_BITMAP macros don't really change that point,
they just inspect what is inside of that bitmap_head the pointer points
to.
So, the simplest I think is avoid references (which cause even worse
code as it has to be dereferenced twice rather than once).
2025-01-23 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118605
* tree-assume.cc (assume_query::m_parm_list): Change type
from bitmap & to bitmap.
Jakub Jelinek [Thu, 23 Jan 2025 10:11:23 +0000 (11:11 +0100)]
builtins: Store unspecified value to *exp for inf/nan [PR114877]
The fold_builtin_frexp folding for NaN/Inf just returned the first argument
with evaluating second arguments side-effects, rather than storing something
to what the second argument points to.
The PR argues that the C standard requires the function to store something
there but what exactly is stored is unspecified, so not storing there
anything can result in UB if the value isn't initialized and is read later.
glibc and newlib store there 0, musl apparently doesn't store anything.
The following patch stores there zero (or would you prefer storing there
some other value, 42, INT_MAX, INT_MIN, etc.?; zero is cheapest to form
in assembly though) and adjusts the test so that it
doesn't rely on not storing there anything but instead checks for
-Wmaybe-uninitialized warning to find out that something has been stored
there.
Unfortunately I had to disable the NaN tests for -O0, while we can fold
__builtin_isnan (__builtin_nan ("")) at compile time, we can't fold
__builtin_isnan ((i = 0, __builtin_nan (""))) at compile time.
fold_builtin_classify uses just tree_expr_nan_p and if that isn't true
(because expr is a COMPOUND_EXPR with tree_expr_nan_p on the second arg),
it does
arg = builtin_save_expr (arg);
return fold_build2_loc (loc, UNORDERED_EXPR, type, arg, arg);
and that isn't folded at -O0 further, as we wrap it into SAVE_EXPR and
nothing propagates the NAN to the comparison.
I think perhaps tree_expr_nan_p etc. could have case COMPOUND_EXPR:
added and recurse on the second argument, but that feels like stage1
material to me if we want to do that at all.
2025-01-23 Jakub Jelinek <jakub@redhat.com>
PR middle-end/114877
* builtins.cc (fold_builtin_frexp): Handle rvc_nan and rvc_inf cases
like rvc_zero, return passed in arg and set *exp = 0.
* gcc.dg/torture/builtin-frexp-1.c: Add -Wmaybe-uninitialized as
dg-additional-options.
(bar): New function.
(TESTIT_FREXP2): Rework the macro so that it doesn't test whether
nothing has been stored to what the second argument points to, but
instead that something has been stored there, whatever it is.
(main): Temporarily don't enable the nan tests for -O0.
Jakub Jelinek [Fri, 17 Jan 2025 10:30:07 +0000 (11:30 +0100)]
match.pd: Fix (FTYPE) N CMP (FTYPE) M optimization for GENERIC [PR118522]
The last case of this optimization assumes that if 2 integral types
have same precision and TYPE_UNSIGNED, then they are uselessly convertible.
While that is very likely the case for GIMPLE, it is not the case for
GENERIC, so the following patch adds there a convert so that the
optimization produces also valid GENERIC. Without it we got
(int) p == b where b had _BitInt(32) type, so incompatible types.
2025-01-17 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118522
* match.pd ((FTYPE) N CMP (FTYPE) M): Add convert, as in GENERIC
integral types with the same precision and sign might actually not
be compatible types.
Jakub Jelinek [Thu, 16 Jan 2025 08:17:50 +0000 (09:17 +0100)]
vec.h: Properly destruct elements in auto_vec auto storage [PR118400]
For T with non-trivial destructors, we were destructing objects in the
vector on release only when not using auto storage of auto_vec.
The following patch calls truncate (0) instead of m_vecpfx.m_num clearing,
and truncate takes care of that destruction:
unsigned l = length ();
gcc_checking_assert (l >= size);
if (!std::is_trivially_destructible <T>::value)
vec_destruct (address () + size, l - size);
m_vecpfx.m_num = size;
Dimitry Andric [Tue, 28 Jan 2025 17:36:16 +0000 (18:36 +0100)]
libgcc: On FreeBSD use GCC's crt objects for static linking
Add crtbeginT.o to extra_parts on FreeBSD. This ensures we use GCC's
crt objects for static linking. Otherwise it could mix crtbeginT.o
from the base system with libgcc's crtend.o, possibly leading to
segfaults.
libgcc:
PR target/118685
* config.host (*-*-freebsd*): Add crtbeginT.o to extra_parts.
Paul Thomas [Thu, 6 Feb 2025 16:40:19 +0000 (16:40 +0000)]
Fortran: FIx ICE in associate with elemental function [PR118750]
2025-02-06 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/118750
* resolve.cc (resolve_assoc_var): If the target expression has
a rank, do not use gfc_expression_rank, since it will return 0
if the function is elemental. Resolution will have produced the
correct rank.
gcc/testsuite/
PR fortran/118750
* gfortran.dg/associate_72.f90: New test.
Paul Thomas [Sat, 11 Jan 2025 08:23:48 +0000 (08:23 +0000)]
Fortran: Fix error recovery for bad component arrayspecs [PR108434]
2025-01-11 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran/
PR fortran/108434
* class.cc (generate_finalization_wrapper): To avoid memory
leaks from callocs, return immediately if the derived type
error flag is set.
* decl.cc (build_struct): If the declaration of a derived type
or class component does not have a deferred arrayspec, correct,
set the error flag of the derived type and emit an immediate
error.
Harald Anlauf [Thu, 30 Jan 2025 21:21:19 +0000 (22:21 +0100)]
Fortran: host association issue with symbol in COMMON block [PR108454]
When resolving a flavorless symbol that is already registered with a COMMON
block, and which neither has the intrinsic, generic, or external attribute,
skip searching among interfaces to avoid false resolution to a derived type
of the same name.
PR fortran/108454
gcc/fortran/ChangeLog:
* resolve.cc (resolve_common_blocks): Initialize variable.
(resolve_symbol): If a symbol is already registered with a COMMON
block, do not search for an interface with the same name.
Lulu Cheng [Wed, 22 Jan 2025 09:57:21 +0000 (17:57 +0800)]
LoongArch: Fix ICE caused by illegal calls to builtin functions [PR118561].
PR target/118561
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc
(loongarch_expand_builtin_lsx_test_branch):
NULL_RTX will not be returned when an error is detected.
(loongarch_expand_builtin): Likewise.
Paul Thomas [Wed, 6 Nov 2024 07:17:25 +0000 (07:17 +0000)]
Fortran: F2008 passing of internal procs to a proc pointer [PR117434]
2024-11-06 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/117434
* interface.cc (gfc_compare_actual_formal): Skip 'Expected a
procedure pointer error' if the formal argument typespec has an
interface and the type of the actual arg is BT_PROCEDURE.
gcc/testsuite/
PR fortran/117434
* gfortran.dg/proc_ptr_54.f90: New test. This is temporarily
compile-only until one one seven four five five is fixed.
* gfortran.dg/proc_ptr_55.f90: New test.
* gfortran.dg/proc_ptr_56.f90: New test.
Lewis Hyatt [Sun, 26 Jan 2025 23:57:00 +0000 (18:57 -0500)]
options: Adjust cl_optimization_compare to avoid checking ICE [PR115913]
At the end of a sequence like:
#pragma GCC push_options
...
#pragma GCC pop_options
the handler for pop_options calls cl_optimization_compare() (as generated by
optc-save-gen.awk) to make sure that all global state has been restored to
the value it had prior to the push_options call. The verification is
performed for almost all entries in the global_options struct. This leads to
unexpected checking asserts, as discussed in the PR, in case the state of
warnings-related options has been intentionally modified in between
push_options and pop_options via a call to #pragma GCC diagnostic. Address
that by skipping the verification for CL_WARNING-flagged options.
gcc/ChangeLog:
PR middle-end/115913
* optc-save-gen.awk (cl_optimization_compare): Skip options with
CL_WARNING flag.
gcc/testsuite/ChangeLog:
PR middle-end/115913
* c-c++-common/cpp/pr115913.c: New test.
Harald Anlauf [Sun, 26 Jan 2025 21:56:57 +0000 (22:56 +0100)]
Fortran: fix bogus diagnostics on renamed interface import [PR110993]
PR fortran/110993
gcc/fortran/ChangeLog:
* frontend-passes.cc (check_externals_procedure): Do not compare
interfaces of a non-bind(C) procedure against a bind(C) global one.
(check_against_globals): Use local name from rename-on-use in the
search for interfaces.
Harald Anlauf [Tue, 28 Jan 2025 20:21:40 +0000 (21:21 +0100)]
Fortran: fix passing of component ref to assumed-rank dummy [PR118683]
While the fix for pr117774 addressed the passing of an inquiry reference
to an assumed-rank dummy, it missed the similar case of passing a component
reference. The newer testcase gfortran.dg/pr81978.f90 uncovered this
latent issue with a UBSAN instrumented compiler.
PR fortran/118683
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): The bounds update for
passing to assumed-rank dummies shall also handle component
references besides inquiry references.
The range adaptor perfect forwarding simplification mechanism is currently
only enabled for trivially copyable bound arguments, to prevent undesirable
copies of complex objects. But "trivially copyable" is the wrong property
to check for here, since a move-only type with a trivial move constructor
is considered trivially copyable, and after P2492R2 we can't assume copy
constructibility of the bound arguments. This patch makes the mechanism
more specifically check for trivial copy constructibility instead so
that it's properly disabled for move-only bound arguments.
PR libstdc++/118413
libstdc++-v3/ChangeLog:
* include/std/ranges (views::__adaptor::_Partial): Adjust
constraints on the "simple" partial specializations to require
is_trivially_copy_constructible_v instead of
is_trivially_copyable_v.
* testsuite/std/ranges/adaptors/adjacent_transform/1.cc (test04):
Extend P2494R2 test.
* testsuite/std/ranges/adaptors/transform.cc (test09): Likewise.
In c++/102990 we had a problem where massage_init_elt got {},
digest_nsdmi_init turned that {} into { .value = (int) 1.0e+0 },
and we crashed in the call to fold_non_dependent_init because
a FIX_TRUNC_EXPR/FLOAT_EXPR got into tsubst*. So we avoided
calling fold_non_dependent_init for a CONSTRUCTOR.
But that broke the following test, where we no longer fold the
CONST_DECL in
{ .type = ZERO }
to
{ .type = 0 }
and then process_init_constructor_array does:
if (next != error_mark_node
&& (initializer_constant_valid_p (next, TREE_TYPE (next))
!= null_pointer_node))
{
/* Use VEC_INIT_EXPR for non-constant initialization of
trailing elements with no explicit initializers. */
picflags |= PICFLAG_VEC_INIT;
because { .type = ZERO } isn't initializer_constant_valid_p. Then we
create a VEC_INIT_EXPR and say we can't convert the argument.
So we have to fold the elements of the CONSTRUCTOR. We just can't
instantiate the elements in a template.
This also fixes c++/118047.
PR c++/118047
PR c++/118355
gcc/cp/ChangeLog:
* typeck2.cc (massage_init_elt): Call fold_non_dependent_init
unless for a CONSTRUCTOR in a template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-list10.C: New test.
* g++.dg/cpp0x/nsdmi-list9.C: New test.
Patrick Palka [Tue, 28 Jan 2025 14:27:02 +0000 (09:27 -0500)]
c++: friend vs inherited guide confusion [PR117855]
We recently started using the lang_decl_fn::context field to track
inheritedness of a deduction guide (for C++23 inherited CTAD). This
new overloading of the field accidentally made DECL_FRIEND_CONTEXT
return non-NULL for inherited guides, which breaks the below testcase
during overload resolution with an inherited guide.
This patch fixes this by refining DECL_FRIEND_CONTEXT appropriately.
Tamar Christina [Thu, 16 Jan 2025 19:23:50 +0000 (19:23 +0000)]
AArch64: don't override march to assembler with mcpu if march is specified [PR110901]
When both -mcpu and -march are specified, the value of -march wins out.
This is done correctly for the calls to cc1 and for the assembler directives we
put out in assembly files.
However in the call to as we don't do this and instead use the arch from the
cpu. This leads to a situation that GCC cannot reliably be used to compile
assembly files which don't have a .arch directive.
This is quite common with .S files which use macros to selectively enable
codepath based on what the preprocessor sees.
The fix is to change MCPU_TO_MARCH_SPEC to not override the march if an march
is already specified.
gcc/ChangeLog:
PR target/110901
* config/aarch64/aarch64.h (MCPU_TO_MARCH_SPEC): Don't override if
march is set.
gcc/testsuite/ChangeLog:
PR target/110901
* gcc.target/aarch64/options_set_29.c: New test.
This has worked great but was only added for homogenous systems.
However the same thing works for big.LITTLE as in such system the cores must
have the same extensions otherwise it doesn't fundamentally work.
i.e. task migration from one core to the other wouldn't work.
This extends the same handling to non-homogenous systems.
gcc/ChangeLog:
PR target/113257
* config/aarch64/driver-aarch64.cc (get_cpu_from_id, DEFAULT_CPU): New.
(host_detect_local_cpu): Use it.
gcc/testsuite/ChangeLog:
PR target/113257
* gcc.target/aarch64/cpunative/info_34: New test.
* gcc.target/aarch64/cpunative/native_cpu_34.c: New test.
* gcc.target/aarch64/cpunative/info_35: New test.
* gcc.target/aarch64/cpunative/native_cpu_35.c: New test.
The FakeStack flag is not zeroed out when can_store_by_pieces()
returns false. Over time, this causes FakeStack::Allocate() to perform
the maximum number of loop iterations, significantly slowing down the
instrumented program.
As reported in PR118185, std::ranges::clamp does not correctly forward
the projected value to the comparator. Add the missing forward.
libstdc++-v3/ChangeLog:
PR libstdc++/118185
PR libstdc++/100249
* include/bits/ranges_algo.h (__clamp_fn): Correctly forward the
projected value to the comparator.
* testsuite/25_algorithms/clamp/118185.cc: New test.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
(cherry picked from commit b342614139c0a981b369176980663941b9c27f39)
Patrick Palka [Thu, 16 Jan 2025 21:40:08 +0000 (16:40 -0500)]
c++: explicit spec of constrained member tmpl [PR107522]
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints are carried over
from the original template and thus are in terms of the original
DECL_TEMPLATE_PARMS. So during normalization for such an explicit
specialization we need to consider the (parameters of) the most general
template, since that's what the constraints are in terms of and since we
always use the full set of template arguments during satisfaction.
PR c++/107522
gcc/cp/ChangeLog:
* constraint.cc (get_normalized_constraints_from_decl): Use the
most general template for an explicit specialization of a
member template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-explicit-spec7.C: New test.
projects / thirdparty / gcc.git / log
