int8_t is currently defined as char in Solaris <sys/int_types.h>
/*
* Basic / Extended integer types
*
* The following defines the basic fixed-size integer types.
*
* Implementations are free to typedef them to Standard C integer types or
* extensions that they support. If an implementation does not support one
* of the particular integer data types below, then it should not define the
* typedefs and macros corresponding to that data type. Note that int8_t
* is not defined in -Xs mode on ISAs for which the ABI specifies "char"
* as an unsigned entity because there is no way to define an eight bit
* signed integral.
*/
typedef char int8_t;
typedef signed char int8_t;
and _CHAR_IS_SIGNED defined as 1 in <sys/isa_defs.h>. As has long been
known, this violates C99, 7.18.1.1, Exact-width integer types.
While this works in general nonetheless, it creates constant trouble for
C++ code as can be seen in PRs libstdc++/113450 and recently
libstdc++/123176, but also in LLVM.
While Oracle Solaris engineering is amenable to changing int8_t to
signed char, this will take time. However, it proved easy to do so now
using fixincludes.
This works for a GCC bootstrap just fine with one exception: as
documented in PR d/123509, libdruntime has its own definition of int8_t
which is now inconsistent with GCC's. This leads to some gdc.test and
libphobos testsuite failures, which can easily be fixed with the patch
attached to that PR. I wouldn't consider this a showstopper for GCC 16
if that patch wouldn't make it to the release.
However, the failures point to another problem: with this change, the
mangling of
void func(int8_t);
changes in C++, creating an ABI break. Fortunately, this isn't seen in
libstdc++, so the impact should be reasonable compared to the constant
trouble the current definition causes for C++.
Besides, clang already uses
#define __INT8_TYPE__ signed char
apparently without problems.
In case users do run into the incompatiblity, the fixed definitions are
wrapped in #if !defined(_LEGACY_INT8_T)/#endif so there's an easy way back
to the original definition.
Bootstrapped on i386-pc-solaris2.11, amd64-pc-solaris2.11,
sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 with only the D
failure described above.
I've also run 1-stage and bootstrap builds of LLVM main using a patched
GCC 16 as bootstrap compiler on amd64-pc-solaris2.11 and
sparcv9-sun-solaris2.11 without regressions.
2026-01-07 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
fixincludes:
PR libstdc++/113450
PR libstdc++/123176
* inclhack.def (solaris_int8_t): New fix.
* fixincl.x: Regenerate.
gcc:
PR libstdc++/113450
PR libstdc++/123176
* config/sol2.h (INT8_TYPE): Change to signed char.
(INT_LEAST8_TYPE): Likewise.
(INT_FAST8_TYPE): Likewise.
The change in r16-7507 misses a cast on the value to pp_scalar which
leads to a bootstrap fail on 32b hosts where size_t has a different
declaration from the value. Fixed by applying the fmt_size_t cast.
gcc/ChangeLog:
* json.cc (pointer::token::print): Cast the value to pp_scalar
with (fmt_size_t).
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
Fix ICE caused by speculating already speculated target with auto-fdo.
ipa_devirt is supposed to consistently skip devirtualized edges (or just check
if devirtualization agrees with the static prediction when dumping). This was
not hecked correctly in the simpe call path.
gcc/ChangeLog:
* ipa-devirt.cc (ipa_devirt): Improve statistics for multi-target
devirtualization; do not simple-call devirtualize already devirtualized calls.
Here the lambda has a by-value capture of non-trivial type, which
in turn makes the closure type non-trivial. This means its by-value
'this' parameter, which gets deduced to the closure type, becomes an
invisiref parameter, and so when lowering the operator() body we need to
adjust uses of 'this' by adding implicit dereferences.
But the GIMPLE dump for operator() shows that we miss some adjustments:
bool main()::<lambda(this auto:1)>::operator()<main()::<lambda(this auto:1)> > (struct ._anon_0 & self)
{
bool D.3091;
struct ._anon_0 & self.1;
struct A a [value-expr: self.__a]; // should be self->__a
self.1 = self;
_1 = self.1.__a.n; // should be self.1->__a
D.3091 = _1 == 42;
return D.3091;
}
Apparently this is because cp_genericize_r, which is responsible for the
invisiref use adjustments, never walks DECL_VALUE_EXPR. This patch makes
us walk it. For GCC 16, restrict the walking to xobj lambdas.
PR c++/121500
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_genericize_r): Walk DECL_VALUE_EXPR within
an xobj lambda.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-lambda20.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
The SPARC ISA extensions guarded by HAVE_AS_FMAF_HPC_VIS3 etc. have been
supported both in the Solaris as and GNU as for a long time. The
original Solaris 11.4 as supports all of them, and gas support has been
added over time:
HAVE_AS_FMAF_HPC_VIS3 -xarch=v9d 2.22
HAVE_AS_SPARC4 -xarch=sparc4 2.23.1
HAVE_AS_SPARC5_VIS4 -xarch=sparc5 2.25
HAVE_AS_SPARC6 -xarch=sparc6 2.29
Solaris requires binutils 2.30 already on trunk, and 2.29 can be
expected on other SPARC targets, too, so this patch removes all code
that checks for their presence.
Bootstrapped without regressions on sparc-sun-solaris2.11 (as and gas),
sparcv9-sun-solaris2.11 (as), and sparc64-unknown-linux-gnu.
2026-02-14 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc:
* configure.ac <sparc*-*-*> (gcc_cv_as_sparc_fmaf): Remove.
(gcc_cv_as_sparc_sparc4): Remove.
(gcc_cv_as_sparc_sparc): Remove.
(gcc_cv_as_sparc_sparc6): Remove.
* configure: Regenerate.
* config.in: Regenerate.
* config/sparc/sparc.h (AS_NIAGARA3_FLAG) Remove. Replace uses by
definition.
(AS_NIAGARA4_FLAG): Likewise.
(AS_NIAGARA7_FLAG): Likewise.
(AS_M8_FLAG): Likewise.
* config/sparc/sol2.h [!HAVE_AS_SPARC4]: Remove.
(AS_SPARC32_FLAG): Remove.
(AS_SPARC64_FLAG): Remove.
(AS_NIAGARA3_FLAG) Replace uses by definition.
(AS_NIAGARA4_FLAG): Likewise.
(AS_NIAGARA7_FLAG): Likewise.
(AS_M8_FLAG): Likewise.
* config/sparc/sparc.cc (sparc_option_override):
[!HAVE_AS_FMAF_HPC_VIS3]: Remove.
[!HAVE_AS_SPARC4]: Likewise.
[!HAVE_AS_SPARC5_VIS4]: Likewise.
[!HAVE_AS_SPARC6]: Likewise.
So a few more restrictions are needed here.
First we don't need to change if the return statement is already
a RESULT_DECL nor deference of the RESULT_DECL.
Second proping a global variable into the return is ok for the most
part except enumtls does not know how to expand that correctly and things
go down hill. So restrict to non global vars now.
Bootstrapped and tested on x86_64-linux-gnu.
Also tested the testcase with TLS turned off so enumtls ran.
PR tree-optimization/124099
gcc/ChangeLog:
* tree-ssa-forwprop.cc (optimize_agr_copyprop_return): Don't do anything
if the return is already result decl or a deference of result decl.
Also reject non local var decls.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/tls-return-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
2026-02-15 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/108663
* decl.cc (gfc_get_pdt_instance): Use PDT_PREFIX and
PDT_PREFIX_LEN.
* gfortran.h : Define PDT_PREFIX and PDT_PREFIX_LEN. Note that
PDT_PREFIX must have at least two upper case letters.
* module.cc (read_module): Use PDT_PREFIX and PDT_PREFIX_LEN.
* resolve.cc (resolve_typebound_procedure): Both pdt_template
and pdt_type resolve_bindings_derived dummies should be tested
for LEN type parameters being assumed.
* symbol.cc (gfc_pdt_is_instance_of): Update preceding comment
and use PDT_PREFIX_LEN.
gcc/testsuite
PR fortran/108663
* gfortran.dg/pdt_15.f03: Modify tree dump test for new prefix.
* gfortran.dg/pdt_71.f03: Ditto.
* gfortran.dg/pdt_79.f03: Ditto.
* gfortran.dg/pdt_84.f03: New test.
On some targets (ia32 for an example), sizeof long double
is not a power of 2, this means you can't create a vector
of it. So let's disable this testcase for non power of 2
sizeof long double. This needs to be done via a preprocessor
macro as vector_size would cause an error otherwise.
Committed as obvious after a test on x86_64 with -m32.
gcc/testsuite/ChangeLog:
* c-c++-common/torture/pr124086-1.c: Only enable
for power of 2 long double.
The following patch adds new configure options similar to ObjC/Algol68
--with-bdw-gc{,-lib,-include}= configure options where one can override
the default of -I /usr/include/libxml2 and -lxml2 for finding libxml2
headers and library. Similarly to the bdw-gc options, the override can
be for all multilibs or just specific to each multilib.
Tested also with
../configure --enable-languages=c,c++,cobol --with-target-libxml2=/tmp/libxml2 \
--disable-bootstrap --disable-libsanitizer --disable-libgomp
2026-02-14 Jakub Jelinek <jakub@redhat.com>
PR cobol/122839
* configure.ac (--with-target-libxml2, --with-target-libxml2-include,
--with-target-libxml2-lib): New configure options, use those to find
libxml2.
(LIBXML2_CPPFLAGS, LIBXML2_LIBS): New AC_SUBSTs.
* Makefile.am (AM_CPPFLAGS): Add $(LIBXML2_CPPFLAGS) rather than
-I /usr/include/libxml2.
(libgcobol_la_LDFLAGS): Add $(LIBXML2_LIBS).
* configure: Regenerate.
* config.h.in: Regenerate.
* Makefile.in: Regenerate.
* doc/install.texi (COBOL-Specific Options): New.
Since the introduction of gcc_cv_as_flags on SPARC,
HAVE_AS_SPARC_GOTDATA_OP became undefined on sparcv9-sun-solaris2.11
with the native assembler. This happens because /bin/as is now invoked
with -m64, but the test fails to assemble:
/bin/as: "gotdata_op.s", line 8: error: detect global register use not covered .register pseudo-op
While the test can be adjusted by the addition of
.register %g2, #scratch
which makes it work with both as -m32/-m64 and gas --32/--64, it
turns out the whole workaround has become unnecessary:
When trying all combinations of as/ld with -m32/-m64, with both the
original Solaris 11.4 as/ld and the current one, as well as gas/gld
2.20.1, 2.30, and 2.46, the only cases where the test fails are when
using gld 2.20.1. Solaris/SPARC requires binutils 2.30 now, and 2.20.1
can be considered ancient history on Linux/sparc64, too. Therefore the
test and the code guarded by it can just go.
Bootstrapped without regressions on sparc{,v9}-sun-solaris2.11 and
sparc64-unknown-linux-gnu.
2026-02-12 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc:
* configure.ac <sparc*-*-*> (gcc_cv_as_sparc_gotdata_op): Remove.
* configure: Regenerate.
* config.in: Regenerate.
* config/sparc/sparc.md [!HAVE_AS_SPARC_GOTDATA_OP]: Remove.
When cross-compiling itself for VAX, GCC terminates abruptly with an ICE
when compiling gimple_match.cc; the root cause seems to be an
incompletely removed computed jump instruction, which causes the
assertion in cfgrtl.cc around line 4083, to no longer hold.
I have verified that the problem is present in GCC 15.2.0 and believe
that it's also present in trunk (based on the fact that the patterns for
the "casesi1" and "*casesi1" instructions in 15.2.0 and trunk are the
same).
To fix this issue wrap the limit operand in a USE, to allow `single_set'
to identify it as an RTL expression setting PC. This allows the
optimizer to optimize away case statements branching only to a basic
block, removing the ICE.
Include a test case reduced from gimple_match.cc, which demonstrates the
problem in GCC 15.2.0 on NetBSD/amd64 cross-compiling for VAX.
gcc/
PR target/112400
* config/vax/vax.md (casesi1): Wrap naked operand 1 with a USE
where used with the insn split to.
(*casesi1): Likewise naked incoming operand 1.
gcc/testsuite/
PR target/112400
* g++.dg/torture/pr112400.C: New file.
Replace an unguarded early access to the incoming RTX's operand 0 in
`nonindexed_address_p' with direct accesses at the actual use places,
fixing a libgcc build error:
during RTL pass: reload
.../libgcc/libgcc2.c: In function '__udiv_w_sdiv':
.../libgcc/libgcc2.c:649:1: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'r' (rtx reg) in nonindexed_address_p, at config/vax/vax.cc:1826
where `--enable-checking=rtl' has been specified so as to enable RTL
consistency checks.
gcc/
* config/vax/vax.cc (nonindexed_address_p): Move incoming RTX's
operand 0 access to the actual use places.
Fix iterator-depth pre-counting in gfc_resolve_forall for nested
DO CONCURRENT/FORALL constructs inside block arms (e.g. IF/ELSE,
SELECT CASE). The previous logic only scanned a flat next-chain,
which could undercount and trigger an ICE assertion.
Add a regression test based on a reduced testcase from Harald Anlauf.
Adjust wording in one comment to avoid GNU-style checker complaints.
PR fortran/123943
gcc/fortran/ChangeLog:
* resolve.cc (gfc_max_forall_iterators_in_chain): New helper
function for factorization of iterator-depth counting.
(gfc_count_forall_iterators): Use it.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr123943.f90: New test.
Co-authored-by: Harald Anlauf <anlauf@gcc.gnu.org>
Signed-off-by: Christopher Albert <albert@tugraz.at>
2026-02-14 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/99250
* check.cc (gfc_check_coshape): New function.
* gfortran.h: Add GFC_ISYM_COSHAPE to gfc_isym_id.
* intrinsic.cc (add_functions): Add the coshape prototype and
its 'make_generic'.
* intrinsic.h: Add prototypes for gfc_check_coshape and
gfc_resolve_coshape.
* intrinsic.texi : Add entries for coshape.
* iresolve.cc (gfc_resolve_coshape): New function.
* trans-array.cc (gfc_conv_ss_startstride): Add 'case
GFC_ISYM_COSHAPE' in two places.
* trans-intrinsic.cc (conv_intrinsic_cobound): Modify assert in
scalarized section for lbound. Set bound to zero for scalar
case of coshape. Keep the lbound and use it together with the
scalarized ubound to obtain the coshape.
(gfc_conv_intrinsic_function, gfc_add_intrinsic_ss_code and
gfc_walk_intrinsic_function): Add 'case GFC_ISYM_COSHAPE' as
appropriate.
gcc/testsuite/
PR fortran/99250
* gfortran.dg/coshape_1.f90: New test.
This was an oversight on my part when I converted extract_component
to use gimple_build_assign instead of force_gimple_operand_gsi.
I had provided a special case for VCE of a SSA_NAME but I missed
that the same issue would be caused with invariants too and invariants
would show up with VCE; I assumed they would be folded.
This changes the check to include invariants too.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/124086
gcc/ChangeLog:
* tree-complex.cc (extract_component): Extend the check
for ssa names for VCE to include invariants.
gcc/testsuite/ChangeLog:
* c-c++-common/torture/pr124086-1.c: New test.
* g++.dg/torture/pr124086-1.C: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
This testcase fails on some targets so just limit to x86_64 (non-ia32) and aarch64
which are known to work here.
Pushed as obvious after testing.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/copy-prop-aggregate-return-1.c: Limit check to x86_64
and aarch64.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
I had forgot to check to make sure address sanitizer is supported.
Disable this test case if there is no address sanitizer.
Pushed as obvious after testing it.
gcc/testsuite/ChangeLog:
* g++.dg/warn/uninit-pr95825-1.C: Skip if no address sanitizer.
Recent patch for PR121191 broke compilation of s390 SPEC benchmarks.
This patch fixes it. The patch uses existing lra_constraint_offset to
calculate offsets. The same function is used to find invalid matching
reloads.
gcc/ChangeLog:
PR rtl-optimization/124079
* lra-constraints.cc (get_matching_reload_reg_subreg): Add new arg
rclass. Use another condition to use lowpart_subreg. Use lra_constraint_offset
to calculate the subreg offset.
(get_reload_reg, match_reload): Pass the new arg.
gcc/testsuite/ChangeLog:
PR rtl-optimization/124079
* gcc.target/s390/pr124079.c: New.
Code for implementing many common scenarios of "MOVE <literal> TO
<alphanumeric>" and " MOVE <alphanumeric> to <alphanumeric> " is created
directly through GENERIC rather than by calling the general-purpose
libgcobol __gg__move routine.
gcc/cobol/ChangeLog:
PR cobol/119455
* genapi.cc (mh_source_is_group): Formatting.
(mh_source_is_literalA): Implement accelerated move.
(mh_alpha_to_alpha): New function; implements accelerated move.
(move_helper): Calls new mh_alpha_to_alpha.
I didn't implement this before today as I had not see any code
where this would make a difference. I noticed while looking into
regressions an uninitialized warning that shows up only with
-fsanitize=address. This because SRA causes some extra total
scalaization when using -fsanitize=address. Which in turn exposes
an uninitialized warning. This fixes the uninitialized warning
by doing a simple copy prop into the return statement.
That is if we have:
```
D.3407 = D.3418;
return D.3407;
```
turn it into:
```
D.3407 = D.3418;
return D.3418;
```
This forces SRA not to do total scalarization on D.3418 and allows for better code
too.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/95825
gcc/ChangeLog:
* tree-ssa-forwprop.cc (optimize_agr_copyprop_return): New function.
(optimize_agr_copyprop): Call optimize_agr_copyprop_return
for return statements.
gcc/testsuite/ChangeLog:
* g++.dg/warn/uninit-pr95825-1.C: New test.
* gcc.dg/tree-ssa/copy-prop-aggregate-return-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
This patch improves various reflection diagnostics as discussed in
<https://gcc.gnu.org/pipermail/gcc-patches/2025-December/704168.html>.
In particular:
- reword "not usable" diagnostics to say what kind of reflections we
expected,
- use the new inform_tree_category to better describe what kind of reflection
we actually got,
- when we see a missing 'template' keyword, emit a -Wmissing-template-keyword
warning instead of giving a hard error (this should only happen when the
code would be valid with the 'template' added.
gcc/cp/ChangeLog:
* cp-tree.h (inform_tree_category): Declare.
* error.cc (inform_tree_category): New.
* parser.cc (cp_parser_splice_specifier): Use OVL_FIRST when checking
for TEMPLATE_DECL.
(cp_parser_splice_type_specifier): Reword an error message. Call
inform_tree_category.
(cp_parser_splice_expression): Check check_splice_expr earlier. Reword
error messages. Call inform_tree_category. Turn an error into an
assert. Use missing_template_diag instead of giving an error about
a missing 'template' keyword.
(cp_parser_splice_scope_specifier): Reword an error message. Call
inform_tree_category.
(missing_template_diag): Forward declare. Drop "enum" in a parameter.
* reflect.cc (check_splice_expr): Reword error messages. Call
inform_tree_category.
gcc/testsuite/ChangeLog:
* g++.dg/reflect/crash10.C: Adjust expected diagnostics.
* g++.dg/reflect/crash2.C: Likewise.
* g++.dg/reflect/crash3.C: Likewise.
* g++.dg/reflect/crash7.C: Likewise.
* g++.dg/reflect/crash9.C: Likewise.
* g++.dg/reflect/dep5.C: Likewise.
* g++.dg/reflect/diag1.C: Likewise.
* g++.dg/reflect/error10.C: Likewise.
* g++.dg/reflect/error12.C: Likewise.
* g++.dg/reflect/error5.C: Likewise.
* g++.dg/reflect/expr3.C: Likewise.
* g++.dg/reflect/member1.C: Likewise.
* g++.dg/reflect/ns2.C: Likewise. Test more cases.
* g++.dg/reflect/p2996-12.C: Likewise.
* g++.dg/reflect/splice5.C: Likewise.
* g++.dg/reflect/diag1a.C: New test.
* g++.dg/reflect/diag1b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
We ICE on the following testcase, because a constexpr structured binding
with consteval-only initializer of the whole struct but not for this exact
structured binding is used in a context where it is not constant evaluated
and folded into a constant.
The problem is that check_out_of_consteval_use during walking didn't walk
DECL_VALUE_EXPR of vars it sees being used. So we haven't noticed invalid
consteval-only use, the consteval-only base of the structured binding isn't
gimplified but the structured binding referencing that in its
DECL_VALUE_EXPR is and so we ICE during gimplification.
In order to fix that, I had to move the lambda into a separate function
(similarly to why consteval_only_type_r is not a lambda) so that it can
recurse with that.
That isn't the only problem though. DECL_VALUE_EXPR in this case is just
COMPONENT_REF with the underlying VAR_DECL (which is consteval-only).
But walker had:
if (VAR_P (t)
&& (DECL_DECLARED_CONSTEXPR_P (t) || DECL_DECLARED_CONSTINIT_P (t)))
/* This is fine, don't bother checking the type. */
return NULL_TREE;
and so wouldn't report anything even after the fix.
The reason why it works correctly in the
constexpr auto a = A {};
foo (a.a); // { dg-error "consteval-only expressions are only allowed in a constant-evaluated context" }
case is that in that case (no DECL_VALUE_EXPR) there is COMPONENT_REF
of VIEW_CONVERT_EXPR of the VAR_DECL (i.e. location wrapper) and so we
diagnose it on the location wrapper. That is just weird, we really
shouldn't depend on location wrappers being there for correct behavior
(rather than just for better locations). That if is there because
cp_finish_decl calls check_out_of_consteval_use on the whole VAR_DECL
and in that case we want to avoid diagnosing anything if it is
constexpr/constinit var. Maybe we just shouldn't call
check_out_of_consteval_use at all, though this patch moves that check to
an early out in that function rather than during the walk (similarly
to early out for expr == NULL_TREE which also happens occassionally).
If we see a constexpr/constinit VAR_DECL which is consteval-only
nested somewhere deep inside of other expressions, we should diagnose
that.
On Wed, Feb 11, 2026 at 08:58:26PM +0900, Jason Merrill wrote:
> I'd drop constinit, that doesn't seem to qualify under
> [basic.types.general]/12.1.
You're right. Seems constinit was still in P2996R9 but P2996R10
has removed it except for one occurrence in the revision history (that
is ok, but surprisingly the P2996R10 change that removed it is not
mentioned). So, this patch additionally stops special casing constinit
for consteval-only checks anywhere, only constexpr is significant.
There is an unresolved part of the PR, if there is
constexpr auto a = A {};
int b = a.a;
then we don't reject that (similarly after the patch with constexpr
structured binding). The problem in that case is that we try to
constant evaluate initializers of vars (and a few other spots) and
if they fold to constants (like in this case to 0) even when it is
not manifestly constant-evaluated, we just replace it with the constant
and so don't see there was a consteval-only use that should have
been reported. Of course, if it is something manifestly constant-evaluated
and folds into constant, it shouldn't be rejected.
So I wonder if we don't need to call check_out_of_consteval_use in
further spots...
2026-02-13 Jakub Jelinek <jakub@redhat.com>
PR c++/124012
* reflect.cc (check_out_of_consteval_use_r): New function.
(check_out_of_consteval_use): Use it instead of lambda. Don't ignore
constexpr/constinit vars in the walker and walk DECL_VALUE_EXPR of
vars which have it. Ignore expr equal to constexpr VAR_DECL. In
diagnostics only complain about missing constexpr on VAR_DECLs without
that flag and never suggest constinit. Remove constinit traces from
function comment.
* g++.dg/reflect/pr124012.C: New test.
* g++.dg/reflect/init1.C (r): Change constinit to constexpr.
(p): Change constinit to constexpr const.
* g++.dg/reflect/init6.C: Expect diagnostics for constinit
consteval-only vars.
* g++.dg/reflect/init7.C: Likewise.
* g++.dg/reflect/init10.C: Likewise.
* g++.dg/reflect/diag3.C: Likewise. Don't expect suggestion to
add constinit.
The following adjusts two uninit testcases to avoid a false negative
that appears when using -msoft-float on arm because the testcase
then mutates into a classical case of CCP eliding
# _11 = PHI <1.0e+0(2), f$real_9(D)(3)>
Avoid this by using a non-constant. And avoid flipping locations
for the diagnostic by not duplicating the return statement.
PR testsuite/115827
* gcc.dg/auto-init-uninit-17.c: Avoid CCP.
* gcc.dg/uninit-17.c: Likewise.
r16-7422-g13c2da6cdbd1a3 fixed an ICE that was due to caching of the
logical_locations::manager * in sarif_sink.
Do the same for html_sink.
gcc/ChangeLog:
PR diagnostics/124014
* diagnostics/html-sink.cc (html_builder::get_logical_loc_mgr):
New.
(html_builder::m_logical_loc_mgr): Drop field.
(html_builder::html_builder): Drop initialization of
m_logical_loc_mgr.
(html_builder::maybe_make_state_diagram): Use get_logical_loc_mgr
rather than m_logical_loc_mgr.
(html_builder::make_element_for_diagnostic): Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Testcases in gcc/testsuite/ may not '#include <omp.h>' or 'use omp_lib';
instead, now a local declaration of the enum/Fortran-parameter values is
used.
gcc/testsuite/ChangeLog:
PR middle-end/113436
* c-c++-common/gomp/pr113436-1.c: Replace '#include <omp.h>' by
local declaration for omp_allocator_handle_t.
* c-c++-common/gomp/pr113436-2.c: Likewise.
* g++.dg/gomp/pr113436.C: Likewise.
* gfortran.dg/gomp/pr113436-1.f90: Replace 'use omp_lib' by local
omp_*_mem_alloc parameter declarations.
* gfortran.dg/gomp/pr113436-2.f90: Likewise.
* gfortran.dg/gomp/pr113436-3.f90: Likewise.
* gfortran.dg/gomp/pr113436-4.f90: Likewise.
Presence implicit conversion from int to it's allocator, makes constructing
string from rvalue of same string type and int ambiguous, as none of following
candidates is better:
basic_string(basic_string&&, allocator_type)
// conversion from int to allocator for second argument
basic_string(const basic_string&, int, allocator_type)
// reference adjustment for first argument
This makes __gnu_test:uneq_allocator(int) constructor explicit, to avoid
above issues.
libstdc++-v3/ChangeLog:
* testsuite/20_util/scoped_allocator/construct_pair_c++2a.cc
(__gnu_test::uneq_allocator(int)): Declare as explicit.
* testsuite/std/memory/indirect/ctor.cc: Construct uneq_allocator
from int explicitly.
* testsuite/std/memory/polymorphic/ctor.cc: Likewise.
* testsuite/std/memory/polymorphic/ctor_poly.cc: Likewise.
* testsuite/util/testsuite_allocator.h: Likewise.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
The following includes DECL_NONLOCAL_FRAME in the processing for
setting debug expressions on access replacements, avoiding disabling
diagnostics.
PR tree-optimization/99959
* tree-sra.cc (create_access_replacement): Always create
debug expressions for DECL_NONLOCAL_FRAME bases.
* gcc.dg/uninit-pr99959.c: New testcase.
This is similar to the r16-3536-g0bb0d1d2880d56 change for std::pair, so
that CTAD ignores the tuple(const Types&...) constructor and only uses
the tuple(Types...) -> tuple<Types...> deduction guide. This ensures
that the deduced type comes from the decayed argument types.
libstdc++-v3/ChangeLog:
PR libstdc++/121771
* include/std/tuple (tuple::tuple(const Elements&...)): Use
type_identity_t to prevent constructor being used for CTAD.
(tuple::tuple(allocator_arg_t, const A&, const Elements&...)):
Likewise.
* testsuite/20_util/tuple/cons/121771.cc: New test.
Reviewed-by: Ville Voutilainen <ville.voutilainen@gmail.com>
This patch should have been a part of r16-6348-g4dfa48077e3892 but
unfortunately I forgot to bump these versions with it.
Bootstrapped and regtested on aarch64-linux-gnu.
Signed-off-by: Dhruv Chawla <dhruvc@nvidia.com>
gcc/ChangeLog:
* Makefile.in (all.fda): Bump profile_merger gcov_version to 3.
gcc/c/ChangeLog:
* Make-lang.in (cc1.fda): Likewise.
gcc/cp/ChangeLog:
* Make-lang.in (cc1plus.fda): Likewise.
gcc/lto/ChangeLog:
* Make-lang.in (lto1.fda): Likewise.
In some cases the C front-end calls into fold_offsetof to fold
an address but that does not handle REALPART_EXPR nor IMAGPART_EXPR so
gcc produces an internal compiler error. For offsetof, REALPART_EXPR/IMAGPART_EXPR
won't show up which is why they were not there before.
Bootstrapped and tested on x86_64-linux-gnu.
PR c/105555
gcc/c-family/ChangeLog:
* c-common.cc (fold_offsetof): Handle REALPART_EXPR
and IMAGPART_EXPR.
gcc/testsuite/ChangeLog:
* gcc.dg/complex-10.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
According to [temp.param], the constraint on an auto NTTP is an
associated constraint and so should be checked as part of satisfaction
of the overall associated constraints, but we currently don't include
them in the template's associated constraints and instead check them
separately during template argument coercion/deduction.
Fixing this is mostly a matter of storing the NTTP's constraint inside
TEMPLATE_PARM_CONSTRAINTS instead of PLACEHOLDER_TYPE_CONSTRAINTS and
generalizing the relevant template parameter processing subroutines to
also handle such NTTPs.
While this is straightfoward for "simple" constrained autos, it was
later noticed that for e.g. 'C auto* P' or 'D auto& Q' it's not clear
how to express their constraint as an associated constraint. For P an
option would be C<decltype(*P)>, but for Q it's not clear how to pass
the referenced type to C. C<decltype(auto(Q))> would be wrong because
we don't want to decay function/array types.
So this patch sidesteps this question by preserving the existing
behavior for such "non-simple" constrained auto (i.e. don't add them
to the associated constraints, and continue ad-hoc checking them during
do_auto_deduction). The simple case is by far the most common anyway.
The main observeable difference with this change is that such
constrained auto NTTPs are now involved in the "more constrained"
determination during partial ordering.
gcc/cp/ChangeLog:
* constraint.cc (finish_shorthand_constraint): Add is_non_type
parameter. Handle constrained auto NTTPs.
* cp-tree.h (copy_template_args): Declare.
(expand_template_argument_pack): Declare.
(finish_shorthand_constraint): Adjust declaration.
* mangle.cc (write_template_param_decl): Obtain constraints of
an auto NTTP through TEMPLATE_PARM_CONSTRAINTS instead of
PLACEHOLDER_TYPE_CONSTRAINTS.
* parser.cc (cp_parser_constrained_type_template_parm): Inline
into its only caller and remove.
(cp_parser_constrained_non_type_template_parm): Likewise.
(finish_constrained_parameter): Simplify after the above. Replace
the type of an ordinary constrained auto NTTP with a
non-constrained one and set TEMPLATE_PARM_CONSTRAINTS for it.
(cp_parser_template_parameter): Dispatch to
finish_constrained_parameter for a constrained auto NTTP.
* pt.cc (process_template_parm): Pass is_non_type to
finish_shorthand_constraint. Use TEMPLATE_PARM_CONSTRAINTS
instead of TREE_TYPE for clarity.
(expand_template_argument_pack): Remove forward declaration.
(copy_template_args): Likewise.
(make_constrained_placeholder_type): Return the type not the
TYPE_NAME for consistency with make_auto_1 etc.
(do_auto_deduction): Assert we no longer see simple constrained
autos during coercion/deduction.
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/pack-indexing15.C: Adjust expected error upon
constrained auto NTTP satisfaction failure.
* g++.dg/cpp2a/concepts-placeholder12.C: Likewise.
* g++.dg/cpp2a/concepts-pr97093.C: Likewise.
* g++.dg/cpp2a/concepts-template-parm2.C: Likewise.
* g++.dg/cpp2a/concepts-template-parm6.C: Likewise.
* g++.dg/cpp2a/concepts-template-parm12.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
Now that _Executor is non-recursive most subroutines no longer use their
_Match_mode parameter (previously it was just passed to recursive _M_dfs
calls). For now, just make them unnamed to avoid warnings.
libstdc++-v3/ChangeLog:
* include/bits/regex_executor.tcc (_Executor::_M_rep_once_more):
Make unnused _Match_mode parameter unnamed.
(_Executor::_M_handle_repeat): Likewise.
(_Executor::_M_handle_subexpr_begin): Likewise.
(_Executor::_M_handle_subexpr_end): Likewise.
(_Executor::_M_handle_line_begin_assertion): Likewise.
(_Executor::_M_handle_line_end_assertion): Likewise.
(_Executor::_M_handle_match): Likewise.
(_Executor::_M_handle_backref): Likewise.
(_Executor::_M_handle_alternative): Likewise.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
The comment from r16-7487 is confused, the object argument of PMF
calls _must_ be sequenced first by [expr.call]/7 since syntactically
it appears in the postfix-expression: (a.*pmf)(...).
It's indirect calls to a (known) xobj memfn that don't need such
sequencing, since syntactically the object argument isn't in the
postfix-expression: (&A::f)(a, ...).
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_gimplify_expr) <case CALL_EXPR>: Adjust
r16-7487 comment.
The object argument of an xobj memfn call needs to be evaluated before its
formal arguments, like with an iobj memfn call. This patch generalizes the
existing such handling in cp_gimplify_expr for METHOD_TYPE callees to also
accept xobj memfn callees.
PR c++/123989
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_gimplify_expr) <case CALL_EXPR>: Evaluate
the object argument of an xobj memfn call first too.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-eval-order.C: New test.
Reviewed-by: Marek Polacek <polacek@redhat.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
x86_64 glibc has started to use it since the 2.43 release, but is
expected to fix it before the 2.44 release.
Link: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b9579342c68b#patch67
libstdc++-v3/ChangeLog:
* testsuite/17_intro/badnames.cc (__unused): Do not define.
* testsuite/17_intro/names.cc [glibc == 2.43] (__unused): Undef.
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
When the builtins aren't used we need a declaration of std::is_function
for the fallback definitions of std::is_member_function_pointer and
std::is_member_object_pointer.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_function): Declare before first
use.
Yet more testing showed that compare insns too, were prone to catching
double-memory operands, for example with
c-c++-common/vector-compare-3.c -O2, from gcc.dg. So, better try to
fix them, helping current and future optimization passes that are
reluctant or unable to operate on patterns with two memory operands.
This just happens at expansion time by hacking the force_reg stuff to
conveniently happen in the operand-massaging function
cris_reduce_compare. Together, this and the two previous CRIS patches
did improve coremark results, but by a miniscule factor: speed by
0.002% (from 4887074 to 4886993 cycles) and size by 0.1% (code from
58199 to 58143 bytes) and as you can see, with rounding doing heavy
lifting.
* config/cris/cris.cc (cris_reduce_compare): Add forcing the first
operand to be a register, unless the second operand is 0, to scope.
* config/cris/cris.md ("*cstore<mode><code>4")
("*cbranch<mode><code>4"): Add guards to condition, for either operand
to be a register unless the last operand is zero.
Further testing showed that the two-memory-operands case that could
happen for movsf happened for the HI and QI modes as well, for example
in gcc.dg/Wrestrict-5.c. So, for improved performance they'd better
get guards as well. The movstrict<m> case is just tagging along for
summetry; I don't know of test-cases that expose that.
* config/cris/cris.md (BWDSF): New mode_iterator replacing SISF.
All callers changed.
("*movhi_internal<setcc><setnz><setnzvc>"): Anonymized from
"<acc><anz><anzvc>movhi<setcc><setnz><setnzvc>" to make it a
match-only pattern. Add conditions to guard from source and
destination both being memory operands.
("*movstricthi_internal", "*movstrictqi_internal"): Similarly
for "movstricthi" and "movstrictqi".
("movstrict<mode>"): Add common expander for BW, forcing one operand
to be a register or source being zero.
Experimenting, I noticed movsf could get two memory operands, and
when the pass I was hacking, adjusted both operands, the rtl-ssa
framework didn't like the situation and signalled failure, for
example compiling gcc.c-torture/compile/pr85945.c. While that's
arguably a wart in rtl-ssa and may be a problem by itself, this
shouldn't happen: one operand should be either a register or
constant 0. It usually doesn't matter because RA fixes up
operands per the constraints. Still, this is low-handing fruit
for improved performance, letting the RTL passes work on more
correct information ...and also, a plausible excuse for not also
hacking rtl-ssa proper. Either way, the port is responsible for
guarding operand validity, so tweak it. Incidental observation:
the two-memory-operands case happened already at expand time.
This mem-to-mem situation doesn't happen for movsi, because it has
special precautions to keep one operand a register or const_int 0,
which were added for reasons of condition-code handling. That
particular condition, checking for REG_P or the subreg being REG_P
looks too restrictive though, not allowing the (subreg mem) case
that register_operand deliberately allows.
* config/cris/cris.md (SISF): New mode_iterator for SI and SF.
("mov<mode>"): Make "movsi" a define_expand to include SFmode by
means of the SISF iterator and adjust to also handle SFmode.
("*movsf_internal"): Anonymize "movsf"; make it a match-only pattern.
Add conditions to guard from source and destination both being memory
operands.
This patch generates calls to GOMP_alloc to allocate memory for firstprivate
and private clauses on target constructs with an allocator and alignment
as specified by the allocate clause.
The decl values of the clause need to be adjusted to refer to the allocated
memory, and the initial values of variables need to be copied into the
allocated space for firstprivate variables.
For variable-length arrays, the size of the array is stored in a separate
variable, so the allocation and initialization need to be delayed until the
size is made available on the target.
gcc/
PR middle-end/113436
* omp-low.cc (is_variable_sized): Add extra is_ref argument. Check
referenced type if true.
(lower_omp_target): Call lower_private_allocate to generate code to
allocate memory for firstprivate/private clauses with allocators, and
insert code after dependent variables have been initialized.
Construct calls to free allocate memory and insert after target block.
Adjust decl values for clause variables. Copy value of firstprivate
variables to allocated memory.
gcc/testsuite/
PR middle-end/113436
* c-c++-common/gomp/pr113436-1.c: New.
* c-c++-common/gomp/pr113436-2.c: New.
* g++.dg/gomp/pr113436.C: New.
* gfortran.dg/gomp/pr113436-1.f90: New.
* gfortran.dg/gomp/pr113436-2.f90: New.
* gfortran.dg/gomp/pr113436-3.f90: New.
* gfortran.dg/gomp/pr113436-4.f90: New.
libgomp/
PR middle-end/113436
* libgomp.texi (OpenMP 5.0): Mark allocate clause as implemented.
(Memory allocation): Add documentation for use in target construct.
* testsuite/libgomp.c++/firstprivate-1.C: Enable alignment check.
* testsuite/libgomp.c++/pr113436-1.C: New.
* testsuite/libgomp.c++/pr113436-2.C: New.
* testsuite/libgomp.c++/private-1.C: Enable alignment check.
* testsuite/libgomp.c-c++-common/pr113436-1.c: New.
* testsuite/libgomp.c-c++-common/pr113436-2.c: New.
* testsuite/libgomp.fortran/pr113436-1.f90: New.
* testsuite/libgomp.fortran/pr113436-2.f90: New.
These changes cause CALL ... USING BY VALUE to work properly for a
wider range of COBOL variables types, values, and sizes. Some sizes
of numeric-display variables didn't work, some didn't work for negative
values, and floating-extended didn't work at all. Now they do.
Fourteen new DejaGnu tests cover this repaired capability.
gcc/cobol/ChangeLog:
* genapi.cc (establish_using): Use a 128-bit type for
float-extended; handle numeric-edited values of different sizes
and signs correctly.
(create_and_call): Use a 128-bit type for float-extended.
libgcobol/ChangeLog:
* Makefile.am: Temporarily continue to use -fno-strict-aliasing.
* Makefile.in: Likewise.
* libgcobol.cc (__gg__fetch_call_by_value_value): Simplify handling
of FldFloat.
(__gg__assign_value_from_stack): Likewise.
(__gg__unstring): Avoid uninitialized variable error.
(__gg__look_at_int128): New function useful for debugging.
(__gg__look_at_pointer): Likewise.
* xmlparse.cc (xml_event): Implement namespace XML.
(cdataBlock): Likewise.
(characters): Likewise.
(__gg__xml_parse): Likewise.
gcc/testsuite/ChangeLog:
* cobol.dg/group2/USING_COMP-3_BY_REFERENCE.cob: New test.
* cobol.dg/group2/USING_COMP-3_BY_REFERENCE.out: New test.
* cobol.dg/group2/USING_COMP-3_BY_VALUE.cob: New test.
* cobol.dg/group2/USING_COMP-3_BY_VALUE.out: New test.
* cobol.dg/group2/USING_FLOAT-SLX_BY_REFERENCE.cob: New test.
* cobol.dg/group2/USING_FLOAT-SLX_BY_REFERENCE.out: New test.
* cobol.dg/group2/USING_FLOAT-SLX_BY_VALUE.cob: New test.
* cobol.dg/group2/USING_FLOAT-SLX_BY_VALUE.out: New test.
* cobol.dg/group2/USING_NumericDisplay_BY_REFERENCE.cob: New test.
* cobol.dg/group2/USING_NumericDisplay_BY_REFERENCE.out: New test.
* cobol.dg/group2/USING_NumericDisplay_BY_VALUE.cob: New test.
* cobol.dg/group2/USING_NumericDisplay_BY_VALUE.out: New test.
* cobol.dg/group2/USING_Signed_-_COMP-3_BY_REFERENCE.cob: New test.
* cobol.dg/group2/USING_Signed_-_COMP-3_BY_REFERENCE.out: New test.
* cobol.dg/group2/USING_Signed_-_COMP-3_BY_VALUE.cob: New test.
* cobol.dg/group2/USING_Signed_-_COMP-3_BY_VALUE.out: New test.
* cobol.dg/group2/USING_Signed_-_NumericDisplay_BY_REFERENCE.cob: New test.
* cobol.dg/group2/USING_Signed_-_NumericDisplay_BY_REFERENCE.out: New test.
* cobol.dg/group2/USING_Signed_-_NumericDisplay_BY_VALUE.cob: New test.
* cobol.dg/group2/USING_Signed_-_NumericDisplay_BY_VALUE.out: New test.
* cobol.dg/group2/USING_Signed___COMP-3_BY_REFERENCE.cob: New test.
* cobol.dg/group2/USING_Signed___COMP-3_BY_REFERENCE.out: New test.
* cobol.dg/group2/USING_Signed___COMP-3_BY_VALUE.cob: New test.
* cobol.dg/group2/USING_Signed___COMP-3_BY_VALUE.out: New test.
* cobol.dg/group2/USING_Signed___NumericDisplay_BY_REFERENCE.cob: New test.
* cobol.dg/group2/USING_Signed___NumericDisplay_BY_REFERENCE.out: New test.
* cobol.dg/group2/USING_Signed___NumericDisplay_BY_VALUE.cob: New test.
* cobol.dg/group2/USING_Signed___NumericDisplay_BY_VALUE.out: New test.
The commit r16-7202-gb129ff0880c6d1 broke running libitm’s testsuite
using combinations of options because it didn’t clean up all the
global variables set in c++.exp. Fix the regression by using g++ for
the C++ tests and cleaning up the variables shared between C and C++
tests.
libitm/ChangeLog:
PR libitm/69018
* testsuite/lib/libitm.exp (libitm_init): Check
GXX_UNDER_TEST. Add "${blddir}/.libs" to
always_ld_library_path if blddir is not empty. Use
"-fdiagnostics-plain-output". Don't set compiler to GCC_UNDER_TEST.
* testsuite/libitm.c++/c++.exp: If $blddir is not empty set
libstdc++_library_path, shlib_ext, lang_include_flags, add
"${blddir}/${lang_library_paths}" to ld_library_path.
Unset libstdc++_library_path and shlib_ext if we skip C++
tests and at the end of the test run.
* testsuite/libitm.c/c.exp: Update the FSF address to the
website in the license text. Unset lang_library_paths and
lang_include_flags. Set the compiler to $GCC_UNDER_TEST.
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
Signed-off-by: Pietro Monteiro <pietro@sociotechnical.xyz>
The MSVCRT `strtoul()` function resets `errno` to zero upon success. On such
a system, `libiberty_vprintf_buffer_size()` could clobber `errno` like this:
MINGW64 ~
$ ld nonexistent.file
C:\MSYS64\mingw64\bin\ld.exe: cannot find nonexistent.file: No error
libiberty/ChangeLog:
* vprintf-support.c (do_strtoul): New function.
(libiberty_vprintf_buffer_size): Replace `strtoul` with `do_strtoul`.
Signed-off-by: LIU Hao <lh_mouse@126.com>
