On 6/26/25 1:30 PM, Jakub Jelinek wrote:
On Thu, Jun 26, 2025 at 01:33:08PM +0200, Jakub Jelinek wrote:
I get some regressions (which I didn't get with the earlier patch, but
it isn't obvious by what it has been caused):
It ICEs were caused by the canonicalize_obj_off change and indeed
The ICEs are all in the same spot:
tree off = integer_zero_node;
canonicalize_obj_off (op, off);
gcc_assert (integer_zerop (off));
return cxx_fold_indirect_ref_1 (ctx, loc, type, op, 0, empty_base);
fixes that. The remaining FAILs were about constant evaluation of ctors
resulting in copies of construction vtables etc. no longer be needed because
all the construction was compile time evaluated.
Here is what bootstrapped/regtested on x86_64-linux and i686-linux without
any regressions (plus your patch is of course desirable and maybe some
incremental change to the CALL_EXPR handling of fixed_type_or_null but I
don't know what exactly).
I've pushed those changes.
--- gcc/cp/class.cc.jj 2025-06-26 13:49:44.206657109 +0200
+++ gcc/cp/class.cc 2025-06-26 13:51:29.234355488 +0200
@@ -347,9 +347,18 @@ build_base_path (enum tree_code code,
|| processing_template_decl
|| in_template_context);
+ fixed_type_p = resolves_to_fixed_type_p (expr, &nonnull);
+
+ /* Do we need to look in the vtable for the real offset? */
+ virtual_access = (v_binfo && fixed_type_p <= 0);
+
/* For a non-pointer simple base reference, express it as a COMPONENT_REF
without taking its address (and so causing lambda capture, 91933). */
- if (code == PLUS_EXPR && !v_binfo && !want_pointer && !has_empty && !uneval)
+ if (code == PLUS_EXPR
+ && !want_pointer
+ && !has_empty
+ && !uneval
+ && (!v_binfo || !virtual_access))
This can just be !virtual_access since !v_binfo implies !virtual_access.
OK with that tweak.
Jason
