This is the same fix as was done for std::numeric_limits in r183905.
PR libstdc++/52119
* include/ext/numeric_traits.h (__glibcxx_min): Avoid integer
overflow warning with -Wpedantic -Wsystem-headers.
From-SVN: r270858
Armv6 has support for unaligned accesses to memory. However, the
thumb1 code patterns were trying to use the 32-bit code constraints.
One failure mode from this was that the patterns are designed to be
compatible with conditional execution and this was then causing an
assert in the compiler.
The unaligned_loadhis pattern is only used for expanding extv, which
in turn is only enabled for systems supporting thumb2. Given that
there is no simple expansion for a thumb1 sign-extending load (the
instruction has no immediate offset form and requires two registers in
the address) it seems simpler to just disable this for thumb1.
Fixed thusly:
PR target/89400
* config/arm/arm.md (unaligned_loadsi): Add variant for thumb1.
Restrict 'all' variant to 32-bit configurations.
(unaligned_loadhiu): Likewise.
(unaligned_storehi): Likewise.
(unaligned_storesi): Likewise.
(unaligned_loadhis): Disable when compiling for thumb1.
From-SVN: r270853
2019-05-03 Richard Biener <rguenther@suse.de>
PR tree-optimization/90316
* tree-ssa-pre.c (pass_pre::execute): Re-compute DOM fast queries
before running VN.
From-SVN: r270848
2019-05-03 Richard Biener <rguenther@suse.de>
* tree-vect-stmts.c (get_group_load_store_type): Avoid
peeling for gaps by loading only lower halves of vectors
if possible.
(vectorizable_load): Likewise.
* gcc.dg/vect/slp-reduc-sad-2.c: New testcase.
From-SVN: r270847
2019-05-03 Richard Biener <rguenther@suse.de>
PR middle-end/89518
* match.pd: Add pattern to optimize (A / B) * B + (A % B) to A.
* gcc.dg/pr89518.c: New testcase.
From-SVN: r270846
2019-05-03 Richard Biener <rguenther@suse.de>
PR tree-optimization/89698
* gimple-fold.c (canonicalize_constructor_val): Early out
for constants, handle unfolded INTEGER_CSTs as they appear in
C++ virtual table ctors.
* g++.dg/tree-ssa/pr89698.C: New testcase.
From-SVN: r270833
In order to use the _GLIBCXX_NOEXCEPT_IF macro for an expression
containing commas I enclosed it in parentheses, so the preprocessor
wouldn't treat it as two arguments to the function-like macro. Clang
gives an error because now the noexcept-specifier noexcept((C)) is not
equivalent to the noexcept(C) one on the declaration of swap in
<type_traits>.
Instead of requiring extra parentheses around the expression, redefine
_GLIBCXX_NOEXCEPT_IF as a variadic macro (even though supporting that in
C++98 is a GNU extension).
PR libstdc++/90314
* include/bits/c++config (_GLIBCXX_NOEXCEPT_IF): Use variadic macro.
* include/bits/move.h (swap): Remove extra parentheses.
From-SVN: r270827
The std::__addressof function is always constexpr, even in C++14, so we
can just use that.
* include/experimental/bits/lfts_config.h: Improve doc markup.
* include/experimental/optional: Improve docs.
(_Has_addressof_mem, _Has_addressof_free, _Has_addressof)
(__constexpr_addressof): Remove.
(optional::operator->()): Use std::__addressof().
* include/std/optional (optional::operator->()): Adjust whitespace.
* testsuite/experimental/optional/constexpr/observers/2.cc: Check
that operator-> is still constexpr with overloaded operator&. Change
to compile-only test.
* testsuite/experimental/optional/constexpr/observers/3.cc: Change to
compile-only test.
From-SVN: r270826
Where we use "internal GCC register numbers" in debug info, that
defines an ABI, so we cannot change those numbers. But we want to
change the internal numbers, and sometimes we do that without
remembering this gotcha anyway; so let's make everything independent
of the internal numbers.
For those registers that are not recognised here (we still have MQ for
example, but also the GCC-internal frame pointer and arg pointer
registers), this just returns the internal register number. This is a
bit worrying: that number could be the same as that for a register we
validly want to have in debug info. I first had a gcc_unreachable ()
for that, but this does now work because dwarf2cfi calls
rs6000_dbx_register_number for every internal register. Then I just
returned 0 for the internal regs, but that causes various regression
tests to fail. So now I return the internal register number again,
as it was before; but this needs to be fixed.
* config/rs6000/rs6000.c (rs6000_dbx_register_number): Do not use
the internal register number, for any "real" register.
From-SVN: r270820
Since GCC 8, we have output incorrect numbers for the transactional
memory registers.
Also, we didn't output the correct DWARF register numbers for those.
The number for sprN is 100+N.
This fixes both these issues.
* config/rs6000/rs6000.c (rs6000_dbx_register_number): Return the
correct numbers for TFHAR, TFIAR, TEXASR.
From-SVN: r270819
Fix assembly errors:
.../libphobos/src/std/math.d: Assembler messages:.../libphobos/src/std/math.d:4773: Error: unrecognized opcode `frflags a0'.../libphobos/src/std/math.d:4856: Error: unrecognized opcode `fsflags a5'.../libphobos/src/std/math.d:4856: Error: unrecognized opcode `fsflags a5'.../libphobos/src/std/math.d:4773: Error: unrecognized opcode `frflags a0'.../libphobos/src/std/math.d:5549: Error: unrecognized opcode `fscsr a5'.../libphobos/src/std/math.d:5456: Error: unrecognized opcode `frcsr a5'.../libphobos/src/std/math.d:5456: Error: unrecognized opcode `frcsr a5'.../libphobos/src/std/math.d:5549: Error: unrecognized opcode `fscsr a5'.../libphobos/src/std/math.d:5456: Error: unrecognized opcode `frcsr a5'.../libphobos/src/std/math.d:5549: Error: unrecognized opcode `fscsr a0'.../libphobos/src/std/math.d:5456: Error: unrecognized opcode `frcsr a0'.../libphobos/src/std/math.d:5456: Error: unrecognized opcode `frcsr a0'.../libphobos/src/std/math.d:5549: Error: unrecognized opcode `fscsr s2'make[8]: *** [Makefile:1119: std/math.lo] Error 1
triggered with the RISC-V lp64 multilib in a GCC build configured with
`--enable-multilib --enable-languages=all --target=riscv64-linux-gnu'.
This is due to unconditional explicit use of F extension instructions
within inline assembly, to access IEEE exception flags. The use of
these instructions is not allowed when building for a soft-float ABI.
Correct the problem by wrapping said inline assembly into a conditional
such that if `D_SoftFloat' is true, then reads from IEEE exception flags
return 0 and writes are ignored instead, complementing r270522
("libphobos: Add D support for RISC-V Linux"), which is an updated
version of <https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00325.html>,
where the problematic code has originated from.
libphobos/ChangeLog:
2019-05-02 Maciej W. Rozycki <macro@wdc.com>
* std/math.d (IeeeFlags.getIeeeFlags): Handle RISC-V soft-float ABI.
(IeeeFlags.resetIeeeFlags): Likewise.
(FloatingPointControl.getControlState): Likewise.
(FloatingPointControl.setControlState): Likewise.
From-SVN: r270815
This prevents "Mathematical Special Functions" appearing in the
top-level menu of the generated HTML docs, and adds "TR1" to the title
for the TR1 docs, to avoid duplicate titles.
* include/bits/specfun.h: Improve docs.
* include/tr1/cmath: Likewise. Fix nesting of preprocessor conditions
and namespaces.
From-SVN: r270806
Several of the pb_ds headers are intended to be included multiple times,
within the definition of various class templates. The including files
define macros like PB_DS_CLASS_C_DEC and PB_DS_GEN_POS before including
these headers.
In some cases the types defined in the headers are actually nested types
within other classes, and so should not have been documented as though
they are declared in the global namespace, as in:
https://gcc.gnu.org/onlinedocs/gcc-8.3.0/libstdc++/api/a12028.html
In other cases the headers provide inline member function definitions,
but when processed by Doxygen the class name "PB_DS_CLASS_C_DEC" is not
recognised.
This patch makes Doxygen ignore definitions that only make sense when
included in the right context with the right macros defined.
* include/ext/pb_ds/detail/bin_search_tree_/*_imps.hpp: Do not define
anything unless PB_DS_CLASS_C_DEC is defined.
* include/ext/pb_ds/detail/binary_heap_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/binomial_heap_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/binomial_heap_base_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/cc_hash_table_map_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/gp_hash_table_map_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/hash_fn/*_imp.hpp: Likewise.
* include/ext/pb_ds/detail/left_child_next_sibling_heap_/*_imps.hpp:
Likewise.
* include/ext/pb_ds/detail/list_update_map_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/ov_tree_map_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/pairing_heap_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/pat_trie_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/rb_tree_map_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/rc_binomial_heap_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/resize_policy*_imp.hpp: Likewise.
* include/ext/pb_ds/detail/splay_tree_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/thin_heap_/*_imps.hpp: Likewise.
* include/ext/pb_ds/detail/trie_policy*_imp.hpp: Likewise.
* include/ext/pb_ds/detail/unordered_iterator/const_iterator.hpp:
Likewise.
* include/ext/pb_ds/detail/unordered_iterator/iterator.hpp: Likewise.
* include/ext/pb_ds/detail/unordered_iterator/point_const_iterator.hpp:
Likewise.
* include/ext/pb_ds/detail/unordered_iterator/point_iterator.hpp:
Likewise.
From-SVN: r270803
The GROUP_NESTED_COMPOUNDS option means that types nested inside inline
namespaces or other classes will be automatically added to a Doxygen
group, e.g. this actually works as intended:
/**
* @defgroup chrono Time
* @ingroup utilities
*
* Classes and functions for time.
* @{
*/
namespace chrono
{
template<typename _Rep, typename _Period = ratio<1>>
struct duration;
template<typename _Clock, typename _Dur = typename _Clock::duration>
struct time_point;
}
/// @}
Currently chrono::duration and chrono::time_point are not added to the
"chrono" group. They would need an explicit @ingroup tag added to them
individually. With GROUP_NESTED_COMPOUNDS=YES they get added to the
enclosing group.
The SORT_BY_SCOPE_NAME option means that the list of classes will sort
by class name, not the full qualified-id. Currently the alphabetical
Class List for classes beginning with 'c' looks like:
char_traits (__gnu_cxx)
character (__gnu_cxx)
condition_base (__gnu_cxx)
const_iterator_
condition_variable_any (std::_V2)
cauchy_distribution (std)
char_traits (std)
i.e. the list is sorted by the namespaces first, then the class names.
This is not helpful when you don't know which namespace a class might be
in, and inline namespaces with reserved names are not hidden (see
https://github.com/doxygen/doxygen/issues/5914 for a feature request to
allow that).
With SORT_BY_SCOPE_NAME=NO the list looks like:
cauchy_distribution (std)
char_traits (__gnu_cxx)
char_traits (std)
character (__gnu_cxx)
condition_base (__gnu_cxx)
condition_variable_any (std::_V2)
const_iterator_
This allows you to find a class by name more easily.
Also add PREDEFINED macros so that __attribute__ and various macros like
_GLIBCXX_NO_DISCARD, _GLIBCXX14_CONSTEXPR don't appear in the generated
docs.
* doc/doxygen/user.cfg.in: Regenerate with Doxygen 1.8.14 and set
GROUP_NESTED_COMPOUNDS=YES and SORT_BY_SCOPE_NAME=NO. Add various
_GLIBCXX_xxx macros and __attribute__(X) to PREDEFINED macros that
Doxygen expands.
From-SVN: r270802
The istantiate2.C test has started to fail since Darwin's impl. of
this part of the ABI was fixed. It now emits the same output as
other platforms (and clang).
2019-05-02 Iain Sandoe <iain@sandoe.co.uk>
* g++.dg/ext/instantiate2.C: Remove special-caseing for Darwin.
From-SVN: r270801
2019-05-02 Richard Biener <rguenther@suse.de>
PR tree-optimization/89653
* tree-ssa-loop.c (pass_data_tree_loop_init): Execute
update-address-taken before the pass.
* passes.def (pass_tree_loop_init): Put comment before it.
* g++.dg/vect/pr89653.cc: New testcase.
From-SVN: r270800
2019-05-02 Richard Biener <rguenther@suse.de>
PR tree-optimization/89509
* tree-ssa-structalias.c (compute_dependence_clique): Look
at the first subvar when determining whether it is restrict.
* gcc.dg/torture/restrict-8.c: New testcase.
From-SVN: r270799
