Same issue as the initial commit that addressed PR96153, only this time to fix
it also for structs that are not returned in memory. Tests have been added
that triggered an assertion on x86_64, however the original test was failing
on SPARC 64-bit targets.
gcc/d/ChangeLog:
PR d/96153
* d-codegen.cc (build_address): Create a temporary for CALL_EXPRs
returning trivial aggregates, pre-filling it with zeroes.
(build_memset_call): Use build_zero_cst if setting the entire object.
gcc/testsuite/ChangeLog:
PR d/96153
* gdc.dg/pr96153.d: Add new tests.
TREE_ADDRESSABLE was not propagated from the RECORD_TYPE to the ARRAY_TYPE, so
NRVO code generation was not being triggered.
gcc/d/ChangeLog:
PR d/96157
* d-codegen.cc (d_build_call): Handle TREE_ADDRESSABLE static arrays.
* types.cc (make_array_type): Propagate TREE_ADDRESSABLE from base
type to static array.
gcc/testsuite/ChangeLog:
PR d/96157
* gdc.dg/pr96157a.d: New test.
* gdc.dg/pr96157b.d: New test.
Fail compilation tests only check for language errors from the front-end, all
default option switches do nothing to alter the error.
gcc/testsuite/ChangeLog:
* lib/gdc-utils.exp (gdc-convert-test): Clear PERMUTE_ARGS for
fail_compilation tests if not set by test file.
gcc/d/ChangeLog:
* d-gimplify.cc (d_gimplify_expr): Move lowering of each tree node to
separate functions.
(d_gimplify_modify_expr): New function.
(d_gimplify_addr_expr): New function.
(d_gimplify_call_expr): New function.
(d_gimplify_unsigned_rshift_expr): New function.
Rewriting testcase with cpp source file, then compare operator could
be used directly for vector, this would avoid impact of vectorizer.
gcc/testsuite/ChangeLog:
PR target/96667
* gcc.target/i386/avx512bw-pr96246-1.c: Moved to...
* g++.target/i386/avx512bw-pr96246-1.C: ...here.
* gcc.target/i386/avx512bw-pr96246-2.c: Moved to...
* g++.target/i386/avx512bw-pr96246-2.C: ...here.
* gcc.target/i386/avx512vl-pr96246-1.c: Moved to...
* g++.target/i386/avx512vl-pr96246-1.C: ...here.
* gcc.target/i386/avx512vl-pr96246-2.c: Moved to...
* g++.target/i386/avx512vl-pr96246-2.C: ...here.
PR analyzer/94858 reports a false diagnostic from
-Wanalyzer-malloc-leak, where the allocated pointer is pointed to by a
field of a struct, and a loop writes to a buffer, writing through an
iterating pointer value.
There were several underlying problems, relating to clobbering of the
struct holding the malloc-ed pointer; in each case the analyzer was
conservatively assuming that a write could affect this region,
clobbering it to "unknown", and this was detected as a leak.
The initial write within the loop dereferences the initial value of
a field, and the analyzer was assuming that that pointer could
point to the result of the malloc call. The patch extends
store::eval_alias_1 so that it "knows" that the initial value of a
pointer at the beginning of a path can't point to a region that was
allocated on the heap after the beginning of the path.
On fixing that, the next issue is that within the loop the iterated
pointer value becomes "unknown", and hence *ptr becomes a write to a
symbolic region, and thus might clobber the struct (which it can't).
This patch adds enough logic to svalue::can_merge_p to merge the
iterating pointer value so that at the 2nd iteration analyzing
the loop it becomes a widening_svalue from the initial svalue, so
that this becomes a fixed point of the analysis, and is not an
unknown_svalue. The patch further extends store::eval_alias_1 so that
it "knows" that this widening_svalue can only point to the same base
region as the initial value did; in particular, symbolic writes through
this pointer can only clobber that base region, not the struct holding
the malloc-ed pointer.
gcc/analyzer/ChangeLog:
PR analyzer/94858
* region-model-manager.cc
(region_model_manager::get_or_create_widening_svalue): Assert that
neither of the inputs are themselves widenings.
* store.cc (store::eval_alias_1): The initial value of a pointer
can't point to a region that was allocated on the heap after the
beginning of the path. A widened pointer value can't alias anything
that the initial pointer value can't alias.
* svalue.cc (svalue::can_merge_p): Merge BINOP (X, OP, CST) with X
to a widening svalue. Merge
BINOP(WIDENING(BASE, BINOP(BASE, X)), X) and BINOP(BASE, X) to
to the LHS of the first BINOP.
gcc/testsuite/ChangeLog:
PR analyzer/94858
* gcc.dg/analyzer/loop-start-up-to-end-by-1.c: Remove xfail.
* gcc.dg/analyzer/pr94858-1.c: New test.
* gcc.dg/analyzer/pr94858-2.c: New test.
* gcc.dg/analyzer/torture/loop-inc-ptr-2.c: Update expected number
of enodes.
* gcc.dg/analyzer/torture/loop-inc-ptr-3.c: Likewise.
gcc/analyzer/ChangeLog:
PR analyzer/96777
* region-model.h (class compound_svalue): Document that all keys
must be concrete.
(compound_svalue::compound_svalue): Move definition to svalue.cc.
* store.cc (binding_map::apply_ctor_to_region): Handle
initializers for trailing arrays with incomplete size.
* svalue.cc (compound_svalue::compound_svalue): Move definition
here from region-model.h. Add assertion that all keys are
concrete.
gcc/testsuite/ChangeLog:
PR analyzer/96777
* gcc.dg/analyzer/pr96777.c: New test.
Change CTZ_DEFINED_VALUE_AT_ZERO/CTZ_DEFINED_VALUE_AT_ZERO to return 0/2
to enable table-based clz/ctz optimization:
-- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
-- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
A C expression that indicates whether the architecture defines a
value for 'clz' or 'ctz' with a zero operand. A result of '0'
indicates the value is undefined. If the value is defined for only
the RTL expression, the macro should evaluate to '1'; if the value
applies also to the corresponding optab entry (which is normally
the case if it expands directly into the corresponding RTL), then
the macro should evaluate to '2'. In the cases where the value is
defined, VALUE should be set to this value.
gcc/
PR target/95863
* config/i386/i386.h (CTZ_DEFINED_VALUE_AT_ZERO): Return 0/2.
(CLZ_DEFINED_VALUE_AT_ZERO): Likewise.
gcc/testsuite/
PR target/95863
* gcc.target/i386/pr95863-1.c: New test.
* gcc.target/i386/pr95863-2.c: Likewise.
This is my proposed fix to PR middle-end/87256 where synth_mult takes an
unreasonable amount of CPU time determining an optimal sequence of
instructions to perform multiplication by (large) integer constants on hppa.
One workaround proposed in bugzilla, is to increase the hash table used
to cache/reuse intermediate results. This helps but is a workaround for
the (hidden) underlying problem.
The real issue is that the hppa_rtx_costs function is providing wildly
inaccurate values (estimates) to the middle-end. For example, (p*q)+(r*s)
would appear to be cheaper than a single multiplication. Another
example is that "(ashiftrt:di regA regB)" is claimed to be only be
COST_N_INSNS(1) when in fact the hppa backend actually generates
slightly more than a single instruction.
It turns out that simply tightening up the logic in hppa_rtx_costs to
return more reasonable values, dramatically reduces the number of recursive
invocations in synth_mult for the test case in PR87256, and presumably
also produces faster code (that should be observable in benchmarks).
2020-08-25 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR middle-end/87256
* config/pa/pa.c (hppa_rtx_costs_shadd_p): New helper function
to check for coefficients supported by shNadd and shladd,l.
(hppa_rtx_costs): Rewrite to avoid using estimates based upon
FACTOR and enable recursing deeper into RTL expressions.
This patch improves the code generated on PA-RISC for DImode
(double word) left shifts by small constants (1-31). This target
has a very cool shd instruction that can be recognized by combine
for simple shifts, but relying on combine is fragile for more
complicated functions. This patch tweaks pa.md's ashldi3 expander,
to form the optimal two instruction shd/zdep sequence at RTL
expansion time.
As an example of the benefits of this approach, the simple function
unsigned long long u9(unsigned long long x) { return x*9; }
currently generates 9 instructions and with this patch now requires
only 7.
2020-08-25 Roger Sayle <roger@nextmovesoftware.com>
* config/pa/pa.md (ashldi3): Additionally, on !TARGET_64BIT
generate a two instruction shd/zdep sequence when shifting
registers by suitable constants.
(shd_internal): New define_expand to provide gen_shd_internal.
Add a static_assertions to check the result type is destructible, as in
the proposed resolution for LWG 3466 (which supersedes 3458).
libstdc++-v3/ChangeLog:
* include/std/future (future, shared_future. promise): Add
is_destructible assertion (LWG 3466). Adjust string-literal for
!is_array and !is_function assertions.
* testsuite/30_threads/future/requirements/lwg3458.cc: Check
types with no accessible destructor. Adjust expected errors.
* testsuite/30_threads/promise/requirements/lwg3466.cc:
Likewise.
* testsuite/30_threads/shared_future/requirements/lwg3458.cc:
Likewise.
This patch adds the C++20 calendar types and their methods as defined in
[time.cal] (modulo the parsing/printing support). This patch also
implements [time.hms] and [time.12], and a few more bits of
[time.clock]. The remaining C++20 additions to <chrono> from P0355 and
P1466 depend on [time.zone] and <format>, so they will come later, as
will more optimized versions of some of the algorithms added here.
The non-member operator overloads for the calendar types are defined as
namespace-scope functions in the standard, but here we instead define
these operator overloads as hidden friends. This simplifies the
implementation somewhat and lets us reap the benefits of hidden friends
for these overloads.
The bulk of this work is based on a patch from Ed Smith-Rowland, which can
be found at the Git branch users/redi/heads/calendar.
Co-authored-by: Ed Smith-Rowland <3dw4rd@verizon.net>
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/chrono (time_point::operator++)
(time_point::operator--): Define.
(utc_clock, tai_clock, gps_clock): Forward declare.
(utc_time, utc_seconds, tai_time, tai_seconds, gps_time)
(gps_seconds): Define.
(is_clock<utc_clock>, is_clock<tai_clock>, is_clock<gps_clock>)
(is_clock_v<utc_clock>, is_clock_v<tai_clock>)
(is_clock_v<gps_clock>): Define these specializations.
(leap_second_info): Define.
(day, month, year, weekday, weekday_indexed)
(weekday_last, month_day, month_day_last, month_weekday)
(month_weekday_last, year_month, year_month_day)
(year_month_day_last, year_month_weekday, year_month_weekday_last):
Declare and later define.
(last_spec, last, __detail::__days_per_month)
(__detail::__days_per_month, __detail::__last_day): Define.
(January, February, March, April, May, June, July, August)
(September, October, November, December, Sunday, Monday, Tuesday)
(Wednesday, Thursday, Friday, Saturday): Define.
(weekday::operator[]): Define out-of-line.
(year_month_day::_S_from_days, year_month_day::M_days_since_epoch):
Likewise.
(year_month_day::year_month_day, year_month_day::ok): Likewise.
(__detail::__pow10, hh_mm_ss): Define.
(literals::chrono_literals::operator""d)
(literals::chrono_literals::operator""y): Define.
(is_am, is_pm, make12, make24): Define.
* testsuite/20_util/time_point/4.cc: New test.
* testsuite/std/time/day/1.cc: New test.
* testsuite/std/time/hh_mm_ss/1.cc: New test.
* testsuite/std/time/is_am/1.cc: New test.
* testsuite/std/time/is_pm/1.cc: New test.
* testsuite/std/time/make12/1.cc: New test.
* testsuite/std/time/make24/1.cc: New test.
* testsuite/std/time/month/1.cc: New test.
* testsuite/std/time/month_day/1.cc: New test.
* testsuite/std/time/month_day_last/1.cc: New test.
* testsuite/std/time/month_weekday/1.cc: New test.
* testsuite/std/time/month_weekday_last/1.cc: New test.
* testsuite/std/time/weekday/1.cc: New test.
* testsuite/std/time/weekday_indexed/1.cc: New test.
* testsuite/std/time/weekday_last/1.cc: New test.
* testsuite/std/time/year/1.cc: New test.
* testsuite/std/time/year_month/1.cc: New test.
* testsuite/std/time/year_month_day/1.cc: New test.
* testsuite/std/time/year_month_day_last/1.cc: New test.
* testsuite/std/time/year_month_weekday/1.cc: New test.
* testsuite/std/time/year_month_weekday_last/1.cc: New test.
GCC used the name __ARM_FEATURE_SVE_VECTOR_OPERATIONS, but in the
final spec it was renamed to__ARM_FEATURE_SVE_VECTOR_OPERATORS.
gcc/
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Rename
__ARM_FEATURE_SVE_VECTOR_OPERATIONS to
__ARM_FEATURE_SVE_VECTOR_OPERATORS.
gcc/testsuite/
* gcc.target/aarch64/sve/acle/general/attributes_1.c: Rename
__ARM_FEATURE_SVE_VECTOR_OPERATIONS to
__ARM_FEATURE_SVE_VECTOR_OPERATORS.
This patch is really four things rolled into one, since separating
them seemed artificial:
- Update the mangling of the fixed-length SVE ACLE types to match
the upcoming spec. The idea is to mangle:
VLAT __attribute__((arm_sve_vector_bits(N)))
as an instance __SVE_VLS<VLAT, N> of the template:
__SVE_VLS<typename, unsigned>
- Give the fixed-length types their own TYPE_DECL. This is needed
to make the above mangling fix work, but should also be a minor
QoI improvement for error reporting. Unfortunately, the names are
quite verbose, e.g.:
svint8_t __attribute__((arm_sve_vector_bits(512)))
but anything shorter would be ad-hoc syntax and so might be more
confusing.
- Improve the error message reported when arm_sve_vector_bits is
applied to tuples, such as:
svint32x2_t __attribute__((arm_sve_vector_bits(N)))
Previously we would complain that the type isn't an SVE type;
now we complain that it isn't a vector type.
- Don't allow arm_sve_vector_bits(N) to be applied to existing
fixed-length SVE types.
gcc/
* config/aarch64/aarch64-sve-builtins.cc (add_sve_type_attribute):
Take the ACLE name of the type as a parameter and add it as fourth
argument to the "SVE type" attribute.
(register_builtin_types): Update call accordingly.
(register_tuple_type): Likewise. Construct the name of the type
earlier in order to do this.
(get_arm_sve_vector_bits_attributes): New function.
(handle_arm_sve_vector_bits_attribute): Report a more sensible
error message if the attribute is applied to an SVE tuple type.
Don't allow the attribute to be applied to an existing fixed-length
SVE type. Mangle the new type as __SVE_VLS<type, vector-bits>.
Add a dummy TYPE_DECL to the new type.
gcc/testsuite/
* g++.target/aarch64/sve/acle/general-c++/attributes_2.C: New test.
* g++.target/aarch64/sve/acle/general-c++/mangle_6.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/mangle_7.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/mangle_8.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/mangle_9.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/mangle_10.C: Likewise.
* gcc.target/aarch64/sve/acle/general/attributes_7.c: Check the
error messages reported when arm_sve_vector_bits is applied to
SVE tuple types or to existing fixed-length SVE types.
GCC was implementing an old mangling scheme for single SVE
vectors and predicates (based on the Advanced SIMD one).
The final definition instead put them in the vendor built-in
namespace via the "u" prefix.
gcc/
* config/aarch64/aarch64-sve-builtins.cc (DEF_SVE_TYPE): Add a
leading "u" to each mangled name.
gcc/testsuite/
* g++.target/aarch64/sve/acle/general-c++/mangle_1.C: Add a leading
"u" to the mangling of each SVE vector and predicate type.
* g++.target/aarch64/sve/acle/general-c++/mangle_2.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/mangle_3.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/mangle_5.C: Likewise.
This recomputes RPO after store-motion changes the CFG.
2020-08-25 Richard Biener <rguenther@suse.de>
PR tree-optimization/96548
PR tree-optimization/96760
* tree-ssa-loop-im.c (tree_ssa_lim): Recompute RPO after
store-motion.
* gcc.dg/torture/pr96548.c: New testcase.
* gcc.dg/torture/pr96760.c: Likewise.
Clobbers of MEM_REF with NULL address are just fancy nops, something we just
ignore and don't emit any code for it (ditto for other clobbers), they just
mark end of life on something, so we shouldn't infer from those that there
is some UB.
2020-08-25 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/96722
* gimple.c (infer_nonnull_range): Formatting fix.
(infer_nonnull_range_by_dereference): Return false for clobber stmts.
* g++.dg/opt/pr96722.C: New test.
The following testcase is miscompiled, because handle_builtin_string_cmp
sees a strncmp call with constant last argument 4, where one of the strings
has an upper bound of 5 bytes (due to it being an array of that size) and
the other has a known string length of 1 and the result is used only in
equality comparison.
It is folded into __builtin_strncmp_eq (str1, str2, 4), which is
incorrect, because that means reading 4 bytes from both strings and
comparing that. When one of the strings has known strlen of 1, we want to
compare just 2 bytes, not 4, as strncmp shouldn't compare any bytes beyond
the null.
So, the last argument to __builtin_strncmp_eq should be the minimum of the
provided strncmp last argument and the known string length + 1 (assuming
the other string has only a known upper bound due to array size).
Besides that, I've noticed the code has been written with the intent to also
support the case where we know exact string length of both strings (but not
the string content, so we can't compute it at compile time). In that case,
both cstlen1 and cstlen2 are non-negative and both arysiz1 and arysiz2 are
negative. We wouldn't optimize that, cmpsiz would be either the strncmp
last argument, or for strcmp the first string length, but varsiz would be
-1 and thus cmpsiz would be never < varsiz. The patch fixes it by using the
correct length, in that case using the minimum of the two and for strncmp
also the last argument.
2020-08-25 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/96758
* tree-ssa-strlen.c (handle_builtin_string_cmp): If both cstlen1
and cstlen2 are set, set cmpsiz to their minimum, otherwise use the
one that is set. If bound is used and smaller than cmpsiz, set cmpsiz
to bound. If both cstlen1 and cstlen2 are set, perform the optimization.
* gcc.dg/strcmpopt_12.c: New test.
I must admit I was quite surprised to see that SRA does not disqualify
an aggregate from any transformations when it encounters an offset for
which get_ref_base_and_extent returns a negative offset. It may not
matter too much because I sure hope such programs always have
undefined behavior (SRA candidates are local variables on stack) but
it is probably better not to perform weird transformations on them as
build ref model with the new build_reconstructed_reference function
currently happily do for negative offsets (they just copy the existing
expression which is then used as the expression of a "propagated"
access) and of course the compiler must not ICE (as it currently does
because the SRA forest verifier does not like the expression).
gcc/ChangeLog:
2020-08-24 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/96730
* tree-sra.c (create_access): Disqualify any aggregate with negative
offset access.
(build_ref_for_model): Add assert that offset is non-negative.
gcc/testsuite/ChangeLog:
2020-08-24 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/96730
* gcc.dg/tree-ssa/pr96730.c: New test.
PR tree-optimization/21137 is now an old enhancement request pointing out
that an optimization I added back in 2006, to optimize "((x>>31)&64) != 0"
as "x < 0", doesn't fire in the presence of unanticipated type conversions.
The fix is to call STRIP_NOPS at the appropriate point.
2020-08-25 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR tree-optimization/21137
* fold-const.c (fold_binary_loc) [NE_EXPR/EQ_EXPR]: Call
STRIP_NOPS when checking whether to simplify ((x>>C1)&C2) != 0.
gcc/testsuite/ChangeLog
PR tree-optimization/21137
* gcc.dg/pr21137.c: New test.
The problem here is mips has its own builtin_longjmp
pattern and it was not fixed when expand_builtin_longjmp
was fixed. We need to read the new fp and gp before
restoring the stack as the buffer might be a local
variable.
2020-08-25 Andrew Pinski <apinski@marvell.com>
gcc/ChangeLog:
PR middle-end/64242
* config/mips/mips.md (builtin_longjmp): Restore the frame
pointer and stack pointer and gp.
The following makes sure to, at early debug generation time, mangle
symbols we eventually end up outputting during late finish.
2020-08-24 Richard Biener <rguenther@suse.de>
PR debug/96690
* dwarf2out.c (reference_to_unused): Make FUNCTION_DECL
processing more consistent with respect to
symtab->global_info_ready.
(tree_add_const_value_attribute): Unconditionally call
rtl_for_decl_init to do all mangling early but throw
away the result if early_dwarf.
* g++.dg/lto/pr96690_0.C: New testcase.
2020-08-24 Hongtao Liu <hongtao.liu@intel.com>
gcc/ChangeLog:
PR target/96755
* config/i386/sse.md: Correct the mode of NOT operands to
SImode.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr96755.c: New test.
The following patch implements an optimization suggested in the PR,
copysign(x,-x) can be optimized into -x (even without -ffast-math,
should work fine even for signed zeros and infinities or nans).
2020-08-25 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/96715
* match.pd (copysign(x,-x) -> -x): New simplification.
* gcc.dg/tree-ssa/copy-sign-3.c: New test.
The following testcase is miscompiled, because build_trivial_dtor_call
handles the case when instance is a pointer by adding a clobber to what
the pointer points to (which is desirable e.g. for delete) rather than the
pointer itself. That is I think always desirable behavior for references,
but for pointers for the pseudo dtor case it is not.
2020-08-25 Jakub Jelinek <jakub@redhat.com>
PR c++/96721
* cp-tree.h (build_trivial_dtor_call): Add bool argument defaulted
to false.
* call.c (build_trivial_dtor_call): Add NO_PTR_DEREF argument. If
instance is a pointer and NO_PTR_DEREF is true, clobber the pointer
rather than what it points to.
* semantics.c (finish_call_expr): Call build_trivial_dtor_call with
true as NO_PTR_DEREF.
* g++.dg/opt/flifetime-dse8.C: New test.
My patch to introduce native_encode_initializer to fold_ctor_reference
apparently broke gnulib/m4 on powerpc64.
There it uses a const union with two doubles and corresponding IBM double
double long double which actually is the largest normalizable long double
value (1 ulp higher than __LDBL_MAX__). The reason our __LDBL_MAX__ is
smaller is that we internally treat the double double type as one having
106-bit precision, but it actually has a variable 53-bit to 2000-ish bit precision
and for the
0x1.fffffffffffff7ffffffffffffc000p+1023L
value gnulib uses we need 107-bit precision, therefore for GCC __LDBL_MAX__
is
0x1.fffffffffffff7ffffffffffff8000p+1023L
Before my changes, we wouldn't be able to fold_ctor_reference it and it
worked fine at runtime, but with the change we are able to do that, but
because it is larger than anything we can handle internally, we treat it
weirdly. Similar problem would be if somebody creates this way valid,
but much more than 106 bit precision e.g. 1.0 + 1.0e-768.
Now, I think similar problem could happen e.g. on i?86/x86_64 with long
double there, it also has some weird values in the format, e.g. the
unnormals, pseudo infinities and various other magic values.
This patch for floating point types (including vector and complex types
with such elements) will try to encode the returned value again and punt
if it has different memory representation from the original. Note, this
is only done in the path where native_encode_initializer was used, in order
not to affect e.g. just reading an unpunned long double value; the value
should be compiler generated in that case and thus should be properly
representable. It will punt also if e.g. the padding bits are initialized
to non-zero values.
I think the verification that what we encode can be interpreted back
woiuld be only an internal consistency check (so perhaps for ENABLE_CHECKING
if flag_checking only, but if both directions perform it, then we need
to avoid mutual recursion).
While for the other direction (interpretation), at least for the broken by
design long doubles we just know we can't represent in GCC all valid values.
The other floating point formats are just theoretical case, perhaps we would
canonicalize something to a value that wouldn't trigger invalid exception
when without canonicalization it would trigger it at runtime, so let's just
ignore those.
Adjusted (so far untested) patch to do it in native_interpret_real instead
and limit it to the MODE_COMPOSITE_P cases, for which e.g.
fold-const.c/simplify-rtx.c punts in several other places too because we just
know we can't represent everything.
E.g.
/* Don't constant fold this floating point operation if the
result may dependent upon the run-time rounding mode and
flag_rounding_math is set, or if GCC's software emulation
is unable to accurately represent the result. */
if ((flag_rounding_math
|| (MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations))
&& (inexact || !real_identical (&result, &value)))
return NULL_TREE;
Or perhaps guard it with MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations
too, thus break what gnulib / m4 does with -ffast-math, but not normally?
2020-08-25 Jakub Jelinek <jakub@redhat.com>
PR target/95450
* fold-const.c (native_interpret_real): For MODE_COMPOSITE_P modes
punt if the to be returned REAL_CST does not encode to the bitwise
same representation.
* gcc.target/powerpc/pr95450.c: New test.
For PR70462 I stopped emitting the as-base constructor and destructor
variants for final classes, because they can never be called. Except that
it turns out that clang calls base variants from complete variants, even for
classes with virtual bases, and in some cases inlines them such that the
calls to the base variant are exposed. So we need to continue to emit the
as-base symbols, even though they're unreachable by G++-compiled code.
gcc/cp/ChangeLog:
PR c++/95428
* optimize.c (populate_clone_array): Revert PR70462 change.
(maybe_clone_body): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/other/final8.C: Adjust expected output.
This implements the proposed resolution of LWG 3446. I'm also adding
another new constrained specialization which isn't proposed by 3446, to
resolve the ambiguity when a type has both value_type and element_type
but denoting different types.
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (indirectly_readable): Add
partial specializations to resolve ambiguities (LWG 3446).
* testsuite/24_iterators/associated_types/readable.traits.cc:
Check types with both value_type and element_type.
This avoids the overflow that occurs when negating the most negative
value of an integral type.
Also prevent returning signed int when the values have lower rank and
promote to int.
libstdc++-v3/ChangeLog:
* include/std/ranges (ranges::iota_view::size()): Perform all
calculations in the right unsigned types.
* testsuite/std/ranges/iota/size.cc: New test.
I frequently need to look at overload sets, and debug_node spews more
information than is useful, most of the time. Here's a dumper for
overloads, that just tells you their full name and where they came from.
gcc/cp
* ptree.c (debug_overload): New.
Runtime error occurs when the type of the value argument is
character(0): "Zero-length string passed as value...".
The status argument, intent(out), will contain -1 if the value
of the environment is too large to fit in the value argument, this
is the case if the type is character(0) so there is no reason to
produce a runtime error if the value argument is zero length.
2020-08-24 Mark Eggleston <markeggleston@gcc.gnu.org>
libgfortran/
PR fortran/96486
* intrinsics/env.c: If value_len is > 0 blank the string.
Copy the result only if its length is > 0.
2020-08-24 Mark Eggleston <markeggleston@gcc.gnu.org>
gcc/testsuite/
PR fortran/96486
* gfortran.dg/pr96486.f90: New test.
armv8-m.base (cortex-m23) has the movt instruction, so we need to
disable the define_split to generate a constant in this case,
otherwise we get incorrect insn constraints as described in PR94538.
We also need to fix the pure-code alternative for thumb1_movsi_insn
because the assembler complains with instructions like
movs r0, #:upper8_15:1234
(Internal error in md_apply_fix)
We now generate movs r0, 4 instead.
2020-08-24 Christophe Lyon <christophe.lyon@linaro.org>
PR target/94538
gcc/
* config/arm/thumb1.md: Disable set-constant splitter when
TARGET_HAVE_MOVT.
(thumb1_movsi_insn): Fix -mpure-code
alternative.
PR target/94538
gcc/testsuite/
* gcc.target/arm/pure-code/pr94538-1.c: New test.
* gcc.target/arm/pure-code/pr94538-2.c: New test.
gcc/ChangeLog:
* tree-vect-data-refs.c (dr_group_sort_cmp): Work on
data_ref_pair.
(vect_analyze_data_ref_accesses): Work on groups.
(vect_find_stmt_data_reference): Add group_id argument and fill
up dataref_groups vector.
* tree-vect-loop.c (vect_get_datarefs_in_loop): Pass new
arguments.
(vect_analyze_loop_2): Likewise.
* tree-vect-slp.c (vect_slp_analyze_bb_1): Pass argument.
(vect_slp_bb_region): Likewise.
(vect_slp_region): Likewise.
(vect_slp_bb):Work on the entire BB.
* tree-vectorizer.h (vect_analyze_data_ref_accesses): Add new
argument.
(vect_find_stmt_data_reference): Likewise.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-38.c: Adjust pattern as now we only process
a single vectorization and now 2 partial.
* gcc.dg/vect/bb-slp-45.c: New test.
