When using %qs instead of '%s' or %<=%> instead of '=' looks nicer
by having nicer quotes and bold text, if the terminal supports it;
otherwise, plain quotes are used.
gcc/fortran/ChangeLog:
* match.cc (gfc_match_member_sep): Use %<...%> in gfc_error.
* openmp.cc (gfc_match_oacc_routine, gfc_match_omp_context_selector,
gfc_match_omp_context_selector_specification,
gfc_match_omp_declare_variant, resolve_omp_clauses): Likewise;
use %qs instead of '%s'.
* primary.cc (match_real_constant, gfc_match_varspec): Likewise.
* resolve.cc (gfc_resolve_formal_arglist, resolve_operator,
resolve_ordinary_assign): Likewise.
Prepare to add changelogs for the Modula2 front end by changing
the contrib git_commit.py script.
contrib/ChangeLog:
* gcc-changelog/git_commit.py (default_changelog_locations):
New entry for gcc/m2. New entry for libgm2.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
Function rs6000_emit_set_const/rs6000_emit_set_long_const are only invoked from
two "define_split"s where the target operand is limited to gpc_reg_operand or
int_reg_operand, then the operand must be REG_P.
And in rs6000_emit_set_const/rs6000_emit_set_long_const, to create temp rtx,
it is using code like "gen_reg_rtx({S|D}Imode)", it must also be REG_P.
So, copy_rtx is not needed for temp and dest.
This patch removes those "copy_rtx" for rs6000_emit_set_const and
rs6000_emit_set_long_const.
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_emit_set_const): Remove copy_rtx.
(rs6000_emit_set_long_const): Likewise.
Similar story as PR103661, we again return a negative number
for __builtin_cpu_supports:
Documentation says:
int __builtin_cpu_supports(const char *feature)
This function returns a positive integer if the run-time CPU supports feature and returns 0 otherwise.
while we return -2147483648.
Moreover, I noticed "x86-64" is not a valid option for __builtin_cpu_is,
but for __builtin_cpu_supports.
PR target/107551
gcc/ChangeLog:
* config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
as for PR103661.
* doc/extend.texi: Fix "x86-64" use.
gcc/testsuite/ChangeLog:
* gcc.target/i386/builtin_target.c: Add more checks.
This change resolves a naming conflict introduced by the recently added
SUBTARGET_CC1_SPEC to gcc.cc. Some targets (mips and loongarch) aready used
a SUBTARGET_CC1_SPEC define. Rename the define used by gcc.cc to OS_CC1_SPEC.
gcc/ChangeLog:
* config/rtems.h (SUBTARGET_CC1_SPEC): Rename to...
(OS_CC1_SPEC): ...this.
* gcc.cc (SUBTARGET_CC1_SPEC): Rename to...
(OS_CC1_SPEC): ...this.
gcc/analyzer/ChangeLog:
PR analyzer/108003
* call-summary.cc
(call_summary_replay::convert_region_from_summary_1): Convert
heap_regs_in_use from auto_sbitmap to auto_bitmap.
* region-model-manager.cc
(region_model_manager::get_or_create_region_for_heap_alloc):
Convert from sbitmap to bitmap.
* region-model-manager.h: Likewise.
* region-model.cc
(region_model::get_or_create_region_for_heap_alloc): Convert from
auto_sbitmap to auto_bitmap.
(region_model::get_referenced_base_regions): Likewise.
* region-model.h: Include "bitmap.h" rather than "sbitmap.h".
(region_model::get_referenced_base_regions): Convert from
auto_sbitmap to auto_bitmap.
gcc/testsuite/ChangeLog:
PR analyzer/108003
* g++.dg/analyzer/pr108003.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
gcc/analyzer/ChangeLog:
* region-model-impl-calls.cc (class kf_memcpy): Rename to...
(class kf_memcpy_memmove): ...this.
(kf_memcpy::impl_call_pre): Rename to...
(kf_memcpy_memmove::impl_call_pre): ...this, and check the src for
poison.
(register_known_functions): Update for above renaming, and
register BUILT_IN_MEMMOVE and BUILT_IN_MEMMOVE_CHK.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/memcpy-1.c (test_8a, test_8b): New tests.
* gcc.dg/analyzer/memmove-1.c: New test, based on memcpy-1.c
* gcc.dg/analyzer/out-of-bounds-1.c (test7): Update expected
result for uninit srcBuf.
* gcc.dg/analyzer/out-of-bounds-5.c (test8, test9): Add
dg-warnings for memcpy from uninit src vla.
* gcc.dg/analyzer/pr104308.c (test_memmove_within_uninit):
Expect creation point note to be missing on riscv*-*-*.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
These are not valid in C++11 and cause a warning when preprocessing,
even though they're inside a skipped group.
chrono:2436: warning: missing terminating ' character
libstdc++-v3/ChangeLog:
PR libstdc++/108015
* include/std/chrono (hh_mm_ss): Remove digit separators.
We define these with the 'struct' keyword, but the standard uses
'class'. This results in warnings if users try to refer to them using
elaborated type specifiers.
libstdc++-v3/ChangeLog:
* include/bits/chrono.h (duration, time_point): Change 'struct'
to 'class'.
I got a complaint that while Clang docs suggest options that improve
the quality of the backtraces ASAN prints (cf.
<https://clang.llvm.org/docs/AddressSanitizer.html#usage>), our docs
don't say anything to that effect. This patch amends that with a new
paragraph. (It deliberately doesn't mention -fno-omit-frame-pointer.)
gcc/ChangeLog:
* doc/invoke.texi (-fsanitize=address): Suggest options to improve
stack traces.
The existing comparison was incorrect for non-PRECISE counts
(e.g., AFDO): we could end up with a 0 base_count, which could
lead to asserts, e.g., in good_cloning_opportunity_p.
Tested on x86_64-pc-linux-gnu.
gcc/ChangeLog:
PR ipa/108000
* ipa-cp.cc (ipcp_propagate_stage): Fix profile count comparison
gcc/testsuite
* gcc.dg/tree-prof/pr108000.c: Regression test
The eBPF architecture provides 'end[be,le]' instructions for endianness
swapping. Add a define_insn for bswap<mode>2 to use them instaed of
falling back on a libcall.
gcc/
* config/bpf/bpf.md (bswap<mode>2): New define_insn.
gcc/testsuite/
* gcc.target/bpf/bswap-1.c: New test.
The previous patch avoided building an initializer_list<string> at all when
building a vector<string>, but in situations where that isn't possible, we
could still build the initializer_list with a loop over a constant array.
This is represented using a VEC_INIT_EXPR, which required adjusting a couple
of places that expected the initializer array to have the same type as the
target array and fixing build_vec_init not to undo our efforts.
PR c++/105838
gcc/cp/ChangeLog:
* call.cc (convert_like_internal) [ck_list]: Use
maybe_init_list_as_array.
* constexpr.cc (cxx_eval_vec_init_1): Init might have
a different type.
* tree.cc (build_vec_init_elt): Likewise.
* init.cc (build_vec_init): Handle from_array from a
TARGET_EXPR. Retain TARGET_EXPR of a different type.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/initlist-opt2.C: New test.
When constructing a vector<string> from { "strings" }, first is built an
initializer_list<string>, which is then copied into the strings in the
vector. But this is inefficient: better would be treat the { "strings" }
as a range and construct the strings in the vector directly from the
string-literals. We can do this transformation for standard library
classes because we know the design patterns they follow.
PR c++/105838
gcc/cp/ChangeLog:
* call.cc (list_ctor_element_type): New.
(braced_init_element_type): New.
(has_non_trivial_temporaries): New.
(maybe_init_list_as_array): New.
(maybe_init_list_as_range): New.
(build_user_type_conversion_1): Use maybe_init_list_as_range.
* parser.cc (cp_parser_braced_list): Call
recompute_constructor_flags.
* cp-tree.h (find_temps_r): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/initlist-opt1.C: New test.
In this PR, initializing the array of std::string to pass to the vector
initializer_list constructor gets very confusing to the optimizers as the
number of elements increases, primarily because of all the std::allocator
temporaries passed to all the string constructors. Instead of creating one
for each string, let's share an allocator between all the strings; we can do
this safely because we know that std::allocator is stateless and that string
doesn't care about the object identity of its allocator parameter.
PR c++/105838
gcc/cp/ChangeLog:
* cp-tree.h (is_std_allocator): Declare.
* constexpr.cc (is_std_allocator): Split out from...
(is_std_allocator_allocate): ...here.
* init.cc (find_temps_r): New.
(find_allocator_temp): New.
(build_vec_init): Use it.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/allocator-opt1.C: New test.
Currently patchable area is at the wrong place on AArch64. It is placed
immediately after function label, before .cfi_startproc. This patch
adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
modifies aarch64_print_patchable_function_entry to avoid placing
patchable area before .cfi_startproc.
gcc/
PR target/98776
* config/aarch64/aarch64-protos.h (aarch64_output_patchable_area):
Declared.
* config/aarch64/aarch64.cc (aarch64_print_patchable_function_entry):
Emit an UNSPECV_PATCHABLE_AREA pseudo instruction.
(aarch64_output_patchable_area): New.
* config/aarch64/aarch64.md (UNSPECV_PATCHABLE_AREA): New.
(patchable_area): Define.
gcc/testsuite/
PR target/98776
* gcc.target/aarch64/pr98776.c: New.
* gcc.target/aarch64/pr92424-2.c: Adjust pattern.
* gcc.target/aarch64/pr92424-3.c: Adjust pattern.
In commit e5cfb9cac1d7aba9a8ea73bfe7922cfaff9d61f3 I introduced tests
for strdup and strndup with leaks. Fix those leaks.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-dynamic-object-size-0.c (test_strdup,
test_strndup, test_strdup_min, test_strndup_min): Free RES
before returning from function.
Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
The following testcase FAILs on aarch64-linux. We have some atomic
instruction followed by 2 DEBUG_INSNs (if -g only of course) followed
by NOTE_INSN_EPILOGUE_BEG followed by some USE insn.
Now, split3 pass replaces the atomic instruction with a code sequence
which ends with a conditional jump and the split3 pass calls
find_many_sub_basic_blocks.
For -g0, find_bb_boundaries sees the flow_transfer_insn (the new conditional
jump), then NOTE_INSN_EPILOGUE_BEG which can live in between basic blocks
and then the USE insn, so splits block after the NOTE_INSN_EPILOGUE_BEG
and puts the NOTE in between the blocks.
For -g, if sees a DEBUG_INSN after the flow_transfer_insn, so sets
debug_insn to it, then walks over another DEBUG_INSN, NOTE_INSN_EPILOGUE_BEG
until it finally sees the USE insn, and triggers the:
rtx_insn *prev = PREV_INSN (insn);
/* If the first non-debug inside_basic_block_p insn after a control
flow transfer is not a label, split the block before the debug
insn instead of before the non-debug insn, so that the debug
insns are not lost. */
if (debug_insn && code != CODE_LABEL && code != BARRIER)
prev = PREV_INSN (debug_insn);
code I've added for PR81325. If there are only DEBUG_INSNs, that is
the right thing to do, but if in between debug_insn and insn there are
notes which can stay in between basic blocks or simnilarly JUMP_TABLE_DATA
or their associated CODE_LABELs, it causes -fcompare-debug differences.
The following patch fixes it by clearing debug_insn if JUMP_TABLE_DATA
or associated CODE_LABEL is seen (I'm afraid there is no good answer
what to do with DEBUG_INSNs before those; the code then removes them:
/* Clean up the bb field for the insns between the blocks. */
for (x = NEXT_INSN (flow_transfer_insn);
x != BB_HEAD (fallthru->dest);
x = next)
{
next = NEXT_INSN (x);
/* Debug insns should not be in between basic blocks,
drop them on the floor. */
if (DEBUG_INSN_P (x))
delete_insn (x);
else if (!BARRIER_P (x))
set_block_for_insn (x, NULL);
}
but if there are NOTEs, the patch just reorders the NOTEs and DEBUG_INSNs,
such that the NOTEs come first (so that they stay in between basic blocks
like with -g0) and DEBUG_INSNs after those (so that bb is split before
them, so they will be in the basic block after NOTE_INSN_BASIC_BLOCK).
2022-12-08 Jakub Jelinek <jakub@redhat.com>
PR debug/106719
* cfgbuild.cc (find_bb_boundaries): If there are NOTEs in between
debug_insn (seen after flow_transfer_insn) and insn, move NOTEs
before all the DEBUG_INSNs and split after NOTEs. If there are
other insns like jump table data, clear debug_insn.
* gcc.dg/pr106719.c: New test.
PR tree-optimization/107985
gcc/
* gimple-range-op.cc
(gimple_range_op_handler::gimple_range_op_handler): Check if type
of the operands is supported.
* gimple-range.cc (gimple_ranger::prefill_stmt_dependencies): Do
not assert if here is no range-op handler.
gcc/testsuite/
* g++.dg/pr107985.C: New.
The following addresses a missed folding noticed in PR107699 that can
be fixed amending the existing &x + a != &x + b pattern to also handle
the case of only one side having a pointer plus. I'm moving the
patterns next to related simpifications showing there'd be an existing
pattern matching this if it were not gated with an explicit single_use
constraint. Note the new pattern also handles &x.a + a != &x.b, but
this hints at some unification / generalization opportunities here.
PR tree-optimization/107699
* match.pd (&a !=/== &a.b + c -> (&a - &a.b) !=/== c): New
pattern variant.
* gcc.dg/tree-ssa/pr107699.c: New testcase.
The bogus Wstringop-overflow warnings conditionally issued for
Warray-bounds-48.c and -Wzero-length-array-bounds-2.c are expected
under conditions that depend on the availability of certain vector
patterns, but that don't seem to model the conditions under which the
warnings are expected.
On riscv64-elf and arm-eabi/-mcpu=cortex-r5, for example, though the
Warray-bounds-48.c condition passes, we don't issue warnings. On
riscv64-elf, we decide not to vectorize the assignments; on cortex-r5,
we do vectorize pairs of assignments, but that doesn't yield the
expected warning, even though assignments that should trigger the
bogus warning are vectorized and associated with the earlier line
where the bogus warning would be expected.
On riscv64, for Wzero-length-array-bounds-2.c, we issue the expected
warning in test_C_global_buf, but we also issue a warning for
test_C_local_buf under the same conditions, that would be expected on
other platforms but that is not issued on them. On
arm-eabi/-mcpu=cortex-r5, the condition passes so we'd expect the
warning in both functions, but we don't warn on either.
Instead of further extending the effective target tests, introduced to
temporarily tolerate these expected bogus warnings, so as to capture
the vectorizer analyses that lead to the mismatched decisions, I'm
disabling the undesired warnings for these two tests.
for gcc/testsuite/ChangeLog
PR tree-optimization/102706
* gcc.dg/Warray-bounds-48.c: Disable -Wstringop-overflow.
* gcc.dg/Wzero-length-array-bounds-2.c: Likewise.
The FP emulation on ARM doesn't take rounding modes into account. The
tests require hard_float, but that only tests for calls when adding
doubles. There are arm targets that support hardware adds, but that
emulate conversions.
for gcc/testsuite/ChangeLog
* gcc.dg/torture/fp-uint64-convert-double-1.c: Expect fail on
arm-*-eabi*.
* gcc.dg/torture/fp-uint64-convert-double-2.c: Likewise.
On arm-eabi, and possibly on other platforms, -fshort-enums is enabled
by default, which breaks some tests' expectations as to enum sizes
with DEFERRED_INIT. Disable short enums so that the expectations are
met.
for gcc/testsuite/ChangeLog
* c-c++-common/auto-init-1.c: Add -fno-short-enums.
* c-c++-common/auto-init-2.c: Likewise.
* gcc.dg/debug/btf/btf-enum-1.c: Likewise.
As mentioned in PR107967, ibm-ldouble-format documents that
+- has 1ulp accuracy, * 2ulps and / 3ulps.
So, even if the result is exact, we need to widen the range a little bit.
The following patch does that. I just wonder what it means for reverse
division (the op1_range case), which we implement through multiplication,
when division has 3ulps error and multiplication just 2ulps. In any case,
this format is a mess and for non-default rounding modes can't be trusted
at all, instead of +inf or something close to it it happily computes -inf.
2022-12-08 Jakub Jelinek <jakub@redhat.com>
* range-op-float.cc (frange_nextafter): For MODE_COMPOSITE_P from
denormal or zero, use real_nextafter on DFmode with conversions
around it.
(frange_arithmetic): For mode_composite, on top of rounding in the
right direction accept extra 1ulp error for PLUS/MINUS_EXPR, extra
2ulps error for MULT_EXPR and extra 3ulps error for RDIV_EXPR.
The addition of PLUS/MINUS/MULT/RDIV_EXPR frange handlers causes
miscompilation of some of the libm routines, resulting in lots of
glibc test failures. A part of them is purely PR107608 fold-overflow-1.c
etc. issues, say when the code does
return -0.5 / 0.0;
and expects division by zero to be emitted, but we propagate -Inf
and avoid the operation.
But there are also various tests where we end up with different computed
value from the expected ones. All those cases are like:
is: inf inf
should be: 1.18973149535723176502e+4932 0xf.fffffffffffffff0p+16380
is: inf inf
should be: 1.18973149535723176508575932662800701e+4932 0x1.ffffffffffffffffffffffffffffp+16383
is: inf inf
should be: 1.7976931348623157e+308 0x1.fffffffffffffp+1023
is: inf inf
should be: 3.40282346e+38 0x1.fffffep+127
and the corresponding source looks like:
static const double huge = 1.0e+300;
double whatever (...) {
...
return huge * huge;
...
}
which for rounding to nearest or +inf should and does return +inf, but
for rounding to -inf or 0 should instead return nextafter (inf, -inf);
The rules IEEE754 has are that operations on +-Inf operands are exact
and produce +-Inf (except for the invalid ones that produce NaN) regardless
of rounding mode, while overflows:
"a) roundTiesToEven and roundTiesToAway carry all overflows to ∞ with the
sign of the intermediate result.
b) roundTowardZero carries all overflows to the format’s largest finite
number with the sign of the intermediate result.
c) roundTowardNegative carries positive overflows to the format’s largest
finite number, and carries negative overflows to −∞.
d) roundTowardPositive carries negative overflows to the format’s most
negative finite number, and carries positive overflows to +∞."
The behavior around overflows to -Inf or nextafter (-inf, inf) was actually
handled correctly, we'd construct [-INF, -MAX] ranges in those cases
because !real_less (&value, &result) in that case - value is finite
but larger in magnitude than what the format can represent (but GCC
internal's format can), while result is -INF in that case.
But for the overflows to +Inf or nextafter (inf, -inf) was handled
incorrectly, it tested real_less (&result, &value) rather than
!real_less (&result, &value), the former test is true when already the
rounding value -> result rounded down and in that case we shouldn't
round again, we should round down when it didn't.
So, in theory this could be fixed just by adding one ! character,
- if ((mode_composite || (real_isneg (&inf) ? real_less (&result, &value)
+ if ((mode_composite || (real_isneg (&inf) ? !real_less (&result, &value)
: !real_less (&value, &result)))
but the following patch goes further. The distance between
nextafter (inf, -inf) and inf is large (infinite) and expressions like
1.0e+300 * 1.0e+300 always produce +inf in round to nearest mode by far,
so I think having low bound of nextafter (inf, -inf) in that case is
unnecessary. But if it isn't multiplication but say addition and we are
inexact and very close to the boundary between rounding to nearest
maximum representable vs. rounding to nearest +inf, still using [MAX, +INF]
etc. ranges seems safer because we don't know exactly what we lost in the
inexact computation.
The following patch implements that.
2022-12-08 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/107967
* range-op-float.cc (frange_arithmetic): Fix a thinko - if
inf is negative, use nextafter if !real_less (&result, &value)
rather than if real_less (&result, &value). If result is +-INF
while value is finite and -fno-rounding-math, don't do rounding
if !inexact or if result is significantly above max representable
value or below min representable value.
* gcc.dg/pr107967-1.c: New test.
* gcc.dg/pr107967-2.c: New test.
* gcc.dg/pr107967-3.c: New test.
The constraints on auto in C2x disallow use with other storage-class
specifiers unless the type is inferred from an initializer. That
includes constexpr; add the missing checks for this case (the
combination of auto, constexpr and a type specifier).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c/
* c-decl.cc (declspecs_add_type, declspecs_add_scspec): Check for
auto, constexpr and a type used together.
gcc/testsuite/
* gcc.dg/c2x-constexpr-1.c: Do not use auto, constexpr and a type
together.
* gcc.dg/c2x-constexpr-3.c: Add tests of auto, constexpr and type
used together.
Also pass threaded=1 to __glibcxx_backtrace_create_state and remove some
of the namespace scope declarations in the header.
Co-authored-by: François Dumont <frs.dumont@gmail.com>
libstdc++-v3/ChangeLog:
* include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE]
(_Error_formatter::_Error_formatter): Pass error handler to
__glibcxx_backtrace_create_state. Pass 1 for threaded argument.
(_Error_formatter::_S_err): Define empty function.
* src/c++11/debug.cc (_Error_formatter::_M_error): Pass error
handler to __glibcxx_backtrace_full.
Add a test for the case of auto with implicit int in C90 mode, which
is incompatible with C2x semantics (I missed adding such a test when
implementing C2x auto).
Tested for x86_64-pc-linux-gnu.
* gcc.dg/c90-auto-1.c: New test.
