Derived from the changes that added C++2a support in 2017.
r8-3237-g026a79f70cf33f836ea5275eda72d4870a3041e5
No C++23 features are added here.
Use of -std=c++23 sets __cplusplus to 202100L.
$ g++ -std=c++23 -dM -E -x c++ - < /dev/null | grep cplusplus
#define __cplusplus 202100L
gcc/
* doc/cpp.texi (__cplusplus): Document value for -std=c++23
or -std=gnu++23.
* doc/invoke.texi: Document -std=c++23 and -std=gnu++23.
* dwarf2out.c (highest_c_language): Recognise C++20 and C++23.
(gen_compile_unit_die): Recognise C++23.
gcc/c-family/
* c-common.h (cxx_dialect): Add cxx23 as a dialect.
* c.opt: Add options for -std=c++23, std=c++2b, -std=gnu++23
and -std=gnu++2b
* c-opts.c (set_std_cxx23): New.
(c_common_handle_option): Set options when -std=c++23 is enabled.
(c_common_post_options): Adjust comments.
(set_std_cxx20): Likewise.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_c++2a):
Check for C++2a or C++23.
(check_effective_target_c++20_down): New.
(check_effective_target_c++23_only): New.
(check_effective_target_c++23): New.
* g++.dg/cpp23/cplusplus.C: New.
libcpp/
* include/cpplib.h (c_lang): Add CXX23 and GNUCXX23.
* init.c (lang_defaults): Add rows for CXX23 and GNUCXX23.
(cpp_init_builtins): Set __cplusplus to 202100L for C++23.
In this testcase, we refer to the a parameter through a reference in its own
member, which we asserted couldn't happen by marking the parameter as
'restrict'. This assumption could also be broken if the address escapes
from the constructor.
gcc/cp/ChangeLog:
PR c++/97474
* call.c (type_passed_as): Don't mark invisiref restrict.
gcc/testsuite/ChangeLog:
PR c++/97474
* g++.dg/torture/pr97474.C: New test.
In the discussion of PR98463, Jakub pointed out that in C++17 and up,
cxx_fold_indirect_ref_1 could use the field we build for an empty base. I
tried implementing that, but it broke one of the tuple tests, so I did some
more digging.
To start with, I generalized the PR98463 patch to handle the case where we
do have a field, for an empty base or [[no_unique_address]] member. This is
enough also for the no-field case because the member of the empty base must
itself be an empty field; if it weren't, the base would not be empty.
I looked for related PRs and found 97566, which was also fixed by the patch.
After some poking around to figure out why, I noticed that the testcase had
been breaking because E, though an empty class, has an ABI nvsize of one
byte, and we were giving the [[no_unique_address]] FIELD_DECL that
DECL_SIZE, whereas in build_base_field_1 empty base fields always get
DECL_SIZE zero, and various places were relying on that to recognize empty
fields. So I adjusted both the size and the checking. When I adjusted
check_bases I wondered if we were correctly handling bases with only empty
data members, but it appears we do.
I'm deferring the cxx_fold_indirect_ref_1 change until stage 1, as I don't
think it actually fixes anything.
gcc/cp/ChangeLog:
PR c++/97566
PR c++/98463
* class.c (layout_class_type): An empty field gets size 0.
(is_empty_field): New.
(check_bases): Check it.
* cp-tree.h (is_empty_field): Declare it.
* constexpr.c (cxx_eval_store_expression): Check it.
(cx_check_missing_mem_inits): Likewise.
* init.c (perform_member_init): Likewise.
* typeck2.c (process_init_constructor_record): Likewise.
gcc/testsuite/ChangeLog:
PR c++/97566
* g++.dg/cpp2a/no_unique_address10.C: New test.
* g++.dg/cpp2a/no_unique_address9.C: New test.
This patch drops the no-strict-aliasing hack in m128-check.h and instead
ensures the tests read objects with the right dynamic type.
2021-01-26 Jakub Jelinek <jakub@redhat.com>
* gcc.target/powerpc/m128-check.h (CHECK_EXP): Remove
optimize ("no-strict-aliasing") attribute.
* gcc.target/powerpc/sse-andnps-1.c (TEST): Copy e into float[4]
array to avoid violating TBAA.
* gcc.target/powerpc/sse2-andpd-1.c (TEST): Copy e.d into double[2]
array to avoid violating TBAA.
* gcc.target/powerpc/sse-andps-1.c (TEST): Copy e.f into float[4]
array to avoid violating TBAA.
* gcc.target/powerpc/sse2-andnpd-1.c (TEST): Copy e into double[2]
array to avoid violating TBAA.
This is the profiled bootstrap failure for s390x/Linux on the mainline,
which has been introduced by the modref pass but actually exposing an
existing issue in the maybe_pad_type function that is visible on s390x.
The issue is too weak a test for the addressability of the inner component.
gcc/ada/
Marius Hillenbrand <mhillen@linux.ibm.com>
PR ada/98228
* gcc-interface/utils.c (maybe_pad_type): Test the size of the new
packable type instead of its alignment for addressability's sake.
My recent dwarf2asm.c patch broke powerpc*-*-* bootstrap, while most target
define POINTER_SIZE to (cond ? cst1 : cst2) or constant, rs6000 defines
it to a variable, and the arbitrarily chosen type of that variable determines
whether we get warnings on comparison of that against signed or unsigned
ints.
Fixed by adding a cast.
2021-01-26 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/98839
* dwarf2asm.c (dw2_assemble_integer): Cast DWARF2_ADDR_SIZE to int
in comparison.
The testcase in the patch doesn't assemble, because the instruction requires
that the penultimate operand (lsb) range is [0, 32] (or [0, 64]) and the last
operand's range is [1, 32 - lsb] (or [1, 64 - lsb]).
The INTVAL (shft_amnt) < GET_MODE_BITSIZE (mode) will accept the lsb operand
to be in range [MIN, 32] (or [MIN, 64]) and then we invoke UB in the
compiler and sometimes it will make it through.
The patch changes all the INTVAL uses in that function to UINTVAL,
which isn't strictly necessary, but can be done (e.g. after the
UINTVAL (shft_amnt) < GET_MODE_BITSIZE (mode) check we know it is not
negative and thus INTVAL (shft_amnt) and UINTVAL (shft_amnt) then behave the
same. But, I had to add INTVAL (mask) > 0 check in that case, otherwise we
risk (hypothetically) emitting instruction that doesn't assemble.
The problem is with masks that have the MSB bit set, while the instruction
can handle those, e.g.
ubfiz w1, w0, 13, 19
will do
(w0 << 13) & 0xffffe000
in RTL we represent SImode constants with MSB set as negative HOST_WIDE_INT,
so it will actually be HOST_WIDE_INT_C (0xffffffffffffe000), and
the instruction uses %P3 to print the last operand, which calls
asm_fprintf (f, "%u", popcount_hwi (INTVAL (x)))
to print that. But that will not print 19, but 51 instead, will include
there also all the copies of the sign bit.
Not supporting those masks with MSB set isn't a big loss though, they really
shouldn't appear normally, as both GIMPLE and RTL optimizations should
optimize those away (one isn't masking any bits off with such masks, so
just w0 << 13 will do too).
2021-01-26 Jakub Jelinek <jakub@redhat.com>
PR target/98681
* config/aarch64/aarch64.c (aarch64_mask_and_shift_for_ubfiz_p):
Use UINTVAL (shft_amnt) and UINTVAL (mask) instead of INTVAL (shft_amnt)
and INTVAL (mask). Add && INTVAL (mask) > 0 condition.
* gcc.c-torture/execute/pr98681.c: New test.
This avoids dumping them as <<< ??? >>>.
2021-01-26 Richard Biener <rguenther@suse.de>
* gimple-pretty-print.c (dump_binary_rhs): Handle
VEC_WIDEN_{PLUS,MINUS}_{LO,HI}_EXPR.
This fixes VECTOR_CST element access with POLY_INT elements and
allows to produce dump files of the PR98726 testcase without
ICEing.
2021-01-26 Richard Biener <rguenther@suse.de>
PR middle-end/98726
* tree.h (vector_cst_int_elt): Remove.
* tree.c (vector_cst_int_elt): Use poly_wide_int for computations,
make static.
libgcc/ChangeLog:
PR gcov-profile/98739
* libgcov.h (gcov_topn_add_value): Do not train when
we have a merged profile with a negative number of total
value.
I don't know why these were disabled. There're no direct min/max DPP
instructions for this mode, but the "use moves" strategy works fine.
gcc/ChangeLog:
* config/gcn/gcn.c (gcn_expand_reduc_scalar): Use move instructions
for V64DFmode min/max reductions.
D front-end changes:
- Contracts for pre- and postconditions are now implicitly "this"
const, so that state can no longer be altered in these functions.
- Inside a constructor scope, assigning to aggregate declaration
members is done by considering the first assignment as initialization
and subsequent assignments as modifications of the constructed
object. For const/immutable fields the initialization is accepted in
the constructor but subsequent modifications are not. However this
rule did not apply when inside a constructor scope there is a call to
a different constructor. This been changed so it is now an error
when there's a double initialization of immutable fields inside a
constructor.
Phobos changes:
- Don't run unit-tests for unsupported clocks in std.datetime. The
phobos and phobos_shared tests now add -fversion=Linux_Pre_2639 if
required.
- Deprecate public extern(C) bindings for getline and getdelim in
std.stdio. The correct module for bindings is core.sys.posix.stdio.
Reviewed-on: https://github.com/dlang/dmd/pull/12153https://github.com/dlang/phobos/pull/7768
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd 609c3ce2d.
* d-compiler.cc (Compiler::loadModule): Rename to ...
(Compiler::onParseModule): ... this.
(Compiler::onImport): New function.
* d-lang.cc (d_parse_file): Remove call to Compiler::loadModule.
libphobos/ChangeLog:
* src/MERGE: Merge upstream phobos 3dd5df686.
* testsuite/libphobos.phobos/phobos.exp: Add compiler flag
-fversion=Linux_Pre_2639 if target is linux_pre_2639.
* testsuite/libphobos.phobos_shared/phobos_shared.exp: Likewise.
The new testcase FAILs on i686-linux with:
gcc/testsuite/gcc.dg/pr98807.c: In function 'foo0':
gcc/testsuite/gcc.dg/pr98807.c:20:1: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
gcc/testsuite/gcc.dg/pr98807.c:19:1: note: the ABI for passing parameters with 16-byte alignment has changed in GCC 4.6
gcc/testsuite/gcc.dg/pr98807.c:19:1: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi]
FAIL: gcc.dg/pr98807.c (test for excess errors)
Adding usual testcase treatment for such cases.
2021-01-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/98807
* gcc.dg/pr98807.c: Add -Wno-psabi -w to dg-options.
For the 32-bit targets the limitations of the object
file format (e.g. 32-bit ELF) will not allow > 2GiB debug info anyway,
and as I've just tested, e.g. on x86_64 with -m32 -gdwarf64 will not work
even on tiny testcases:
as: pr64716.o: unsupported relocation type: 0x1
pr64716.s: Assembler messages:
pr64716.s:6013: Error: cannot represent relocation type BFD_RELOC_64
as: pr64716.o: unsupported relocation type: 0x1
pr64716.s:6015: Error: cannot represent relocation type BFD_RELOC_64
as: pr64716.o: unsupported relocation type: 0x1
pr64716.s:6017: Error: cannot represent relocation type BFD_RELOC_64
So yes, we can either do a sorry, error, or could just avoid 64-bit
relocations (depending on endianity instead of emitting
.quad expression_that_needs_relocation
emit
.long expression_that_needs_relocation, 0
or
.long 0, expression_that_needs_relocation
This patch implements that last option, dunno if we need also configure tests
for that or not, maybe some 32-bit targets use 64-bit ELF and can handle such
relocations.
> 64bit relocs are not required here? That is, can one with
> dwarf64 choose 32bit forms for select offsets (like could
> dwz exploit this?)?
I guess it depends on whether for 32-bit target and -gdwarf64, when
calling dw2_assemble_integer with non-CONST_INT argument we only
need positive values or might need negative ones too.
Because positive ones can be easily emulated through that
.long expression, 0
or
.long 0, expression
depending on endianity, but I'm afraid there is no way to emit
0 or -1 depending on the sign of expression, when it needs relocations.
Looking through dw2_asm_output_delta calls, at least the vast majority
of the calls seem to guarantee being positive, not 100% sure about
one case in .debug_line views, but I'd hope it is ok too.
In most cases, the deltas are between two labels where the first one
in the arguments is later in the same section than the other one,
or where the second argument is the start of a section or another section
base.
2021-01-26 Jakub Jelinek <jakub@redhat.com>
* dwarf2asm.c (dw2_assemble_integer): Handle size twice as large
as DWARF2_ADDR_SIZE if x is not a scalar int by emitting it as
two halves, one with x and the other with const0_rtx, ordered
depending on endianity.
GNAT may create temporaries to hold return values of function calls.
If such a temporary is created as part of a dynamic initializer of a
variable in a unit other than the one being compiled, the initializer
is dropped, including the temporary and its binding block.
Don't issue asan mark calls for such variables, they are gone.
for gcc/ChangeLog
* gimplify.c (gimplify_decl_expr): Skip asan marking calls for
temporaries not seen in binding block, and not about to be
added as gimple variables.
for gcc/testsuite/ChangeLog
* gnat.dg/asan1.adb: New test.
* gnat.dg/asan1_pkg.ads: New additional source.
Check for initialization of substrings beyond bounds in DATA statements.
gcc/fortran/ChangeLog:
PR fortran/70070
* data.c (create_character_initializer): Check substring indices
against bounds.
(gfc_assign_data_value): Catch error returned from
create_character_initializer.
gcc/testsuite/ChangeLog:
PR fortran/70070
* gfortran.dg/pr70070.f90: New test.
In this testcase, cxx_eval_store_expression got confused trying to build up
CONSTRUCTORs for initializing a subobject because the subobject is a member
of an empty base. In C++14 mode and below we don't build FIELD_DECLs for
empty bases, so the CONSTRUCTOR skipped the empty base, and treated the
member as a member of the derived class, which breaks.
Fixed by recognizing this situation and giving up on trying to build a
CONSTRUCTOR for the inner target at that point; since it doesn't have any
data, we don't need to actually store anything.
gcc/cp/ChangeLog:
PR c++/98463
* constexpr.c (get_or_insert_ctor_field): Add check.
(cxx_eval_store_expression): Handle discontinuity of refs.
gcc/testsuite/ChangeLog:
PR c++/98463
* g++.dg/cpp2a/no_unique_address8.C: New test.
binutils since https://sourceware.org/bugzilla/show_bug.cgi?id=25612
changes from March last year until the
https://sourceware.org/pipermail/binutils/2020-August/112684.html
fix in early August emits incorrect .debug_info when assembling files
with --gdwarf-5. Instead of emitting proper DWARF 5 .debug_info header,
it emits DWARF 4 .debug_info header with 5 as the dwarf version instead of
4. This results e.g. in libgcc.a (morestack.o) having garbage in its
.debug_info sections and e.g. libbacktrace during pretty much all libgo
tests fails miserably.
The following patch adds a workaround for that, don't set
HAVE_AS_GDWARF_5_DEBUG_FLAG if readelf can't read the .debug_info back.
Built tested on x86_64-linux against both binutils 2.35 (buggy ones) and
latest binutils trunk, the former with the patch now has DWARF 3
.debug_line and DWARF 2 .debug_info in morestack.o, while the latter
as before correct DWARF 5 .debug_line and .debug_info.
2021-01-25 Jakub Jelinek <jakub@redhat.com>
PR debug/98811
* configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG): Only define if
readelf -wi is able to read the emitted .debug_info back.
* configure: Regenerated.
This simplifies vector_element_bits further, avoiding any mode
dependence and instead relying on boolean vector construction
to populate element precision accordingly.
2021-01-25 Richard Biener <rguenther@suse.de>
PR middle-end/98807
* tree.c (vector_element_bits): Always use precision of
the element type for boolean vectors.
* gcc.dg/pr98807.c: New testcase.
We have to use ENDFILE_SPEC for the default linker script and not
STARTFILE_SPEC, since STARTFILE_SPEC is place before the user provided
library search paths.
gcc/
* config/rtems.h (STARTFILE_SPEC): Remove qnolinkcmds.
(ENDFILE_SPEC): Evaluate qnolinkcmds.
This is a regression present on the mainline, 10 and 9 branches, in the
form of an internal error with the Ada compiler when a covariant-only
thunk is inlined into its caller.
gcc/ada/
* gcc-interface/trans.c (make_covariant_thunk): Set the DECL_CONTEXT
of the parameters and do not set TREE_PUBLIC on the thunk.
(maybe_make_gnu_thunk): Pass the alias to the covariant thunk.
* gcc-interface/utils.c (finish_subprog_decl): Set the DECL_CONTEXT
of the parameters here...
(begin_subprog_body): ...instead of here.
gcc/testsuite/
* gnat.dg/thunk2.adb, gnat.dg/thunk2.ads: New test.
* gnat.dg/thunk2_pkg.ads: New helper.
2021-01-25 Steve Kargl <kargl@gcc.gnu.org>
gcc/fortran
PR fortran/98517
* resolve.c (resolve_charlen): Check that length expression is
present before testing for scalar/integer..
gcc/testsuite/
PR fortran/98517
* gfortran.dg/charlen_18.f90 : New test.
The use of -nostdlib and -nodefaultlibs disables the processing of
LIB_SPEC (%L) as specified by LINK_COMMAND_SPEC and thus disables the
default linker script for RTEMS. Move the linker script to
STARTFILE_SPEC which is controlled by -nostdlib and -nostartfiles. This
fits better since the linker script defines the platform start file
provided by the board support package in RTEMS.
gcc/
* config/rtems.h (STARTFILE_SPEC): Remove nostdlib and
nostartfiles handling since this is already done by
LINK_COMMAND_SPEC. Evaluate qnolinkcmds.
(ENDFILE_SPEC): Remove nostdlib and nostartfiles handling since this
is already done by LINK_COMMAND_SPEC.
(LIB_SPECS): Remove nostdlib and nodefaultlibs handling since
this is already done by LINK_COMMAND_SPEC. Remove qnolinkcmds
evaluation.
As mentioned in the PR, the compiler behaves differently during strncmp
and strncasecmp folding between 32-bit and 64-bit hosts targeting 64-bit
target. I think that is highly undesirable.
The culprit is the host_size_t_cst_p predicate that is used by
fold_const_call, which punts if the target size_t constants don't fit into
host size_t. This patch gets rid of that behavior, instead it punts the
same when it doesn't fit into uhwi.
The predicate was used for strncmp and strncasecmp folding and for bcmp, memcmp and
memchr folding.
The constant is in all cases compared to 0, we can do that whether it fits
into size_t or unsigned HOST_WIDE_INT, then it is used in s2 <= s0 or
s2 <= s1 comparisons where s0 and s1 already have uhwi type and represent
the sizes of the objects.
The important difference is for strn{,case}cmp folding, we pass that s2
value as the last argument to the host functions comparing the c_getstr
results. If s2 fits into size_t, then my patch makes no difference,
but if it is larger, we know the 2 c_getstr objects need to fit into the
host address space, so larger s2 should just act essentially as strcmp
or strcasecmp; as none of those objects can occupy 100% of the address
space, using MIN (SIZE_MAX, s2) achieves that.
2021-01-25 Jakub Jelinek <jakub@redhat.com>
PR testsuite/98771
* fold-const-call.c (host_size_t_cst_p): Renamed to ...
(size_t_cst_p): ... this. Check and store unsigned HOST_WIDE_INT
value rather than host size_t.
(fold_const_call): Change type of s2 from size_t to
unsigned HOST_WIDE_INT. Use size_t_cst_p instead of
host_size_t_cst_p. For strncmp calls, pass MIN (s2, SIZE_MAX)
instead of s2 as last argument.
The dynamic section on MIPS is read-only, but this was not properly
handled in the runtime library. The segfault only occurred for programs
that linked to the shared libphobos library.
libphobos/ChangeLog:
PR d/98806
* libdruntime/gcc/sections/elf_shared.d (MIPS_Any): Declare version
for MIPS32 and MIPS64.
(getDependencies): Adjust dlpi_addr on MIPS_Any.
This patch fixes PR17314. Previously, when class C attempted
to access member a declared in class A through class B, where class B
privately inherits from A and class C inherits from B, GCC would correctly
report an access violation, but would erroneously report that the reason was
because a was "protected", when in fact, from the point of view of class C,
it was really "private". This patch updates the diagnostics code to generate
more correct errors in cases of failed inheritance such as these.
The reason this bug happened was because GCC was examining the
declared access of decl, instead of looking at it in the
context of class inheritance.
gcc/cp/ChangeLog:
2021-01-21 Anthony Sharp <anthonysharp15@gmail.com>
* call.c (complain_about_access): Altered function.
* cp-tree.h (complain_about_access): Changed parameters of function.
(get_parent_with_private_access): Declared new function.
* search.c (get_parent_with_private_access): Defined new function.
* semantics.c (enforce_access): Modified function.
* typeck.c (complain_about_unrecognized_member): Updated function
arguments in complain_about_access.
gcc/testsuite/ChangeLog:
2021-01-21 Anthony Sharp <anthonysharp15@gmail.com>
* g++.dg/lookup/scoped1.C: Modified testcase to run successfully
with changes.
* g++.dg/tc1/dr142.C: Same as above.
* g++.dg/tc1/dr52.C: Same as above.
* g++.old-deja/g++.brendan/visibility6.C: Same as above.
* g++.old-deja/g++.brendan/visibility8.C: Same as above.
* g++.old-deja/g++.jason/access8.C: Same as above.
* g++.old-deja/g++.law/access4.C: Same as above.
* g++.old-deja/g++.law/visibility12.C: Same as above.
* g++.old-deja/g++.law/visibility4.C: Same as above.
* g++.old-deja/g++.law/visibility8.C: Same as above.
* g++.old-deja/g++.other/access4.C: Same as above.
The x86 __m64 type is defined as:
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));
and so matches the comment above it in that reads and stores through
pointers to __m64 can alias anything.
But in the rs6000 headers that is the case only for __m128, but not __m64.
The following patch adds that attribute, which fixes the
FAIL: gcc.target/powerpc/sse-movhps-1.c execution test
FAIL: gcc.target/powerpc/sse-movlps-1.c execution test
regressions that appeared when Honza improved ipa-modref.
2021-01-23 Jakub Jelinek <jakub@redhat.com>
PR testsuite/97301
* config/rs6000/mmintrin.h (__m64): Add __may_alias__ attribute.
In the testcase pr97399.C below, finish_qualified_id_expr at parse time
adds an implicit 'this->' to the expression tmp::integral<T> (because
it's type-dependent, and also current_class_ptr is set at this point)
within the trailing return type. Later when substituting into this
trailing return type we crash because we can't resolve the 'this', since
tsubst_function_type does inject_this_parm only for non-static member
functions, which tmp::func is not.
This patch fixes this issue by removing the type-dependence check
in finish_qualified_id_expr added by r9-5972, and instead relaxes
shared_member_p to handle dependent USING_DECLs:
> I think I was wrong in my assertion around Alex's patch that
> shared_member_p should abort on a dependent USING_DECL; it now seems
> appropriate for it to return false if we don't know, we just need to
> adjust the comment to say that.
And when parsing a friend function declaration, we shouldn't be setting
current_class_ptr at all, so this patch additionally suppresses
inject_this_parm in this case.
Finally, the self-contained change to cp_parser_init_declarator is so
that we properly communicate static-ness to cp_parser_direct_declarator
when parsing a member function template. This lets us reject the
explicit use of 'this' in the testcase this2.C below.
gcc/cp/ChangeLog:
PR c++/97399
* cp-tree.h (shared_member_p): Adjust declaration.
* parser.c (cp_parser_init_declarator): If the storage class
specifier is sc_static, pass true for static_p to
cp_parser_declarator.
(cp_parser_direct_declarator): Don't do inject_this_parm when
the declarator is a friend.
* search.c (shared_member_p): Change return type to bool and
adjust function body accordingly. Return false for a dependent
USING_DECL instead of aborting.
* semantics.c (finish_qualified_id_expr): Rely on shared_member_p
even when type-dependent.
gcc/testsuite/ChangeLog:
PR c++/88548
PR c++/97399
* g++.dg/cpp0x/this2.C: New test.
* g++.dg/template/pr97399.C: New test.
The recent vec insert code generation changes were not reflected in the
expected output for ilp32 targets. This patch updates the expected
instructions and counts.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/fold-vec-insert-char-p9.c: Adjust ilp32.
* gcc.target/powerpc/fold-vec-insert-float-p9.c: Same.
* gcc.target/powerpc/fold-vec-insert-int-p9.c: Same.
* gcc.target/powerpc/fold-vec-insert-longlong.c: Same.
* gcc.target/powerpc/fold-vec-insert-short-p9.c: Same.
* gcc.target/powerpc/pr79251.p9.c: Same.
I discovered very strange code in inject_parm_decls:
if (args && is_this_parameter (args))
{
gcc_checking_assert (current_class_ptr == NULL_TREE);
current_class_ptr = NULL_TREE;
We are tripping up on the assert because when we call inject_parm_decls,
current_class_ptr is set to 'A'. It was set by inject_this_parameter
after we've parsed the parameter-declaration-clause of the member
function foo. It seems correct to set ccp/ccr to A::B when we're
late parsing the noexcept-specifiers of bar* functions in B, so that
this-> does the right thing. Since inject_parm_decls doesn't expect
to see non-null ccp/ccr, reset it before calling inject_parm_decls.
gcc/cp/ChangeLog:
PR c++/96623
* parser.c (inject_parm_decls): Remove a redundant assignment.
(cp_parser_class_specifier_1): Clear current_class_{ptr,ref}
before calling inject_parm_decls.
gcc/testsuite/ChangeLog:
PR c++/96623
* g++.dg/cpp0x/noexcept64.C: New test.
This testcase was disabled in the distant past when AIX did not have
support for DWARF and the testcase explicitly invokes DWARF debugging.
This patch re-enables the testcase.
gcc/testsuite/ChangeLog:
* g++.dg/eh/spbp.C: Remove skip on AIX.
