| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It's now possible to see an active member of a union that has not actually
been initialized, so let's clarify the diagnostic.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_component_reference): Clarify diagnostic.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/constexpr-98122.C: Adjust diagnostic.
* g++.dg/cpp26/constexpr-new6a.C: New test.
|
|
Since Jakub's P2795R5 work removes the initial clobber from constructors,
let's add a clobber for new of all non-empty classes.
gcc/cp/ChangeLog:
* init.cc (build_new_1): Clobber classes.
gcc/testsuite/ChangeLog:
* g++.dg/analyzer/pr97116.C: Adjust diagnostic.
* g++.dg/warn/Warray-bounds-20.C: Likewise.
|
|
r16-3022 changed placement new to clobber the object, and improved constexpr
handling to do more with clobbers. But it occurred to me that in a lot of
cases we don't need to introduce a constructor_elt to represent an
uninitialized member of an uninitialized struct/array.
gcc/cp/ChangeLog:
* constexpr.cc (get_or_insert_ctor_field): -2 means don't insert.
(cxx_eval_component_reference): Handle finding void_node.
(cxx_eval_store_expression): Don't represent initial clobber
unless we need to activate a union member.
(cxx_eval_statement_list): Don't ask for a void prvalue.
(cxx_eval_loop_expr): The expr is discarded-value.
(cxx_eval_constant_expression): A loose clobber is non-constant.
Handle getting void_node instead of a real result.
(potential_constant_expression_1): A local temp is
potentially-constant.
* init.cc (build_new_1): Don't clobber empty types or
in a template.
(build_vec_init): Fix clobber handling.
gcc/testsuite/ChangeLog:
* g++.dg/init/pr25811.C: Tweak diagnostic.
* g++.dg/warn/Warray-bounds-12.C: Likewise.
* g++.dg/warn/Warray-bounds-13.C: Likewise.
* g++.dg/cpp26/constexpr-new6.C: New test.
|
|
With new (nothrow) we need to check whether the allocation returned null,
and the resulting COND_EXPR was confusing -Wmismatched-new-delete-2 at -O0.
Let's help it out by appending the address if it's the same on both arms.
gcc/cp/ChangeLog:
* init.cc (build_new_1): Append alloc_node to checking COND_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wmismatched-new-delete-2.C: Remove xfail.
|
|
|
|
Comment #2 of PR c++/121966 notes that the "inherited here" messages
should be nested *within* the note they describe.
Implemented by this patch, which also nests other notes emitted for
rejection_reason within the first note of print_z_candidate.
gcc/cp/ChangeLog:
PR c++/121966
* call.cc (print_z_candidate): Consolidate instances of
auto_diagnostic_nesting_level into one, above the "inherited here"
message so that any such message is nested within the note,
and any messages emitted due to the switch on rejection_reason are
similarly nested within the note.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
In r15-6116-gd3dd24acd74605 I updated print_z_candidates to show the
number of candidates, and a number for each candidate.
PR c++/121966 notes that the printed count is sometimes higher than
what's actually printed: I missed the case where candidates in the
list aren't printed due to not being viable.
Fixed thusly.
gcc/cp/ChangeLog:
PR c++/121966
* call.cc (print_z_candidates): Copy the filtering logic on viable
candidates from the printing loop to the counting loop, so that
num_candidates matches the number of iterations of the latter
loop.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
|
|
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
gcc/cp/ChangeLog:
* mangle.cc (write_real_cst): Replace 8 spaces with Tab.
|
|
|
|
We weren't explicitly treating a pack index specifier as a non-deduced
context (as per [temp.deduct.type]/5), leading to an ICE for the first
testcase below.
PR c++/121795
gcc/cp/ChangeLog:
* pt.cc (unify) <case PACK_INDEX_TYPE>: New non-deduced context
case.
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/pack-indexing17.C: New test.
* g++.dg/cpp26/pack-indexing17a.C: New test.
Reviewed-by: Marek Polacek <polacek@redhat.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
My r16-3559-gc2e567a6edb563 reworked ADL for modules, including a change
to allow seeing module-linkage declarations if they only exist on the
instantiation path. This caused a crash however as I neglected to
unwrap the stat hack wrapper when we were happy to see all declarations,
allowing search_adl to add non-functions to the overload set.
PR c++/121893
gcc/cp/ChangeLog:
* name-lookup.cc (name_lookup::adl_namespace_fns): Unwrap the
STAT_HACK also when on_inst_path.
gcc/testsuite/ChangeLog:
* g++.dg/modules/adl-10_a.C: New test.
* g++.dg/modules/adl-10_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
|
|
Don't upgrade TLS model when cplus_decl_attributes is called on a thread
local variable whose TLS model isn't set yet.
gcc/cp/
PR c++/121889
* decl2.cc (cplus_decl_attributes): Don't upgrade TLS model if
TLS model isn't set yet.
gcc/testsuite/
PR c++/121889
* g++.dg/tls/pr121889.C: New test.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
A static member template doesn't always have a DECL_INITIAL, as in the
below testcase, and so checking its TREE_CODE performs a null-pointer
dereference. I don't think we need to specially detect this case as
traits we care about are unlikely to be members, so this just adds the
missing null check.
PR c++/121859
gcc/cp/ChangeLog:
* constraint.cc (maybe_diagnose_standard_trait): Check if expr
is non-null.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-traits5.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
On Fri, Sep 05, 2025 at 09:57:06PM +0200, Matthias Kretz wrote:
> > Hmm, would this fail for x86 long double, which is 80 bits? OK, just
> > checked. It's mangled as 12/16 bytes on i686/x86_64.
>
> It seems that Clang and GCC disagree on mangling 80-Bit long double:
>
> I like Clang's interpretation of https://itanium-cxx-abi.github.io/cxx-abi/
> abi.html#mangle.float better.
This patch changes the mangling of 80-bit long double literals from
24 or 32 digits (on m68k with padding bits in the middle, on x86
at the start) to just 20 hex digits.
2025-09-10 Jakub Jelinek <jakub@redhat.com>
* mangle.cc (write_real_cst): Mangle Intel/Motorola extended
80-bit formats using 20 hex digits instead of 24 or 32.
* g++.target/i386/mangle-ldbl-1.C: New test.
* g++.target/i386/mangle-ldbl-2.C: New test.
* g++.target/m68k/mangle-ldbl-1.C: New test.
* g++.target/m68k/mangle-ldbl-2.C: New test.
|
|
|
|
This patch fixes some issues with import handling.
The main functional change is to allow importing a module's interface
file into its implementation file indirectly. [module.import] p9
forbids an explicit 'import M;' declaration, but there's no provision
against having 'import X;' where module X itself imports M, so this
patch splits up the detection of circular imports to handle this better.
I also updated the errors to be closer to the standard wording.
A second issue I found while testing this is that we don't properly
handle name visibility when a partition implementation unit imports its
primary module interface (g++.dg/modules/part-10). This is resolved by
setting 'module_p' on the primary interface when it gets imported.
Solving this I incidentally removed the assertion that PR121808 was
failing on, which was never valid: we can enter import_module for a
module previously seen as a module-declaration if parsing bails before
declare_module is called. I experimented with guaranteeing that
declare_module always gets called for a module_state generated during
preprocessing if at all possible, but the resulting errors didn't seem a
lot better so I've left it as-is for now.
I did make a small adjustment so that a direct import of a module
doesn't overwrite the location of a module-declaration from earlier in
the file; this is important because preprocessing (and thus the
assigning of these locations) seems to happen for the whole file before
parsing begins, which can otherwise cause confusing locations referring
to later in the file than parsing would otherwise indicate.
PR c++/99682
PR c++/121808
gcc/cp/ChangeLog:
* module.cc (class module_state): Add comment to 'parent'.
(module_state::check_not_purview): Rename to...
(module_state::check_circular_import): ...this. Only handle
interface dependencies, adjust diagnostic message.
(module_state::read_imports): Use new function. Pass location
of import as from_loc instead of the module location.
(module_state::do_import): Set module_p when importing the
primary interface for the current module.
(import_module): Split out check for imports in own unit.
Remove incorrect assertion.
(preprocess_module): Don't overwrite module-decl location with
later import.
gcc/testsuite/ChangeLog:
* g++.dg/modules/circ-1_c.C: Adjust diagnostic.
* g++.dg/modules/mod-decl-1.C: Likewise.
* g++.dg/modules/mod-decl-2_b.C: Likewise.
* g++.dg/modules/pr99174.H: Likewise.
* g++.dg/modules/import-3_a.C: New test.
* g++.dg/modules/import-3_b.C: New test.
* g++.dg/modules/import-3_c.C: New test.
* g++.dg/modules/mod-decl-9.C: New test.
* g++.dg/modules/part-10_a.C: New test.
* g++.dg/modules/part-10_b.C: New test.
* g++.dg/modules/part-10_c.C: New test.
* g++.dg/modules/part-10_d.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
A lot of places use (*modules)[0] to refer to the module state for the
current TU. This is a bit awkward to type and not particularly clear
what it represents; make a helper function to clarify it.
gcc/cp/ChangeLog:
* module.cc (this_module): New function.
(import_entity_module): Use it.
(trees_out::decl_node): Likewise.
(get_module): Likewise.
(module_state::check_not_purview): Likewise.
(module_state::read_imports): Likewise.
(module_state::read_using_directives): Likewise.
(module_state::read_initial): Likewise.
(get_import_bitmap): Likewise.
(module_may_redeclare): Likewise.
(direct_import): Likewise.
(declare_module): Likewise.
(name_pending_imports): Likewise.
(preprocess_module): Likewise.
(finish_module_processing): Likewise.
(late_finish_module): Likewise.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
Apparently an explicitly defined operator<=> isn't required to return
std::foo_ordering, so build_min_non_dep_op_overload needs to be able
to rebuild forms of (x <=> y) @ 0 where the @ resolved to a built-in and
in turn isn't expressed as a function call.
PR c++/121779
gcc/cp/ChangeLog:
* tree.cc (build_min_non_dep_op_overload): Handle comparison
operator expressions rewritten from a <=> that returns a
non-class type.
gcc/testsuite/ChangeLog:
* g++.dg/lookup/operator-8.C: Remove outdated comment about
this test failing.
* g++.dg/lookup/operator-8a.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
gcc/testsuite/ChangeLog:
PR c++/121801
* g++.dg/abi/pr121801.C: New test.
gcc/cp/ChangeLog:
PR c++/121801
* mangle.cc (write_real_cst): Handle 16-bit real and assert
that reals have 16 bits or a multiple of 32 bits.
|
|
|
|
Set a tentative TLS model in grokvardecl and update TLS mode with the
default TLS access model after a TLS variable has been fully processed
if the default TLS access model is stronger.
gcc/cp/
PR c++/107393
* decl.cc (grokvardecl): Set a tentative TLS model which will be
updated by cplus_decl_attributes later.
* decl2.cc (cplus_decl_attributes): Update TLS model with the
default TLS access model if the default TLS access model is
stronger.
* pt.cc (tsubst_decl): Set TLS model only after processing a
variable.
gcc/testsuite/
PR c++/107393
* g++.dg/tls/pr107393-1.C: New test.
* g++.dg/tls/pr107393-2.C: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
Currently we represent exported using-directives as a list of indices
into the namespace array that we stream. However this list of
namespaces doesn't include any namespaces that we don't expose in this
module's purview, and so we ICE.
This patch reworks the handling to instead use the existing depset
tracking for namespaces directly. This means that we don't need to
build up a second lookup map when streaming, and we can reuse the logic
in {read,write}_namespace. We do need to make sure that we create a
depset for namespaces only referenced by a using-directive, though.
I don't expect to be exporting large numbers of using-directives from a
namespace, so for simplicity we stream the names as {parent, target}
pairs.
This also adjusts read handling so that we load the using-directives for
any import (including indirect) if it's in the import list for the
current TU. Otherwise we run into issues if the using-directive is in
a namespace that is otherwise never referenced in the 'export import'ing
module, because we never walk this namespace and so never know that we
need to emit it. To do this the patch ensures that we calculate the
import list before read_language is called.
As a drive-by fix, I noticed that with modules 'add_using_namespace'
will add duplicate using-directives because we compare usings against
the target namespace, but we then push a wrapping USING_DECL instead.
This reworks so that the contents of the structure is equivalent between
modules and non-modules code.
PR c++/121702
gcc/cp/ChangeLog:
* module.cc (enum module_state_counts): New counter.
(depset::hash::add_namespace_entities): Seed using-directive
targets for later streaming.
(module_state::write_namespaces): Don't handle using-directives
here.
(module_state::read_namespaces): Likewise.
(module_state::write_using_directives): New function.
(module_state::read_using_directives): New function.
(module_state::write_counts): Log using-directives.
(module_state::read_counts): Likewise.
(module_state::write_begin): Stream using-directives.
(module_state::read_language): Read using-directives if
directly importing.
(module_state::direct_import): Update current TU import list
before calling read_language.
* name-lookup.cc (add_using_namespace): Fix lookup of previous
using-directives.
* parser.cc (cp_parser_import_declaration): Don't set
MK_EXPORTING when performing import_module.
gcc/testsuite/ChangeLog:
* g++.dg/modules/namespace-10_c.C: Add check for log dump.
* g++.dg/modules/namespace-13_a.C: New test.
* g++.dg/modules/namespace-13_b.C: New test.
* g++.dg/modules/namespace-13_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
[basic.lookup.argdep] p4 says that ADL also finds declarations of
functions or function templates from a point of lookup within the
module, only ignoring discarded (or internal) GM entities.
To implement this we need to create bindings for these entities so that
we can guarantee that name lookup will discover they exist. This raises
some complications, though, as we ideally would like to avoid having
bindings that contain no declarations, or emitting GM namespaces that
only contain discarded or internal functions.
This patch does this by additionally creating a new binding whenever we
call make_dependency on a non-EK_FOR_BINDING decl. We don't do this for
using-decls, as at the point of use of a GM entity we no longer know
whether we called through a using-decl or the declaration directly;
however, this behaviour is explicitly supported by [module.global.frag]
p3.6.
Creating these bindings caused g++.dg/modules/default-arg-4_* to fail.
It turns out that this makes the behaviour look identical to
g++.dg/modules/default-arg-5, which is incorrectly dg-error-ing default
value redeclarations (we only currently error because of PR c++/99000).
This patch removes the otherwise identical test and turns the dg-errors
into xfailed dg-bogus.
As a drive-by fix this also fixes an ICE when debug printing friend
function instantiations.
PR c++/121705
PR c++/117658
gcc/cp/ChangeLog:
* module.cc (depset::hash::make_dependency): Make bindings for
GM functions.
(depset::hash::add_binding_entity): Adjust comment.
(depset::hash::add_deduction_guides): Add log.
* ptree.cc (cxx_print_xnode): Handle friend functions where
TI_TEMPLATE is an OVERLOAD or IDENTIFIER.
gcc/testsuite/ChangeLog:
* g++.dg/modules/default-arg-4_a.C: XFAIL bogus errors.
* g++.dg/modules/default-arg-4_b.C: Likewise.
* g++.dg/modules/default-arg-5_a.C: Remove duplicate test.
* g++.dg/modules/default-arg-5_b.C: Likewise.
* g++.dg/modules/adl-9_a.C: New test.
* g++.dg/modules/adl-9_b.C: New test.
* g++.dg/modules/gmf-5.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Marek Polacek reported to me internally that I've messed up one diagnostic
message in this function, with one word before final double quote on one
line and another word right after opening double quote on the next line,
with no space in between.
Fixed thusly.
2025-09-05 Jakub Jelinek <jakub@redhat.com>
* constexpr.cc (cxx_eval_cxa_builtin_fn): Add missing word separating
space into invalid_nargs diagnostics.
|
|
|
|
On looking again at [basic.lookup.argdep] p4, I believe GCC hasn't fully
implemented the wording here for ADL. This patch fixes two issues.
First, 4.3 indicates that a function exported from a named module should
be visible to ADL regardless of whether it's visible to normal name
lookup, as long as some restrictions are followed.
This patch implements this; for skipping declarations that "do not
appear in the TU containing the point of lookup" I don't think there's
anything special we need to do, as any declarations before the point of
lookup will be found in other ways anyway, and any remaining
declarations from the current TU cannot be seen regardless.
Secondly, currently we only add the exported functions along the
instantiation path of a lookup. But I don't think this is intended by
the current wording, so this patch adjusts that. I also clean up the
logic to do all different module processing in adl_namespace_fns so that
we don't duplicate work in traversing the module binding list
unnecessarily.
This new handling means we need to do some extra work to properly error
on overload sets containing TU-local entities (as this might actually
come up now!) but I'm leaving that for a later patch.
As a drive-by fix this also fixes an ICE for C++26 expansion statements
with finding the instantiation path.
PR c++/117658
gcc/cp/ChangeLog:
* cp-tree.h (get_originating_module): Adjust parameter names.
* module.cc (path_of_instantiation): Handle C++26 expansion
statements.
* name-lookup.cc (name_lookup::adl_namespace_fns): Handle
exported declarations attached to the same module of an
associated entity with the same innermost non-inline namespace,
and non-exported functions on the instantiation path.
(name_lookup::search_adl): Build mapping of namespace to modules
that associated entities are attached to; remove now-unneeded
instantiation path handling.
gcc/testsuite/ChangeLog:
* g++.dg/modules/adl-4_a.C: Test should pass.
* g++.dg/modules/adl-4_b.C: Test should pass.
* g++.dg/modules/adl-6_a.C: New test.
* g++.dg/modules/adl-6_b.C: New test.
* g++.dg/modules/adl-6_c.C: New test.
* g++.dg/modules/adl-7_a.C: New test.
* g++.dg/modules/adl-7_b.C: New test.
* g++.dg/modules/adl-7_c.C: New test.
* g++.dg/modules/adl-8_a.C: New test.
* g++.dg/modules/adl-8_b.C: New test.
* g++.dg/modules/adl-8_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
When we push an existing namespace within the module purview for the
first time, we also need to mark any parent inline namespaces as purview
to not confuse the streaming logic.
PR c++/121724
gcc/cp/ChangeLog:
* name-lookup.cc (push_namespace): Mark inline namespace
contexts as purview if needed.
gcc/testsuite/ChangeLog:
* g++.dg/modules/namespace-12_a.C: New test.
* g++.dg/modules/namespace-12_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
|
|
Here although the local templated variables x and y have the same
reduced constant value, only x's initializer {a.get()} is well-formed
as written since A::m has private access. We correctly reject y's
initializer {&a.m} (at instantiation time), but we also reject x's
initializer because we happen to constant fold it ahead of time, which
means at instantiation time it's already represented as a COMPONENT_REF
to a FIELD_DECL, and so when substituting this COMPONENT_REF we naively
double check that the given FIELD_DECL is accessible, which fails.
This patch sidesteps around this particular issue by not checking access
when substituting a COMPONENT_REF to a FIELD_DECL. If the target of a
COMPONENT_REF is already a FIELD_DECL (i.e. before substitution), then I
think we can assume access has been already checked appropriately.
PR c++/97740
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr) <case COMPONENT_REF>: Don't check access
when the given member is already a FIELD_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-97740a.C: New test.
* g++.dg/cpp0x/constexpr-97740b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
We have contracts-related declarations and macros split between contracts.h
and cp-tree.h, and then contracts.h is included in the latter, which means
that it is included in all c++ front end files.
This patch:
- moves all the contracts-related material to contracts.h.
- makes some functions that are only used in contracts.cc static.
- tries to group the external API for contracts into related topics.
- includes contracts.h in the front end sources that need it.
gcc/cp/ChangeLog:
* constexpr.cc: Include contracts.h
* coroutines.cc: Likewise.
* cp-gimplify.cc: Likewise.
* decl.cc: Likewise.
* decl2.cc: Likewise.
* mangle.cc: Likewise.
* module.cc: Likewise.
* pt.cc: Likewise.
* search.cc: Likewise.
* semantics.cc: Likewise.
* contracts.cc (validate_contract_role, setup_default_contract_role,
add_contract_role, get_concrete_axiom_semantic,
get_default_contract_role): Make static.
* cp-tree.h (make_postcondition_variable, grok_contract,
finish_contract_condition, find_contract, set_decl_contracts,
get_contract_semantic, set_contract_semantic): Move to contracts.h.
* contracts.h (get_contract_role, add_contract_role,
validate_contract_role, setup_default_contract_role,
lookup_concrete_semantic, get_default_contract_role): Remove.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
|
|
|
|
The following minimum reproducer would miscompile with vanilla gcc:
extern int x[10], y[10];
bool g();
void f() { 0[g() ? x : y] = 1; }
gcc would mistakenly treat the subexpression (g() ? x : y) as a prvalue and
move that array to stack. The following assignment would then write to the
stack instead of to the global arrays. When optimizations are enabled, this
assignment is discarded by dse and gcc generates the following code for the
f function:
"_Z1fi":
jmp "_Z1gv"
The miscompilation requires all the following conditions to be met:
- The array subscription expression is written as idx[array], instead of
the usual form array[idx];
- The "array" part must be a ternary expression (COND_EXPR in gcc tree)
and it must be an lvalue.
- The code must be compiled with -fstrong-eval-order which is the default
for -std=c++17 or later.
The cause of the issue lies in cp_build_array_ref, where it mistakenly
generates a COND_EXPR with ARRAY_TYPE to the IL when all the criteria above
are met. This patch tries to resolve this issue. It moves the
canonicalization step that transforms idx[array] to array[idx] early in
cp_build_array_ref to ensure we handle these two forms of array subscription
consistently.
Tested on x86_64-linux.
gcc/cp/ChangeLog:
* typeck.cc (cp_build_array_ref): Handle 0[arr] earlier.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/array-condition-expr.C: New test.
Signed-off-by: Sirui Mu <msrlancern@gmail.com>
|
|
|
|
As with PR116928, we need to set greater_than_is_operator_p within the
lambda delimiters.
PR c++/107953
gcc/cp/ChangeLog:
* parser.cc (cp_parser_lambda_expression): Set
greater_than_is_operator_p.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ18.C: New test.
|
|
different module [PR119844]
The confusion in the PR arose because the definition of 'User' in a
separate named module did not provide an implementation for the
forward-declaration in the global module. This seems likely to be a
common mistake while people are transitioning to modules, so this patch
adds an explanatory note.
While I was looking at this I also noticed that the existing handling of
partial specialisations for this note was wrong (we pointed at the
primary template declaration rather than the relevant partial spec), so
this patch fixes that up, and also gives a more precise error message
for using a template other than by self-reference while it's being
defined.
PR c++/119844
gcc/cp/ChangeLog:
* typeck2.cc (cxx_incomplete_type_inform): Add explanation when
a similar type is complete but attached to a different module.
Also fix handling of partial specs and templates.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr119844_a.C: New test.
* g++.dg/modules/pr119844_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
The following testcase ICEs during expansion, because cfun->returns_struct
wasn't cleared, despite auto being deduced to int.
The problem is that check_return_type -> apply_deduced_return_type
is called when parsing the expansion stmt body, at that time
processing_template_decl is non-zero and apply_deduced_return_type
in that case doesn't do the
if (function *fun = DECL_STRUCT_FUNCTION (fco))
{
bool aggr = aggregate_value_p (result, fco);
#ifdef PCC_STATIC_STRUCT_RETURN
fun->returns_pcc_struct = aggr;
#endif
fun->returns_struct = aggr;
}
My assumption is that !processing_template_decl in that case
is used in the sense "the fco function is not a function template",
for function templates no reason to bother with fun->returns*struct,
nothing will care about that.
When returning a type dependent expression in the expansion stmt
body, apply_deduced_return_type just won't be called during parsing,
but when instantiating the body and all will be fine. But when
returning a non-type-dependent expression, while check_return_type
will be called again during instantiation of the body, as the return
type is no longer auto in that case apply_deduced_return_type will not
be called again and so nothing will fix up fun->returns*struct.
The following patch fixes that by using !uses_template_parms (fco)
check instead of !processing_template_decl.
2025-08-28 Jakub Jelinek <jakub@redhat.com>
PR c++/121583
* semantics.cc (apply_deduced_return_type): Adjust
fun->returns*_struct when !uses_template_parms (fco) instead of
when !processing_template_decl.
* g++.dg/cpp26/expansion-stmt23.C: New test.
* g++.dg/cpp26/expansion-stmt24.C: New test.
|
|
The following testcase shows an ICE when a parameter of a non-template
function is referenced in expansion stmt body.
tsubst_expr in that case assumes that either the PARM_DECL has registered
local specialization, or is this argument or it is in unevaluated context.
Parameters are always defined outside of the expansion statement
for-range-declaration or body, so for the instantiation of the body
outside of templates should always map to themselves.
It could be fixed by registering local self-specializations for all the
function parameters, but just handling it in tsubst_expr seems to be easier
and less costly.
Some PARM_DECLs, e.g. from concepts, have NULL DECL_CONTEXT, those are
handled like before (and assert it is unevaluated operand), for others
this checks if the PARM_DECL is from a non-template and in that case it
will just return t.
2025-08-28 Jakub Jelinek <jakub@redhat.com>
Jason Merrill <jason@redhat.com>
PR c++/121575
* pt.cc (tsubst_expr) <case PARM_DECL>: If DECL_CONTEXT (t) isn't a
template return t for PARM_DECLs without local specialization.
* g++.dg/cpp26/expansion-stmt20.C: New test.
|
|
|
|
As noted in the issue, the C++ front end has deeper problems: it's
supposed to do the name lookup of the variant at the call site but is
instead doing it when parsing the "declare variant" construct, before
registering the decl for the base function. The C++ part of the
patch is a band-aid to catch the case where there is a previous declaration
of the function and it doesn't give an undefined symbol error instead.
Some real solution ought to be included as part of fixing PR118791.
gcc/c/
PR middle-end/118839
* c-parser.cc (c_finish_omp_declare_variant): Error if variant
is the same as base.
gcc/cp/
PR middle-end/118839
* decl.cc (omp_declare_variant_finalize_one): Error if variant
is the same as base.
gcc/fortran/
PR middle-end/118839
* trans-openmp.cc (gfc_trans_omp_declare_variant): Error if variant
is the same as base.
gcc/testsuite/
PR middle-end/118839
* gcc.dg/gomp/declare-variant-3.c: New.
* gfortran.dg/gomp/declare-variant-22.f90: New.
|
|
This patch fixes a number of problems with parser error checking of
"declare variant", especially in the C front end.
The new C testcase unprototyped-variant.c added by this patch used to
ICE when gimplifying the call site, at least in part because the
variant was being recorded even after it was diagnosed as invalid.
There was also a large block of dead code in the C front end that was
supposed to fix up an unprototyped declaration of a variant function
to match the base function declaration, that was never executed because
it was nested in a conditional that could never be true. I've fixed those
problems by rearranging the code and only recording the variant if it
passes the correctness checks. I also tried to add some comments and
re-work some particularly confusing bits of code, so that it's easier to
understand.
The OpenMP specification doesn't say what the behavior of "declare
variant" with the "append_args" clause should be when the base
function is unprototyped. The additional arguments are supposed to be
inserted between the last fixed argument of the base function and any
varargs, but without a prototype, for any given call we have no idea
which arguments are fixed and which are varargs, and therefore no idea
where to insert the additional arguments. This used to trigger some
other diagnostics (which one depending on whether the variant was also
unprototyped), but I thought it was better to just reject this with an
explicit "sorry".
Finally, I also observed that a missing "match" clause was only
rejected if "append_args" or "adjust_args" was present. Per the spec,
"match" has the "required" property, so if it's missing it should be
diagnosed unconditionally. The C++ and Fortran front ends had the same
issue so I fixed this one there too.
gcc/c/ChangeLog
* c-parser.cc (c_finish_omp_declare_variant): Rework diagnostic
code. Do not record variant if there are errors. Make check for
a missing "match" clause unconditional.
gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Structure diagnostic
code similarly to C front end. Make check for a missing "match"
clause unconditional.
gcc/fortran/ChangeLog
* openmp.cc (gfc_match_omp_declare_variant): Make check for a
missing "match" clause unconditional.
gcc/testsuite/ChangeLog
* c-c++-common/gomp/append-args-1.c: Adjust expected output.
* g++.dg/gomp/adjust-args-1.C: Likewise.
* g++.dg/gomp/adjust-args-3.C: Likewise.
* gcc.dg/gomp/adjust-args-1.c: Likewise:
* gcc.dg/gomp/append-args-1.c: Likewise.
* gcc.dg/gomp/unprototyped-variant.c: New.
* gfortran.dg/gomp/adjust-args-1.f90: Adjust expected output.
* gfortran.dg/gomp/append_args-1.f90: Likewise.
|
|
|
|
The following patch implements the proposed resolution of
https://cplusplus.github.io/CWG/issues/3048.html
Instead of rejecting structured binding size it just builds a normal
decl rather than structured binding declaration.
2025-08-25 Jakub Jelinek <jakub@redhat.com>
* pt.cc (finish_expansion_stmt): Implement C++ CWG3048
- Empty destructuring expansion statements. Don't error for
destructuring expansion stmts if sz is 0, don't call
fit_decomposition_lang_decl if n is 0 and pass NULL rather than
this_decomp to cp_finish_decl.
* g++.dg/cpp26/expansion-stmt15.C: Don't expect error on
destructuring expansion stmts with structured binding size 0.
* g++.dg/cpp26/expansion-stmt21.C: New test.
* g++.dg/cpp26/expansion-stmt22.C: New test.
|
|
The following testcase ICEs, because the
/* Check we aren't dereferencing a null pointer when calling a non-static
member function, which is undefined behaviour. */
if (i == 0 && DECL_OBJECT_MEMBER_FUNCTION_P (fun)
&& integer_zerop (arg)
/* But ignore calls from within compiler-generated code, to handle
cases like lambda function pointer conversion operator thunks
which pass NULL as the 'this' pointer. */
&& !(TREE_CODE (t) == CALL_EXPR && CALL_FROM_THUNK_P (t)))
{
if (!ctx->quiet)
error_at (cp_expr_loc_or_input_loc (x),
"dereferencing a null pointer");
*non_constant_p = true;
}
checking is done before testing if (*jump_target). Especially when
throws (jump_target), arg can be (and is on this testcase) NULL_TREE,
so calling integer_zerop on it ICEs.
Fixed by moving the if (*jump_target) test earlier.
2025-08-25 Jakub Jelinek <jakub@redhat.com>
PR c++/121601
* constexpr.cc (cxx_bind_parameters_in_call): Move break
if *jump_target before the check for null this object pointer.
* g++.dg/cpp26/constexpr-eh16.C: New test.
|
|
|
