Pseudo class calculated on the 1st iteration should not have a
special treatment in cost calculation when processing move involving
the pseudo and a hard register.
gcc/ChangeLog:
PR target/99531
* ira-costs.c (record_operand_costs): Do not take pseudo class
calculated on the 1st iteration into account when processing move
involving the pseudo and a hard register.
gcc/testsuite/ChangeLog:
PR target/99531
* gcc.target/i386/pr99531.c: New test.
I'll post my proposed fix for PR target/103611 shortly, but this patch
fixes another missed optimization opportunity revealed by that PR.
Occasionally, reload materializes integer constants during register
allocation sometimes resulting in unnecessary instructions such as:
(insn 23 31 24 2 (parallel [
(set (reg:SI 0 ax [99])
(ior:SI (reg:SI 0 ax [99])
(const_int 0 [0])))
(clobber (reg:CC 17 flags))
]) "pr103611.c":18:73 550 {*iorsi_1}
(nil))
These then get "optimized" during the split2 pass, which realizes that
no bits outside of 0xff00 are set, so this operation can be implemented
by operating on just the highpart of a QIreg_operand, i.e. %ah, %bh, %ch
etc., which leads to the useless "orb $0, %ah" seen in the reported PR.
This fix catches the case of const0_rtx in relevant splitter, either
eliminating the instruction or turning it into a simple move.
2021-12-13 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/i386/i386.md (define_split any_or:SWI248 -> orb %?h):
Optimize the case where the integer constant operand is zero.
gcc/testsuite/ChangeLog
* gcc.target/i386/pr103611-1.c: New test case.
Split LINK_SPEC as BASE_LINK_SPEC + EXTRA_LINK_SPEC,
with an overridable LINK_OS component that cpu ports may
redefine.
Leverage the latter on powerpc for VxWorks 7, where we incorporate
our specific bits in the linux os configuration as the system compiler
is now very close to a standard linux one.
The split allows supporting shared objects (shared libs and
non-static rtps) on recent versions of VxWorks while retaining
compatibility with older VxWorks targets which could link with
shared libraries but not build them.
2021-12-07 Doug Rupp <rupp@adacore.com>
Olivier Hainque <hainque@adacore.com>
gcc/
* config/vxworks.h (VXWORKS_LINK_OS_SPEC): New spec.
(VXWORKS_BASE_LINK_SPEC): New spec, using the former.
(VXWORKS_EXTRA_LINK_SPEC): New spec for old and new VxWorks.
(VXWORKS_LINK_SPEC): Combo of BASE and EXTRA specs.
* config/rs6000/vxworks.h (VXWORKS_LINK_OS_SPEC): Empty.
(LINK_OS_EXTRA_SPEC32): Use VXWORKS_LINK_SPEC.
(LINK_OS_EXTRA_SPEC64): Likewise.
t-linux assigns .so version numbers to a set of
symbols, some of which aren't included the VxWorks libgcc
on powerpc (from ibm-ldouble.c, in particular).
t-slibgcc-libgcc yields a kind of .so file that the default
loader can't handle. This sort of extension to tmake_file for
shared libs will be better handled in a grouped fashion for
all targets anyway.
2021-12-13 Olivier Hainque <hainque@adacore.com>
* config.host (powerpc*-*-vxworks7*): Remove
rs6000/t-linux and t-slibgcc-libgcc from tmake_file.
Not needed any more after the recent cleanups issued for the
support of shared libraries.
2021-12-13 Olivier Hainque <hainque@adacore.com>
libgcc/
* config.host (*vxworks*): Remove special case for
arm on the use of vxcrtstuff.
This change tightens and documents the use of libc_internal, then
strengthens the VxWorks crtstuff objects for the support of shared
libraries. In particular:
- Define __dso_handle, which libstdc++.so requires,
- Provide _init and _fini functions to run through the init/fini arrays
for shared libs in configurations which HAVE_INITFINI_ARRAY_SUPPORT.
The init/fini functions are provided by libc_internal.a for static links
but with slightly different names and we don't want to risk dragging other
libc_internal contents in the closure accidentally so make sure we don't
link with it.
As for the !vxworks crtstuff, the new shared libs specific bits are
conditioned by a CRTSTUFFS_O macro, for which we provide new Makefile
fragment.
The bits to actually use the fragment and the shared objects will
be added by a forthcoming change, as part of a more general configury
update for shared libs.
The change also adds guards the eh table registration code
in vxcrtstuff so the objects can be used for either init/fini
or eh tables independently.
2021-12-07 Fred Konrad <konrad@adacore.com>
Olivier Hainque <hainque@adacore.com>
gcc/
* config/vxworks.h (VXWORKS_BASE_LIBS_RTP): Guard -lc_internal
on !shared+!non-static and document.
(VXWORKS_LIB_SPEC): Remove the bits intended to drag the
init/fini functions from libc_internal in the shared lib case.
(VX_CRTBEGIN_SPEC/VX_CRTEND_SPEC): Use vxcrtstuff objects also in
configurations with shared lib and INITFINI_ARRAY support.
libgcc/
* config/t-vxcrtstuffS: New Makefile fragment.
* config/vxcrtstuff.c: Provide __dso_handle. Provide _init/_fini
functions for INITFINI_ARRAY support in shared libs and guard
the definition of eh table registration functions on conditions
indicating they are needed.
This strengthens the VxWorks configuration files for the support
of shared objects, which encompasses a VxWorks specific "non-static"
mode for RTPs (in addition to -static and -shared).
2020-11-06 Fred Konrad <konrad@adacore.com>
Olivier Hainque <hainque@adacore.com>
gcc/
* config/vx-common.h: Define REAL_LIBGCC_SPEC since the
'-non-static' option is not standard.
* config/vxworks.h (VXWORKS_LIBGCC_SPEC): Implement the LIBGCC_SPEC
since REAL_LIBGCC_SPEC is used now.
(STARTFILE_PREFIX_SPEC): Use the PIC VSB when building shared libraries
or non-static binaries.
The unconditional assignment performed in t-vxworks to handle
include flags currently overrides what specific cpu ports had
for the regular (!vxworks) crtstuff objects.
This was not done on purpose and the proposed change adjusts the
configuration bits to apply the vxworks specific flags on top of
the cpu ones instead.
2021-12-07 Olivier Hainque <hainque@adacore.com>
* config.host (powerpc*-wrs-vxworks7*): Place t-crtstuff
ahead of the other files in tmake_files.
* config/t-vxworks: Add to CRTSTUFF_T_CFLAGS instead of
overriding it.
This final patch in the series is much simpler and adds command-line support for -march=armv8.8-a,
making use of the +mops features added in the previous patches.
Bootstrapped and tested on aarch64-none-linux-gnu.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (armv8.8-a): Define.
* config/aarch64/aarch64.h (AARCH64_FL_V8_8): Define.
(AARCH64_FL_FOR_ARCH8_8): Define.
* doc/invoke.texi: Document -march=armv8.8-a.
This 3rd patch in the series adds an inline sequence for the memset operation.
The aarch64-mops-memset-size-threshold param is added to control the size threshold for the sequence.
Its default setting is 256, which may seem a bit high, but it is consistent with the current
SIMD memset inline sequence limit, and future CPU tunings can override it easily as needed.
Bootstrapped and tested on aarch64-none-linux-gnu.
gcc/ChangeLog:
* config/aarch64/aarch64.c (aarch64_expand_setmem_mops): Define.
(aarch64_expand_setmem): Adjust for TARGET_MOPS.
* config/aarch64/aarch64.h (CLEAR_RATIO): Adjust for TARGET_MOPS.
(SET_RATIO): Likewise.
* config/aarch64/aarch64.md ("unspec"): Add UNSPEC_SETMEM.
(aarch64_setmemdi): Define.
(setmemdi): Adjust for TARGET_MOPS.
* config/aarch64/aarch64.opt (aarch64-mops-memset-size-threshold):
New param.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mops_3.c: New test.
This second patch in the series adds an inline movmem expansion for TARGET_MOPS
that emits the recommended sequence.
A new param aarch64-mops-memmove-size-threshold is added to control the memmove size threshold
for this expansion. Its default value is zero to be consistent with the current behaviour where
we always emit a libcall, as we don't currently have a movmem inline expansion
(we should add a compatible-everywhere inline expansion, but that's for the future), so we should
always prefer to emit the MOPS sequence when available in lieu of a libcall.
Bootstrapped and tested on aarch64-none-linux-gnu.
gcc/ChangeLog:
* config/aarch64/aarch64.md (aarch64_movmemdi): Define.
(movmemdi): Define.
(unspec): Add UNSPEC_MOVMEM.
* config/aarch64/aarch64.opt (aarch64-mops-memmove-size-threshold):
New param.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mops_2.c: New test.
This patch adds the +mops architecture extension flag from the 2021 Arm Architecture extensions, Armv8.8-a.
The +mops extensions introduce instructions to accelerate the memcpy, memset, memmove standard functions.
The first patch here uses the instructions in the inline memcpy expansion.
Further patches in the series will use similar instructions to inline memmove and memset.
A new param, aarch64-mops-memcpy-size-threshold, is introduced to control the size threshold above which to
emit the new sequence. Its default setting is 256 bytes, which is the same as the current threshold above
which we'd emit a libcall.
Bootstrapped and tested on aarch64-none-linux-gnu.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (mops): Define.
* config/aarch64/aarch64.c (aarch64_expand_cpymem_mops): Define.
(aarch64_expand_cpymem): Define.
* config/aarch64/aarch64.h (AARCH64_FL_MOPS): Define.
(AARCH64_ISA_MOPS): Define.
(TARGET_MOPS): Define.
(MOVE_RATIO): Adjust for TARGET_MOPS.
* config/aarch64/aarch64.md ("unspec"): Add UNSPEC_CPYMEM.
(aarch64_cpymemdi): New pattern.
(cpymemdi): Adjust for TARGET_MOPS.
* config/aarch64/aarch64.opt (aarch64-mops-memcpy-size-threshol):
New param.
* doc/invoke.texi (AArch64 Options): Document +mops.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/mops_1.c: New test.
For -mrtp on VxWorks 6.9, at least inttypes.h ends up #including
system headers checking that _BITS_BYTES is 8, which the system yvals.h
defines. We do pre-include _yvals.h ahead of inttypes.h for this kind of
purpose, but it currently assumes that only VxWorks >= 7 provides yvals.h.
This results in unexpected configure checks failures, complaining about
_BITS_BYTES not being 8, spotted while inspecting libstdc++ config.log for
unrelated reasons.
This change relaxes the guard in _yvals.h to include yvals.h for
__RTP__ in addition to version >= 7.
2021-12-13 Olivier Hainque <hainque@adacore.com>
* config/vxworks/_yvals.h: #include yvals.h also if
defined(__RTP__).
C++ relies on C99 features since C++11 and libstdc++ down to c++98
checks for C99 features at configure time. Simpler is to request C99
features from system headers unconditionally.
2021-12-11 Olivier Hainque <hainque@adacore.com>
* config/vxworks.h (VXWORKS_OS_CPP_BUILTINS): Define
_C99 for C++.
The build of a VxWorks toolchain relies a lot on system headers
and VxWorks has a few very specific features that require special
processing. For example, different sets of headers for the kernel
vs the rtp modes, which the compiler knows about by way of -mrtp
on the command line.
If we manage to avoid the need for fixincludes on recent versions
of VxWorks (>= 7), we still need to handle at least VxWorks 6.9 at
this stage.
We sort of get away with locating the correct headers at
run-time thanks to environment variables and various tests for
-mrtp in cpp specs, but getting fixincludes to work for old
configurations has always been tricky and getting a toolchain
to build with c++/libstdc++ support gets trickier with every
move to a more recent release.
sysroot_headers_suffix_spec is a pretty powerful device to help
address such issues, and this patch introduces changes that let
us get advantage of it.
The general idea is to leverage the assumption that compilations
occur with --sysroot=$VSB_DIR on vx7 or --sysroot=$WIND_BASE/target
prior to that.
For the toolchains we build, this is achieved with a few
configure options like:
--with-sysroot
--with-build-sysroot=${WIND_BASE}/target
--with-specs=%{!sysroot=*:--sysroot=%:getenv(WIND_BASE /target)}
This also allows simplifying the libgcc compilation flags control
and we take the opportunity to merge t-vxworks7 into t-vxworks as
the two files were differing only on the libgcc2 flags part.
2021-12-09 Olivier Hainque <hainque@adacore.com>
gcc/
* config/t-vxworks: Clear NATIVE_SYSTEM_HEADER_DIR.
* config/vxworks.h (SYSROOT_HEADERS_SUFFIX_SPEC): Define, for
VxWorks 7 and earlier.
(VXWORKS_ADDITIONAL_CPP_SPEC): Simplify accordingly.
(STARTFILE_PREFIX_SPEC): Adjust accordingly.
* config/rs6000/vxworks.h (STARTFILE_PREFIX_SPEC): Adjust.
libgcc/
* config/t-vxworks (LIBGCC2_INCLUDES): Simplify and handle
both VxWorks7 and earlier.
* config/t-vxworks7: Remove.
* config.host: Remove special case for vxworks7.
The scripts/make_exports.pl script used for darwin only replaces '*'
wildcards in globs, it doesn't handle '?'. This means the recent changes
to std::__timepunct exports broke darwin.
Rather than use mangled names in the linker script, this adds support
for '?' to the perl script.
This also removes some unnecessary escaping of the replacement strings
in s// substitutions.
libstdc++-v3/ChangeLog:
* scripts/make_exports.pl: Replace '?' with '.' when turning
a glob into a regex.
Passing IncompleteType(&)[] to ranges::begin produces an error outside
the immediate context, which is fine for ranges::begin, but it means
that we fail to enforce the SFINAE-able constraints for ranges::size and
ranges::size. They should not be callable for any array of unknown
bound, whether the type is complete or not. Because we don't enforce
that in their constraints, we get a hard error when they try to use
ranges::begin.
This simply adds explicit checks for arrays of unknown bound to the
constraints for ranges::size and ranges::empty. We only need to check it
for the __sentinel_size and __eq_iter_empty concepts, because those are
the ones that are relevant to arrays, and which try to use
ranges::begin.
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (ranges::size, ranges::empty): Add
explicit check for unbounded arrays before using ranges::begin.
* testsuite/std/ranges/access/empty.cc: Check handling of unbounded
arrays.
* testsuite/std/ranges/access/size.cc: Likewise.
The overload of std::regex_replace that takes a std::basic_string as the
fmt argument (for the replacement string) is implemented in terms of the
one taking a const C*, which uses std::char_traits to find the length.
That means it stops at a null character, even though the basic_string
might have additional characters beyond that.
Rather than duplicate the implementation of the const C* one for the
std::basic_string case, this moves that implementation to a new
__regex_replace function which takes a const C* and a length. Then both
the std::basic_string and const C* overloads can call that (with the
latter using char_traits to find the length to pass to the new
function).
libstdc++-v3/ChangeLog:
PR libstdc++/103664
* include/bits/regex.h (__regex_replace): Declare.
(regex_replace): Use it.
* include/bits/regex.tcc (__regex_replace): Replace regex_replace
definition with __regex_replace.
* testsuite/28_regex/algorithms/regex_replace/char/103664.cc: New test.
> Fixed thusly, compile tested on x86_64-linux, committed to trunk.
Here is a small cleanup. IMHO we should use gt_pointer_operator instead of
specifying manually void (*) (void *, void *) or
void (*) (void *, void *, void *) so that next time we want to change it,
we don't have to trace all the spots. I was afraid it wouldn't work due to
header dependencies, but it works well. gengtype generated files also
use gt_pointer_operator.
2021-12-13 Jakub Jelinek <jakub@redhat.com>
* machmode.h (gt_pch_nx): Use gt_pointer_operator as type of second
argument instead of equivalent void (*) (void *, void *, void *).
* poly-int.h (gt_pch_nx): Likewise.
* wide-int.h (gt_pch_nx): Likewise.
* config/aarch64/aarch64-sve-builtins.cc (gt_pch_nx): Likewise.
gcc/ChangeLog:
2021-12-12 Jan Hubicka <hubicka@ucw.cz>
PR ipa/103513
* ipa-fnsummary.c (evaluate_conditions_for_known_args): Do not ICE
on ternary expression.
gcc/testsuite/ChangeLog:
2021-12-12 Jan Hubicka <hubicka@ucw.cz>
PR ipa/103513
* gcc.c-torture/compile/pr103513.c: New test.
For a function with optimize pragma, it's possible that the target
options change as optimization options change. Now we create one
optimization option node when optimize pragma parsing, but don't
create target option node for possible target option changes. It
makes later processing not detect the target options can actually
change and further doesn't update the target options accordingly.
This patch is to check whether target options have changed when
creating one optimization option node for pragma optimize, and
make one target option node if needed. The associated test case
shows the difference. Without this patch, the function foo1 will
perform unrolling which is unexpected. The reason is that flag
unroll_only_small_loops isn't correctly set for it. The value
is updated after parsing function foo2, but doesn't get restored
later since both decls don't have DECL_FUNCTION_SPECIFIC_TARGET
set and the hook thinks we don't need to switch. With this patch,
there is no unrolling for foo1, which is also consistent with the
behavior by replacing pragma by attribute whether w/ and w/o this
patch.
As Martin noted, this change does the similar thing like what his
previous commit r12-1039 did.
gcc/ChangeLog:
PR target/103515
* attribs.c (decl_attributes): Check if target options change and
create one node if so.
gcc/testsuite/ChangeLog:
PR target/103515
* gcc.target/powerpc/pr103515.c: New test.
Now that GCC is compiled as C++11 there is no need to keep the C++03
implementation of gnu::unique_ptr.
This removes the unique-ptr.h header and replaces it with <memory> in
system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
Uses of gnu::unique_ptr and gnu::move can be replaced with
std::unique_ptr and std::move. There are no uses of unique_xmalloc_ptr
or xmalloc_deleter in GCC.
gcc/analyzer/ChangeLog:
* engine.cc: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
gcc/c-family/ChangeLog:
* known-headers.cc: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* name-hint.h: Likewise.
(class name_hint): Use std::unique_ptr instead of gnu::unique_ptr.
gcc/c/ChangeLog:
* c-decl.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
* c-parser.c: Likewise.
gcc/cp/ChangeLog:
* error.c: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* lex.c: Likewise.
* name-lookup.c: Likewise.
(class namespace_limit_reached): Use std::unique_ptr instead of
gnu::unique_ptr.
(suggest_alternatives_for): Use std::move instead of gnu::move.
(suggest_alternatives_in_other_namespaces): Likewise.
* parser.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
gcc/ChangeLog:
* Makefile.in: Remove unique-ptr-tests.o.
* selftest-run-tests.c (selftest::run_tests): Remove
unique_ptr_tests_cc_tests.
* selftest.h (unique_ptr_tests_cc_tests): Remove.
* system.h: Check INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR
and include <memory> instead of "unique-ptr.h".
* unique-ptr-tests.cc: Removed.
include/ChangeLog:
* unique-ptr.h: Removed.
2021-12-12 Antoni Boucher <bouanto@zoho.com>
gcc/jit/
PR target/100688
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_18): New ABI
tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_lvalue_set_link_section.
* jit-playback.h: New function (set_link_section).
* jit-recording.c: New function (set_link_section) and
support for setting the link section.
* jit-recording.h: New function (set_link_section) and new
field m_link_section.
* libgccjit.c: New function (gcc_jit_lvalue_set_link_section).
* libgccjit.h: New function (gcc_jit_lvalue_set_link_section).
* libgccjit.map (LIBGCCJIT_ABI_18): New ABI tag.
gcc/testsuite/
PR target/100688
* jit.dg/all-non-failing-tests.h: Mention new test
link-section-assembler.
* jit.dg/test-link-section-assembler.c: New test.
* jit.dg/jit.exp: New helper function to test that the
assembly contains a pattern.
The recent flurry of activity around HFmode on gcc-patches intrigued me
to investigate adding HFmode support to the nvptx backend. NVidia GPUs
with an SM ISA above 5.3 support IEEE 16-bit floating point instructions.
Hence, this patch adds support for -misa=sm_53, and implements some
backend patterns/insns sufficient for a proof-of-concept prototype.
The following has been tested on nvptx-none, hosted on x86_64-pc-linux-gnu
with a "make" and "make -k check" with no new failures.
gcc/ChangeLog:
* config/nvptx/nvptx-opts.h (ptx_isa): Add PTX_ISA_SM53 ISA level
to enumeration.
* config/nvptx/nvptx.opt: Add sm_53 to -misa.
* config/nvptx/nvptx-modes.def: Add support for HFmode.
* config/nvptx/nvptx.h (TARGET_SM53):
New helper macro to conditionalize functionality on target ISA.
* config/nvptx/nvptx-c.c (nvptx_cpu_cpp_builtins): Add __PTX_SM__
support for the new ISA levels.
* config/nvptx/nvptx.c (nvtx_ptx_type_from_mode): Support new HFmode
with the ".f16" suffix/qualifier.
(nvptx_file_start): Add support for TARGET_SM53.
(nvptx_omp_device_kind_arch_isa): Add support for TARGET_SM53
and tweak TARGET_SM35.
(nvptx_scalar_mode_supported_p): Target hook with conditional
HFmode support on TARGET_SM53 and higher.
(nvptx_libgcc_floating_mode_supported_p): Likewise.
(TARGET_SCALAR_MODE_SUPPORTED_P): Use nvptx_scalar_mode_supported_p.
(TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Likewise, use new hook.
* config/nvptx/nvptx.md (*movhf_insn): New define_insn.
(movhf): New define_expand for HFmode moves.
(addhf3, subhf3, mulhf, extendhf<mode>2, trunc<mode>hf2): New
instructions conditional on TARGET_SM53 (i.e. -misa=sm_53).
gcc/testsuite/ChangeLog:
* gcc.target/nvptx/float16-1.c: New test case.
As discussed in the PR, we miss some optimization becuase
gimple-ssa-isolate-paths turns NULL memory accesses to volatile and adds
__builtin_trap after them. This is seen as a side-effect by IPA analysis
and additionally the (fully unreachable) builtin_trap is believed to load
all global memory.
I think we should think of less intrusive gimple representation of this, but
it is also easy enough to special case that in IPA analysers as done in
this patch. This is a win even if we improve the representation since
gimple-ssa-isolate-paths is run late and this way we improve optimization
early.
This affects 1623 functions during cc1plus link.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2021-12-12 Jan Hubicka <hubicka@ucw.cz>
PR ipa/103665
* ipa-modref.c (modref_access_analysis::analyze): Terminate BB
analysis on NULL memory access.
* ipa-pure-const.c (analyze_function): Likewise.
2021-12-11 Antoni Boucher <bouanto@zoho.com>
gcc/jit/
PR target/95415
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_17): New ABI
tag.
* docs/topics/expressions.rst: Add document for the function
gcc_jit_lvalue_set_tls_model.
* jit-playback.h: New function (set_tls_model).
* jit-recording.c: New function (set_tls_model), new
variables (tls_models and tls_model_enum_strings) and support
for setting the tls model.
* jit-recording.h: New function (set_tls_model) and new
field m_tls_model.
* libgccjit.c: New function (gcc_jit_lvalue_set_tls_model).
* libgccjit.h: New function (gcc_jit_lvalue_set_tls_model)
and new enum (gcc_jit_tls_model).
* libgccjit.map (LIBGCCJIT_ABI_17): New ABI tag.
gcc/testsuite/
PR target/95415
* jit.dg/all-non-failing-tests.h: Add test-tls.c.
* jit.dg/test-tls.c: New test.
gcc/fortran/ChangeLog:
PR fortran/103606
* resolve.c (resolve_fl_procedure): Do not access CLASS components
before class container has been built.
gcc/testsuite/ChangeLog:
PR fortran/103606
* gfortran.dg/pr103606.f90: New test.
This patch removes apparently forgotten debugging hack (which got in during
the speculative call patchset) which reduces hot bb threshold. This does not
make sense since it is set and reset randomly as the summaries are processed.
One problem is that we set the BB threshold to make certain BBs hot and hten
unrolling or vectorization may reduce it to some fraction of the count that
makes it cold. We may want to add some buffer and divide the value by,
say 32, but that shoulid be done independently of speculative calls.
gcc/ChangeLog:
2021-12-11 Jan Hubicka <hubicka@ucw.cz>
* ipa-profile.c (ipa_profile): Do not update hot bb threshold.
Thunks are not transparent for ipa-modref summary since it cares about offsets
from pointer parameters and also for virtual thunk about the read from memory
in there. We however use function_or_virtual_thunk_symbol to get the summary
that may lead to wrong code (and does in two testsuite testcases with patch
I am working on). This is a first aid fix that is bacportable to gcc 11.
We could easily produce summary for thunk on demand. I will look into it
incrementally. It is not very important since we usually inline the thunk when
we devirutalize...
Bootstrapped/regtested x86_64-linux, will commit it shortly.
gcc/ChangeLog:
2021-12-11 Jan Hubicka <hubicka@ucw.cz>
* ipa-modref.c (get_modref_function_summary): Use ultimate_alias_target.
(ignore_edge): Likewise.
(compute_parm_map): Likewise.
(modref_propagate_in_scc): Likewise.
(modref_propagate_flags_in_scc): Likewise.
When the translation unit itself creates pointers to the ctors/dtors
in a specific section handled by the linker (whether .init_array or
.ctors.*), there's no reason for the functions to have external
linkage. That ends up polluting the symbol table in the running
kernel.
This makes vxcrtstuff.c on par with the generic crtstuff.c which also
defines e.g. frame_dummy and __do_global_dtors_aux static.
libgcc/
* config/vxcrtstuff.c: Make constructor and destructor
functions static when possible.
These declarations prevent the priority given in the
constructor/destructor attributes from taking effect, thus emitting
the function pointers in the ordinary (lowest-priority)
.init_array/.fini_array sections.
libgcc/
* config/vxcrtstuff.c: Remove constructor/destructor
declarations.
In the testcase for 103534 we get a warning about append leading to memcpy
of a very large number of bytes overflowing the buffer. This turns out to
be because we weren't calling _M_check_length for string append. Rather
than do that directly, let's go through the public pointer append that calls
it.
PR c++/103534
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (append (basic_string)): Call pointer
append instead of _M_append directly.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wstringop-overflow-8.C: New test.
We include libgcc_tm.h to provide a prototype for this shim
so add that to the make dependencies.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
libgcc/ChangeLog:
* config/t-darwin: Add libgcc_tm.h to the dependencies
for darwin10-unwind-find-enc-func.
libgccjit was failing to set the DECL_CONTEXT of function RESULT_DECLs,
leading to them failing to be properly handled by the inlining machinery.
Fixed thusly.
gcc/jit/ChangeLog:
PR jit/103562
* jit-playback.c (gcc::jit::playback::context::new_function): Set
DECL_CONTEXT of the result_decl.
gcc/testsuite/ChangeLog:
PR jit/103562
* jit.dg/all-non-failing-tests.h: Add comment about...
* jit.dg/test-pr103562.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
I was curious if our auto(x) works in contexts like bit-field width
and similar. It appears that it does. Might be worth adding a test
for it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/auto-fncast10.C: New test.
gcc/fortran/ChangeLog:
PR fortran/103418
* check.c (variable_check): Replace previous check of procedure
dummy arguments with INTENT(IN) attribute when passed to intrinsic
procedures by gfc_check_vardef_context.
* expr.c (gfc_check_vardef_context): Correct check of INTENT(IN)
dummy arguments for the case of sub-components of a CLASS pointer.
gcc/testsuite/ChangeLog:
PR fortran/103418
* gfortran.dg/move_alloc_8.f90: Adjust error messages.
* gfortran.dg/pointer_intent_9.f90: New test.
This incremental patch adds std::time_get %r support (%p was added already
in the previous patch). The _M_am_fm_format method previously in the header
unfortunately had wrong arguments and so was useless, so the largest
complication in this patch is exporting a new symbol in the right symbol
version.
2021-12-10 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/71367
* config/locale/dragonfly/time_members.cc (_M_initialize_timepunct):
Initialize "C" _M_am_pm_format to %I:%M:%S %p rather than empty
string.
* config/locale/gnu/time_members.cc (_M_initialize_timepunct):
Likewise.
* config/locale/generic/time_members.cc (_M_initialize_timepunct):
Likewise.
* include/bits/locale_facets_nonio.h (_M_am_pm_format): New method.
* include/bits/locale_facets_nonio.tcc (_M_extract_via_format): Handle
%r.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Export _M_am_pm_format
with const _CharT** argument, ensure it isn't exported in GLIBCXX_3.4.
* testsuite/22_locale/time_get/get/char/71367.cc: New test.
* testsuite/22_locale/time_get/get/wchar_t/71367.cc: New test.
The following patch is an attempt to fix various time_get related issues.
Sorry, it is long...
One of them is PR78714. It seems _M_extract_via_format has been written
with how strftime behaves in mind rather than how strptime behaves.
There is a significant difference between the two, for strftime %a and %A
behave differently etc., one emits an abbreviated name, the other full name.
For strptime both should behave the same and accept both the full or
abbreviated names. This needed large changes in _M_extract_name, which
was assuming the names are unique and names aren't prefixes of other names.
The _M_extract_name changes allow to deal with those cases. As can be
seen in the new testcase, e.g. for %b and english locales we need to
accept both Apr and April. If we see Apr in the input, the code looks
at whether there is end right after those 3 chars or if the next
character doesn't match characters in the longer names; in that case
it accepts the abbreviated name. Otherwise, if the input has Apri, it
commits to a longer name and fails if it isn't April. This behavior is
different from strptime, which for %bix and Aprix accepts it, but for
an input iterator I'm afraid we can't do better, we can't go back (peek
more than the current character).
Another case is that %d and %e in strptime should work the same, while
previously the code was hardcoding that %d would be 01 to 31 and %e
1 to 31 (with leading 0 replaced by space).
strptime POSIX 2009 documentation seems to suggest for numbers it should
accept up to the specified number of digits rather than exactly that number
of digits:
The pattern "[x,y]" indicates that the value shall fall within the range
given (both bounds being inclusive), and the maximum number of characters scanned
shall be the maximum required to represent any value in the range without leading
zeros.
so by my reading "1:" is valid for "%H:".
The glibc strptime implementation actually skips any amount of whitespace
in all the cases where a number is read, my current patch skips a single
space at the start of %d/%e but not the others, but doesn't subtract the
space length from the len characters.
One option would be to do the leading whitespace skipping in _M_extract_num
but take it into account how many digits can be read.
This matters for " 12:" and "%H:", but not for " 12:" and " %H:"
as in the latter case the space in the format string results in all the
whitespace at the start to be consumed.
Note, the allowing of a single digit rather than 2 changes a behavior in
other ways, e.g. when seeing 40 in a number for range [1, 31] we reject
it as before, but previously we'd keep *ret == '4' because it was assuming
it has to be 2 digits and 40 isn't valid, so we know error already on the
4, but now we accept the 4 as value and fail iff the next format string
doesn't match the 0.
Also, previously it wasn't really checking the number was in the right
range, it would accept 00 for [1, 31] numbers, or would accept 39.
Another thing is that %I was parsing 12 as tm_hour 12 rather than as tm_hour 0
like e.g. glibc does.
Another thing is that %t was matching a single tab and %n a single newline,
while strptime docs say it skips over whitespace (again, zero or more).
Another thing is that %p wasn't handled at all, I think this was the main
cause of
FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
before this patch, because en_HK* locales do use %I and %p in it.
The patch handles %p only if it follows %I (i.e. when the hour is parsed
first), which is the more usual case (in glibc):
grep '%I' localedata/locales/* | grep '%I.*%p' | wc -l
282
grep '%I' localedata/locales/* | grep -v '%I.*%p' | wc -l
44
grep '%I' localedata/locales/* | grep -v '%p' | wc -l
17
The last case use %P instead of %p in t_fmt_ampm, not sure if that one
is never used by strptime because %P isn't handled by strptime.
Anyway, the right thing to handle even %p%I would be to pass some state
around through all the _M_extract_via_format calls like glibc passes
struct __strptime_state
{
unsigned int have_I : 1;
unsigned int have_wday : 1;
unsigned int have_yday : 1;
unsigned int have_mon : 1;
unsigned int have_mday : 1;
unsigned int have_uweek : 1;
unsigned int have_wweek : 1;
unsigned int is_pm : 1;
unsigned int want_century : 1;
unsigned int want_era : 1;
unsigned int want_xday : 1;
enum ptime_locale_status decided : 2;
signed char week_no;
signed char century;
int era_cnt;
} s;
around. That is for the %p case used like:
if (s.have_I && s.is_pm)
tm->tm_hour += 12;
during finalization, but handles tons of other cases which it is unclear
if libstdc++ needs or doesn't need to handle, e.g. strptime if one
specifies year and yday computes wday/mon/day from it, etc. basically for
the redundant fields computes them from other fields if those have been
parsed and are sufficient to determine it.
To do this we'd need to change ABI for the _M_extract_via_format,
though sure, we could add a wrapper around the new one with the old
arguments that would just use a dummy state. And we'd need a new
_M_whatever finalizer that would do those post parsing tweaks.
Also, %% wasn't handled.
For a whitespace in the strings there was inconsistent behavior,
_M_extract_via_format would require exactly that whitespace char (say
matching space, or matching tab), while the caller follows what
https://eel.is/c++draft/locale.time.get#members-8.5 says, that
when encountering whitespace it skips whitespace in the format and
then whitespace in the input if any. I've changed _M_extract_via_format
to skip whitespace in the input (looping over format isn't IMHO necessary,
because next iteration of the loop will handle that too).
Tested on x86_64-linux by make check-target-libstdc++-v3, ok for trunk
if it passes full bootstrap/regtest?
For the new 3.cc testcases, I have included hopefully correctly
corresponding C testcase using strptime in an attachment, and to the
extent where it can be compared (e.g. strptime on failure just
returns NULL, doesn't tell where it exactly stopped) I think the
only difference is that
str = "Novembur";
format = "%bembur";
ret = strptime (str, format, &time);
case where strptime accepts it but there is no way to do it with input
operator.
I admit I don't have libc++ or other STL libraries around to be able to
check how much the new 3.cc matches or disagrees with other implementations.
Now, the things not handled by this patch but which should be fixed (I
probably need to go back to compiler work) or at least looked at:
1) seems %j, %r, %U, %w and %W aren't handled (not sure if all of them
are already in POSIX 2009 or some are later)
2) I haven't touched the %y/%Y/%C and year handling stuff, that is
definitely not matching what POSIX 2009 says:
C All but the last two digits of the year {2}; leading zeros shall be permitted but shall not be required. A leading '+' or '−' character shall be permitted before
any leading zeros but shall not be required.
y The last two digits of the year. When format contains neither a C conversion specifier nor a Y conversion specifier, values in the range [69,99] shall refer to
years 1969 to 1999 inclusive and values in the range [00,68] shall refer to years 2000 to 2068 inclusive; leading zeros shall be permitted but shall not be re‐
quired. A leading '+' or '−' character shall be permitted before any leading zeros but shall not be required.
Note: It is expected that in a future version of this standard the default century inferred from a 2-digit year will change. (This would apply to all commands
accepting a 2-digit year as input.)
Y The full year {4}; leading zeros shall be permitted but shall not be required. A leading '+' or '−' character shall be permitted before any leading zeros but
shall not be required.
I've tried to avoid making changes to _M_extract_num for these as well
to keep current status quo (the __len == 4 cases). One thing is what
to do for things with %C %y and/or %Y in the formats, another thing
is what to do in the methods that directly perform _M_extract_num
for year
3) the above question what to do for leading whitespace of any numbers
being parsed
4) the %p%I issue mentioned above and generally what to do if we
pass state and have finalizers at the end of parsing
5) _M_extract_via_format is also inconsistent with its callers on handling
the non-whitespace characters in between format specifiers, the caller
follows https://eel.is/c++draft/locale.time.get#members-8.6 and does
case insensitive comparison:
// TODO real case-insensitive comparison
else if (__ctype.tolower(*__s) == __ctype.tolower(*__fmt) ||
__ctype.toupper(*__s) == __ctype.toupper(*__fmt))
while _M_extract_via_format only compares exact characters:
// Verify format and input match, extract and discard.
if (__format[__i] == *__beg)
++__beg;
(another question is if there is a better way how to do real
case-insensitive comparison of 2 characters and whether we e.g. need
to handle the Turkish i/İ and ı/I which have different number of bytes
in UTF-8)
6) _M_extract_name does something weird for case-sensitivity,
// NB: Some of the locale data is in the form of all lowercase
// names, and some is in the form of initially-capitalized
// names. Look for both.
if (__beg != __end)
and
if (__c == __names[__i1][0]
|| __c == __ctype.toupper(__names[__i1][0]))
for the first letter while just
__name[__pos] == *__beg
on all the following letters. strptime says:
In case a text string (such as the name of a day of the week or a month
name) is to be matched, the comparison is case insensitive.
so supposedly all the _M_extract_name comparisons should be case
insensitive.
2021-12-10 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/78714
* include/bits/locale_facets_nonio.tcc (_M_extract_via_format):
Mention in function comment it interprets strptime format string
rather than strftime. Handle %a and %A the same by accepting both
full and abbreviated names. Similarly handle %h, %b and %B the same.
Handle %d and %e the same by accepting possibly optional single space
and 1 or 2 digits. For %I store tm_hour 0 instead of tm_hour 12. For
%t and %n skip any whitespace. Handle %p and %%. For whitespace in
the string skip any whitespace.
(_M_extract_num): For __len == 2 accept 1 or 2 digits rather than
always 2. Don't punt early if __value * __mult is larget than __max
or smaller than __min - __mult, instead punt if __value > __max.
At the end verify __value is in between __min and __max and punt
otherwise.
(_M_extract_name): Allow non-unique names or names which are prefixes
of other names. Don't recompute lengths of names for every character.
* testsuite/22_locale/time_get/get/char/3.cc: New test.
* testsuite/22_locale/time_get/get/wchar_t/3.cc: New test.
* testsuite/22_locale/time_get/get_date/char/12791.cc (test01): Use
62 instead 60 and expect 6 to be accepted and thus *ret01 == '2'.
* testsuite/22_locale/time_get/get_date/wchar_t/12791.cc (test01):
Similarly.
* testsuite/22_locale/time_get/get_time/char/2.cc (test02): Add " PM"
to the string.
* testsuite/22_locale/time_get/get_time/char/5.cc (test01): Expect
tm_hour 1 rather than 0.
* testsuite/22_locale/time_get/get_time/wchar_t/2.cc (test02): Add
" PM" to the string.
* testsuite/22_locale/time_get/get_time/wchar_t/5.cc (test01): Expect
tm_hour 1 rather than 0.
-v needs to generate a -V not -v, as most/all other ports do.
The latter causes collect2 to output exec'd collect-ld with same
switches, which in turn causes a configure test which accumulates
linker switches to contain duplicates, leading to a libstdc++ configure
failure in some configurations.
-V is typically used in such contexts to output the available
emulations.
The change also removes reference to %(link_target), long obsolete.
2021-12-07 Doug Rupp <rupp@adacore.com>
* config/vxworks.h (LINK_SPEC): Remove %(link_target).
Change %{v:-v} to %{v:-V}.
Just redundant with the default Makefile setting.
2021-12-07 Olivier Hainque <hainque@adacore.com>
* config/t-vxworks: Remove assignment to STMP_FIXINC.
A mutex and condition variable is used for timed waits on atomics if
there is no "platform wait" (e.g. futex) supported. But the use of those
types wasn't guarded by the _GLIBCXX_HAS_GTHREADS macro, causing errors
for --disable-threads builds. This fix allows <atomic> to work on
targets with futexes but no gthreads.
libstdc++-v3/ChangeLog:
PR libstdc++/103638
* include/bits/atomic_timed_wait.h: Check _GLIBCXX_HAS_GTHREADS
before using std::mutex and std::__condvar.
Vladimir N. Makarov
Roger Sayle
Douglas B Rupp
Olivier Hainque
Frederic Konrad
Jan Hubicka
Kyrylo Tkachov
Martin Liska
Jonathan Wakely
Tobias Burnus
Jakub Jelinek
Kewen Lin
GCC Administrator
Antoni Boucher
Harald Anlauf
Rasmus Villemoes
Jason Merrill
Iain Sandoe
David Malcolm
Marek Polacek