When determining whether to rule out initializer-list constructors
during CTAD with a single-element initializer list (as per P0702), the
element type's cv-qualifiers should be irrelevant. This patch fixes
this by making is_spec_or_derived strip cv-qualifiers from the supplied
expression type.
In passing, I noticed in maybe_aggr_guide we were calling
is_spec_or_derived with swapped arguments. This led us to prefer the
aggregate deduction candidate over copying deduction in the second
testcase below with -std=c++20.
gcc/cp/ChangeLog:
PR c++/99103
* pt.c (is_spec_or_derived): Drop cv-qualifiers from 'etype'.
(maybe_aggr_guide): Fix order of arguments to is_spec_or_derived.
gcc/testsuite/ChangeLog:
PR c++/99103
* g++.dg/cpp1z/class-deduction79.C: New test.
* g++.dg/cpp1z/class-deduction80.C: New test.
Here we reject
constexpr const int *p = nullptr;
constexpr int *q = const_cast<int*>(p);
with "conversion of 'const int*' null pointer to 'int*' is not a
constant expression", which seems bogus. This code has been rejected
since r238909 which added the can_convert check when converting a null
pointer. I'm not finding any standard rule that this check was supposed
to enforce. The original discussion was here
<https://gcc.gnu.org/legacy-ml/gcc-patches/2016-06/msg01447.html>
and here
<https://gcc.gnu.org/legacy-ml/gcc-patches/2016-07/msg00280.html>.
Since can_convert never assumes a C-style cast, it rejects casting
away constness as in the test above and in:
constexpr int *q = (int *)(const int *) nullptr;
Removing the check only breaks constexpr-nullptr-2.C by not giving any
diagnostic for line 229:
constexpr B *pb2 = static_cast<B*>(pa0); // { dg-error "not a constant expression" }
but the cast seems to be valid: we do [expr.static.cast]/7, and
[expr.const] only says that a reinterpreter_cast and converting from
void* is invalid in constexpr. The can_convert check rejected convering
from void *, but only when converting from a null pointer, so it's not
good enough. So I've added a check to catch conversions from cv void*.
I realize it's not a great time to be adding additional checking, but
removing the can_convert check would then technically be a regression.
Let's limit the new check to only trigger for integer_zerop and then remove
it in GCC 12.
gcc/cp/ChangeLog:
DR 1312
PR c++/99176
* constexpr.c (is_std_construct_at): New overload.
(is_std_allocator_allocate): New overload.
(cxx_eval_call_expression): Use the new overloads.
(cxx_eval_constant_expression): Reject casting
from void * as per DR 1312. Don't check can_convert.
gcc/testsuite/ChangeLog:
DR 1312
PR c++/99176
* g++.dg/cpp0x/constexpr-nullptr-2.C: Adjust dg-error.
* g++.dg/cpp0x/constexpr-cast2.C: New test.
* g++.dg/cpp0x/constexpr-cast3.C: New test.
As the PR notes, we were calling the promise CTOR with the original
function parameters, not the copy (as pointed, a previous wording of
the section was unambiguous). Fixed thus.
gcc/cp/ChangeLog:
PR c++/97587
* coroutines.cc (struct param_info): Track rvalue refs.
(morph_fn_to_coro): Track rvalue refs, and call the promise
CTOR with the frame copy of passed parms.
gcc/testsuite/ChangeLog:
PR c++/97587
* g++.dg/coroutines/coro1-refs-and-ctors.h: Add a CTOR with two
reference parms, to distinguish the rvalue ref. variant.
* g++.dg/coroutines/pr97587.C: New test.
The FE contains a mechanism for cleaning up return expressions if a
function throws during the execution of cleanups prior to the return.
If the original function has a return value with a non-trivial DTOR
and the body contains a var with a DTOR that might throw, the function
decl is marked "throwing_cleanup".
However, we do not [in the coroutine ramp function, which is
synthesised], use any body var types with DTORs that might throw.
The original body [which will then contain the type with the throwing
DTOR] is transformed into the actor function which only contains void
returns, and is also wrapped in a try-catch block.
So (a) the 'throwing_cleanup' is no longer correct for the ramp and
(b) we do not need to transfer it to the actor which only contains
void returns.
gcc/cp/ChangeLog:
PR c++/95822
* coroutines.cc (morph_fn_to_coro): Unconditionally remove any
set throwing_cleanup marker.
gcc/testsuite/ChangeLog:
PR c++/95822
* g++.dg/coroutines/pr95822.C: New test.
The armv8_arm manual [C6.2.226, ROR (immediate)] uses a # in front
of the immediate rotation quantity.
Although, it seems, GAS is able to infer the # (or is leninent about
its absence) assemblers based on the LLVM back end expect it.
gcc/ChangeLog:
* config/aarch64/aarch64.md (<optab>_rol<mode>3): Add a '#'
mark in front of the immediate quantity.
(<optab>_rolsi3_uxtw): Likewise.
Commit r10-6017 relaxed the constraint on thumb2 calls to
__gnu_cmse_nonsecure_call to allow any register for the call address.
Although the initial code expansion continues to use r4 with the FPCXT
extension is not enabled, the change was unsafe because subsequent
optimizations could use the additional freedom to change which
register was being used.
To fix this we need to split the output patterns in the machine
description to use distinct recognizers: one with the additional
freedom when FPCXT is enabled an another that retains the original
restrictions when the extension is not available.
gcc:
PR target/99271
* config/arm/thumb2.md (nonsecure_call_reg_thumb2_fpcxt): New pattern.
(nonsecure_call_value_reg_thumb2_fpcxt): Likewise.
(nonsecure_call_reg_thumb2): Restrict to using r4 for the callee
address and disable when the FPCXT is not available.
(nonsecure_call_value_reg_thumb2): Likewise.
gcc/testsuite:
* gcc.target/arm/cmse/cmse-18.c: New test.
I realized that the just-added flang-note-module-read option should
also cover module writes, and was therefore misnamed. This addresses
that, replacing it with a -flang-note-module-cmi pair of options. As
this was such a recent addition, I didn't leave the old option
available.
PR c++/99166
gcc/c-family/
* c.opt (-flang-info-module-cmi): Renamed option.
gcc/
* doc/invoke.texi (flang-info-module-cmi): Renamed option.
gcc/cp/
* module.cc (module_state::inform_cmi_p): Renamed field.
(module_state::do_import): Adjust.
(init_modules, finish_module_processing): Likewise.
(handle_module_option): Likewise.
gcc/testsuite/
* g++.dg/modules/pr99166_a.X: Adjust.
* g++.dg/modules/pr99166_b.C: Adjust.
* g++.dg/modules/pr99166_c.C: Adjust.
* g++.dg/modules/pr99166_d.C: Adjust.
PR98318 also pointed out that the NETWORKING #define was being checked
with both #if and #ifdef. Let's consistently use one form.
c++tools/
* server.cc: Use #if NETWORKING not #ifdef, to be consistent
with elsewhere.
I don't know what it is that ix86, x86_64, Solaris and
apparently CRIS has in common here.
According to
https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652763.html
m68k-unknown-linux-gnu is also in that bunch, but since
there's a *-*-solaris* in the target specifier and also m68k
vs. m68k*, I'm leaving the adjustment to a maintainer.
gcc/testsuite:
* gfortran.dg/pr95690.f90: CRIS error appears on line 5.
The given testcase shows that one of the children of the complex MUL contains a
PHI node. This results in the vectorizer having a child that's (nil).
The pattern matcher handles this correctly, but optimize_load_redistribution_1
needs to not traverse/inspect the NULL nodes.
This however does high-light a missed opportunity. This testcase seems to
result in a different canonicalization than normally.
Normally the expressions are right leaning. But sometimes, especially when type
casts are introduced the trees suddenly become left leaning. For instance this
testcase (even without type casts) won't detect the FMA form because the addition
gets the MUL node in the left and not right node as it expects.
Checking all forms would be quite expensive so for GCC 12 it probably makes sense to make
forms with type casts in them have the same form as those without?
gcc/ChangeLog:
* tree-vect-slp.c (optimize_load_redistribution_1): Abort on NULL nodes.
gcc/testsuite/ChangeLog:
* g++.dg/vect/simd-complex-num-null-node.cc: New test.
The test in question is assumed to work only for little endian target.
gcc/testsuite/ChangeLog:
PR testsuite/99233
* gcc.target/powerpc/pr96264.c: Run it only for powerpc64le.
Skip test when -shared is not supported.
2021-02-25 Christophe Lyon <christophe.lyon@linaro.org>
gcc/testsuite/
PR middle-end/97172
* gcc.dg/pr97172-2.c: Add dg-require-effective-target shared.
User reported this typo: '0' and '-' are right next to each other, and
as it happened I always had networking, so it went unnoticed.
PR c++/98318
gcc/cp/
* mapper-client.cc (module_client::open_module_client): Fix typo
of fd init.
Implement P1682R2 as just approved for C++23.
libstdc++-v3/ChangeLog:
* include/std/utility (to_underlying): Define.
* include/std/version (__cpp_lib_to_underlying): Define.
* testsuite/20_util/to_underlying/1.cc: New test.
* testsuite/20_util/to_underlying/version.cc: New test.
This fixes an ordering problem with verifying that no intermediate
computations in a reduction path are used outside of the chain. The
check was disabled for value-preserving conversions at the tail
but whether a stmt was a conversion or not was only computed after
the first use. The following fixes this by re-ordering things
accordingly.
2021-02-25 Richard Biener <rguenther@suse.de>
PR tree-optimization/99253
* tree-vect-loop.c (check_reduction_path): First compute
code, then verify out-of-loop uses.
* gcc.dg/vect/pr99253.c: New testcase.
> So I wonder what other optimizations are prevented here?
> Why does uninit warn with VCE but not with NOP_EXPR? Or does the
> warning disappear because of those other optimizations you mention?
The optimization that it prevents is in this particular case in tree-vrp.c
(vrp_simplify_cond_using_ranges):
if (!is_gimple_assign (def_stmt)
|| !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
return;
so it punts on VIEW_CONVERT_EXPR, with NOP_EXPR it optimizes that:
_9 = (bool) maybe_a$4_7;
if (_9 != 0)
into:
_9 = (bool) maybe_a$4_7;
if (maybe_a$4_7 != 0)
Now, if I apply my patch but manually disable this
vrp_simplify_cond_using_ranges optimization, then the uninit warning is
back, so on the uninit side it is not about VIEW_CONVERT_EXPR vs. NOP_EXPR,
both are bad there, uninit wants the guarding condition to be
that SSA_NAME and not some demotion cast thereof.
We have:
# maybe_a$m_6 = PHI <_5(4), maybe_a$m_4(D)(6)>
# maybe_a$4_7 = PHI <1(4), 0(6)>
...
One of:
_9 = VIEW_CONVERT_EXPR<bool>(maybe_a$4_7);
if (_9 != 0)
or:
_9 = (bool) maybe_a$4_7;
if (_9 != 0)
or:
if (maybe_a$4_7 != 0)
followed by:
goto <bb 11>; [0.00%]
else
goto <bb 14>; [0.00%]
...
<bb 11> [count: 0]:
set (maybe_a$m_6);
and uninit wants to see that maybe_a$m_4(D) is not used if
bb 11 is encountered.
This patch fixes it by teaching vrp_simplify_cond_using_ranges
to handle VCE (when from an integral type) in addition to
NOP_EXPR/CONVERT_EXPR, of course as long as the VCE or demotion
doesn't change any values, i.e. when the range of the VCE or
conversion operand fits into the target type.
2021-02-25 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/80635
* tree-vrp.c (vrp_simplify_cond_using_ranges): Also handle
VIEW_CONVERT_EXPR if modes are the same, innerop is integral and
has mode precision.
* g++.dg/warn/pr80635-1.C: New test.
* g++.dg/warn/pr80635-2.C: New test.
This avoids interleaving pattern recognition and load redistribution
optimization since the load_map used in the latter is fragile with
respect to release and reuse of SLP nodes, something which can also
occur within the pattern recognition machinery.
2021-02-25 Richard Biener <rguenther@suse.de>
* tree-vect-slp.c (optimize_load_redistribution_1): Delay
load_map population.
(vect_match_slp_patterns_2): Revert part of last change.
(vect_analyze_slp): Do not interleave optimize_load_redistribution
with pattern detection but do it afterwards. Dump the
whole SLP graph after pattern recognition and load
redistribution optimization finished.
PR analyzer/99193 describes various false positives from
-Wanalyzer-mismatching-deallocation on realloc(3) calls
of the form:
| 31 | void *p = malloc (1024);
| | ^~~~~~~~~~~~~
| | |
| | (1) allocated here (expects deallocation with ‘free’)
| 32 | void *q = realloc (p, 4096);
| | ~~~~~~~~~~~~~~~~~
| | |
| | (2) deallocated with ‘realloc’ here; allocation at (1) expects deallocation with ‘free’
|
The underlying issue is that the analyzer has no knowledge of
realloc(3), and realloc has awkward semantics.
Unfortunately, the analyzer is currently structured so that each call
statement can only have at most one successor state; there is no
way to "bifurcate" the state, or have N-way splits into multiple
outcomes. The existing "on_stmt" code works on a copy of the next
state, updating it in place, rather than copying it and making any
necessary changes. I did this as an optimization to avoid unnecessary
copying of state objects, but it makes it hard to support multiple
outcomes. (ideally our state objects would be immutable and thus
support trivial copying, alternatively, C++11 move semantics may
help here)
I attempted a few approaches to implementing bifurcation within the
existing state-update framework, but they were messy and thus likely
buggy; a proper implementation would rework state-updating to
generate copies, but this would be a major change, and seems too
late for GCC 11.
As a workaround, this patch implements enough of realloc(3) to
suppress the false positives.
This fixes the false positives in PR analyzer/99193.
I've filed PR analyzer/99260 to track "properly" implementing realloc(3).
gcc/analyzer/ChangeLog:
PR analyzer/99193
* region-model-impl-calls.cc (region_model::impl_call_realloc): New.
* region-model.cc (region_model::on_call_pre): Call it.
* region-model.h (region_model::impl_call_realloc): New decl.
* sm-malloc.cc (enum wording): Add WORDING_REALLOCATED.
(malloc_state_machine::m_realloc): New field.
(use_after_free::describe_state_change): Add case for
WORDING_REALLOCATED.
(use_after_free::describe_final_event): Likewise.
(malloc_state_machine::malloc_state_machine): Initialize
m_realloc.
(malloc_state_machine::on_stmt): Handle realloc by calling...
(malloc_state_machine::on_realloc_call): New.
gcc/testsuite/ChangeLog:
PR analyzer/99193
* gcc.dg/analyzer/pr99193-1.c: New test.
* gcc.dg/analyzer/pr99193-2.c: New test.
* gcc.dg/analyzer/pr99193-3.c: New test.
* gcc.dg/analyzer/realloc-1.c: New test.
The code path in __floating_to_chars_precision for handling long double
by going through printf now also handles __float128, so the condition
that guards this code path needs to get updated accordingly.
libstdc++-v3/ChangeLog:
* src/c++17/floating_to_chars.cc (__floating_to_chars_precision):
Relax the condition that guards the printf code path to accept
F128_type as well as long double.
This fixes some issues with macro maps. We were incorrectly
calculating the number of macro expansions in a location span, and I
had a workaround that partially covered that up. Further, while macro
location spans are monotonic, that is not true of ordinary location
spans. Thus we need to insert an indirection array when binary
searching the latter. (We load ordinary locations before loading
imports, but macro locations afterwards. We make sure an import
location is de-macrofied, if needed.)
PR c++/98718
gcc/cp/
* module.cc (ool): New indirection vector.
(loc_spans::maybe_propagate): Location is not optional.
(loc_spans::open): Likewise. Assert monotonically advancing.
(module_for_ordinary_loc): Use ool indirection vector.
(module_state::write_prepare_maps): Do not count empty macro
expansions. Elide empty spans.
(module_state::write_macro_maps): Skip empty expansions.
(ool_cmp): New qsort comparator.
(module_state::write): Create and destroy ool vector.
(name_pending_imports): Fix dump push/pop.
(preprocess_module): Likewise. Add more dumping.
(preprocessed_module): Likewise.
libcpp/
* include/line-map.h
* line-map.c
gcc/testsuite/
* g++.dg/modules/pr98718_a.C: New.
* g++.dg/modules/pr98718_b.C: New.
The OpenMP standard says:
"A teams region can only be strictly nested within the implicit parallel region
or a target region. If a teams construct is nested within a target construct,
that target construct must contain no statements, declarations or directives
outside of the teams construct."
We weren't diagnosing that restriction, because we need to allow e.g.
#pragma omp target
{{{{{{
#pragma omp teams
;
}}}}}}
and as target doesn't need to have teams nested in it, using some special
parser of the target body didn't feel right. And after the parsing,
the question is if e.g. already parsing of the clauses doesn't add some
statements before the teams statement (gimplification certainly will).
As we now have a bugreport where we ICE on the invalid code, this just
diagnoses a subset of the invalid programs, in particular those where
nest to the teams strictly nested in targets the target region contains
some other OpenMP construct.
2021-02-24 Jakub Jelinek <jakub@redhat.com>
PR fortran/99226
* omp-low.c (struct omp_context): Add teams_nested_p and
nonteams_nested_p members.
(scan_omp_target): Diagnose teams nested inside of target with other
directives strictly nested inside of the same target.
(check_omp_nesting_restrictions): Set ctx->teams_nested_p or
ctx->nonteams_nested_p as needed.
* c-c++-common/gomp/pr99226.c: New test.
* gfortran.dg/gomp/pr99226.f90: New test.
When these functions are called with integer minimum, there is UB on the libgcc
side. Fixed in the obvious way, the code in the end wants ABSU_EXPR behavior.
2021-02-24 Jakub Jelinek <jakub@redhat.com>
PR libgcc/99236
* libgcc2.c (__powisf2, __powidf2, __powitf2, __powixf2): Perform
negation of m in unsigned type.
Inline asm in question has empty constraint which means anything
including memory with invalid address. To check used hard regs we
used decompose_mem_address which assumes memory with valid address.
The patch implements the same semantics without assuming valid
addresses.
gcc/ChangeLog:
PR inline-asm/99123
* lra-constraints.c (uses_hard_regs_p): Don't use decompose_mem_address.
gcc/testsuite/ChangeLog:
PR inline-asm/99123
* gcc.target/i386/pr99123.c: New.
This patch reimplements std::chrono::year_month_day_last:day() which yields the
last day of a particular month. The current implementation uses a look-up table
implemented as an unsigned[12] array. The new implementation instead
is based on
the fact that a month m in [1, 12], except for m == 2 (February), is
either 31 or
30 days long and m's length depends on two things: m's parity and whether m >= 8
or not. These two conditions are determined by the 0th and 3th bit of m and,
therefore, cheap and straightforward bit-twiddling can provide the right result.
Measurements in x86_64 [1] suggest a 10% performance boost. Although this does
not seem to be huge, notice that measurements are done in hot L1 cache
conditions which might not be very representative of production runs. Also
freeing L1 cache from holding the look-up table might allow performance
improvements elsewhere.
References:
[1] https://github.com/cassioneri/calendar
libstdc++-v3/ChangeLog:
* include/std/chrono (year_month_day_last:day): New
implementation.
This patch reimplements std::chrono::year::is_leap(). Leap year check is
ubiquitously implemented (including here) as:
y % 4 == 0 && (y % 100 != 0 || y % 400 == 0).
The rationale being that testing divisibility by 4 first implies an earlier
return for 75% of the cases, therefore, avoiding the needless calculations of
y % 100 and y % 400. Although this fact is true, it does not take into account
the cost of branching. This patch, instead, tests divisibility by 100 first:
(y % 100 != 0 || y % 400 == 0) && y % 4 == 0.
It is certainly counterintuitive that this could be more efficient since among
the three divisibility tests (4, 100 and 400) the one by 100 is the only one
that can never provide a definitive answer and a second divisibility test (by 4
or 400) is always required. However, measurements [1] in x86_64 suggest this is
3x more efficient! A possible explanation is that checking divisibility by 100
first implies a split in the execution path with probabilities of (1%, 99%)
rather than (25%, 75%) when divisibility by 4 is checked first. This decreases
the entropy of the branching distribution which seems to help prediction.
Given that y belongs to [-32767, 32767] [time.cal.year.members], a more
efficient algorithm [2] to check divisibility by 100 is used (instead of
y % 100 != 0). Measurements suggest that this optimization improves performance
by 20%.
The patch adds a test that exhaustively compares the result of this
implementation with the ubiquitous one for all y in [-32767, 32767]. Although
its completeness, the test completes in a matter of seconds.
References:
[1] https://stackoverflow.com/a/60646967/1137388
[2] https://accu.org/journals/overload/28/155/overload155.pdf#page=16
libstdc++-v3/ChangeLog:
* include/std/chrono (year::is_leap): New implementation.
* testsuite/std/time/year/2.cc: New test.
This patch reimplements std::chrono::year_month_day::_M_days_since_epoch()
which calculates the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.2 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
https://arxiv.org/abs/2102.06959.
The aforementioned paper benchmarks the implementation against several
counterparts, including libc++'s (which is identical to the current
implementation). The results, shown in Figure 3, indicate the new algorithm is
1.7 times faster than the current one.
The patch adds a test which loops through all dates in [-32767/01/01,
32767/12/31], and for each of them, gets the number of days and compares the
result against its expected value. The latter is calculated using a much
simpler and easy to understand algorithm but which is also much slower.
The dates used in the test covers the full range of possible values
[time.cal.year.members]. Despite its completeness the test runs in matter of
seconds.
libstdc++-v3/ChangeLog:
* include/std/chrono (year_month_day::_M_days_since_epoch):
New implementation.
* testsuite/std/time/year_month_day/4.cc: New test.
This patch reimplements std::chrono::year_month_day::_S_from_days() which
retrieves a date from the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.3 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
https://arxiv.org/abs/2102.06959.
The aforementioned paper benchmarks the implementation against several
counterparts, including libc++'s (which is identical to the current
implementation). The results, shown in Figure 4, indicate the new algorithm is
2.2 times faster than the current one.
The patch adds a test which loops through all integers in [-12687428, 11248737],
and for each of them, gets the corresponding date and compares the result
against its expected value. The latter is calculated using a much simpler and
easy to understand algorithm but which is also much slower.
The interval used in the test covers the full range of values for which a
roundtrip must work [time.cal.ymd.members]. Despite its completeness the test
runs in a matter of seconds.
libstdc++-v3/ChangeLog:
* include/std/chrono (year_month_day::_S_from_days): New
implementation.
* testsuite/std/time/year_month_day/3.cc: New test.
All the bits were there, used with a pre-existing
-mmax-stackframe=SIZE which unfortunately seems to lack
test-cases.
Note that the early-return for -mno-prologue-epilogue (what
some targets call -mnaked) is deliberately not clearing
current_function_static_stack_size, as I consider that
erroneous usage but don't really care to emit a better error
message.
For stack-usage-1.c, like most ILP32 targets, CRIS (at -O0)
needs 4 bytes for the return-address. The default size of
256 seems ill chosen but not worth fixing.
gcc:
* config/cris/cris.c (cris_expand_prologue): Set
current_function_static_stack_size, if flag_stack_usage_info.
gcc/testsuite:
* gcc.dg/stack-usage-1.c: Adjust for CRIS.
The long double std::to_chars testcase currently verifies the
correctness of its output by comparing it to that of printf, so if
there's a mismatch between to_chars and printf, the test FAILs. This
works well for the scientific, fixed and general formatting modes,
because the corresponding printf conversion specifiers (%e, %f and %g)
are rigidly specified.
But this doesn't work well for the hex formatting mode because the
corresponding printf conversion specifier %a is more flexibly specified.
For instance, the hexadecimal forms 0x1p+0, 0x2p-1, 0x4p-2 and 0x8p-3
are all equivalent and valid outputs of the %a specifier for the number 1.
The apparent freedom here is the choice of leading hex digit -- the
standard just requires that the leading hex digit is nonzero for
normalized numbers.
Currently, our hexadecimal formatting implementation uses 0/1/2 as the
leading hex digit for floating point types that have an implicit leading
mantissa bit which in practice means all supported floating point types
except x86 long double. The latter type has a 64 bit mantissa with an
explicit leading mantissa bit, and for this type our implementation uses
the most significant four bits of the mantissa as leading hex digit.
This seems to be consistent with most printf implementations, but not
all, as PR98384 illustrates.
In order to avoid false-positive FAILs due to arbitrary disagreement
between to_chars and printf about the choice of leading hex digit, this
patch makes the testcase's verification via printf conditional on the
leading hex digits first agreeing. An additional verification step is
also added: round-tripping the output of to_chars through from_chars
should recover the value exactly.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Include <optional>.
(test01): Simplify verifying the nearby values by using a
2-iteration loop and a dedicated output buffer to check that the
nearby values are different. Factor out the printf-based
verification into a local function, and check that the leading
hex digits agree before comparing to the output of printf. Also
verify the output by round-tripping it through from_chars.
When we read preprocessed source, we deal with a couple of special
location lines at the start of the file. These provide information
about the original filename of the source and the current directory,
so we can process the source in the same manner. When updating that
code, I had a somewhat philosophical question: Should the line table
contain evidence of the filename the user provided to the compiler? I
figured to leave it there, as it did no harm. But this defect shows
an issue. It's in the line table and our (non optimizing) line table
serializer emits that filename. Which means if one re-preprocesses
the original source to a differently-named intermediate file, the
resultant CMI is different. Boo. That's a difference that doesn't
matter, except the CRC matching then fails. We should elide the
filename, so that one can preprocess to mktemp intermediate filenames
for whatever reason.
This patch takes the approach of expunging it from the line table --
so the line table will end up with exactly the same form. That seems
a better bet than trying to fix up mismatching line tables in CMI
emission.
PR c++/99072
libcpp/
* init.c (read_original_filename): Expunge all evidence of the
original filename.
gcc/testsuite/
* g++.dg/modules/pr99072.H: New.
This adds overloads of std::to_chars for powerpc64's __ieee128, so that
std::to_chars can be used for long double when -mabi=ieeelongdouble is
in used.
Eventually we'll want to extend these new overloads to work for
__float128 on all targets that support that type. For now, we're only
doing it for powerpc64 when the new long double type is supported in
parallel to the old long double type.
Additionally the existing std::to_chars overloads for long double
are given the right symbol version, resolving PR libstdc++/98389.
libstdc++-v3/ChangeLog:
PR libstdc++/98389
* config/abi/pre/gnu.ver (GLIBCXX_3.4.29): Do not match to_chars
symbols for long double arguments mangled as 'g'.
* config/os/gnu-linux/ldbl-extra.ver: Likewise.
* config/os/gnu-linux/ldbl-ieee128-extra.ver: Likewise.
* src/c++17/Makefile.am [GLIBCXX_LDBL_ALT128_COMPAT_TRUE]:
Use -mabi=ibmlongdouble for floating_to_chars.cc.
* src/c++17/Makefile.in: Regenerate.
* src/c++17/floating_to_chars.cc (floating_type_traits_binary128):
New type defining type traits of IEEE binary128 format.
(floating_type_traits<__float128>): Define specialization.
(floating_type_traits<long double>): Define in terms of
floating_type_traits_binary128 when appropriate.
(floating_to_shortest_scientific): Handle __float128.
(sprintf_ld): New function template for printing a long double
or __ieee128 value using sprintf.
(__floating_to_chars_shortest, __floating_to_chars_precision):
Use sprintf_ld.
(to_chars): Define overloads for __float128.
2021-02-24 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/98342
* trans-expr.c (gfc_conv_derived_to_class): Add optional arg.
'derived_array' to hold the fixed, parmse expr in the case of
assumed rank formal arguments. Deal with optional arguments.
(gfc_conv_procedure_call): Null 'derived' array for each actual
argument. Add its address to the call to gfc_conv_derived_to_
class. Access the 'data' field of scalar descriptors before
deallocating allocatable components. Also strip NOPs before the
calls to gfc_deallocate_alloc_comp. Use 'derived' array as the
input to gfc_deallocate_alloc_comp if it is available.
* trans.h : Include the optional argument 'derived_array' to
the prototype of gfc_conv_derived_to_class. The default value
is NULL_TREE.
gcc/testsuite/
PR fortran/98342
* gfortran.dg/assumed_rank_21.f90 : New test.
As discussed in the PR, the Makefile fragment lacks a double '$' to
get the return-code from GCC invocation, resulting is CMSE support
missing from multilibs.
I checked that the simple patch proposed in the PR fixes the problem.
2021-02-23 Christophe Lyon <christophe.lyon@linaro.org>
Hau Hsu <hsuhau617@gmail.com>
PR target/99157
libgcc/
* config/arm/t-arm: Fix cmse support detection.
The attached testcase shows a bug where two nodes end up with the same pointer.
During the loop that analyzes all the instances
in optimize_load_redistribution_1 we do
if (value)
{
SLP_TREE_REF_COUNT (value)++;
SLP_TREE_CHILDREN (root)[i] = value;
vect_free_slp_tree (node);
}
when doing a replacement. When this is done and the refcount for the node
reaches 0, the node is removed, which allows the libc to return the pointer
again in the next call to new, which it does..
First instance
note: node 0x5325f48 (max_nunits=1, refcnt=2)
note: op: VEC_PERM_EXPR
note: { }
note: lane permutation { 0[0] 1[1] 0[2] 1[3] }
note: children 0x5325db0 0x5325200
Second instance
note: node 0x5325f48 (max_nunits=1, refcnt=1)
note: op: VEC_PERM_EXPR
note: { }
note: lane permutation { 0[0] 1[1] }
note: children 0x53255b8 0x5325530
This will end up with the illegal construction of
note: node 0x53258e8 (max_nunits=2, refcnt=2)
note: op template: slp_patt_57 = .COMPLEX_MUL (_16, _16);
note: stmt 0 _16 = _14 - _15;
note: stmt 1 _23 = _17 + _22;
note: children 0x53257d8 0x5325d28
note: node 0x53257d8 (max_nunits=2, refcnt=3)
note: op template: l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 0 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 1 l$c_5 = MEM[(const struct a &)_3].c;
note: load permutation { 0 1 }
note: node 0x5325d28 (max_nunits=2, refcnt=8)
note: op template: l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 0 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 1 l$c_5 = MEM[(const struct a &)_3].c;
note: stmt 2 l$b_4 = MEM[(const struct a &)_3].b;
note: stmt 3 l$c_5 = MEM[(const struct a &)_3].c;
note: load permutation { 0 1 0 1 }
To prevent this we remove the node from the load_map if it's
about to be deleted.
gcc/ChangeLog:
PR tree-optimization/99220
* tree-vect-slp.c (optimize_load_redistribution_1): Remove
node from cache when it's about to be deleted.
gcc/testsuite/ChangeLog:
PR tree-optimization/99220
* g++.dg/vect/pr99220.cc: New test.
This patch disables the test for PR99149 on Big-endian
where for standard AArch64 the patterns are disabled.
gcc/testsuite/ChangeLog:
PR tree-optimization/99149
* g++.dg/vect/pr99149.cc: Disabled on BE.
Although coroutines are not permitted to be constexpr, generic lambdas
are implicitly from C++17 and, because of this, a generic coroutine lambda
can be marked as potentially constexpr. As per the PR, this then fails when
type substitution is attempted because the check disallowing constexpr in
the coroutines code was overly restrictive.
This changes the error handing to mark the function as 'invalid_constexpr'
but suppresses the error in the case that we are instantiating a constexpr.
gcc/cp/ChangeLog:
PR c++/96251
* coroutines.cc (coro_common_keyword_context_valid_p): Suppress
error reporting when instantiating for a constexpr.
gcc/testsuite/ChangeLog:
PR c++/96251
* g++.dg/coroutines/pr96251.C: New test.
This optimization was written purely with scalar integers in mind,
can work fine even with vectors, but we can't use build_int_cst but
need to use build_one_cst instead.
2021-02-24 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/99225
* fold-const.c (fold_binary_loc) <case NE_EXPR>: In (x & (1 << y)) != 0
to ((x >> y) & 1) != 0 simplifications use build_one_cst instead of
build_int_cst (..., 1). Formatting fixes.
* gcc.c-torture/compile/pr99225.c: New test.
