This fixes a regression in std::normal_distribution deserialization that
caused the object to be left unchanged if the __state_avail value read
from the stream was false.
libstdc++-v3/ChangeLog:
PR libstdc++/105502
* include/bits/random.tcc
(operator>>(basic_istream<C,T>&, normal_distribution<R>&)):
Update state when __state_avail is false.
* testsuite/26_numerics/random/normal_distribution/operators/serialize.cc:
Check that deserialized object equals serialized one.
(cherry picked from commit 909ef4e272)
The -mpower8-fusion and -mpower10-fusion options do not modify which
instructions we can generate, so ignore them when deciding whether we
can inline callee into caller.
2022-05-06 Michael Meissner <meissner@linux.ibm.com>
gcc/
PR target/102059
* config/rs6000/rs6000.cc (rs6000_can_inline_p): Ignore -mpower8-fusion
and -mpower10-fusion options for inlining purposes.
gcc/testsuite/
PR target/102059
* gcc.target/powerpc/pr102059-4.c: New test.
(cherry picked from commit 2fb654f77d)
Here we're crashing from maybe_aggr_guide ultimately because
processing_template_decl isn't set when partially instantiating the
guide's parameter list; this causes us to force completion of the
dependent type Visitor_functior<Fn>, which of course fails and results
in an unexpected error_mark_node (the instantation should always succeed).
PR c++/105476
gcc/cp/ChangeLog:
* pt.cc (maybe_aggr_guide): Set processing_template_decl when
partially instantiating the guide's parameter list.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-aggr13.C: New test.
* g++.dg/cpp2a/class-deduction-aggr13a.C: New test.
(cherry picked from commit 8a98e3ff7e)
As with std::isdigit in r12-6281-gc83ecfbe74a5cf, we shouldn't be using
std::tolower in <charconv> either.
PR libstdc++/103911
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc (find_end_of_float): Accept
two delimeters for the exponent part in the form of a possibly
NULL string of length two. Don't use std::tolower.
(pattern): Adjust calls to find_end_of_float accordingly.
(cherry picked from commit 86d821ddf5)
We are eventually ICEing in decimal_to_decnumber on non-decimal
REAL_VALUE_TYPE that creep in from uses of build_real (..., dconst*)
for DFP types. The following extends the decimal_to_decnumber
special-casing of dconst* to build_real, avoiding the bogus REAL_CSTs
from creeping into the IL and modified to ones not handled by
the decimal_to_decnumber special casing. It also makes sure to
ICE for not handled dconst* values at the point we build the REAL_CST.
2022-04-27 Richard Biener <rguenther@suse.de>
PR middle-end/105376
* tree.cc (build_real): Special case dconst* arguments
for decimal floating point types.
* gcc.dg/pr105376.c: New testcase.
(cherry picked from commit e27eef7478)
The floating-point overloads of from_char are only declared if
_GLIBCXX_HAVE_USELOCALE is #defined as nonzero. That's exposed from
charconv as __cpp_lib_to_chars >= 201611L, so guard the test body with
that.
for libstdc++-v3/ChangeLog
PR c++/105324
* testsuite/20_util/from_chars/pr105324.cc: Guard test body
with conditional for floating-point overloads of from_char.
(cherry picked from commit 25389f3de4)
On the following testcase, we emit deprecated warnings or unavailable errors
even on merge declarations of those lambdas (the dg-bogus directives), while
IMHO we should emit them only when something actually calls those lambdas.
The following patch temporarily disables that diagnostics during
maybe_add_lambda_conv_op.
PR2173R1 also says that ambiguity between attribute-specifier-seq at the
end of requires-clause and attribute-specifier-seq from lambda-expression
should be resolved to attribute-specifier-seq for the latter. Do we need
to do anything about that? I mean, can a valid requires-clause end with
an attribute-specifier-seq? Say operator int [[]] is valid primary
expression, but requires operator int [[]] isn't valid, nor is
requires operator int, no?
2022-05-04 Jakub Jelinek <jakub@redhat.com>
* lambda.cc: Include decl.h.
(maybe_add_lambda_conv_op): Temporarily override deprecated_state to
UNAVAILABLE_DEPRECATED_SUPPRESS.
* g++.dg/cpp23/lambda-attr1.C: New test.
* g++.dg/cpp23/lambda-attr2.C: New test.
(cherry picked from commit 1c8e9bed9b)
When the IL representation of VEC_SET is marked as throwing
(unnecessarily), we need to clean that when replacing it with
the .VEC_SET internal function call which cannot throw.
2022-05-05 Richard Biener <rguenther@suse.de>
PR tree-optimization/105484
* gimple-isel.cc (gimple_expand_vec_set_expr): Clean EH, return
whether the CFG changed.
(gimple_expand_vec_exprs): When the CFG changed, clean it up.
* gcc.dg/torture/pr105484.c: New testcase.
(cherry picked from commit e1a41143a2)
The flag_var_tracking reset in finish_options doesn't match the
condition in process_options, in particular we fail to reset it
when the option was specified on the command line. The following
fixes this and also alters the debug info level guard to match
the one in process_options.
2022-05-03 Richard Biener <rguenther@suse.de>
PR middle-end/105461
* opts.cc (finish_options): Match the condition to
disable flag_var_tracking to that of process_options.
* gcc.dg/pr105461.c: New testcase.
(cherry picked from commit 6b4cc78480)
When some code was moved from process_options to finish_options,
uses of OPTION_SET_P were not replaced with references to the
opts_set option set. The following fixes this.
2022-05-03 Richard Biener <rguenther@suse.de>
* opts.cc: #undef OPTIONS_SET_P.
(finish_options): Use opts_set instead of OPTIONS_SET_P.
(cherry picked from commit 99f55024b0)
We have to watch out for vectorized stmt insert locations if the
def from the last stmt alters control flow. We constrain region
building so we know the def is outside of the current region
and thus we can insert at the region start point.
2022-05-02 Richard Biener <rguenther@suse.de>
PR tree-optimization/105437
* tree-vect-slp.cc (vect_schedule_slp_node): Handle the
case where last_stmt alters control flow.
* g++.dg/vect/pr105437.cc: New testcase.
(cherry picked from commit 3a3eda000f)
The following fixes missing handling of non-integer mode but
masked (SVE or MVE) compares in vector lowering by using the
appropriate mask element width to extract the components and
adjust the index.
2022-04-29 Richard Biener <rguenther@suse.de>
PR tree-optimization/105394
* tree-vect-generic.cc (expand_vector_condition): Adjust
comp_width for non-integer mode masks as well.
(cherry picked from commit dfae0c5a29)
gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c covers ppc variants
that accept and reject misaligned accesses. The message that it
expects for rejection was removed in the gcc-11 development cycle by
commit r11-1969. The patch adjusted multiple tests to use the message
introduced in r11-1945, but missed this one.
for gcc/testsuite/ChangeLog
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Update
the expected message for the case in which unaligned accesses
are not allowed.
(cherry picked from commit 404edfce68)
The hexfloat parser for binary32/64 added in r12-6645-gcc3bf3404e4b1c
overlooked that the exponent part can also begin with an uppercase 'P'.
PR libstdc++/105441
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
Also accept 'P' as the start of the exponent.
* testsuite/20_util/from_chars/7.cc: Add corresponding testcase.
(cherry picked from commit 576f975cab)
On Sun, May 01, 2022 at 07:06:53PM +0100, Jonathan Wakely wrote:
> > >> the reason is that "gcc/analyzer/region-model.cc” uses initializer_lists, and it seems that <initializer_list>
> > >> is not transitively included by any used headers for _LIBCPP_VERSION < 4000. I fixed that locally by
> > >> adding initializer_list into system.h (and adding INCLUDE_INITIALIZER_LIST to the top of gcc/analyzer/region-model.cc)
> > >> - with that change those versions do bootstrap and test OK***
> > >
> > > From what I can see, with libstdc++ it works because <utility> which is
> > > included by system.h includes <initializer_list>.
> > > If I rename initializer_list in analyzer/region-model.ii to initializer_listx, I
> > > also get:
> > > ../../gcc/analyzer/region-model.cc: In function ‘void ana::selftest::test_binop_svalue_folding()’:
> > > ../../gcc/analyzer/region-model.cc:4966:48: error: deducing from brace-enclosed initializer list requires ‘#include <initializer_list>’
> > > 4508 |
> > > +++ |+#include <initializer_list>
> > > 4509 | static void
> > > ......
> > > 4966 | for (auto op : {BIT_IOR_EXPR, TRUTH_OR_EXPR})
> > > | ^
> > > ../../gcc/analyzer/region-model.cc:4978:49: error: deducing from brace-enclosed initializer list requires ‘#include <initializer_list>’
> > > 4978 | for (auto op : {BIT_AND_EXPR, TRUTH_AND_EXPR})
> > > | ^
> > >
> > > I think we have 2 options, one is do what you wrote above,
> > > INCLUDE_INITIALIZER_LIST defined before system.h to get #include <initializer_list>.
> > > The other option is just to include that unconditionally, it is a very small
> > > header. For libstdc++ it will make no difference as it is included anyway
> > > and the header is really small there, libc++ includes <cstddef> which isn't
> > > normally included and system.h includes <stddef.h> instead.
> >
> > I’d say unconditionally would be OK. I suppose the chance that any host
> > C++ is good enough to build GCC as-is but fails to provide
> > <initializer_list> is zero?
> >
>
> Yes, definitely.
>
> > I’d be OK to do this change without a new RC even.
2022-05-02 Jakub Jelinek <jakub@redhat.com>
* system.h: Include initializer_list.
(cherry picked from commit 4a0e89b10f)
The --with-long-double-abi=ibm build is missing some exports that are
present in the --with-long-double-abi=ieee build. Those symbols never
should have been exported at all, but now that they have been, they
should be exported consistently by both ibm and ieee.
This simply defines them as aliases for equivalent symbols that are
already present. The abi-tag on num_get::_M_extract_int isn't really
needed, because it only uses a std::string as a local variable, not in
the return type or function parameters, so it's safe to define the
_M_extract_int[abi:cxx11] symbols as aliases for the corresponding
function without the abi-tag.
This causes some new symbols to be added to the GLIBCXX_3.4.29 version
for the ibm long double build mode, but there is no advantage to adding
them to 3.4.30 for that build. That would just create more
inconsistencies.
libstdc++-v3/ChangeLog:
PR libstdc++/105417
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:
Regenerate.
* src/c++11/compatibility-ldbl-alt128.cc [_GLIBCXX_USE_DUAL_ABI]:
Define __gnu_ieee128::num_get<C>::_M_extract_int[abi:cxx11]<I>
symbols as aliases for corresponding symbols without abi-tag.
(cherry picked from commit bb7cf39b05)
The following patch updates the Solaris baselines for GCC 12.1.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (Solaris 11.3
and 11.4 in each case).
The only (expected) difference between the 11.3 and 11.4 versions is
--- baseline_symbols.txt.s113s 2022-04-28 10:37:11.464068450 +0000
+++ baseline_symbols.txt.s114s 2022-04-27 16:54:31.995636805 +0000
@@ -4070,3 +4070,3 @@
-FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.30
-FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.30
-FUNC:_ZSt10from_charsPKcS0_RfSt12chars_format@@GLIBCXX_3.4.30
+FUNC:_ZSt10from_charsPKcS0_RdSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_ReSt12chars_format@@GLIBCXX_3.4.29
+FUNC:_ZSt10from_charsPKcS0_RfSt12chars_format@@GLIBCXX_3.4.29
which is handled by the fix for PR libstdc++/103407. I'm using the 11.4
version here.
2022-04-27 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libstdc++-v3:
* config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate.
* config/abi/post/i386-solaris/amd64/baseline_symbols.txt:
Likewise.
* config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise.
* config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt:
Likewise.
The changes to fix PR 105287 included a tightening of the constraints on which
variables are promoted to frame copies. This has exposed that we are failing
to name some variables that should be promoted.
We avoid the use of DECL_UID to build anonymous symbols since that might not
be stable for -fcompare-debug.
The long-term fix is to address the cases where the naming has been missed,
but for the short-term (and for the GCC-12 branch) backing out the additional
constraint is proposed.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR c++/105426
gcc/cp/ChangeLog:
* coroutines.cc (register_local_var_uses): Allow promotion of unnamed
temporaries to coroutine frame copies.
(cherry picked from commit 3d8d093e82)
Here ever since r12-6022-gbb2a7f80a98de3 we stopped deeming the partial
specialization #2 to be more specialized than #1 ultimately because
dependent operator expressions now have a DEPENDENT_OPERATOR_TYPE type
instead of an empty type, and this made unify stop deducing T(2) == 1
for K during partial ordering for #1 and #2.
This minimal patch fixes this by making the relevant logic in unify
treat DEPENDENT_OPERATOR_TYPE like an empty type.
PR c++/105425
gcc/cp/ChangeLog:
* pt.cc (unify) <case TEMPLATE_PARM_INDEX>: Treat
DEPENDENT_OPERATOR_TYPE like an empty type.
gcc/testsuite/ChangeLog:
* g++.dg/template/partial-specialization13.C: New test.
(cherry picked from commit 509fd16da8)
The following testcase ICEs, because the ctors during cc1plus all have
!opt_for_fn (decl, flag_semantic_interposition) - they have NULL
DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) and optimization_default_node
is for -Ofast and so has flag_semantic_interposition cleared.
During free lang data, we set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
for the ctor which has body (or for thunks), but don't touch it for
aliases.
During lto1 optimization_default_node reflects the lto1 flags which
are -O2 rather than -Ofast and so has flag_semantic_interposition
set, for the ctor which has body that makes no difference, but as the
alias doesn't still have DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) set,
we now trigger this verification check.
The following patch just doesn't verify it for aliases during lto1.
Another possibility would be to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
during free lang data even for aliases.
2022-04-28 Jakub Jelinek <jakub@redhat.com>
PR lto/105399
* cgraph.cc (cgraph_node::verify_node): Don't verify
semantic_interposition flag against
opt_for_fn (decl, flag_semantic_interposition) for aliases in lto1.
* g++.dg/lto/pr105399_0.C: New test.
We check that the final_suspend () method returns a sane type (i.e. a class
or structure) but, unfortunately, that check has to be later than the one
for a throwing case. If the use returns some nonsensical type from the
method, we need to handle that in the checking for noexcept.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR c++/104051
gcc/cp/ChangeLog:
* coroutines.cc (coro_diagnose_throwing_final_aw_expr): Handle
non-target expression inputs.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr104051.C: New test.
Whether it was intended or not, it is possible to define a coroutine promise
with multiple return_value() methods [which need not even have the same type].
We were not accounting for this possibility in the check to see whether both
return_value and return_void are specifier (which is prohibited by the
standard). Fixed thus and provided an adjusted diagnostic for the case that
multiple return_value() methods are present.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR c++/105301
gcc/cp/ChangeLog:
* coroutines.cc (coro_promise_type_found_p): Account for possible
mutliple overloads of the promise return_value() method.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr105301.C: New test.
There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral). The
intent was that unnamed temporaries should not be 'promoted' to coroutine
frame entries. However there was a thinko and these were not actually ever
added to the bind expressions being generated for the expanded awaits. This
meant that they were showing in the global namspace, leading to an empty
DECL_CONTEXT and the ICE reported.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR c++/105287
gcc/cp/ChangeLog:
* coroutines.cc (maybe_promote_temps): Ensure generated temporaries
are added to the bind expr.
(add_var_to_bind): Fix local var naming to use portable punctuation.
(register_local_var_uses): Do not add synthetic names to unnamed
temporaries.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr105287.C: New test.
This is a forward-port of a patch by Nathan (against 10.x) which fixes an open
PR.
We are ICEing because we ended up tsubst_copying something that had already
been tsubst, leading to an assert failure (mostly such repeated tsubsting is
harmless).
We had a non-dependent co_await in a non-dependent-type template fn, so we
processed it at definition time, and then reprocessed at instantiation time.
We fix this here by deferring substitution while processing templates.
Additional observations (for a better future fix, in the GCC13 timescale):
Exprs only have dependent type if at least one operand is dependent which was
what the current code was intending to do. Coroutines have the additional
wrinkle, that the current fn's type is an implicit operand.
So, if the coroutine function's type is not dependent, and the operand is not
dependent, we should determine the type of the co_await expression using the
DEPENDENT_EXPR wrapper machinery. That allows us to determine the
subexpression type, but leave its operand unchanged and then instantiate it
later.
PR c++/103868
gcc/cp/ChangeLog:
* coroutines.cc (finish_co_await_expr): Do not process non-dependent
coroutine expressions at template definition time.
(finish_co_yield_expr): Likewise.
(finish_co_return_stmt): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/pr103868.C: New test.
Co-Authored-by: Iain Sandoe <iain@sandoe.co.uk>
