Re: [PATCH, libphobos] Add explicit casts in emutls.d to fix build on some systems
On Thu, 2 May 2019 at 20:52, Johannes Pfau wrote: > > Am 02.05.19 um 20:48 schrieb Johannes Pfau: > > This fixes builds on systems where __builtin_machine_uint != size_t. In D, > > casts from larger to smaller integer size need to be made explicitly. > > Most notably this fixes --disable-tls for MIPS64 systems. > > > > Built on x86_64 with --disable-tls and ran D test suite. Unfortunately I > can't test on MIPS64 myself, but it should fix all the errors previously > reported ;-) Looks fine to me, though I won't be able to cross test until later. A rudimentary test would be to configure --target=mipsisa64r2-linux --enable-languages=d && make all-gcc. The resultant D compiler can then be used to attempt compiling the module down to assembly. -- Iain
Re: [PATCH] libphobos: RISC-V: Fix soft-float build errors with IEEE exception flags
On Thu, 2 May 2019 at 22:35, Jim Wilson wrote:
>
> On Wed, May 1, 2019 at 6:14 PM Maciej Rozycki wrote:
> > within inline assembly, to access IEEE exception flags. The use of
> > these instructions is not allowed when building for a soft-float ABI.
>
> Technically it is an architecture issue not an ABI issue. If you
> compile for -march=rv32imac -mabi=ilp32 then you can't use FP
> instructions. If you compile for -march=rv32imafc -mabi=ilp32 then
> you can use FP instructions, but we don't use FP regs for argument
> passing. This is similar to the distinction that ARM makes between
> the soft and softfp ABIs. The RISC-V newlib port for instance checks
> __riscv_flen to decide whether to use FP instructions. The predefined
> macro __riscv_flen is set to 0 if the target architecture doesn't have
> FP registers. So the choice of using FP instructions depends on the
> target architecture, not the target ABI.
>
> I see that gcc/config/riscv/riscv-d.c has
> if (TARGET_HARD_FLOAT)
> d_add_builtin_version ("D_HardFloat");
> else
> d_add_builtin_version ("D_SoftFloat");
> so the patch looks OK, because this is checking the architecture not the ABI.
>
> But the arm/arm-d.c file is defining 3 ARM_* macros for FP support,
> and long term we might need something similar in the RISC-V D port for
> full RISC-V support. Through for RISC-V it is probably better to have
> separate macros for architecture FP support and ABI FP support, each
> of which can have 3 values, because you can have for instance an arch
> with 64-bit FP support, but an ABI with only 32-bit FP support, and so
> worst case we might need to track the arch/abi FP support separately.
> This is how it works in the C front end. We have __riscv_flen which
> can be 0, 4, or 8 and which indicates the hardware FP register size in
> bytes. And we have __riscv_float_abi_soft, __riscv_float_abi_single,
> and __riscv_float_abi_double, only one of which is defined, which
> indicates the max size of arguments that can be passed in FP
> registers.
>
A future version of the D language adds a new feature to cover this,
__traits(getTargetInfo,"key").
https://dlang.org/spec/traits.html#getTargetInfo
I have a slight inclination to push the information there instead of
adding additional RISCV_* version conditions, particularly as the
result returned can be any kind of value, which has a slight leverage
over version conditions which are just boolean true/false.
--
Iain
libstdc++/90277 Review rehash policy
Hi
This is a patch I already proposed in another thread but I review
it and moreover there is now a PR associated so I am submitting it as a
brand new one.
So working on PR 68303 I noticed that one of the performance issue
of current implementation is that initial sizing of buckets is small. In
tr1 implementation we were starting at 11 but now we go through 2, 3, 5,
7 and eventually 11, a lot of intermediate reallocation/rehash. It can
be considered as a fix for PR 90277 cause when initial bucket count is
11 there is no rehash anymore during those tests.
Compared to initial submission this version has the refinement that
if the user explicitly set initial bucket count we respect it and do not
jump to 11.
Additionally this patch extend the PR 87135 fix to the power of 2
rehash policy alternative and it adopts the long double versions of
builtin ceil/floor as advised in another message thread.
Last I realized that _Hashtable<>::reserve could leverage on rehash
policy _M_bkt_for_elements rather than trying to compute it itself, it
brings more consistency in the container behavior.
* include/bits/hashtable.h (_Hashtable<>::rehash): Review comment.
* include/bits/hashtable_policy.h
(_Prime_rehash_policy::_M_bkt_for_elements): Use __builtin_ceill.
(_Power2_rehash_policy::_M_bkt_for_elements): Likewise.
(_Power2_rehash_policy::_M_next_bkt): Enforce returning a result not
smaller than input value rather than always greater. Preserve
_M_next_resize if called with 0 input. Use __builtin_floorl.
(_Power2_rehash_policy::_M_need_rehash): Rehash only if number of
elements + number of insertions is greater than _M_next_resize. Start
with 11 buckets if not told otherwise. Use __builtin_floorl.
(_Rehash_base<>::reserve): Use rehash policy _M_bkt_for_elements.
* src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_M_next_bkt):
Preserve _M_next_resize if called with 0 input. Use __builtin_floorl.
(_Prime_rehash_policy::_M_need_rehash): Start with 11 buckets if not
told otherwise. Use __builtin_floorl.
* testsuite/23_containers/unordered_set/hash_policy/71181.cc: Adapt
test
to also validate _Power2_rehash_policy.
* testsuite/23_containers/unordered_set/hash_policy/power2_rehash.cc:
Adapt.
Tested under Linux x86_64 normal and debug modes.
Ok to commit ?
François
diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index da78c68434f..2e8aeb7e4d4 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -2055,7 +2055,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if (__buckets != _M_bucket_count)
_M_rehash(__buckets, __saved_state);
else
- // No rehash, restore previous state to keep a consistent state.
+ // No rehash, restore previous state to keep it consistent with
+ // container state.
_M_rehash_policy._M_reset(__saved_state);
}
diff --git a/libstdc++-v3/include/bits/hashtable_policy.h b/libstdc++-v3/include/bits/hashtable_policy.h
index b38e8e0ecef..c7f466cd686 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -460,7 +460,7 @@ namespace __detail
// Return a bucket count appropriate for n elements
std::size_t
_M_bkt_for_elements(std::size_t __n) const
-{ return __builtin_ceil(__n / (long double)_M_max_load_factor); }
+{ return __builtin_ceill(__n / (long double)_M_max_load_factor); }
// __n_bkt is current bucket count, __n_elt is current element count,
// and __n_ins is number of elements to be inserted. Do we need to
@@ -535,24 +535,32 @@ namespace __detail
std::size_t
_M_next_bkt(std::size_t __n) noexcept
{
+ if (__n == 0)
+ // Special case on container 1st initialization with 0 bucket count
+ // hint. We keep _M_next_resize to 0 to make sure that next time we
+ // want to add an element allocation will take place.
+ return 1;
+
const auto __max_width = std::min(sizeof(size_t), 8);
const auto __max_bkt = size_t(1) << (__max_width * __CHAR_BIT__ - 1);
std::size_t __res = __clp2(__n);
- if (__res == __n)
- __res <<= 1;
-
if (__res == 0)
__res = __max_bkt;
+ else if (__res == 1)
+ // If __res is 1 we force it to 2 to make sure there will be an
+ // allocation so that nothing need to be stored in the initial
+ // single bucket
+ __res = 2;
if (__res == __max_bkt)
// Set next resize to the max value so that we never try to rehash again
// as we already reach the biggest possible bucket number.
// Note that it might result in max_load_factor not being respected.
- _M_next_resize = std::size_t(-1);
+ _M_next_resize = numeric_limits::max();
else
_M_next_resize
- = __builtin_ceil(__res * (long double)_M_max_load_factor);
+ = __builtin_floorl(__res * (long double)_M_max_load_factor);
return __res;
}
@@ -560,7 +568,7
Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap
On 02/05/19 21:33 +0100, Jonathan Wakely wrote:
On 02/05/19 20:11 +0100, Jonathan Wakely wrote:
On 02/05/19 20:09 +0100, Jonathan Wakely wrote:
On 02/05/19 20:34 +0200, Stephan Bergmann wrote:
On 29/04/2019 15:26, Jonathan Wakely wrote:
* include/bits/move.h (swap(T&, T&), swap(T (&)[N], T (&)[N])): Use
_GLIBCXX_NOEXCEPT_IF to simplify declarations.
This just avoids having to repeat the name and parameter-list of the
functions.
libstdc++-v3/include/std/type_traits still has
template
inline
typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>,
is_move_constructible<_Tp>,
is_move_assignable<_Tp>>::value>::type
swap(_Tp&, _Tp&)
noexcept(__and_,
is_nothrow_move_assignable<_Tp>>::value);
using noexcept instead of _GLIBCXX_NOEXPECT_IF, and at least
during configure of building LibreOffice with Clang, that causes
failure
.../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/move.h:185:5:
error: exception specification in declaration does not match previous
declaration
swap(_Tp& __a, _Tp& __b)
^
.../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:2531:5:
note: previous declaration is here
swap(_Tp&, _Tp&)
^
I didn't try to track down under what conditions
_GLIBCXX_NOEXCEPT_IF would not expand to noexcept, but I assume
that just type_traits needs adapting, too?
That's weird. _GLIBCXX_NOEXCEPT_IF is only empty for C++11, in which
case the declaration in isn't seen anyway. And there's
no point using _GLIBCXX_NOEXCEPT_IF in because we can
(and should) just use noexcept directly in C++11 code. The macro
exists for code that needs to be compiled as C++98 too.
The only difference is that there's an extra set of parentheses around
the NOEXCEPT_IF condition, so the preprocessor doesn't try to eat the
comma.
So one declaration is:
template
inline
typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>,
is_move_constructible<_Tp>,
is_move_assignable<_Tp>>::value>::type
swap(_Tp&, _Tp&)
noexcept(__and_,
is_nothrow_move_assignable<_Tp>>::value);
And the other is:
template
inline
typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>,
is_move_constructible<_Tp>,
is_move_assignable<_Tp>>::value>::type
swap(_Tp&, _Tp&)
noexcept((__and_,
is_nothrow_move_assignable<_Tp>>::value));
Yep, Clang doesn't like that:
https://wandbox.org/permlink/clslE9PGCVtKPppz
This was also reported as https://gcc.gnu.org/PR90314
And here's what I've tested and committed.
commit 3a40e123af3226cd577de7db678fff5815816487
Author: Jonathan Wakely
Date: Thu May 2 21:52:09 2019 +0100
PR libstdc++/90314 fix non-equivalent declarations of std::swap
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
.
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.
diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config
index 5016f4853de..ca1557af564 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -157,12 +157,12 @@
#ifndef _GLIBCXX_NOEXCEPT
# if __cplusplus >= 201103L
# define _GLIBCXX_NOEXCEPT noexcept
-# define _GLIBCXX_NOEXCEPT_IF(_COND) noexcept(_COND)
+# define _GLIBCXX_NOEXCEPT_IF(...) noexcept(__VA_ARGS__)
# define _GLIBCXX_USE_NOEXCEPT noexcept
# define _GLIBCXX_THROW(_EXC)
# else
# define _GLIBCXX_NOEXCEPT
-# define _GLIBCXX_NOEXCEPT_IF(_COND)
+# define _GLIBCXX_NOEXCEPT_IF(...)
# define _GLIBCXX_USE_NOEXCEPT throw()
# define _GLIBCXX_THROW(_EXC) throw(_EXC)
# endif
diff --git a/libstdc++-v3/include/bits/move.h b/libstdc++-v3/include/bits/move.h
index 996078cfbce..7271e273e8e 100644
--- a/libstdc++-v3/include/bits/move.h
+++ b/libstdc++-v3/include/bits/move.h
@@ -183,8 +183,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
void
#endif
swap(_Tp& __a, _Tp& __b)
-_GLIBCXX_NOEXCEPT_IF((__and_,
- is_nothrow_move_assignable<_Tp>>::value))
+_GLIBCXX_NOEXCEPT_IF(__and_,
+is_nothrow_move_assignable<_Tp>>::value)
{
// concept requirements
__glibcxx_function_requires(_SGIAssignableConcept<_Tp>)
Re: [PATCH][stage1] Prefer to use strlen call instead of inline expansion (PR target/88809).
On Tue, Apr 30, 2019 at 10:00:07AM -0600, Jeff Law wrote: > > 2019-04-23 Martin Liska > > > > PR target/88809 > > * config/i386/i386.c (ix86_expand_strlen): Use strlen call. > > With -minline-all-stringops use inline expansion using 4B loop. > > * doc/invoke.texi: Document the change of > > -minline-all-stringops. > > > > gcc/testsuite/ChangeLog: > > > > 2019-04-23 Martin Liska > > > > PR target/88809 > > * gcc.target/i386/pr88809.c: New test. > > * gcc.target/i386/pr88809-2.c: New test. > OK for the trunk. The pr88809-2.c test fails on i686-linux. spawn -ignore SIGHUP /home/jakub/src/gcc/obj31/gcc/xgcc -B/home/jakub/src/gcc/obj31/gcc/ /home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr88809- 2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -Os -ffat-lto-objects -fno-ident -S -o pr88809-2.s PASS: gcc.target/i386/pr88809-2.c (test for excess errors) FAIL: gcc.target/i386/pr88809-2.c scan-assembler call[ \t]strlen Jakub
[PATCH] x86: Put -fPIC and -shared the last to create offload image
On x86, since -fPIC and -shared should be used to create offload image,
we put them the last to properly create offload image.
PR target/87833
* config/i386/intelmic-mkoffload.c (prepare_target_image): Put
-fPIC and -shared the last to create offload image.
---
gcc/config/i386/intelmic-mkoffload.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/config/i386/intelmic-mkoffload.c
b/gcc/config/i386/intelmic-mkoffload.c
index 2a3e912ee74..0b12edc72c1 100644
--- a/gcc/config/i386/intelmic-mkoffload.c
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -453,8 +453,6 @@ prepare_target_image (const char *target_compiler, int
argc, char **argv)
if (verbose)
obstack_ptr_grow (&argv_obstack, "-v");
obstack_ptr_grow (&argv_obstack, "-xlto");
- obstack_ptr_grow (&argv_obstack, "-shared");
- obstack_ptr_grow (&argv_obstack, "-fPIC");
obstack_ptr_grow (&argv_obstack, opt1);
for (int i = 1; i < argc; i++)
{
@@ -466,6 +464,9 @@ prepare_target_image (const char *target_compiler, int
argc, char **argv)
if (!out_obj_filename)
fatal_error (input_location, "output file not specified");
obstack_ptr_grow (&argv_obstack, opt2);
+ /* NB: Put -fPIC and -shared the last to create shared library. */
+ obstack_ptr_grow (&argv_obstack, "-fPIC");
+ obstack_ptr_grow (&argv_obstack, "-shared");
obstack_ptr_grow (&argv_obstack, "-o");
obstack_ptr_grow (&argv_obstack, target_so_filename);
compile_for_target (&argv_obstack);
--
2.20.1
[PATCH] Remove redundant __constexpr_addressof function
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.
Tested powerpc64le-linux, committed to trunk.
commit d7780f66625687168221ff0032405718173b3ac9
Author: Jonathan Wakely
Date: Thu May 2 17:43:41 2019 +0100
Remove redundant __constexpr_addressof function
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.
diff --git a/libstdc++-v3/include/experimental/bits/lfts_config.h
b/libstdc++-v3/include/experimental/bits/lfts_config.h
index 8fc67054c55..851b8b4d43a 100644
--- a/libstdc++-v3/include/experimental/bits/lfts_config.h
+++ b/libstdc++-v3/include/experimental/bits/lfts_config.h
@@ -36,9 +36,8 @@
* Components defined by the _C++ Extensions for Library Fundamentals_
* Technical Specification, versions 1 and 2.
*
- * ISO/IEC TS 19568:2015 C++ Extensions for Library Fundamentals
- *
- * ISO/IEC TS 19568:2017 C++ Extensions for Library Fundamentals, Version 2
+ * - ISO/IEC TS 19568:2015 C++ Extensions for Library Fundamentals
+ * - ISO/IEC TS 19568:2017 C++ Extensions for Library Fundamentals, Version 2
*/
#if _GLIBCXX_INLINE_VERSION
diff --git a/libstdc++-v3/include/experimental/optional
b/libstdc++-v3/include/experimental/optional
index 9a0112de854..ee06b63efd1 100644
--- a/libstdc++-v3/include/experimental/optional
+++ b/libstdc++-v3/include/experimental/optional
@@ -112,6 +112,8 @@ inline namespace fundamentals_v1
virtual ~bad_optional_access() noexcept = default;
};
+ /// @cond undocumented
+
void
__throw_bad_optional_access(const char*)
__attribute__((__noreturn__));
@@ -121,59 +123,6 @@ inline namespace fundamentals_v1
__throw_bad_optional_access(const char* __s)
{ _GLIBCXX_THROW_OR_ABORT(bad_optional_access(__s)); }
-#ifndef __cpp_lib_addressof_constexpr
- template
-struct _Has_addressof_mem : std::false_type { };
-
- template
-struct _Has_addressof_mem<_Tp,
- __void_t().operator&() )>
- >
-: std::true_type { };
-
- template
-struct _Has_addressof_free : std::false_type { };
-
- template
-struct _Has_addressof_free<_Tp,
- __void_t()) )>
- >
-: std::true_type { };
-
- /**
-* @brief Trait that detects the presence of an overloaded unary operator&.
-*
-* Practically speaking this detects the presence of such an operator when
-* called on a const-qualified lvalue (e.g.
-* declval().operator&()).
-*/
- template
-struct _Has_addressof
-: std::__or_<_Has_addressof_mem<_Tp>, _Has_addressof_free<_Tp>>::type
-{ };
-
- /**
-* @brief An overload that attempts to take the address of an lvalue as a
-* constant expression. Falls back to __addressof in the presence of an
-* overloaded addressof operator (unary operator&), in which case the call
-* will not be a constant expression.
-*/
- template
-constexpr
-enable_if_t::value, _Tp*>
-__constexpr_addressof(_Tp& __t)
-{ return &__t; }
-
- /**
-* @brief Fallback overload that defers to __addressof.
-*/
- template
-inline
-enable_if_t<_Has_addressof<_Tp>::value, _Tp*>
-__constexpr_addressof(_Tp& __t)
-{ return std::__addressof(__t); }
-#endif // __cpp_lib_addressof_constexpr
-
/**
* @brief Class template that holds the necessary state for @ref optional
* and that has the responsibility for construction and the special members.
@@ -452,9 +401,6 @@ inline namespace fundamentals_v1
bool _M_engaged = false;
};
- template
- class optional;
-
template
using __converts_from_optional =
__or_&>,
Re: [PATCH] Several patches to improve libstdc++ API docs
On 02/05/19 16:47 +0100, Jonathan Wakely wrote:
I've just committed a series of patches to improve the organization
and formatting of the Doxygen-generated API documentation.
- Update libstdc++ Doxygen config
- Adjust Doxygen processing of pb_ds containers
- Fix markup for Parallel Mode docs
- Improve Doxygen docs for nested namespaces
- Improve API docs for mathematical special functions
- Improve API docs for and
- Improve docs for Filesystem TS
- Improve docs for Library Fundamentals TS
- Improve docs for Networking TS
- Improve docs for C++17 Filesystem library
- Improve docs for mutexes
- Allow Markdown formatting in Doxygen comments
- Miscellaneous API doc improvements
The patch is large so I've bzipped it, but it's almost entirely
changes to comments, with a couple of small re-arrangements of code to
improve the generated HTML docs.
Committed to trunk.
More changes coming soon too (including enabling Doxygen processing
for the C++17 components).
Another similar patch for smart pointers.
Tested x86_64-linux. Committed to trunk.
commit e483bf175e8d3bb0db26428979e5cbc22de3731e
Author: Jonathan Wakely
Date: Thu May 2 17:25:59 2019 +0100
Improve smart pointer docs
* include/bits/shared_ptr.h: Improve docs.
* include/bits/shared_ptr_atomic.h: Likewise.
* include/bits/unique_ptr.h: Likewise. Adjust whitespace.
diff --git a/libstdc++-v3/include/bits/shared_ptr.h b/libstdc++-v3/include/bits/shared_ptr.h
index 2d53478f1f4..a38c1988973 100644
--- a/libstdc++-v3/include/bits/shared_ptr.h
+++ b/libstdc++-v3/include/bits/shared_ptr.h
@@ -82,6 +82,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
/// 20.7.2.2.10 shared_ptr get_deleter
+ /// @relates shared_ptr
template
inline _Del*
get_deleter(const shared_ptr<_Tp>& __p) noexcept
@@ -96,8 +97,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
* @brief A smart pointer with reference-counted copy semantics.
*
- * The object pointed to is deleted when the last shared_ptr pointing to
- * it is destroyed or reset.
+ * A `shared_ptr` object is either empty or _owns_ a pointer passed
+ * to the constructor. Copies of a `shared_ptr` share ownership of
+ * the same pointer. When the last `shared_ptr` that owns the pointer
+ * is destroyed or reset, the owned pointer is freed (either by `delete`
+ * or by invoking a custom deleter that was passed to the constructor).
+ *
+ * A `shared_ptr` also stores another pointer, which is usually
+ * (but not always) the same pointer as it owns. The stored pointer
+ * can be retrieved by calling the `get()` member function.
*/
template
class shared_ptr : public __shared_ptr<_Tp>
@@ -370,6 +378,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
friend class weak_ptr<_Tp>;
};
+ /// @relates shared_ptr @{
+
#if __cpp_deduction_guides >= 201606
template
shared_ptr(weak_ptr<_Tp>) -> shared_ptr<_Tp>;
@@ -480,12 +490,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ return !(nullptr < __a); }
// 20.7.2.2.8 shared_ptr specialized algorithms.
+ /// Swap overload for shared_ptr
template
inline void
swap(shared_ptr<_Tp>& __a, shared_ptr<_Tp>& __b) noexcept
{ __a.swap(__b); }
// 20.7.2.2.9 shared_ptr casts.
+ /// Convert type of `shared_ptr`, via `static_cast`
template
inline shared_ptr<_Tp>
static_pointer_cast(const shared_ptr<_Up>& __r) noexcept
@@ -494,6 +506,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return _Sp(__r, static_cast(__r.get()));
}
+ /// Convert type of `shared_ptr`, via `const_cast`
template
inline shared_ptr<_Tp>
const_pointer_cast(const shared_ptr<_Up>& __r) noexcept
@@ -502,6 +515,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return _Sp(__r, const_cast(__r.get()));
}
+ /// Convert type of `shared_ptr`, via `dynamic_cast`
template
inline shared_ptr<_Tp>
dynamic_pointer_cast(const shared_ptr<_Up>& __r) noexcept
@@ -512,7 +526,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return _Sp();
}
-#if __cplusplus > 201402L
+#if __cplusplus >= 201703L
+ /// Convert type of `shared_ptr`, via `reinterpret_cast`
template
inline shared_ptr<_Tp>
reinterpret_pointer_cast(const shared_ptr<_Up>& __r) noexcept
@@ -522,6 +537,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
#endif
+ // @}
+
/**
* @brief A smart pointer with weak semantics.
*
@@ -601,6 +618,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#endif
// 20.7.2.3.6 weak_ptr specialized algorithms.
+ /// Swap overload for weak_ptr
+ /// @relates weak_ptr
template
inline void
swap(weak_ptr<_Tp>& __a, weak_ptr<_Tp>& __b) noexcept
@@ -617,12 +636,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ };
/// Partial specialization of owner_less for shared_ptr.
+ /// @relates shared_ptr
template
struct owner_less>
: public _Sp_owner_less, weak_ptr<_Tp>>
{ };
/// Partial specialization of owner_less for weak_ptr.
+ /// @relates w
Re: [PATCH] libphobos: RISC-V: Fix soft-float build errors with IEEE exception flags
On Wed, May 1, 2019 at 6:14 PM Maciej Rozycki wrote:
> within inline assembly, to access IEEE exception flags. The use of
> these instructions is not allowed when building for a soft-float ABI.
Technically it is an architecture issue not an ABI issue. If you
compile for -march=rv32imac -mabi=ilp32 then you can't use FP
instructions. If you compile for -march=rv32imafc -mabi=ilp32 then
you can use FP instructions, but we don't use FP regs for argument
passing. This is similar to the distinction that ARM makes between
the soft and softfp ABIs. The RISC-V newlib port for instance checks
__riscv_flen to decide whether to use FP instructions. The predefined
macro __riscv_flen is set to 0 if the target architecture doesn't have
FP registers. So the choice of using FP instructions depends on the
target architecture, not the target ABI.
I see that gcc/config/riscv/riscv-d.c has
if (TARGET_HARD_FLOAT)
d_add_builtin_version ("D_HardFloat");
else
d_add_builtin_version ("D_SoftFloat");
so the patch looks OK, because this is checking the architecture not the ABI.
But the arm/arm-d.c file is defining 3 ARM_* macros for FP support,
and long term we might need something similar in the RISC-V D port for
full RISC-V support. Through for RISC-V it is probably better to have
separate macros for architecture FP support and ABI FP support, each
of which can have 3 values, because you can have for instance an arch
with 64-bit FP support, but an ABI with only 32-bit FP support, and so
worst case we might need to track the arch/abi FP support separately.
This is how it works in the C front end. We have __riscv_flen which
can be 0, 4, or 8 and which indicates the hardware FP register size in
bytes. And we have __riscv_float_abi_soft, __riscv_float_abi_single,
and __riscv_float_abi_double, only one of which is defined, which
indicates the max size of arguments that can be passed in FP
registers.
Jim
Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap
On 02/05/19 20:11 +0100, Jonathan Wakely wrote: On 02/05/19 20:09 +0100, Jonathan Wakely wrote: On 02/05/19 20:34 +0200, Stephan Bergmann wrote: On 29/04/2019 15:26, Jonathan Wakely wrote: * include/bits/move.h (swap(T&, T&), swap(T (&)[N], T (&)[N])): Use _GLIBCXX_NOEXCEPT_IF to simplify declarations. This just avoids having to repeat the name and parameter-list of the functions. libstdc++-v3/include/std/type_traits still has template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept(__and_, is_nothrow_move_assignable<_Tp>>::value); using noexcept instead of _GLIBCXX_NOEXPECT_IF, and at least during configure of building LibreOffice with Clang, that causes failure .../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/move.h:185:5: error: exception specification in declaration does not match previous declaration swap(_Tp& __a, _Tp& __b) ^ .../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:2531:5: note: previous declaration is here swap(_Tp&, _Tp&) ^ I didn't try to track down under what conditions _GLIBCXX_NOEXCEPT_IF would not expand to noexcept, but I assume that just type_traits needs adapting, too? That's weird. _GLIBCXX_NOEXCEPT_IF is only empty for C++11, in which case the declaration in isn't seen anyway. And there's no point using _GLIBCXX_NOEXCEPT_IF in because we can (and should) just use noexcept directly in C++11 code. The macro exists for code that needs to be compiled as C++98 too. The only difference is that there's an extra set of parentheses around the NOEXCEPT_IF condition, so the preprocessor doesn't try to eat the comma. So one declaration is: template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept(__and_, is_nothrow_move_assignable<_Tp>>::value); And the other is: template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept((__and_, is_nothrow_move_assignable<_Tp>>::value)); Yep, Clang doesn't like that: https://wandbox.org/permlink/clslE9PGCVtKPppz This was also reported as https://gcc.gnu.org/PR90314
Mention -std=c2x in GCC 9 release notes
This patch adds a mention of -std=c2x and associated options, and the single new C2X feature supported (given the early stage of C2X development when we left development stage 1), to the GCC 9 release notes. Committed. Index: gcc-9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.61 diff -u -r1.61 changes.html --- gcc-9/changes.html 2 May 2019 12:19:27 - 1.61 +++ gcc-9/changes.html 2 May 2019 20:18:44 - @@ -402,6 +402,17 @@ C + There is now experimental support for -std=c2x, to + select support for the upcoming C2X revision of the ISO C + standard. This standard is in the early stages of development and + the only feature supported in GCC 9 is _Static_assert + with a single argument (support for _Static_assert with two + arguments was added in C11 and GCC 4.6). There are also new + options -std=gnu2x, for C2X with GNU extensions, + and -Wc11-c2x-compat, to warn for uses of features + added in C2X (such warnings are also enabled by use + of -Wpedantic if not using -std=c2x + or -std=gnu2x). New warnings: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wabsolute-value";>-Wabsolute-value -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap
On 02/05/19 20:09 +0100, Jonathan Wakely wrote: On 02/05/19 20:34 +0200, Stephan Bergmann wrote: On 29/04/2019 15:26, Jonathan Wakely wrote: * include/bits/move.h (swap(T&, T&), swap(T (&)[N], T (&)[N])): Use _GLIBCXX_NOEXCEPT_IF to simplify declarations. This just avoids having to repeat the name and parameter-list of the functions. libstdc++-v3/include/std/type_traits still has template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept(__and_, is_nothrow_move_assignable<_Tp>>::value); using noexcept instead of _GLIBCXX_NOEXPECT_IF, and at least during configure of building LibreOffice with Clang, that causes failure .../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/move.h:185:5: error: exception specification in declaration does not match previous declaration swap(_Tp& __a, _Tp& __b) ^ .../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:2531:5: note: previous declaration is here swap(_Tp&, _Tp&) ^ I didn't try to track down under what conditions _GLIBCXX_NOEXCEPT_IF would not expand to noexcept, but I assume that just type_traits needs adapting, too? That's weird. _GLIBCXX_NOEXCEPT_IF is only empty for C++11, in which case the declaration in isn't seen anyway. And there's no point using _GLIBCXX_NOEXCEPT_IF in because we can (and should) just use noexcept directly in C++11 code. The macro exists for code that needs to be compiled as C++98 too. The only difference is that there's an extra set of parentheses around the NOEXCEPT_IF condition, so the preprocessor doesn't try to eat the comma. So one declaration is: template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept(__and_, is_nothrow_move_assignable<_Tp>>::value); And the other is: template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept((__and_, is_nothrow_move_assignable<_Tp>>::value)); Yep, Clang doesn't like that: https://wandbox.org/permlink/clslE9PGCVtKPppz Does adding the extra parens into type_traits fix it? i.e. --- a/libstdc++-v3/include/std/type_traits +++ b/libstdc++-v3/include/std/type_traits @@ -2529,8 +2529,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) -noexcept(__and_, - is_nothrow_move_assignable<_Tp>>::value); +noexcept((__and_, + is_nothrow_move_assignable<_Tp>>::value)); template inline
Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap
On 02/05/19 20:34 +0200, Stephan Bergmann wrote: On 29/04/2019 15:26, Jonathan Wakely wrote: * include/bits/move.h (swap(T&, T&), swap(T (&)[N], T (&)[N])): Use _GLIBCXX_NOEXCEPT_IF to simplify declarations. This just avoids having to repeat the name and parameter-list of the functions. libstdc++-v3/include/std/type_traits still has template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept(__and_, is_nothrow_move_assignable<_Tp>>::value); using noexcept instead of _GLIBCXX_NOEXPECT_IF, and at least during configure of building LibreOffice with Clang, that causes failure .../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/move.h:185:5: error: exception specification in declaration does not match previous declaration swap(_Tp& __a, _Tp& __b) ^ .../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:2531:5: note: previous declaration is here swap(_Tp&, _Tp&) ^ I didn't try to track down under what conditions _GLIBCXX_NOEXCEPT_IF would not expand to noexcept, but I assume that just type_traits needs adapting, too? That's weird. _GLIBCXX_NOEXCEPT_IF is only empty for C++11, in which case the declaration in isn't seen anyway. And there's no point using _GLIBCXX_NOEXCEPT_IF in because we can (and should) just use noexcept directly in C++11 code. The macro exists for code that needs to be compiled as C++98 too. The only difference is that there's an extra set of parentheses around the NOEXCEPT_IF condition, so the preprocessor doesn't try to eat the comma. So one declaration is: template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept(__and_, is_nothrow_move_assignable<_Tp>>::value); And the other is: template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept((__and_, is_nothrow_move_assignable<_Tp>>::value)); Does adding the extra parens into type_traits fix it? i.e. --- a/libstdc++-v3/include/std/type_traits +++ b/libstdc++-v3/include/std/type_traits @@ -2529,8 +2529,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) -noexcept(__and_, - is_nothrow_move_assignable<_Tp>>::value); +noexcept((__and_, + is_nothrow_move_assignable<_Tp>>::value)); template inline
Re: [RFH] split {generic,gimple}-match.c files
On May 2, 2019 8:14:46 PM GMT+02:00, Segher Boessenkool wrote: >On Thu, May 02, 2019 at 07:41:18PM +0200, Richard Biener wrote: >> On May 2, 2019 7:00:16 PM GMT+02:00, Segher Boessenkool > wrote: >> >On Thu, May 02, 2019 at 03:18:00PM +0200, Richard Biener wrote: >> >> Somewhen earlier this year I've done the experiment with using >> >> a compile with -flto -fno-fat-lto-objects and a link >> >> via -flto -r -flinker-output=rel into the object file. This cut >> >> compile-time more than in half with less maintainance overhead. >> >> >> >> Adding other files to this handling looks trivial as well, as well >> >> as conditionalizing it (I'd probably not want this for devel >builds). >> > >> >But we want devel builds to be a lot faster than they are now :-/ >> >> My devel build is -O0 non-bootstrapped and building the files after >dependency changes is fast enough. It's the bootstraps that matter, no? > > >Yes, I bootstrap most of the time. For development. It catches a >*lot* >of problems progressive builds do not. (Those are plenty fast already >of >course, -O0 or not). So we'd catch it there but disable by default for stage 1 since we probably do not want to rely on the host compiler. Richard. > >Segher
Re: [PATCH, libphobos] Add explicit casts in emutls.d to fix build on some systems
Am 02.05.19 um 20:48 schrieb Johannes Pfau: This fixes builds on systems where __builtin_machine_uint != size_t. In D, casts from larger to smaller integer size need to be made explicitly. Most notably this fixes --disable-tls for MIPS64 systems. Built on x86_64 with --disable-tls and ran D test suite. Unfortunately I can't test on MIPS64 myself, but it should fix all the errors previously reported ;-)
[PATCH, libphobos] Add explicit casts in emutls.d to fix build on some systems
This fixes builds on systems where __builtin_machine_uint != size_t. In D,
casts from larger to smaller integer size need to be made explicitly.
Most notably this fixes --disable-tls for MIPS64 systems.
libphobos/ChangeLog:
2019-05-02 Johannes Pfau
* libdruntime/gcc/emutls.d: Add explicit casts to size_t.
---
libphobos/libdruntime/gcc/emutls.d | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libphobos/libdruntime/gcc/emutls.d
b/libphobos/libdruntime/gcc/emutls.d
index 461f20d9e28..1f8bbf5d69e 100644
--- a/libphobos/libdruntime/gcc/emutls.d
+++ b/libphobos/libdruntime/gcc/emutls.d
@@ -197,7 +197,7 @@ void** emutlsAlloc(shared __emutls_object* obj) nothrow
@nogc
emutls_destroy accordingly. */
if ((cast() obj).align_ <= pointerSize)
{
-ptr = malloc((cast() obj).size + pointerSize);
+ptr = malloc(cast(size_t)((cast() obj).size + pointerSize));
if (ptr == null)
abort();
(cast(void**) ptr)[0] = ptr;
@@ -205,7 +205,7 @@ void** emutlsAlloc(shared __emutls_object* obj) nothrow
@nogc
}
else
{
-ptr = malloc(obj.size + pointerSize + obj.align_ - 1);
+ptr = malloc(cast(size_t)(obj.size + pointerSize + obj.align_ - 1));
if (ptr == null)
abort();
ret = cast(void*)((cast(pointer)(ptr + pointerSize + obj.align_ - 1))
& ~cast(
@@ -214,9 +214,9 @@ void** emutlsAlloc(shared __emutls_object* obj) nothrow
@nogc
}
if (obj.templ)
-memcpy(ret, cast(ubyte*) obj.templ, cast() obj.size);
+memcpy(ret, cast(ubyte*) obj.templ, cast(size_t) obj.size);
else
-memset(ret, 0, cast() obj.size);
+memset(ret, 0, cast(size_t) obj.size);
return cast(void**) ret;
}
--
2.19.2
Let ldist ignore clobbers
Hello,
this lets ldist ignore clobbers. In the testcase, this makes us lose the
information that b is clobbered, but being able to distribute seems worth
it.
Bootstrap+regtest on x86_64-pc-linux-gnu.
2019-05-03 Marc Glisse
PR tree-optimization/90269
gcc/
* tree-loop-distribution.c (find_seed_stmts_for_distribution):
Ignore clobbers.
gcc/testsuite/
* g++.dg/tree-ssa/ldist-1.C: New file.
--
Marc GlisseIndex: gcc/testsuite/g++.dg/tree-ssa/ldist-1.C
===
--- gcc/testsuite/g++.dg/tree-ssa/ldist-1.C (nonexistent)
+++ gcc/testsuite/g++.dg/tree-ssa/ldist-1.C (working copy)
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-ldist-details" } */
+
+#include
+struct T {
+int* p;
+T(T const&t):p(t.p){}
+};
+void f(T*__restrict a,T*__restrict b){
+for(int i=0;i<1024;++i){
+ new(a+i)T(b[i]);
+ b[i].~T();
+}
+}
+
+/* { dg-final { scan-tree-dump "generated memcpy" "ldist" } } */
Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c (revision 270818)
+++ gcc/tree-loop-distribution.c (working copy)
@@ -3033,20 +3033,24 @@ find_seed_stmts_for_distribution (struct
the loop. */
if (!stmt_has_scalar_dependences_outside_loop (loop, phi))
continue;
work_list->safe_push (phi);
}
for (gimple_stmt_iterator gsi = gsi_start_bb (bbs[i]);
!gsi_end_p (gsi); gsi_next (&gsi))
{
gimple *stmt = gsi_stmt (gsi);
+ /* Ignore clobbers, they do not have true side effects. */
+ if (gimple_clobber_p (stmt))
+ continue;
+
/* If there is a stmt with side-effects bail out - we
cannot and should not distribute this loop. */
if (gimple_has_side_effects (stmt))
{
free (bbs);
return false;
}
/* Distribute stmts which have defs that are used outside of
the loop. */
Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap
On 29/04/2019 15:26, Jonathan Wakely wrote: * include/bits/move.h (swap(T&, T&), swap(T (&)[N], T (&)[N])): Use _GLIBCXX_NOEXCEPT_IF to simplify declarations. This just avoids having to repeat the name and parameter-list of the functions. libstdc++-v3/include/std/type_traits still has template inline typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>, is_move_constructible<_Tp>, is_move_assignable<_Tp>>::value>::type swap(_Tp&, _Tp&) noexcept(__and_, is_nothrow_move_assignable<_Tp>>::value); using noexcept instead of _GLIBCXX_NOEXPECT_IF, and at least during configure of building LibreOffice with Clang, that causes failure .../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/move.h:185:5: error: exception specification in declaration does not match previous declaration swap(_Tp& __a, _Tp& __b) ^ .../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:2531:5: note: previous declaration is here swap(_Tp&, _Tp&) ^ I didn't try to track down under what conditions _GLIBCXX_NOEXCEPT_IF would not expand to noexcept, but I assume that just type_traits needs adapting, too?
[PATCH 2/2] rs6000: Make debug regnums independent of internal ones
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.
Tested on Linux, as the previous patch. Committing to trunk.
Segher
2019-05-02 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_dbx_register_number): Do not use
the internal register number, for any "real" register.
---
gcc/config/rs6000/rs6000.c | 107 +++--
1 file changed, 64 insertions(+), 43 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index f8e9fd2..c75fd86 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -36269,53 +36269,74 @@ rs6000_init_dwarf_reg_sizes_extra (tree address)
unsigned int
rs6000_dbx_register_number (unsigned int regno, unsigned int format)
{
- /* We use the GCC 7 (and before) internal number for non-DWARF debug
- information, and also for .eh_frame. */
- if ((format == 0 && write_symbols != DWARF2_DEBUG) || format == 2)
-{
- /* Translate the regnos to their numbers in GCC 7 (and before). */
- if (regno == TFHAR_REGNO)
- regno = 114;
- else if (regno == TFIAR_REGNO)
- regno = 115;
- else if (regno == TEXASR_REGNO)
- regno = 116;
-
- return regno;
-}
-
/* On some platforms, we use the standard DWARF register
numbering for .debug_info and .debug_frame. */
+ if ((format == 0 && write_symbols == DWARF2_DEBUG) || format == 1)
+{
#ifdef RS6000_USE_DWARF_NUMBERING
- if (regno <= 63)
-return regno;
- if (regno == LR_REGNO)
-return 108;
- if (regno == CTR_REGNO)
-return 109;
- /* Special handling for CR for .debug_frame: rs6000_emit_prologue has
- translated any combination of CR2, CR3, CR4 saves to a save of CR2.
- The actual code emitted saves the whole of CR, so we map CR2_REGNO
- to the DWARF reg for CR. */
- if (format == 1 && regno == CR2_REGNO)
-return 64;
- if (CR_REGNO_P (regno))
-return regno - CR0_REGNO + 86;
- if (regno == CA_REGNO)
-return 101; /* XER */
- if (ALTIVEC_REGNO_P (regno))
-return regno - FIRST_ALTIVEC_REGNO + 1124;
- if (regno == VRSAVE_REGNO)
-return 356;
- if (regno == VSCR_REGNO)
-return 67;
- if (regno == TFHAR_REGNO)
-return 228;
- if (regno == TFIAR_REGNO)
-return 229;
- if (regno == TEXASR_REGNO)
-return 230;
+ if (regno <= 31)
+ return regno;
+ if (FP_REGNO_P (regno))
+ return regno - FIRST_FPR_REGNO + 32;
+ if (ALTIVEC_REGNO_P (regno))
+ return regno - FIRST_ALTIVEC_REGNO + 1124;
+ if (regno == LR_REGNO)
+ return 108;
+ if (regno == CTR_REGNO)
+ return 109;
+ if (regno == CA_REGNO)
+ return 101; /* XER */
+ /* Special handling for CR for .debug_frame: rs6000_emit_prologue has
+translated any combination of CR2, CR3, CR4 saves to a save of CR2.
+The actual code emitted saves the whole of CR, so we map CR2_REGNO
+to the DWARF reg for CR. */
+ if (format == 1 && regno == CR2_REGNO)
+ return 64;
+ if (CR_REGNO_P (regno))
+ return regno - CR0_REGNO + 86;
+ if (regno == VRSAVE_REGNO)
+ return 356;
+ if (regno == VSCR_REGNO)
+ return 67;
+ if (regno == TFHAR_REGNO)
+ return 228;
+ if (regno == TFIAR_REGNO)
+ return 229;
+ if (regno == TEXASR_REGNO)
+ return 230;
+
+ return regno;
#endif
+}
+
+ /* We use the GCC 7 (and before) internal number for non-DWARF debug
+ information, and also for .eh_frame. */
+ /* Translate the regnos to their numbers in GCC 7 (and before). */
+ if (regno <= 31)
+return regno;
+ if (FP_REGNO_P (regno))
+return regno - FIRST_FPR_REGNO + 32;
+ if (ALTIVEC_REGNO_P (regno))
+return regno - FIRST_ALTIVEC_REGNO + 77;
+ if (regno == LR_REGNO)
+return 65;
+ if (regno == CTR_REGNO)
+return 66;
+ if (regno == CA_REGNO)
+return 76; /* XER */
+ if (CR_REGNO_P (regno))
+return regno - CR0_REGNO + 68;
+ if (regno == VRSAVE_REGNO)
+return 109;
+ if (regno == VSCR_REGNO)
+return 110;
+ if (regno == TFHAR_REGNO)
[PATCH 1/2] rs6000: Debug regnums for TM registers
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.
Tested on powerpc64-linux (-m32,-m64} and on powerpc64le-linux.
Committing. I hope this (and the next patch) doesn't break targets
using the old DWARF register numbers, I cannot easily test that; but
it's stage 1.
This should be backported to GCC 8 and GCC 9 (9.2).
Segher
2019-05-02 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_dbx_register_number): Return the
correct numbers for TFHAR, TFIAR, TEXASR.
---
gcc/config/rs6000/rs6000.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index f0de18d..f8e9fd2 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -36269,10 +36269,20 @@ rs6000_init_dwarf_reg_sizes_extra (tree address)
unsigned int
rs6000_dbx_register_number (unsigned int regno, unsigned int format)
{
- /* Except for the above, we use the internal number for non-DWARF
- debug information, and also for .eh_frame. */
+ /* We use the GCC 7 (and before) internal number for non-DWARF debug
+ information, and also for .eh_frame. */
if ((format == 0 && write_symbols != DWARF2_DEBUG) || format == 2)
-return regno;
+{
+ /* Translate the regnos to their numbers in GCC 7 (and before). */
+ if (regno == TFHAR_REGNO)
+ regno = 114;
+ else if (regno == TFIAR_REGNO)
+ regno = 115;
+ else if (regno == TEXASR_REGNO)
+ regno = 116;
+
+ return regno;
+}
/* On some platforms, we use the standard DWARF register
numbering for .debug_info and .debug_frame. */
@@ -36299,6 +36309,12 @@ rs6000_dbx_register_number (unsigned int regno,
unsigned int format)
return 356;
if (regno == VSCR_REGNO)
return 67;
+ if (regno == TFHAR_REGNO)
+return 228;
+ if (regno == TFIAR_REGNO)
+return 229;
+ if (regno == TEXASR_REGNO)
+return 230;
#endif
return regno;
}
--
1.8.3.1
Re: [RFH] split {generic,gimple}-match.c files
On Thu, May 02, 2019 at 07:41:18PM +0200, Richard Biener wrote: > On May 2, 2019 7:00:16 PM GMT+02:00, Segher Boessenkool > wrote: > >On Thu, May 02, 2019 at 03:18:00PM +0200, Richard Biener wrote: > >> Somewhen earlier this year I've done the experiment with using > >> a compile with -flto -fno-fat-lto-objects and a link > >> via -flto -r -flinker-output=rel into the object file. This cut > >> compile-time more than in half with less maintainance overhead. > >> > >> Adding other files to this handling looks trivial as well, as well > >> as conditionalizing it (I'd probably not want this for devel builds). > > > >But we want devel builds to be a lot faster than they are now :-/ > > My devel build is -O0 non-bootstrapped and building the files after > dependency changes is fast enough. It's the bootstraps that matter, no? Yes, I bootstrap most of the time. For development. It catches a *lot* of problems progressive builds do not. (Those are plenty fast already of course, -O0 or not). Segher
Re: V5 [PATCH] Optimize vector constructor
On Thu, May 2, 2019 at 7:55 AM Richard Biener
wrote:
>
> On Thu, May 2, 2019 at 4:54 PM Richard Biener
> wrote:
> >
> > On Mon, Mar 11, 2019 at 8:03 AM H.J. Lu wrote:
> > >
> > > On Fri, Mar 8, 2019 at 7:03 PM Richard Biener
> > > wrote:
> > > >
> > > > On Fri, Mar 8, 2019 at 9:49 AM H.J. Lu wrote:
> > > > >
> > > > > On Thu, Mar 7, 2019 at 9:51 AM H.J. Lu wrote:
> > > > > >
> > > > > > On Wed, Mar 6, 2019 at 8:33 PM Richard Biener
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Mar 04, 2019 at 12:55:04PM +0100, Richard Biener
> > > > > > > > > wrote:
> > > > > > > > > > On Sun, Mar 3, 2019 at 10:13 PM H.J. Lu
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Mar 03, 2019 at 06:40:09AM -0800, Andrew Pinski
> > > > > > > > > > > wrote:
> > > > > > > > > > > > )
> > > > > > > > > > > > ,On Sun, Mar 3, 2019 at 6:32 AM H.J. Lu
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > For vector init constructor:
> > > > > > > > > > > > >
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > typedef float __v4sf __attribute__ ((__vector_size__
> > > > > > > > > > > > > (16)));
> > > > > > > > > > > > >
> > > > > > > > > > > > > __v4sf
> > > > > > > > > > > > > foo (__v4sf x, float f)
> > > > > > > > > > > > > {
> > > > > > > > > > > > > __v4sf y = { f, x[1], x[2], x[3] };
> > > > > > > > > > > > > return y;
> > > > > > > > > > > > > }
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >
> > > > > > > > > > > > > we can optimize vector init constructor with vector
> > > > > > > > > > > > > copy or permute
> > > > > > > > > > > > > followed by a single scalar insert:
> > > > > > > > >
> > > > > > > > > > and you want to advance to the _1 = BIT_INSERT_EXPR here.
> > > > > > > > > > The easiest way
> > > > > > > > > > is to emit a new stmt for _2 = copy ...; and do the set_rhs
> > > > > > > > > > with the
> > > > > > > > > > BIT_INSERT_EXPR.
> > > > > > > > >
> > > > > > > > > Thanks for BIT_INSERT_EXPR suggestion. I am testing this
> > > > > > > > > patch.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > H.J.
> > > > > > > > > ---
> > > > > > > > > We can optimize vector constructor with vector copy or
> > > > > > > > > permute followed
> > > > > > > > > by a single scalar insert:
> > > > > > > > >
> > > > > > > > > __v4sf y;
> > > > > > > > > __v4sf D.1930;
> > > > > > > > > float _1;
> > > > > > > > > float _2;
> > > > > > > > > float _3;
> > > > > > > > >
> > > > > > > > >:
> > > > > > > > > _1 = BIT_FIELD_REF ;
> > > > > > > > > _2 = BIT_FIELD_REF ;
> > > > > > > > > _3 = BIT_FIELD_REF ;
> > > > > > > > > y_6 = {f_5(D), _3, _2, _1};
> > > > > > > > > return y_6;
> > > > > > > > >
> > > > > > > > > with
> > > > > > > > >
> > > > > > > > > __v4sf y;
> > > > > > > > > __v4sf D.1930;
> > > > > > > > > float _1;
> > > > > > > > > float _2;
> > > > > > > > > float _3;
> > > > > > > > > vector(4) float _8;
> > > > > > > > >
> > > > > > > > >:
> > > > > > > > > _1 = BIT_FIELD_REF ;
> > > > > > > > > _2 = BIT_FIELD_REF ;
> > > > > > > > > _3 = BIT_FIELD_REF ;
> > > > > > > > > _8 = x_9(D);
> > > > > > > > > y_6 = BIT_INSERT_EXPR ;
> > > > > > > > > return y_6;
> > > > > > > > >
> > > > > > > > > gcc/
> > > > > > > > >
> > > > > > > > > PR tree-optimization/88828
> > > > > > > > > * tree-ssa-forwprop.c (simplify_vector_constructor):
> > > > > > > > > Optimize
> > > > > > > > > vector init constructor with vector copy or permute
> > > > > > > > > followed
> > > > > > > > > by a single scalar insert.
> > > > > > > > >
> > > > > > > > > gcc/testsuite/
> > > > > > > > >
> > > > > > > > > PR tree-optimization/88828
> > > > > > > > > * gcc.target/i386/pr88828-1a.c: New test.
> > > > > > > > > * gcc.target/i386/pr88828-2b.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-2.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-3a.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-3b.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-3c.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-3d.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-4a.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-4b.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-5a.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-5b.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-6a.c: Likewise.
> > > > > > > > > * gcc.target/i386/pr88828-6b.c: Likewise.
> > > > > > > >
> > > > > > > > Here is the updated patch with run-time tests.
> > > > > > >
> > > > > > > - if (TREE_CODE (elt->value) != SSA_NAME)
> > > > > > > +
Re: [RFH] split {generic,gimple}-match.c files
On May 2, 2019 7:00:16 PM GMT+02:00, Segher Boessenkool wrote: >On Thu, May 02, 2019 at 03:18:00PM +0200, Richard Biener wrote: >> Somewhen earlier this year I've done the experiment with using >> a compile with -flto -fno-fat-lto-objects and a link >> via -flto -r -flinker-output=rel into the object file. This cut >> compile-time more than in half with less maintainance overhead. >> >> Adding other files to this handling looks trivial as well, as well >> as conditionalizing it (I'd probably not want this for devel builds). > >But we want devel builds to be a lot faster than they are now :-/ My devel build is -O0 non-bootstrapped and building the files after dependency changes is fast enough. It's the bootstraps that matter, no? Richard. > >Segher
Re: [RFH] split {generic,gimple}-match.c files
On Thu, May 02, 2019 at 03:18:00PM +0200, Richard Biener wrote: > Somewhen earlier this year I've done the experiment with using > a compile with -flto -fno-fat-lto-objects and a link > via -flto -r -flinker-output=rel into the object file. This cut > compile-time more than in half with less maintainance overhead. > > Adding other files to this handling looks trivial as well, as well > as conditionalizing it (I'd probably not want this for devel builds). But we want devel builds to be a lot faster than they are now :-/ Segher
[v3 PATCH] Make stateful allocator propagation more consistent for operator+(basic_string) (P1165R1)
Tested on Linux x86_64
Make stateful allocator propagation more consistent for
operator+(basic_string) (P1165R1)
2019-05-01 Nina Dinka Ranns
Make stateful allocator propagation more consistent for
operator+(basic_string) (P1165R1)
* include/bits/basic_string.tcc:
(operator+(const _CharT*, const basic_string&)) : Changed
resulting allocator to be SOCCC on the second parameter's allocator
(operator+(_CharT, const basic_string&)) : Likewise
(operator+(basic_string&&,basic_string&&) : Changed resulting
allocator to always be the one from the first parameter
* testsuite/21_strings/basic_string/allocator/char/operator_plus.cc: New
* testsuite/21_strings/basic_string/allocator/wchar_t/operator_plus.cc
: New
Index: libstdc++-v3/include/bits/basic_string.h
===
--- libstdc++-v3/include/bits/basic_string.h (revision 270655)
+++ libstdc++-v3/include/bits/basic_string.h (working copy)
@@ -6096,13 +6096,7 @@
inline basic_string<_CharT, _Traits, _Alloc>
operator+(basic_string<_CharT, _Traits, _Alloc>&& __lhs,
basic_string<_CharT, _Traits, _Alloc>&& __rhs)
-{
- const auto __size = __lhs.size() + __rhs.size();
- const bool __cond = (__size > __lhs.capacity()
- && __size <= __rhs.capacity());
- return __cond ? std::move(__rhs.insert(0, __lhs))
- : std::move(__lhs.append(__rhs));
-}
+{ return std::move(__lhs.append(__rhs)); }
template
inline basic_string<_CharT, _Traits, _Alloc>
Index: libstdc++-v3/include/bits/basic_string.tcc
===
--- libstdc++-v3/include/bits/basic_string.tcc (revision 270655)
+++ libstdc++-v3/include/bits/basic_string.tcc (working copy)
@@ -1161,8 +1161,12 @@
__glibcxx_requires_string(__lhs);
typedef basic_string<_CharT, _Traits, _Alloc> __string_type;
typedef typename __string_type::size_type __size_type;
+ typedef typename __gnu_cxx::__alloc_traits<_Alloc>::template
+ rebind<_CharT>::other _Char_alloc_type;
+ typedef __gnu_cxx::__alloc_traits<_Char_alloc_type> _Alloc_traits;
const __size_type __len = _Traits::length(__lhs);
- __string_type __str;
+ __string_type __str(_Alloc_traits::_S_select_on_copy(
+ __rhs.get_allocator()));
__str.reserve(__len + __rhs.size());
__str.append(__lhs, __len);
__str.append(__rhs);
@@ -1175,7 +1179,11 @@
{
typedef basic_string<_CharT, _Traits, _Alloc> __string_type;
typedef typename __string_type::size_type __size_type;
- __string_type __str;
+ typedef typename __gnu_cxx::__alloc_traits<_Alloc>::template
+ rebind<_CharT>::other _Char_alloc_type;
+ typedef __gnu_cxx::__alloc_traits<_Char_alloc_type> _Alloc_traits;
+ __string_type __str(_Alloc_traits::_S_select_on_copy(
+ __rhs.get_allocator()));
const __size_type __len = __rhs.size();
__str.reserve(__len + 1);
__str.append(__size_type(1), __lhs);
Index: libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/operator_plus.cc
===
--- libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/operator_plus.cc (nonexistent)
+++ libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/operator_plus.cc (working copy)
@@ -0,0 +1,151 @@
+// 2019-04-30 Nina Dinka Ranns
+// Copyright (C) 2019 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
Re: [patch, fortran] Fix PR 61968
Hi Dominique,
Not for me, I still get
% gfc pr61968.f90 -c -O3
pr61968.f90:32:0:
32 | call test_lib (a, int (sizeof (a), kind=c_size_t))
|
internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:1265
You're right, I will clear this up separately.
In the meantime, here is the one-line patch with the test case above
with -O3 added, so any failure will be noted soon.
OK for trunk?
Regards
Thomas
2019-05-02 Thomas Koenig
PR fortran/61968
* interface.c (compare_actual_formal): Do not create a vtab if
the actual argument is assumed type.
2019-05-02 Thomas Koenig
PR fortran/61968
* gfortran.dg/assumed_type_10.f90: New test case.
* gfortran.dg/assumed_type_11.f90: New test case.
! { dg-do compile }
! { dg-options "-O3 -fdump-tree-original" }
! PR 61968 - this used to generate invalid assembler containing
! TYPE(*).
module testmod
use iso_c_binding, only: c_size_t, c_int32_t, c_int64_t
implicit none
interface test
procedure :: test_32
procedure :: test_array
end interface test
interface
subroutine test_lib (a, len) bind(C, name="xxx")
use iso_c_binding, only: c_size_t
type(*), dimension(*) :: a
integer(c_size_t), value :: len
end subroutine
end interface
contains
subroutine test_32 (a, len)
type(*), dimension(*) :: a
integer(c_int32_t), value :: len
call test_lib (a, int (len, kind=c_size_t))
end subroutine
subroutine test_array (a)
use iso_c_binding, only: c_size_t
class(*), dimension(..), target :: a
call test_lib (a, int (sizeof (a), kind=c_size_t))
end subroutine
end module
subroutine test_32_ (a, len)
use iso_c_binding, only: c_int32_t
use testmod
type(*), dimension(*) :: a
integer(c_int32_t), value :: len
call test (a, len)
end subroutine
! { dg-final { scan-tree-dump-not "! __vtype_TYPE\\(*\\)" "original" } }
! { dg-do compile }
! { dg-options "-O0 -fdump-tree-original" }
! PR 61968 - this used to generate invalid assembler containing
! TYPE(*).
module testmod
use iso_c_binding, only: c_size_t, c_int32_t, c_int64_t
implicit none
interface test
procedure :: test_32
procedure :: test_array
end interface test
interface
subroutine test_lib (a, len) bind(C, name="xxx")
use iso_c_binding, only: c_size_t
type(*), dimension(*) :: a
integer(c_size_t), value :: len
end subroutine
end interface
contains
subroutine test_32 (a, len)
type(*), dimension(*) :: a
integer(c_int32_t), value :: len
call test_lib (a, int (len, kind=c_size_t))
end subroutine
subroutine test_array (a)
use iso_c_binding, only: c_size_t
class(*), dimension(..), target :: a
call test_lib (a, int (sizeof (a), kind=c_size_t))
end subroutine
end module
subroutine test_32_ (a, len)
use iso_c_binding, only: c_int32_t
use testmod
type(*), dimension(*) :: a
integer(c_int32_t), value :: len
call test (a, len)
end subroutine
! { dg-final { scan-tree-dump-not "! __vtype_TYPE\\(*\\)" "original" } }
Index: interface.c
===
--- interface.c (Revision 270622)
+++ interface.c (Arbeitskopie)
@@ -2989,7 +2989,8 @@ compare_actual_formal (gfc_actual_arglist **ap, gf
polymorphic formal arguments. */
if (UNLIMITED_POLY (f->sym)
&& a->expr->ts.type != BT_DERIVED
- && a->expr->ts.type != BT_CLASS)
+ && a->expr->ts.type != BT_CLASS
+ && a->expr->ts.type != BT_ASSUMED)
gfc_find_vtab (&a->expr->ts);
if (a->expr->expr_type == EXPR_NULL
Re: [PATCH] Several patches to improve libstdc++ API docs
On 02/05/19 16:47 +0100, Jonathan Wakely wrote:
I've just committed a series of patches to improve the organization
and formatting of the Doxygen-generated API documentation.
- Update libstdc++ Doxygen config
- Adjust Doxygen processing of pb_ds containers
- Fix markup for Parallel Mode docs
- Improve Doxygen docs for nested namespaces
- Improve API docs for mathematical special functions
- Improve API docs for and
- Improve docs for Filesystem TS
- Improve docs for Library Fundamentals TS
- Improve docs for Networking TS
- Improve docs for C++17 Filesystem library
- Improve docs for mutexes
- Allow Markdown formatting in Doxygen comments
- Miscellaneous API doc improvements
The patch is large so I've bzipped it, but it's almost entirely
changes to comments, with a couple of small re-arrangements of code to
improve the generated HTML docs.
Committed to trunk.
More changes coming soon too (including enabling Doxygen processing
for the C++17 components).
Some things worth calling out specifically from this series of
patches:
* Markdown is enabled in doxygen comments now. That might mess
existing comments up, where underscores in type names get interpreted
as markdown. I'll try to review the existing docs for that, and escape
things with backslashes, or surround them with backticks if that's
more appropriate.
* I've made extensive use of @relates (aka @related) to group things
like operator== and operator!= with the class they belong to.
* I've started using Doxygen's @cond command to mark things that we
don't want to document, because they're not meant to be user-visible
e.g.
/// @cond undocumented
template
struct __some_internal_helper
{ };
/// @endcond
If the "undocumented" tag is set in the ENABLE_SECTIONS config in the
doc/doxygen/user.cfg.in file then these sections will still be
processed by doxygen. That means maintainers who want to generate full
docs can still do so, but the default won't include the @cond stuff.
* I've just realized I committed this chunk, which was unintentional:
+# ifdef _GLIBCXX_DOXYGEN
+/// Windows uses wchar_t for path::value_type, POSIX uses char.
+using value_type = __os_dependent__;
+# else
+using value_type = char;
+# endif
Since I didn't commit a change to actually defined _GLIBCXX_DOXYGEN,
that serves no purpose.
* Currently no C++17 or Networking TS headers are processed by
Doxygen. I'm doing to change that soon.
Re: [PATCH] libphobos: RISC-V: Fix soft-float build errors with IEEE exception flags
On Thu, 2 May 2019 at 12:36, Jakub Jelinek wrote: > > On Thu, May 02, 2019 at 09:37:36AM +0200, Iain Buclaw wrote: > > > libphobos/ > > > * std/math.d (IeeeFlags.getIeeeFlags): Handle RISC-V soft-float > > > ABI. > > > (IeeeFlags.resetIeeeFlags): Likewise. > > > (FloatingPointControl.getControlState): Likewise. > > > (FloatingPointControl.setControlState): Likewise. > > > > I believe this change is obviously correct, and I also verified generated > > > code using `objdump -d'. I have no way to regression-test it right now. > > > > > > Please confirm if I correctly referred to identifiers in the ChangeLog > > > entry though, as my experience WRT the D programming language and its > > > syntax in particular is nil. > > > > > > My understanding is changes to `libphobos' are supposed to go upstream > > > first, but r270522 is a local change anyway AFAICT, and technically a > > > `--enable-languages=all' build regression, so we better fix it ASAP. > > > > > > Finally my WDC copyright assignment with FSF is still in the works, but I > > > believe this change can be considered legally insignificant for copyright > > > purposes, i.e. having at most 15 lines or so, unless adding white space > > > for indentation counts against that limit as well (which I doubt). > > > > > > With all of the above in mind, OK to apply to trunk and to GCC 9? > > > > > > > Looks OK to me. > > The change is ok for 9.1 if it can be committed to gcc-9-branch today. > Committed to both trunk and gcc-9-branch. -- Iain
Re: [PATCH/AARCH64] Generate FRINTZ for (double)(long) under -ffast-math on aarch64
On Fri, Aug 18, 2017 at 12:17 PM Andrew Pinski wrote: > > Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for > PowerPC, we should do something similar for aarch64. This pattern > does show up in SPEC CPU 2006 in astar but I did not look into > performance improvement of it though. > > OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions. Ping? It has been over a year and half now. > > Thanks, > Andrew Pinski > > ChangeLog: > * config/aarch64/aarch64.md (*frintz): New pattern. > > testsuite/ChangeLog: > * testsuite/gcc.target/aarch64/floattointtofloat-1.c: New testcase.
Re: [PATCH] [AARCH64] Improve vector generation cost model
On Thu, Mar 14, 2019 at 6:19 PM wrote:
>
> From: Andrew Pinski
>
> Hi,
> On OcteonTX2, ld1r and ld1 (with a single lane) are split
> into two different micro-ops unlike most other targets.
> This adds three extra costs to the cost table:
> ld1_dup: used for "ld1r {v0.4s}, [x0]"
> merge_dup: used for "dup v0.4s, v0.4s[0]" and "ins v0.4s[0], v0.4s[0]"
> ld1_merge: used fir "ld1 {v0.4s}[0], [x0]"
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
Ping? It has been 1.5 months now.
>
> Thanks,
> Andrew Pinski
>
> ChangeLog:
> * config/arm/aarch-common-protos.h (vector_cost_table):
> Add merge_dup, ld1_merge, and ld1_dup.
> * config/aarch64/aarch64-cost-tables.h (qdf24xx_extra_costs):
> Update for the new fields.
> (thunderx_extra_costs): Likewise.
> (thunderx2t99_extra_costs): Likewise.
> (tsv110_extra_costs): Likewise.
> * config/arm/aarch-cost-tables.h (generic_extra_costs): Likewise.
> (cortexa53_extra_costs): Likewise.
> (cortexa57_extra_costs): Likewise.
> (exynosm1_extra_costs): Likewise.
> (xgene1_extra_costs): Likewise.
> * config/aarch64/aarch64.c (aarch64_rtx_costs): Handle vec_dup of a memory.
> Hanlde vec_merge of a memory.
>
> Signed-off-by: Andrew Pinski
> ---
> gcc/config/aarch64/aarch64-cost-tables.h | 20 +++
> gcc/config/aarch64/aarch64.c | 22 +
> gcc/config/arm/aarch-common-protos.h | 3 +++
> gcc/config/arm/aarch-cost-tables.h | 25 +++-
> 4 files changed, 61 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64-cost-tables.h
> b/gcc/config/aarch64/aarch64-cost-tables.h
> index 5c9442e1b89..9a7c70ba595 100644
> --- a/gcc/config/aarch64/aarch64-cost-tables.h
> +++ b/gcc/config/aarch64/aarch64-cost-tables.h
> @@ -123,7 +123,10 @@ const struct cpu_cost_table qdf24xx_extra_costs =
>},
>/* Vector */
>{
> -COSTS_N_INSNS (1) /* alu. */
> +COSTS_N_INSNS (1), /* Alu. */
> +COSTS_N_INSNS (1), /* dup_merge. */
> +COSTS_N_INSNS (1), /* ld1_merge. */
> +COSTS_N_INSNS (1) /* ld1_dup. */
>}
> };
>
> @@ -227,7 +230,10 @@ const struct cpu_cost_table thunderx_extra_costs =
>},
>/* Vector */
>{
> -COSTS_N_INSNS (1) /* Alu. */
> +COSTS_N_INSNS (1), /* Alu. */
> +COSTS_N_INSNS (1), /* dup_merge. */
> +COSTS_N_INSNS (1), /* ld1_merge. */
> +COSTS_N_INSNS (1) /* ld1_dup. */
>}
> };
>
> @@ -330,7 +336,10 @@ const struct cpu_cost_table thunderx2t99_extra_costs =
>},
>/* Vector */
>{
> -COSTS_N_INSNS (1) /* Alu. */
> +COSTS_N_INSNS (1), /* Alu. */
> +COSTS_N_INSNS (1), /* dup_merge. */
> +COSTS_N_INSNS (1), /* ld1_merge. */
> +COSTS_N_INSNS (1) /* ld1_dup. */
>}
> };
>
> @@ -434,7 +443,10 @@ const struct cpu_cost_table tsv110_extra_costs =
>},
>/* Vector */
>{
> -COSTS_N_INSNS (1) /* alu. */
> +COSTS_N_INSNS (1), /* Alu. */
> +COSTS_N_INSNS (1), /* dup_merge. */
> +COSTS_N_INSNS (1), /* ld1_merge. */
> +COSTS_N_INSNS (1) /* ld1_dup. */
>}
> };
>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index b38505b0872..dc4d3d39af8 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -10568,6 +10568,28 @@ cost_plus:
> }
>break;
>
> +case VEC_DUPLICATE:
> + if (!speed)
> + return false;
> +
> + if (GET_CODE (XEXP (x, 0)) == MEM)
> + *cost += extra_cost->vect.ld1_dup;
> + else
> + *cost += extra_cost->vect.merge_dup;
> + return true;
> +
> +case VEC_MERGE:
> + if (speed && GET_CODE (XEXP (x, 0)) == VEC_DUPLICATE)
> + {
> + if (GET_CODE (XEXP (XEXP (x, 0), 0)) == MEM)
> + *cost += extra_cost->vect.ld1_merge;
> + else
> + *cost += extra_cost->vect.merge_dup;
> + return true;
> + }
> + break;
> +
> +
> case TRUNCATE:
>
>/* Decompose muldi3_highpart. */
> diff --git a/gcc/config/arm/aarch-common-protos.h
> b/gcc/config/arm/aarch-common-protos.h
> index 11cd5145bbc..dbc1282402a 100644
> --- a/gcc/config/arm/aarch-common-protos.h
> +++ b/gcc/config/arm/aarch-common-protos.h
> @@ -131,6 +131,9 @@ struct fp_cost_table
> struct vector_cost_table
> {
>const int alu;
> + const int merge_dup;
> + const int ld1_merge;
> + const int ld1_dup;
> };
>
> struct cpu_cost_table
> diff --git a/gcc/config/arm/aarch-cost-tables.h
> b/gcc/config/arm/aarch-cost-tables.h
> index bc33efadc6c..a51bc668f56 100644
> --- a/gcc/config/arm/aarch-cost-tables.h
> +++ b/gcc/config/arm/aarch-cost-tables.h
> @@ -121,7 +121,10 @@ const struct cpu_cost_table generic_extra_costs =
>},
>/* Vector */
>{
> -COSTS_N_INSNS (1) /* alu. */
> +COSTS_N_INSNS (1), /* alu. */
> +COSTS_N_INSNS (1), /* dup_merge. */
> +COSTS_N_INSNS (1), /* ld1_merge. */
> +COSTS_N_INSNS (1) /* ld1_dup. */
>}
> };
>
> @@ -224,7 +227,10
Re: [PATCH] Fix PR 81721: ICE with PCH and Pragma warning and C++ operator
On Mon, Apr 1, 2019 at 5:12 PM wrote:
>
> From: Andrew Pinski
>
> Hi,
> The problem here is the token->val.node is not saved over
> a precompiled header for C++ operator. This can cause an
> internal compiler error as we tried to print out the spelling
> of the token as we assumed it was valid.
> The fix is to have cpp_token_val_index return CPP_TOKEN_FLD_NODE
> for operator tokens that have NAMED_OP set.
>
> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Ping? It has been a month now.
>
> Thanks,
> Andrew Pinski
>
> libcpp/ChangeLog:
> * lex.c (cpp_token_val_index ): If tok->flags
> has NAMED_OP set, then return CPP_TOKEN_FLD_NODE.
>
> gcc/testsuite/ChangeLog:
> * g++.dg/pch/operator-1.C: New testcase.
> * g++.dg/pch/operator-1.Hs: New file.
> ---
> gcc/testsuite/g++.dg/pch/operator-1.C | 2 ++
> gcc/testsuite/g++.dg/pch/operator-1.Hs | 9 +
> libcpp/lex.c | 6 +-
> 3 files changed, 16 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/pch/operator-1.C
> create mode 100644 gcc/testsuite/g++.dg/pch/operator-1.Hs
>
> diff --git a/gcc/testsuite/g++.dg/pch/operator-1.C
> b/gcc/testsuite/g++.dg/pch/operator-1.C
> new file mode 100644
> index 000..290b5f7
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pch/operator-1.C
> @@ -0,0 +1,2 @@
> +#include "operator-1.H"
> +int main(void){ major(0);} /* { dg-warning "Did not Work" } */
> diff --git a/gcc/testsuite/g++.dg/pch/operator-1.Hs
> b/gcc/testsuite/g++.dg/pch/operator-1.Hs
> new file mode 100644
> index 000..657dae1
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pch/operator-1.Hs
> @@ -0,0 +1,9 @@
> +# define __glibc_macro_warning1(message) _Pragma (#message)
> +# define __glibc_macro_warning(message) \
> + __glibc_macro_warning1 (GCC warning message)
> +#define __SYSMACROS_DM1(...) __glibc_macro_warning (#__VA_ARGS__)
> +
> +#define __SYSMACROS_DM(symbol) __SYSMACROS_DM1 \
> + (Did not Work)
> +
> +# define major(dev) __SYSMACROS_DM (major) (dev+0)
> diff --git a/libcpp/lex.c b/libcpp/lex.c
> index eedfcbb..16ded6e 100644
> --- a/libcpp/lex.c
> +++ b/libcpp/lex.c
> @@ -3756,7 +3756,11 @@ cpp_token_val_index (const cpp_token *tok)
> case SPELL_LITERAL:
>return CPP_TOKEN_FLD_STR;
> case SPELL_OPERATOR:
> - if (tok->type == CPP_PASTE)
> + /* Operands which were originally spelled as ident keep around
> + the node for the exact spelling. */
> + if (tok->flags & NAMED_OP)
> + return CPP_TOKEN_FLD_NODE;
> + else if (tok->type == CPP_PASTE)
> return CPP_TOKEN_FLD_TOKEN_NO;
>else
> return CPP_TOKEN_FLD_NONE;
> --
> 1.8.3.1
>
[PATCH] Several patches to improve libstdc++ API docs
I've just committed a series of patches to improve the organization and formatting of the Doxygen-generated API documentation. - Update libstdc++ Doxygen config - Adjust Doxygen processing of pb_ds containers - Fix markup for Parallel Mode docs - Improve Doxygen docs for nested namespaces - Improve API docs for mathematical special functions - Improve API docs for and - Improve docs for Filesystem TS - Improve docs for Library Fundamentals TS - Improve docs for Networking TS - Improve docs for C++17 Filesystem library - Improve docs for mutexes - Allow Markdown formatting in Doxygen comments - Miscellaneous API doc improvements The patch is large so I've bzipped it, but it's almost entirely changes to comments, with a couple of small re-arrangements of code to improve the generated HTML docs. Committed to trunk. More changes coming soon too (including enabling Doxygen processing for the C++17 components). patch.txt.bz2 Description: BZip2 compressed data
Re: [PATCH] Error only when -mabi=ms is used on a non-MS_ABI system (PR sanitizer/90312).
On Thu, May 02, 2019 at 05:11:02PM +0200, Martin Liška wrote: > As mentioned in the PR, we should not provide an error on mingw and cygwin > targets. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Can one use sysv_abi in code compiled on windows (where msabi is the default)? If yes, don't you get ICE in that case? As in, shouldn't the test be that we do not support -fsanitize=address with non-default ABI? Jakub
Re: [committed] [PR tree-optimization/88797] Thottle back path splitting in another case where it'll inhibit if-conversion
On Thu, May 2, 2019 at 5:07 PM Jeff Law wrote: > > On 5/2/19 7:23 AM, Richard Biener wrote: > > On Thu, May 2, 2019 at 3:17 PM Jeff Law wrote: > >> > >> On 5/2/19 6:22 AM, Richard Biener wrote: > >>> On Wed, May 1, 2019 at 7:32 PM Jeff Law wrote: > > > This fixes pr88797 by avoiding path splitting when we've got a > candidate, but the PHI feeds a conditional in the join block. ie: > > # iftmp.0_11 = PHI <(3), 1112(4)> > [ ... ] > _14 = iftmp.0_11 > x_17; > > > These are more likely going to be if-conversion candidates and > if-conversion is generally more profitable than path splitting. > > This doesn't feel terribly important to fix for gcc-9, so I'm just > installing on the trunk. But backporting would be trivial and safe if > someone feels it's important enough to do so. > > This has been bootstrapped and regression tested on a variety of native > targets, it's also been tested to a lesser degree on the various *-elf > targets. > > Installing on the trunk momentarily. > >>> > >>> IMHO we should get rid of path splitting and try to integrate its > >>> transform > >>> with (backward) threading somehow. > >> BUt that wouldn't change the fundamental problem that we don't have a > >> good way to model costs/benefits. > > > > True. But here we seem to be adding more and more cases where we do > > _not_ want the transform to a pass initially having not a single case > > where we _do_ want it... :/ > Actually we do have cases in the testsuite which show examples of where > we do want it (from coremark IIRC). > > I don't think we've done much in here over the last couple years. I > think all I've done is add the half-diamond ifcvt check and the ternary > stuff this week. > > If I was to pick one thing to do it would be to reorganize the ifcvt > code a so that we could query it and use the results of that query to > throttle back path splitting. What we're doing in the path splitting > code to detect ifcvt opportunities is lame/bandaids. > > But I think we have bigger issues on our plate than this stuff :-) > > > > > > > >> What would be slick would be to create two loops, then do a final > >> selection on which to keep after if-conversion or something along those > >> lines. > > > > Of course this scheme quickly explodes it you apply it to more than one > > transform ;) > Of course. Note that the ability to query and filter out ifcvt > opportunities would cut down on the potential explosion here too. > > > > > For optimizations like loop unrolling or jump threading I've always > > wanted to use the > > --params we have to limit growth and simply do "code generation" of the > > paths > > with doing VN on the fly, simply stopping after those N instructions. > Yea. Or some kind of explore code generation approaches and prune. But > that feels all pie in the sky to me. True ;) I hope to have some time experimenting with this for unrolling though. Richard. > > Jeff
[PATCH] Error only when -mabi=ms is used on a non-MS_ABI system (PR sanitizer/90312).
Hi.
As mentioned in the PR, we should not provide an error on mingw and cygwin
targets.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-05-02 Martin Liska
PR sanitizer/90312
* config/i386/i386.c (ix86_option_override_internal): Error only
when DEFAULT_ABI != MS_ABI.
gcc/testsuite/ChangeLog:
2019-05-02 Martin Liska
PR sanitizer/90312
* gcc.dg/asan/pr87930.c: Run the test only on *linux or *gnu
systems.
* gcc.dg/tsan/pr88017.c: Likewise.
---
gcc/config/i386/i386.c | 11 ---
gcc/testsuite/gcc.dg/asan/pr87930.c | 2 +-
gcc/testsuite/gcc.dg/tsan/pr88017.c | 2 +-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index bc2348c3bc7..ad6357fab2c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3706,11 +3706,16 @@ ix86_option_override_internal (bool main_args_p,
error ("%<-mabi=ms%> not supported with X32 ABI");
gcc_assert (opts->x_ix86_abi == SYSV_ABI || opts->x_ix86_abi == MS_ABI);
- if ((opts->x_flag_sanitize & SANITIZE_USER_ADDRESS) && opts->x_ix86_abi == MS_ABI)
+ if ((opts->x_flag_sanitize & SANITIZE_USER_ADDRESS)
+ && opts->x_ix86_abi == MS_ABI
+ && DEFAULT_ABI != MS_ABI)
error ("%<-mabi=ms%> not supported with %<-fsanitize=address%>");
- if ((opts->x_flag_sanitize & SANITIZE_KERNEL_ADDRESS) && opts->x_ix86_abi == MS_ABI)
+ if ((opts->x_flag_sanitize & SANITIZE_KERNEL_ADDRESS)
+ && opts->x_ix86_abi == MS_ABI
+ && DEFAULT_ABI != MS_ABI)
error ("%<-mabi=ms%> not supported with %<-fsanitize=kernel-address%>");
- if ((opts->x_flag_sanitize & SANITIZE_THREAD) && opts->x_ix86_abi == MS_ABI)
+ if ((opts->x_flag_sanitize & SANITIZE_THREAD) && opts->x_ix86_abi == MS_ABI
+ && DEFAULT_ABI != MS_ABI)
error ("%<-mabi=ms%> not supported with %<-fsanitize=thread%>");
/* For targets using ms ABI enable ms-extensions, if not
diff --git a/gcc/testsuite/gcc.dg/asan/pr87930.c b/gcc/testsuite/gcc.dg/asan/pr87930.c
index 4f8e6999fde..5a65d3fb030 100644
--- a/gcc/testsuite/gcc.dg/asan/pr87930.c
+++ b/gcc/testsuite/gcc.dg/asan/pr87930.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
+/* { dg-do compile { target { { i?86-*-linux* i?86-*-gnu* x86_64-*-linux* } && lp64 } } } */
/* { dg-options "-fsanitize=address -mabi=ms" } */
int i;
diff --git a/gcc/testsuite/gcc.dg/tsan/pr88017.c b/gcc/testsuite/gcc.dg/tsan/pr88017.c
index 82693a67e87..10df2818b0d 100644
--- a/gcc/testsuite/gcc.dg/tsan/pr88017.c
+++ b/gcc/testsuite/gcc.dg/tsan/pr88017.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
+/* { dg-do compile { target { { i?86-*-linux* i?86-*-gnu* x86_64-*-linux* } && lp64 } } } */
/* { dg-options "-fsanitize=thread -mabi=ms" } */
int i;
Re: [committed] [PR tree-optimization/88797] Thottle back path splitting in another case where it'll inhibit if-conversion
On 5/2/19 7:23 AM, Richard Biener wrote: > On Thu, May 2, 2019 at 3:17 PM Jeff Law wrote: >> >> On 5/2/19 6:22 AM, Richard Biener wrote: >>> On Wed, May 1, 2019 at 7:32 PM Jeff Law wrote: This fixes pr88797 by avoiding path splitting when we've got a candidate, but the PHI feeds a conditional in the join block. ie: # iftmp.0_11 = PHI <(3), 1112(4)> [ ... ] _14 = iftmp.0_11 > x_17; These are more likely going to be if-conversion candidates and if-conversion is generally more profitable than path splitting. This doesn't feel terribly important to fix for gcc-9, so I'm just installing on the trunk. But backporting would be trivial and safe if someone feels it's important enough to do so. This has been bootstrapped and regression tested on a variety of native targets, it's also been tested to a lesser degree on the various *-elf targets. Installing on the trunk momentarily. >>> >>> IMHO we should get rid of path splitting and try to integrate its transform >>> with (backward) threading somehow. >> BUt that wouldn't change the fundamental problem that we don't have a >> good way to model costs/benefits. > > True. But here we seem to be adding more and more cases where we do > _not_ want the transform to a pass initially having not a single case > where we _do_ want it... :/ Actually we do have cases in the testsuite which show examples of where we do want it (from coremark IIRC). I don't think we've done much in here over the last couple years. I think all I've done is add the half-diamond ifcvt check and the ternary stuff this week. If I was to pick one thing to do it would be to reorganize the ifcvt code a so that we could query it and use the results of that query to throttle back path splitting. What we're doing in the path splitting code to detect ifcvt opportunities is lame/bandaids. But I think we have bigger issues on our plate than this stuff :-) > >> What would be slick would be to create two loops, then do a final >> selection on which to keep after if-conversion or something along those >> lines. > > Of course this scheme quickly explodes it you apply it to more than one > transform ;) Of course. Note that the ability to query and filter out ifcvt opportunities would cut down on the potential explosion here too. > > For optimizations like loop unrolling or jump threading I've always > wanted to use the > --params we have to limit growth and simply do "code generation" of the paths > with doing VN on the fly, simply stopping after those N instructions. Yea. Or some kind of explore code generation approaches and prune. But that feels all pie in the sky to me. Jeff
[PATCH, Darwin, committed] Fix regressed instantiate2
This test regressed when we fixed Darwin to follow the standard ABI and I
missed to commit the change at the time.
backports to 9,8,7 pending re-opening of 9.
The fix is to remove Darwin’s special-casing thus.
thanks
Iain
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 270800)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2019-05-02 Iain Sandoe
+
+ * g++.dg/ext/instantiate2.C: Remove special-casing for Darwin.
+
2019-05-02 Richard Biener
PR tree-optimization/89653
Index: gcc/testsuite/g++.dg/ext/instantiate2.C
===
--- gcc/testsuite/g++.dg/ext/instantiate2.C (revision 270800)
+++ gcc/testsuite/g++.dg/ext/instantiate2.C (working copy)
@@ -8,8 +8,7 @@
template T A::t = 0;
static template struct A;
-// { dg-final { scan-assembler "\n_?_ZN1AIiE1tE(:|\n|\t)" { target { !
*-*-darwin* } } } }
-// { dg-final { scan-assembler ".zerofill __DATA,__pu_bss2,__ZN1AIiE1tE" {
target *-*-darwin* } } }
+// { dg-final { scan-assembler "\n_?_ZN1AIiE1tE(:|\n|\t)" } }
void test_int() { A::t = 42; }
// { dg-final { scan-assembler-not "\n_?_ZN1AIcE1tE(:|\n|\t)" } }
Re: V5 [PATCH] Optimize vector constructor
On Thu, May 2, 2019 at 4:54 PM Richard Biener
wrote:
>
> On Mon, Mar 11, 2019 at 8:03 AM H.J. Lu wrote:
> >
> > On Fri, Mar 8, 2019 at 7:03 PM Richard Biener
> > wrote:
> > >
> > > On Fri, Mar 8, 2019 at 9:49 AM H.J. Lu wrote:
> > > >
> > > > On Thu, Mar 7, 2019 at 9:51 AM H.J. Lu wrote:
> > > > >
> > > > > On Wed, Mar 6, 2019 at 8:33 PM Richard Biener
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu wrote:
> > > > > > >
> > > > > > > On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, Mar 04, 2019 at 12:55:04PM +0100, Richard Biener wrote:
> > > > > > > > > On Sun, Mar 3, 2019 at 10:13 PM H.J. Lu
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Sun, Mar 03, 2019 at 06:40:09AM -0800, Andrew Pinski
> > > > > > > > > > wrote:
> > > > > > > > > > > )
> > > > > > > > > > > ,On Sun, Mar 3, 2019 at 6:32 AM H.J. Lu
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > For vector init constructor:
> > > > > > > > > > > >
> > > > > > > > > > > > ---
> > > > > > > > > > > > typedef float __v4sf __attribute__ ((__vector_size__
> > > > > > > > > > > > (16)));
> > > > > > > > > > > >
> > > > > > > > > > > > __v4sf
> > > > > > > > > > > > foo (__v4sf x, float f)
> > > > > > > > > > > > {
> > > > > > > > > > > > __v4sf y = { f, x[1], x[2], x[3] };
> > > > > > > > > > > > return y;
> > > > > > > > > > > > }
> > > > > > > > > > > > ---
> > > > > > > > > > > >
> > > > > > > > > > > > we can optimize vector init constructor with vector
> > > > > > > > > > > > copy or permute
> > > > > > > > > > > > followed by a single scalar insert:
> > > > > > > >
> > > > > > > > > and you want to advance to the _1 = BIT_INSERT_EXPR here.
> > > > > > > > > The easiest way
> > > > > > > > > is to emit a new stmt for _2 = copy ...; and do the set_rhs
> > > > > > > > > with the
> > > > > > > > > BIT_INSERT_EXPR.
> > > > > > > >
> > > > > > > > Thanks for BIT_INSERT_EXPR suggestion. I am testing this patch.
> > > > > > > >
> > > > > > > >
> > > > > > > > H.J.
> > > > > > > > ---
> > > > > > > > We can optimize vector constructor with vector copy or permute
> > > > > > > > followed
> > > > > > > > by a single scalar insert:
> > > > > > > >
> > > > > > > > __v4sf y;
> > > > > > > > __v4sf D.1930;
> > > > > > > > float _1;
> > > > > > > > float _2;
> > > > > > > > float _3;
> > > > > > > >
> > > > > > > >:
> > > > > > > > _1 = BIT_FIELD_REF ;
> > > > > > > > _2 = BIT_FIELD_REF ;
> > > > > > > > _3 = BIT_FIELD_REF ;
> > > > > > > > y_6 = {f_5(D), _3, _2, _1};
> > > > > > > > return y_6;
> > > > > > > >
> > > > > > > > with
> > > > > > > >
> > > > > > > > __v4sf y;
> > > > > > > > __v4sf D.1930;
> > > > > > > > float _1;
> > > > > > > > float _2;
> > > > > > > > float _3;
> > > > > > > > vector(4) float _8;
> > > > > > > >
> > > > > > > >:
> > > > > > > > _1 = BIT_FIELD_REF ;
> > > > > > > > _2 = BIT_FIELD_REF ;
> > > > > > > > _3 = BIT_FIELD_REF ;
> > > > > > > > _8 = x_9(D);
> > > > > > > > y_6 = BIT_INSERT_EXPR ;
> > > > > > > > return y_6;
> > > > > > > >
> > > > > > > > gcc/
> > > > > > > >
> > > > > > > > PR tree-optimization/88828
> > > > > > > > * tree-ssa-forwprop.c (simplify_vector_constructor):
> > > > > > > > Optimize
> > > > > > > > vector init constructor with vector copy or permute
> > > > > > > > followed
> > > > > > > > by a single scalar insert.
> > > > > > > >
> > > > > > > > gcc/testsuite/
> > > > > > > >
> > > > > > > > PR tree-optimization/88828
> > > > > > > > * gcc.target/i386/pr88828-1a.c: New test.
> > > > > > > > * gcc.target/i386/pr88828-2b.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-2.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-3a.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-3b.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-3c.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-3d.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-4a.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-4b.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-5a.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-5b.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-6a.c: Likewise.
> > > > > > > > * gcc.target/i386/pr88828-6b.c: Likewise.
> > > > > > >
> > > > > > > Here is the updated patch with run-time tests.
> > > > > >
> > > > > > - if (TREE_CODE (elt->value) != SSA_NAME)
> > > > > > + if (TREE_CODE (ce->value) != SSA_NAME)
> > > > > > return false;
> > > > > >
> > > > > > hmm, so it doesn't allow { 0, v[1], v[2], v[3] }? I think the
> > > > > > single
> > > > > > scalar value can be a constant as well.
> > > > >
> > > > > Fixed.
> > > > >
> > > > > >if (!def_stmt)
> > > > > > - return false;
> > > > > > +
Re: V5 [PATCH] Optimize vector constructor
On Mon, Mar 11, 2019 at 8:03 AM H.J. Lu wrote:
>
> On Fri, Mar 8, 2019 at 7:03 PM Richard Biener
> wrote:
> >
> > On Fri, Mar 8, 2019 at 9:49 AM H.J. Lu wrote:
> > >
> > > On Thu, Mar 7, 2019 at 9:51 AM H.J. Lu wrote:
> > > >
> > > > On Wed, Mar 6, 2019 at 8:33 PM Richard Biener
> > > > wrote:
> > > > >
> > > > > On Wed, Mar 6, 2019 at 8:46 AM H.J. Lu wrote:
> > > > > >
> > > > > > On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu wrote:
> > > > > > >
> > > > > > > On Mon, Mar 04, 2019 at 12:55:04PM +0100, Richard Biener wrote:
> > > > > > > > On Sun, Mar 3, 2019 at 10:13 PM H.J. Lu
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Mar 03, 2019 at 06:40:09AM -0800, Andrew Pinski wrote:
> > > > > > > > > > )
> > > > > > > > > > ,On Sun, Mar 3, 2019 at 6:32 AM H.J. Lu
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > For vector init constructor:
> > > > > > > > > > >
> > > > > > > > > > > ---
> > > > > > > > > > > typedef float __v4sf __attribute__ ((__vector_size__
> > > > > > > > > > > (16)));
> > > > > > > > > > >
> > > > > > > > > > > __v4sf
> > > > > > > > > > > foo (__v4sf x, float f)
> > > > > > > > > > > {
> > > > > > > > > > > __v4sf y = { f, x[1], x[2], x[3] };
> > > > > > > > > > > return y;
> > > > > > > > > > > }
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > > we can optimize vector init constructor with vector copy
> > > > > > > > > > > or permute
> > > > > > > > > > > followed by a single scalar insert:
> > > > > > >
> > > > > > > > and you want to advance to the _1 = BIT_INSERT_EXPR here. The
> > > > > > > > easiest way
> > > > > > > > is to emit a new stmt for _2 = copy ...; and do the set_rhs
> > > > > > > > with the
> > > > > > > > BIT_INSERT_EXPR.
> > > > > > >
> > > > > > > Thanks for BIT_INSERT_EXPR suggestion. I am testing this patch.
> > > > > > >
> > > > > > >
> > > > > > > H.J.
> > > > > > > ---
> > > > > > > We can optimize vector constructor with vector copy or permute
> > > > > > > followed
> > > > > > > by a single scalar insert:
> > > > > > >
> > > > > > > __v4sf y;
> > > > > > > __v4sf D.1930;
> > > > > > > float _1;
> > > > > > > float _2;
> > > > > > > float _3;
> > > > > > >
> > > > > > >:
> > > > > > > _1 = BIT_FIELD_REF ;
> > > > > > > _2 = BIT_FIELD_REF ;
> > > > > > > _3 = BIT_FIELD_REF ;
> > > > > > > y_6 = {f_5(D), _3, _2, _1};
> > > > > > > return y_6;
> > > > > > >
> > > > > > > with
> > > > > > >
> > > > > > > __v4sf y;
> > > > > > > __v4sf D.1930;
> > > > > > > float _1;
> > > > > > > float _2;
> > > > > > > float _3;
> > > > > > > vector(4) float _8;
> > > > > > >
> > > > > > >:
> > > > > > > _1 = BIT_FIELD_REF ;
> > > > > > > _2 = BIT_FIELD_REF ;
> > > > > > > _3 = BIT_FIELD_REF ;
> > > > > > > _8 = x_9(D);
> > > > > > > y_6 = BIT_INSERT_EXPR ;
> > > > > > > return y_6;
> > > > > > >
> > > > > > > gcc/
> > > > > > >
> > > > > > > PR tree-optimization/88828
> > > > > > > * tree-ssa-forwprop.c (simplify_vector_constructor):
> > > > > > > Optimize
> > > > > > > vector init constructor with vector copy or permute
> > > > > > > followed
> > > > > > > by a single scalar insert.
> > > > > > >
> > > > > > > gcc/testsuite/
> > > > > > >
> > > > > > > PR tree-optimization/88828
> > > > > > > * gcc.target/i386/pr88828-1a.c: New test.
> > > > > > > * gcc.target/i386/pr88828-2b.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-2.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-3a.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-3b.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-3c.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-3d.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-4a.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-4b.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-5a.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-5b.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-6a.c: Likewise.
> > > > > > > * gcc.target/i386/pr88828-6b.c: Likewise.
> > > > > >
> > > > > > Here is the updated patch with run-time tests.
> > > > >
> > > > > - if (TREE_CODE (elt->value) != SSA_NAME)
> > > > > + if (TREE_CODE (ce->value) != SSA_NAME)
> > > > > return false;
> > > > >
> > > > > hmm, so it doesn't allow { 0, v[1], v[2], v[3] }? I think the single
> > > > > scalar value can be a constant as well.
> > > >
> > > > Fixed.
> > > >
> > > > >if (!def_stmt)
> > > > > - return false;
> > > > > + {
> > > > > + if (gimple_nop_p (SSA_NAME_DEF_STMT (ce->value)))
> > > > >
> > > > > if (SSA_NAME_IS_DEFAULT_DEF (ce->value))
> > > > >
> > > > > + {
> > > > >
> > > > > also you seem to disallow
> > > > >
> > > > > { i + 1, v[1], v[2], v[3] }
> > > >
> > > > Fixed by
> > > >
> > > > if (code != BIT_FIELD_REF)
> > > > {
>
Re: [PATCH] Fix PR89653
On Mon, Mar 11, 2019 at 12:39 PM Richard Biener wrote:
>
>
> The following fixes a missed vectorization of std::min() when
> only one argument is a temporary. The following patch is the least
> intrusive and safest one - PRE already performs the necessary
> work to make this vectorizable, it's just that we end up with
> a dead store and clobber of a stack-local that the vectorizer is
> not happy about. The easiest fix is to schedule an update-address-taken
> phase at the right spot which rewrites it into SSA and then DCE
> can get rid of it. DSE would also do the job but is more expensive.
> Since PRE/VN have the chance to expose things that can be written
> into SSA doing so before loop opts sounds like a good idea in any case.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> Queued for GCC 10 for which I also have a fix for phiprop which
> usually deals with std::min/max if-conversion. The one below
> is quite safe but it's not a regression unfortunately.
Applied as r270800.
Richard.
> Richard.
>
> 2019-03-11 Richard Biener
>
> 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.
>
> Index: gcc/tree-ssa-loop.c
> ===
> --- gcc/tree-ssa-loop.c (revision 269569)
> +++ gcc/tree-ssa-loop.c (working copy)
> @@ -330,7 +330,7 @@ const pass_data pass_data_tree_loop_init
>PROP_cfg, /* properties_required */
>0, /* properties_provided */
>0, /* properties_destroyed */
> - 0, /* todo_flags_start */
> + TODO_update_address_taken, /* todo_flags_start */
>0, /* todo_flags_finish */
> };
>
> Index: gcc/passes.def
> ===
> --- gcc/passes.def (revision 269569)
> +++ gcc/passes.def (working copy)
> @@ -261,6 +261,8 @@ along with GCC; see the file COPYING3.
>NEXT_PASS (pass_fix_loops);
>NEXT_PASS (pass_tree_loop);
>PUSH_INSERT_PASSES_WITHIN (pass_tree_loop)
> + /* Before loop_init we rewrite no longer addressed locals into SSA
> +form if possible. */
> NEXT_PASS (pass_tree_loop_init);
> NEXT_PASS (pass_tree_unswitch);
> NEXT_PASS (pass_scev_cprop);
> Index: gcc/testsuite/g++.dg/vect/pr89653.cc
> ===
> --- gcc/testsuite/g++.dg/vect/pr89653.cc(nonexistent)
> +++ gcc/testsuite/g++.dg/vect/pr89653.cc(working copy)
> @@ -0,0 +1,12 @@
> +// { dg-do compile }
> +// { dg-require-effective-target vect_double }
> +
> +#include
> +
> +void loop1(double * const __restrict__ vec, double x, int end)
> +{
> + for (int i = 0; i < end; ++i)
> +vec[i] = std::min(vec[i], vec[i]/x);
> +}
> +
> +// { dg-final { scan-tree-dump "vectorized 1 loops" "vect" } }
[PATCH] Fix PR89509
The following fixes PR89509.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-05-02 Richard Biener
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.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 269212)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -7572,9 +7572,12 @@ compute_dependence_clique (void)
EXECUTE_IF_SET_IN_BITMAP (vi->solution, 0, j, bi)
{
varinfo_t oi = get_varinfo (j);
+ if (oi->head != j)
+ oi = get_varinfo (oi->head);
if (oi->is_restrict_var)
{
- if (restrict_var)
+ if (restrict_var
+ && restrict_var != oi)
{
if (dump_file && (dump_flags & TDF_DETAILS))
{
Index: gcc/testsuite/gcc.dg/torture/restrict-8.c
===
--- gcc/testsuite/gcc.dg/torture/restrict-8.c (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/restrict-8.c (working copy)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
+/* { dg-options "-fdump-tree-fre1" } */
+
+struct S { int i; void *p; int j; };
+int
+foo (struct S * __restrict p, int *q, int flag)
+{
+ int *x = &p->j;
+ if (flag)
+x = &p->i;
+ *q = 1;
+ *x = 2;
+ return *q;
+}
+
+/* { dg-final { scan-tree-dump "return 1;" "fre1" } } */
Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime
Hi Jakub!
I'm currently working on other pending OpenACC 'deviceptr' clause patches
from our backlog, and I noticed the following, which I don't understand.
You reviewed and approved this patch, could you please help?
On Tue, 19 Jun 2018 10:01:20 -0700, Cesar Philippidis
wrote:
> --- a/libgomp/oacc-parallel.c
> +++ b/libgomp/oacc-parallel.c
> +/* Handle the mapping pair that are presented when a
> + deviceptr clause is used with Fortran. */
> +
> +static void
> +handle_ftn_pointers (size_t mapnum, void **hostaddrs, size_t *sizes,
> + unsigned short *kinds)
> +{
> + int i;
> +
> + for (i = 0; i < mapnum; i++)
> +{
> + unsigned short kind1 = kinds[i] & 0xff;
> +
> + /* Handle Fortran deviceptr clause. */
> + if (kind1 == GOMP_MAP_FORCE_DEVICEPTR)
> + {
> + unsigned short kind2;
> +
> + if (i < (signed)mapnum - 1)
> + kind2 = kinds[i + 1] & 0xff;
> + else
> + kind2 = 0x;
> +
> + if (sizes[i] == sizeof (void *))
> + continue;
> +
> + /* At this point, we're dealing with a Fortran deviceptr.
> + If the next element is not what we're expecting, then
> + this is an instance of where the deviceptr variable was
> + not used within the region and the pointer was removed
> + by the gimplifier. */
> + if (kind2 == GOMP_MAP_POINTER
> + && sizes[i + 1] == 0
> + && hostaddrs[i] == *(void **)hostaddrs[i + 1])
> + {
> + kinds[i+1] = kinds[i];
> + sizes[i+1] = sizeof (void *);
> + }
> +
> + /* Invalidate the entry. */
> + hostaddrs[i] = NULL;
> + }
> +}
> }
This is used for rewriting the mappings for OpenACC 'parallel'
etc. constructs:
> @@ -88,6 +141,8 @@ GOACC_parallel_keyed (int device, void (*fn) (void *),
>thr = goacc_thread ();
>acc_dev = thr->dev;
>
> + handle_ftn_pointers (mapnum, hostaddrs, sizes, kinds);
> +
>/* Host fallback if "if" clause is false or if the current device is set to
> the host. */
>if (host_fallback)
..., and on our OpenACC development branch likewise for OpenACC 'data'
constructs ('GOACC_data_start').
What this function seems to be doing, as I understand this, is that when
there is an 'GOMP_MAP_FORCE_DEVICEPTR' with a size not eqal to pointer
size (which should never happen, as per the information given
'include/gomp-constants.h'?), which is followed by a 'GOMP_MAP_POINTER',
then preserve the 'GOMP_MAP_FORCE_DEVICEPTR' (by storing it into the slot
of the 'GOMP_MAP_POINTER'), and unconditionally remove the
'GOMP_MAP_POINTER'. This seems like a strange choice of a GCC/libgomp
ABI to me -- or am I not understanding this correctly?
Instead of rewriting the mappings at run time, why isn't (presumably) the
gimplifier changed to just emit the correct mappings?
Grüße
Thomas
signature.asc
Description: PGP signature
Re: [PATCH] PR85574 - add gcc/lto$(exeext) to files compared
On Thu, Jan 3, 2019 at 3:16 PM Richard Biener wrote:
>
>
> This makes sure we do not regress PR85574 and thus that when
> doing LTO bootstrap the generated binaries do not differ from
> stage2 to stage3. Note we indepenently verify the object
> files which contain just LTO bytecode do not differ (besides
> differences in the LTO options sections).
>
> This has the chance of breaking on some targets given we've
> never compared binaries before but just object files.
>
> Still it's an invariant we'd like to hold, so hopefully it
> works out.
>
> Bootstrapped on x86_64-unknown-linux-gnu, LTO bootstrapped on
> x86_64-unknown-linux-gnu.
>
> OK for trunk?
Now committed as r270798 after LTO bootstrap on x86_64-linux.
Richard.
>
> Note I picked just gcc/lto1 as a binary that will surely be
> available when doing LTO bootstrap rather than also compare
> all $(exeext) found in stageN-gcc/ (build/gen* are for example
> also LTO compiled). The explicit list could also be amended
> of course.
>
> Thanks,
> Richard.
>
> 2019-01-03 Richard Biener
>
> PR bootstrap/85574
> * Makefile.tpl (compare target): Also compare extra-compare
> files.
> * Makefile.in: Regenerate.
>
> config/
> * bootstrap-lto.mk (extra-compare): Set to gcc/lto1$(exeext).
>
> Index: Makefile.in
> ===
> --- Makefile.in (revision 267551)
> +++ Makefile.in (working copy)
> @@ -53850,7 +53850,7 @@ compare:
> sed=`echo stage3 | sed 's,^stage,,;s,.,.,g'`; \
> files=`find stage3-* -name "*$(objext)" -print | \
> sed -n s,^stage$$sed-,,p`; \
> - for file in $${files}; do \
> + for file in $${files} ${extra-compare}; do \
> f1=$$r/stage2-$$file; f2=$$r/stage3-$$file; \
> if test ! -f $$f1; then continue; fi; \
> $(do-compare) > /dev/null 2>&1; \
> @@ -54248,7 +54248,7 @@ compare3:
> sed=`echo stage4 | sed 's,^stage,,;s,.,.,g'`; \
> files=`find stage4-* -name "*$(objext)" -print | \
> sed -n s,^stage$$sed-,,p`; \
> - for file in $${files}; do \
> + for file in $${files} ${extra-compare}; do \
> f1=$$r/stage3-$$file; f2=$$r/stage4-$$file; \
> if test ! -f $$f1; then continue; fi; \
> $(do-compare3) > /dev/null 2>&1; \
> Index: Makefile.tpl
> ===
> --- Makefile.tpl(revision 267551)
> +++ Makefile.tpl(working copy)
> @@ -1675,7 +1675,7 @@ do-clean: clean-stage[+id+]
> sed=`echo stage[+id+] | sed 's,^stage,,;s,.,.,g'`; \
> files=`find stage[+id+]-* -name "*$(objext)" -print | \
> sed -n s,^stage$$sed-,,p`; \
> - for file in $${files}; do \
> + for file in $${files} ${extra-compare}; do \
> f1=$$r/stage[+prev+]-$$file; f2=$$r/stage[+id+]-$$file; \
> if test ! -f $$f1; then continue; fi; \
> $(do-[+compare-target+]) > /dev/null 2>&1; \
> Index: config/bootstrap-lto.mk
> ===
> --- config/bootstrap-lto.mk (revision 267551)
> +++ config/bootstrap-lto.mk (working copy)
> @@ -15,3 +15,4 @@ LTO_EXPORTS = AR="$(LTO_AR)"; export AR;
> LTO_FLAGS_TO_PASS = AR="$(LTO_AR)" RANLIB="$(LTO_RANLIB)"
>
> do-compare = $(SHELL) $(srcdir)/contrib/compare-lto $$f1 $$f2
> +extra-compare = gcc/lto1$(exeext)
[PATCH, Darwin, committed] Fix some regressed rests.
Hi,
This fixes three tests that regressed because the regex wasn’t flexible enough
to cope with codegen changes.
Will backport once 9 opens.
thanks
Iain
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 270796)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2019-05-02 Iain Sandoe
+
+ * gcc.dg/tree-prof/section-attr-1.c: Update scan-asm regex
+ for cold section label.
+ * gcc.dg/tree-prof/section-attr-2.c: Likewise.
+ * gcc.dg/tree-prof/section-attr-3.c: Likewise.
+
2019-05-02 Rainer Orth
* gcc.target/i386/spellcheck-options-5.c: Restrict to Linux and
Index: gcc/testsuite/gcc.dg/tree-prof/section-attr-1.c
===
--- gcc/testsuite/gcc.dg/tree-prof/section-attr-1.c (revision 270796)
+++ gcc/testsuite/gcc.dg/tree-prof/section-attr-1.c (working copy)
@@ -47,4 +47,4 @@
}
/* { dg-final-use { scan-assembler "\.section\[\t
\]*\.text\.unlikely\[\\n\\r\]+\[\t \]*\.size\[\t \]*foo\.cold" { target
*-*-linux* *-*-gnu* } } } */
-/* { dg-final-use { scan-assembler "\.section\[\t
\]*__TEXT,__text_cold\*\[\\n\\r\]+_foo\.cold" { target *-*-darwin* } } } */
+/* { dg-final-use { scan-assembler {.section[\t
]*__TEXT,__text_cold[^\n]*[\n\r]+_foo.cold:} { target *-*-darwin* } } } */
Index: gcc/testsuite/gcc.dg/tree-prof/section-attr-2.c
===
--- gcc/testsuite/gcc.dg/tree-prof/section-attr-2.c (revision 270796)
+++ gcc/testsuite/gcc.dg/tree-prof/section-attr-2.c (working copy)
@@ -46,4 +46,4 @@
}
/* { dg-final-use { scan-assembler "\.section\[\t
\]*\.text\.unlikely\[\\n\\r\]+\[\t \]*\.size\[\t \]*foo\.cold" { target
*-*-linux* *-*-gnu* } } } */
-/* { dg-final-use { scan-assembler "\.section\[\t
\]*__TEXT,__text_cold\*\[\\n\\r\]+_foo\.cold:" { target *-*-darwin* } } } */
+/* { dg-final-use { scan-assembler {.section[\t
]*__TEXT,__text_cold[^\n]*[\n\r]+_foo.cold:} { target *-*-darwin* } } } */
Index: gcc/testsuite/gcc.dg/tree-prof/section-attr-3.c
===
--- gcc/testsuite/gcc.dg/tree-prof/section-attr-3.c (revision 270796)
+++ gcc/testsuite/gcc.dg/tree-prof/section-attr-3.c (working copy)
@@ -47,4 +47,4 @@
}
/* { dg-final-use { scan-assembler "\.section\[\t
\]*\.text\.unlikely\[\\n\\r\]+\[\t \]*\.size\[\t \]*foo\.cold" { target
*-*-linux* *-*-gnu* } } } */
-/* { dg-final-use { scan-assembler "\.section\[\t
\]*__TEXT,__text_cold\*\[\\n\\r\]+_foo\.cold:" { target *-*-darwin* } } } */
+/* { dg-final-use { scan-assembler {.section[\t
]*__TEXT,__text_cold[^\n]*[\n\r]+_foo.cold:} { target *-*-darwin* } } } */
Re: [testsuite, i386] Restrict gcc.target/i386/spellcheck-options-5.c to Linux targets
On Thu, May 02, 2019 at 03:25:33PM +0200, Rainer Orth wrote:
> The new gcc.target/i386/spellcheck-options-5.c testcase FAILs on all
> non-Linux targets (seen on i386-pc-solaris2.11, but there are also
> gcc-testresults reports for freebsd and darwin):
>
> +FAIL: gcc.target/i386/spellcheck-options-5.c (test for errors, line )
> +FAIL: gcc.target/i386/spellcheck-options-5.c (test for excess errors)
>
> This happens for both 32 and 64-bit on trunk and gcc-9 branch.
>
> Excess errors:
> xgcc: error: unrecognized command line option '-mandroidX'
>
> That option is only defined in linux-android.h, and the only x86 targets
> including that file according to config.gcc are
>
> i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-gnu* |
> i[34567]86-*-kopensolaris*-gnu
> x86_64-*-linux* | x86_64-*-kfreebsd*-gnu
>
> So it seems natural to restrict the test to *-*-linux* and *-*-gnu*
> targets, which is what the following patch does.
>
> Tested on i386-pc-solaris2.11 (where it now comes up UNSUPPORTED) and
> x86_64-pc-linux-gnu (where it still PASSes) on the gcc-9 branch.
>
> Ok for mainline and gcc-9 branch?
> 2019-05-02 Rainer Orth
>
> * gcc.target/i386/spellcheck-options-5.c: Restrict to Linux and
> GNU targets.
Ok, thanks.
> --- a/gcc/testsuite/gcc.target/i386/spellcheck-options-5.c
> +++ b/gcc/testsuite/gcc.target/i386/spellcheck-options-5.c
> @@ -1,5 +1,5 @@
> /* PR middle-end/90258. */
>
> -/* { dg-do compile } */
> +/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
> /* { dg-options "-mandroidX" } */
> /* { dg-error "unrecognized command line option '-mandroidX'; did you mean
> '-mandroid'" "" { target *-*-* } 0 } */
Jakub
[testsuite, i386] Restrict gcc.target/i386/spellcheck-options-5.c to Linux targets
The new gcc.target/i386/spellcheck-options-5.c testcase FAILs on all
non-Linux targets (seen on i386-pc-solaris2.11, but there are also
gcc-testresults reports for freebsd and darwin):
+FAIL: gcc.target/i386/spellcheck-options-5.c (test for errors, line )
+FAIL: gcc.target/i386/spellcheck-options-5.c (test for excess errors)
This happens for both 32 and 64-bit on trunk and gcc-9 branch.
Excess errors:
xgcc: error: unrecognized command line option '-mandroidX'
That option is only defined in linux-android.h, and the only x86 targets
including that file according to config.gcc are
i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-gnu* |
i[34567]86-*-kopensolaris*-gnu
x86_64-*-linux* | x86_64-*-kfreebsd*-gnu
So it seems natural to restrict the test to *-*-linux* and *-*-gnu*
targets, which is what the following patch does.
Tested on i386-pc-solaris2.11 (where it now comes up UNSUPPORTED) and
x86_64-pc-linux-gnu (where it still PASSes) on the gcc-9 branch.
Ok for mainline and gcc-9 branch?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2019-05-02 Rainer Orth
* gcc.target/i386/spellcheck-options-5.c: Restrict to Linux and
GNU targets.
# HG changeset patch
# Parent 3c0a67b376bc087a5e7088ec27a543bb94d9f4fb
Restrict gcc.target/i386/spellcheck-options-5.c to Linux targets
diff --git a/gcc/testsuite/gcc.target/i386/spellcheck-options-5.c b/gcc/testsuite/gcc.target/i386/spellcheck-options-5.c
--- a/gcc/testsuite/gcc.target/i386/spellcheck-options-5.c
+++ b/gcc/testsuite/gcc.target/i386/spellcheck-options-5.c
@@ -1,5 +1,5 @@
/* PR middle-end/90258. */
-/* { dg-do compile } */
+/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
/* { dg-options "-mandroidX" } */
/* { dg-error "unrecognized command line option '-mandroidX'; did you mean '-mandroid'" "" { target *-*-* } 0 } */
Re: [committed] [PR tree-optimization/88797] Thottle back path splitting in another case where it'll inhibit if-conversion
On Thu, May 2, 2019 at 3:17 PM Jeff Law wrote: > > On 5/2/19 6:22 AM, Richard Biener wrote: > > On Wed, May 1, 2019 at 7:32 PM Jeff Law wrote: > >> > >> > >> This fixes pr88797 by avoiding path splitting when we've got a > >> candidate, but the PHI feeds a conditional in the join block. ie: > >> > >> # iftmp.0_11 = PHI <(3), 1112(4)> > >> [ ... ] > >> _14 = iftmp.0_11 > x_17; > >> > >> > >> These are more likely going to be if-conversion candidates and > >> if-conversion is generally more profitable than path splitting. > >> > >> This doesn't feel terribly important to fix for gcc-9, so I'm just > >> installing on the trunk. But backporting would be trivial and safe if > >> someone feels it's important enough to do so. > >> > >> This has been bootstrapped and regression tested on a variety of native > >> targets, it's also been tested to a lesser degree on the various *-elf > >> targets. > >> > >> Installing on the trunk momentarily. > > > > IMHO we should get rid of path splitting and try to integrate its transform > > with (backward) threading somehow. > BUt that wouldn't change the fundamental problem that we don't have a > good way to model costs/benefits. True. But here we seem to be adding more and more cases where we do _not_ want the transform to a pass initially having not a single case where we _do_ want it... :/ > What would be slick would be to create two loops, then do a final > selection on which to keep after if-conversion or something along those > lines. Of course this scheme quickly explodes it you apply it to more than one transform ;) For optimizations like loop unrolling or jump threading I've always wanted to use the --params we have to limit growth and simply do "code generation" of the paths with doing VN on the fly, simply stopping after those N instructions. That would make it constant time but allow possibly large paths to be handled if they simplify significantly. The main issue is context for the VN process for the path entry which is of course either not present (cheap) or expensive to compute. Richard. > jeff
Re: [RFH] split {generic,gimple}-match.c files
On Mon, 29 Apr 2019, Martin Liška wrote: > On 9/10/18 1:43 PM, Martin Liška wrote: > > On 09/04/2018 05:07 PM, Martin Liška wrote: > >> - in order to achieve real speed up we need to split also other generated > >> (and also dwarf2out.c, i386.c, ..) files: > >> here I'm most concerned about insn-recog.c, which can't be split the same > >> way without ending up with a single huge SCC component. > > > > About the insn-recog.c file: all functions are static and using SCC one ends > > up with all functions in one component. In order to split the callgraph one > > needs to promote some functions to be extern and then split would be > > possible. > > In order to do that we'll probably need to teach splitter how to do > > partitioning > > based on minimal number of edges to be removed. > > > > I need to inspire in lto_balanced_map, or is there some simple algorithm I > > can start with? > > > > Martin > > > > I'm adding here Richard Sandiford as he wrote majority of gcc/genrecog.c file. > As mentioned, I'm seeking for a way how to split the generated file. Or how > to learn the generator to process a reasonable splitting. Somewhen earlier this year I've done the experiment with using a compile with -flto -fno-fat-lto-objects and a link via -flto -r -flinker-output=rel into the object file. This cut compile-time more than in half with less maintainance overhead. Adding other files to this handling looks trivial as well, as well as conditionalizing it (I'd probably not want this for devel builds). It might be interesting to optimize this a bit as well by somehow merging the compile and WPA stages, thus special-casing single TU WPA input in a similar way as we (still) have -flto-partition=none. That said, re-doing the measurement is probably interesting (as applying to other cases like insn-recog.c). Richard.
Re: [committed] [PR tree-optimization/88797] Thottle back path splitting in another case where it'll inhibit if-conversion
On 5/2/19 6:22 AM, Richard Biener wrote: > On Wed, May 1, 2019 at 7:32 PM Jeff Law wrote: >> >> >> This fixes pr88797 by avoiding path splitting when we've got a >> candidate, but the PHI feeds a conditional in the join block. ie: >> >> # iftmp.0_11 = PHI <(3), 1112(4)> >> [ ... ] >> _14 = iftmp.0_11 > x_17; >> >> >> These are more likely going to be if-conversion candidates and >> if-conversion is generally more profitable than path splitting. >> >> This doesn't feel terribly important to fix for gcc-9, so I'm just >> installing on the trunk. But backporting would be trivial and safe if >> someone feels it's important enough to do so. >> >> This has been bootstrapped and regression tested on a variety of native >> targets, it's also been tested to a lesser degree on the various *-elf >> targets. >> >> Installing on the trunk momentarily. > > IMHO we should get rid of path splitting and try to integrate its transform > with (backward) threading somehow. BUt that wouldn't change the fundamental problem that we don't have a good way to model costs/benefits. What would be slick would be to create two loops, then do a final selection on which to keep after if-conversion or something along those lines. jeff
Re: [PATCH] Fix up gfor_cdir
On Thu, May 2, 2019 at 10:08 AM Jakub Jelinek wrote: > > Hi! > > On Wed, May 01, 2019 at 03:18:00PM -0400, Arvind Sankar wrote: > > Including Paul -- looks like the file gets installed in different places > > in fortran-dev branch vs trunk? > > I agree this is a bug on both sides, on the GCC side because installing the > header which is the same on all targets in different multilib subdirs > doesn't make any sense and is inconsistent with all other headers, on the > glibc side because broken assumptions that there is just one header > directory, there can be many. > > Let's just deal with the GCC side here. > > We intentionally do install finclude files into $(MULTISUBDIR)/finclude, > because those are architecture specific, but for C/C++ headers want > instead to use preprocessor conditionals if possible to deal with possible > differences between targets in a single file. > Examples from other GCC libraries: > grep 'dir = .*/f\?include' lib*/Makefile.am > libgomp/Makefile.am:fincludedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude > libgomp/Makefile.am:libsubincludedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)/include > libitm/Makefile.am:fincludedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude > libitm/Makefile.am:libsubincludedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)/include > liboffloadmic/Makefile.am:coi_inc_dir = $(top_srcdir)/include/coi > liboffloadmic/Makefile.am:libsubincludedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)/include > libquadmath/Makefile.am:libsubincludedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)/include > libsanitizer/Makefile.am:sanincludedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)/include/sanitizer > libssp/Makefile.am:libsubincludedir = > $(libdir)/gcc/$(target_noncanonical)/$(gcc_version)/include > libvtv/Makefile.am:libvtv_includedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)/include > No idea why libitm has fincludedir when it doesn't install any finclude > files. > > In the Fedora gcc 9 rpms, I'm including only the > 9/include/ISO_Fortran_binding.h header and not > 9/32/include/ISO_Fortran_binding.h > for quite some time and it works just fine. > > Ok for trunk/9.1? OK. Richard. > 2019-05-02 Jakub Jelinek > > * Makefile.am (gfor_cdir): Remove $(MULTISUBDIR). > * Makefile.in: Regenerated. > > --- libgfortran/Makefile.am.jj 2019-01-17 13:20:17.196206846 +0100 > +++ libgfortran/Makefile.am 2019-05-02 09:44:15.558608723 +0200 > @@ -31,7 +31,7 @@ version_dep = > endif > > gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h > -gfor_cdir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include > +gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include > > LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ > $(lt_host_flags) > --- libgfortran/Makefile.in.jj 2019-01-17 13:20:12.481283311 +0100 > +++ libgfortran/Makefile.in 2019-05-02 09:44:55.968959734 +0200 > @@ -717,7 +717,7 @@ gcc_version := $(shell @get_gcc_base_ver > @LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = > $(srcdir)/gfortran.map > @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = > gfortran.map-sun > gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h > -gfor_cdir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include > +gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include > LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ > $(lt_host_flags) > > > > Jakub
[C++ PATCH] remove unreachable code
Applying this patch to remove code that has become unreachable. We'll
already have bailed out if it was a NAMESPACE_DECL.
nathan
--
Nathan Sidwell
2019-05-02 Nathan Sidwell
* semantics.c (finish_id_expression_1): Remove unreachable code.
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c (revision 270791)
+++ gcc/cp/semantics.c (working copy)
@@ -3740,17 +3740,13 @@ finish_id_expression_1 (tree id_expressi
wrong, so just return the identifier. */
return id_expression;
- if (TREE_CODE (decl) == NAMESPACE_DECL)
- {
- error ("use of namespace %qD as expression", decl);
- return error_mark_node;
- }
- else if (DECL_CLASS_TEMPLATE_P (decl))
+ if (DECL_CLASS_TEMPLATE_P (decl))
{
error ("use of class template %qT as expression", decl);
return error_mark_node;
}
- else if (TREE_CODE (decl) == TREE_LIST)
+
+ if (TREE_CODE (decl) == TREE_LIST)
{
/* Ambiguous reference to base members. */
error ("request for member %qD is ambiguous in "
Re: [PATCH PR90240][RFC]Avoid scaling cost overflow by introducing scaling bound
On Tue, Apr 30, 2019 at 4:05 AM Bin.Cheng wrote:
>
> On Mon, Apr 29, 2019 at 8:01 PM Richard Biener
> wrote:
> >
> > On Sat, Apr 27, 2019 at 6:13 AM bin.cheng
> > wrote:
> > >
> > > Hi,
> > >
> > > This is the draft patch avoiding scaling cost overflow by introducing a
> > > scaling bound
> > > in IVOPTs. For now the bound is 20, and scaling factor will be further
> > > scaled wrto
> > > this bound. For example, scaling factor like 1, 1000, 2000(max) would be
> > > scaled to
> > > 1, 10, 20 correspondingly.
> > >
> > > HI Martin, I remember you introduced comp_cost/cost_scaling to improve
> > > one case
> > > in spec2017. Unfortunately I don't have access to the benchmark now,
> > > could you help
> > > verify that if this patch has performance issue on it please? Thanks
> > >
> > > Bootstrap and test on x86_64, and this is for further comment/discussion.
> >
> > + float factor = 1.0f * bfreq / lfreq;
> > + if (adjust_factor_p)
> > + {
> > + factor *= COST_SCALING_FACTOR_BOUND;
> > + factor = factor * lfreq / max_freq;
> > + }
> > + body[i]->aux = (void *)(intptr_t)(int) factor;
> >
> > float computations on the host shouldn't be done.
> >
> > I wonder if changing comp_cost::cost to int64_t would help instead? See
> > also my
> > suggestion to use gmp.
> It might be too heavy using gmp, I will try to change to int64_t which
> should be more than enough.
> >
> > Otherwise the approach looks sane to me - can we then even assert that
> > no overflows
> > happen and thus INFTY only appears if we manually set such cost?
> Yeah, this is feasible. Only we wouldn't detect INFTY overflow in
> release build using assert.
>
> BTW, I failed to create generic test for PR90240. The manually tiled
> loop nest doesn't trigger the issue as graphite does.
It probably requires a GIMPLE testcase with appropriate basic block counts
(GIMPLE FE support for that coming).
Richard.
> Thanks,
> bin
> >
> > Thanks,
> > Richard.
> >
> > > Thanks,
> > > bin
Re: [PATCH][stage1] Support profile (BB counts and edge probabilities) in GIMPLE FE.
On Mon, Apr 29, 2019 at 2:51 PM Martin Liška wrote:
>
> On 4/26/19 3:18 PM, Richard Biener wrote:
> > On Wed, Apr 10, 2019 at 10:12 AM Martin Liška wrote:
> >>
> >> On 4/9/19 3:19 PM, Jan Hubicka wrote:
> Hi.
>
> There's updated version that supports profile quality for both counts
> and probabilities. I'm wondering whether ENTRY and EXIT BBs needs to
> have set probability. Apparently, I haven't seen any verifier that
> would complain.
> >>>
> >>> Well, you do not need to define it but then several cases will
> >>> degenerate. In particular BB frequencies (for callgraph profile or
> >>> hot/cold decisions) are calculated as ratios of entry BB and given BB
> >>> count. If entry BB is undefined you will get those undefined and
> >>> heuristics will resort to conservative answers.
> >>>
> >>> I do not think we use exit block count.
> >>>
> >>> Honza
> >>>
> >>
> >> Thank you Honza for explanation. I'm sending version of the patch
> >> that supports entry BB count.
> >>
> >> I've been testing the patch right now.
> >
> > Can you move the GIMPLE/RTL FE specific data in c_declspecs to
> > a substructure accessed via indirection? I guess enlarging that
> > isn't really what we should do. You'd move gimple_or_rtl_pass
> > there and make that pointer one to a struct aux_fe_data
> > (lifetime managed by the respective RTL/GIMPLE FE, thus
> > to be freed there)? Joseph, do you agree or is adding more
> > stuff to c_declspecs OK (I would guess it could be a few more
> > elements in the future).
>
> Let's wait here for Joseph.
So looks like it won't matter so let's go with the current approach
for the moment.
> >
> > -c_parser_gimple_parse_bb_spec (tree val, int *index)
> > +c_parser_gimple_parse_bb_spec (tree val, gimple_parser &parser,
> > + int *index, profile_probability *probablity)
> > {
> >
> > so this will allow specifying probability in PHI node arguments.
> > I think we want to split this into the already existing part
> > and a c_parser_gimple_parse_bb_spec_with_edge_probability
> > to be used at edge sources.
>
> Yes, that's a good idea!
>
> >
> > + if (cfun->curr_properties & PROP_cfg)
> > +{
> > + update_max_bb_count ();
> > + set_hot_bb_threshold (hot_bb_threshold);
> > + ENTRY_BLOCK_PTR_FOR_FN (cfun)->count = entry_bb_count;
> >
> > I guess the last one should be before update_max_bb_count ()?
>
> Same here.
>
> >
> > +}
> >
> > + /* Parse profile: quality(value) */
> > else
> > {
> > - c_parser_error (parser, "unknown block specifier");
> > - return return_p;
> > + tree q;
> > + profile_quality quality;
> > + tree v = c_parser_peek_token (parser)->value;
> >
> > peek next token before the if/else and do
> >
> >else if (!strcmp (...))
> >
> > as in the loop_header case. I expected we can somehow share
> > parsing of profile quality and BB/edge count/frequency? How's
> > the expected syntax btw, comments in the code should tell us.
> > I'm guessing it's quality-id '(' number ')' and thus it should be
> > really shareable between edge and BB count and also __GIMPLE
> > header parsing? So parse_profile_quality should be
> > parse_profile () instead, resulting in a combined value
> > (we do use the same for edge/bb?).
>
> It's problematic, there are different error messages for count/frequency.
> Moreover call to parse_profile_quality in c_parser_gimple_or_rtl_pass_list
> is a way how to test that next 'token' is a profile count.
Who cares about error messages... But sure, I'm just proposing to
merge testing for next token and actual parsing.
> >
> > + else if (!strcmp (op, "hot_bb_threshold"))
> > + {
> >
> > I'm not sure about this - it doesn't make sense to specify this
> > on a per-function base since it seems to control a global
> > variable (booo!)?
>
> Yep, shame on me!
>
> > Isn't this instead computed on-demand
> > based on profile_info->sum_max?
>
> No it's a global value shared among functions.
>
> > If not then I think
> > we need an alternate way of funneling in global state into
> > the GIMPLE FE.
>
> What about --param gimple-fe-hot-bb-threshold ?
I thought about that, yes ... in absence can it actually be
"computed"?
Richard.
> Thanks,
> Martin
>
> >
> > Thanks,
> > Richard.
> >
> >
> >>
> >> Martin
>
Re: [committed] [PR tree-optimization/88797] Thottle back path splitting in another case where it'll inhibit if-conversion
On Wed, May 1, 2019 at 7:32 PM Jeff Law wrote: > > > This fixes pr88797 by avoiding path splitting when we've got a > candidate, but the PHI feeds a conditional in the join block. ie: > > # iftmp.0_11 = PHI <(3), 1112(4)> > [ ... ] > _14 = iftmp.0_11 > x_17; > > > These are more likely going to be if-conversion candidates and > if-conversion is generally more profitable than path splitting. > > This doesn't feel terribly important to fix for gcc-9, so I'm just > installing on the trunk. But backporting would be trivial and safe if > someone feels it's important enough to do so. > > This has been bootstrapped and regression tested on a variety of native > targets, it's also been tested to a lesser degree on the various *-elf > targets. > > Installing on the trunk momentarily. IMHO we should get rid of path splitting and try to integrate its transform with (backward) threading somehow. Richard. > > jeff
Re: [wwwdocs] Add some info on LTO/IPA changes for GCC 9
> On Thu, 2 May 2019, Martin Liška wrote: > > > Hi. > > > > I'm sending updated version. > > OK (though the various absolute percentages might be misleading since > they obviously refer to a very specific build environment). I have comitted this and added bit more specific info (Firefox/Libreoffice version and fact that my testing box has 8 cores) Honza > > Richard. > > > Martin > > > > -- > Richard Biener > SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)
Re: [wwwdocs] Add some info on LTO/IPA changes for GCC 9
On Thu, 2 May 2019, Martin Liška wrote: > Hi. > > I'm sending updated version. OK (though the various absolute percentages might be misleading since they obviously refer to a very specific build environment). Richard. > Martin > -- Richard Biener SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)
Re: [RFC][PATCH] Postpone print of --help=* option.
On 5/2/19 1:04 PM, Jakub Jelinek wrote: > Well, that doesn't answer the question. > I was wondering why you couldn't: Ah sorry, you are right. The patch you suggested is obviously nicer than what we have currently in trunk. Feel free to install it. Martin
Re: [RFC][PATCH] Postpone print of --help=* option.
On Thu, May 02, 2019 at 12:51:05PM +0200, Martin Liška wrote:
> You are right, it's guarded in #ifdef ACCEL_COMPILER
> so I haven't seen the compilation error.
>
> >
> > Any reason why you've called print_help from finish_options rather than
> > decode_options after it calls finish_options?
>
> Yes, I need that as I need option propagation, as described in:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89885#c0
Well, that doesn't answer the question.
I was wondering why you couldn't:
2019-05-02 Jakub Jelinek
* opts.h (finish_options): Remove lang_mask argument.
(print_help, help_option_argument): Declare.
* opts.c (print_help): Remove forward declaration, no longer static.
(finish_options): Remove lang_mask argument, don't call print_help
here.
* opts-global.c (decode_options): Adjust finish_option caller, call
print_help here.
--- gcc/opts.h.jj 2019-05-02 12:18:35.558051021 +0200
+++ gcc/opts.h 2019-05-02 13:00:53.488347939 +0200
@@ -418,8 +418,8 @@ extern bool target_handle_option (struct
void (*target_option_override_hook) (void));
extern void finish_options (struct gcc_options *opts,
struct gcc_options *opts_set,
- location_t loc,
- unsigned int lang_mask);
+ location_t loc);
+extern void print_help (struct gcc_options *opts, unsigned int lang_mask);
extern void default_options_optimization (struct gcc_options *opts,
struct gcc_options *opts_set,
struct cl_decoded_option
*decoded_options,
@@ -443,6 +443,8 @@ extern const struct sanitizer_opts_s
bool can_recover;
} sanitizer_opts[];
+extern const char *help_option_argument;
+
extern void add_misspelling_candidates (auto_vec *candidates,
const struct cl_option *option,
const char *base_option);
--- gcc/opts.c.jj 2019-05-02 12:18:35.557051038 +0200
+++ gcc/opts.c 2019-05-02 13:00:34.058659611 +0200
@@ -858,15 +858,13 @@ control_options_for_live_patching (struc
/* --help option argument if set. */
const char *help_option_argument = NULL;
-static void print_help (struct gcc_options *opts, unsigned int lang_mask);
-
/* After all options at LOC have been read into OPTS and OPTS_SET,
finalize settings of those options and diagnose incompatible
combinations. */
void
finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
- location_t loc, unsigned int lang_mask)
+ location_t loc)
{
enum unwind_info_type ui_except;
@@ -1230,10 +1228,6 @@ finish_options (struct gcc_options *opts
opts->x_flag_live_patching,
loc);
}
-
- /* Print --help=* if used. */
- if (help_option_argument != NULL)
-print_help (opts, lang_mask);
}
#define LEFT_COLUMN27
@@ -2066,7 +2060,7 @@ check_alignment_argument (location_t loc
/* Print help when OPT__help_ is set. */
-static void
+void
print_help (struct gcc_options *opts, unsigned int lang_mask)
{
const char *a = help_option_argument;
--- gcc/opts-global.c.jj2019-05-02 12:18:36.673033137 +0200
+++ gcc/opts-global.c 2019-05-02 13:01:25.024842046 +0200
@@ -314,7 +314,11 @@ decode_options (struct gcc_options *opts
loc, lang_mask,
&handlers, dc);
- finish_options (opts, opts_set, loc, lang_mask);
+ finish_options (opts, opts_set, loc);
+
+ /* Print --help=* if used. */
+ if (help_option_argument != NULL)
+print_help (opts, lang_mask);
}
/* Hold command-line options associated with stack limitation. */
Jakub
[committed, wwwdocs] OpenACC status for GCC 9
Hi! Committed to wwwdocs 'htdocs/gcc-9/changes.html' in revision 1.60: Index: htdocs/gcc-9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.59 retrieving revision 1.60 diff -u -p -r1.59 -r1.60 --- htdocs/gcc-9/changes.html 9 Apr 2019 21:08:28 - 1.59 +++ htdocs/gcc-9/changes.html 2 May 2019 10:53:47 - 1.60 @@ -262,6 +262,23 @@ foo (int how) New Languages and Language specific improvements + +https://www.openacc.org";>OpenACC support in C, C++, and +Fortran continues to be maintained and improved. +Most of the OpenACC 2.5 specification is implemented. +See the +https://gcc.gnu.org/wiki/OpenACC#status-9";>implementation +status section on +the https://gcc.gnu.org/wiki/OpenACC";>OpenACC wiki page for +further information. + + Grüße Thomas signature.asc Description: PGP signature
Re: [RFC][PATCH] Postpone print of --help=* option.
On 5/2/19 12:30 PM, Jakub Jelinek wrote: > On Mon, Apr 01, 2019 at 02:11:17PM +0200, Martin Liška wrote: >> 2019-04-01 Martin Liska >> >> * gcc.c (process_command): Add dummy file only >> if n_infiles == 0. >> * opts-global.c (decode_options): Pass lang_mask. >> * opts.c (print_help): New function. >> (finish_options): Print --help if help_option_argument >> is set. >> (common_handle_option): Factor out content of OPT__help_ >> into print_help. >> * opts.h (finish_options): Add new argument. > > As reported by Ulrich Drepper on IRC, this broke > --enable-as-accelerator-for=... build, tree-streamer-in.c calls > finish_options too and that caller has not been adjusted. You are right, it's guarded in #ifdef ACCEL_COMPILER so I haven't seen the compilation error. > > Any reason why you've called print_help from finish_options rather than > decode_options after it calls finish_options? Yes, I need that as I need option propagation, as described in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89885#c0 > > Or should tree-streamer-in.c pass CL_LTO as the lang_mask, or say CL_DRIVER > so that print_help does nothing in that case? Yes, that would fix it. Can you please provide a patch that he can test? Thanks, Martin > > Jakub >
Re: [PATCH] libphobos: RISC-V: Fix soft-float build errors with IEEE exception flags
On Thu, May 02, 2019 at 09:37:36AM +0200, Iain Buclaw wrote: > > libphobos/ > > * std/math.d (IeeeFlags.getIeeeFlags): Handle RISC-V soft-float > > ABI. > > (IeeeFlags.resetIeeeFlags): Likewise. > > (FloatingPointControl.getControlState): Likewise. > > (FloatingPointControl.setControlState): Likewise. > > I believe this change is obviously correct, and I also verified generated > > code using `objdump -d'. I have no way to regression-test it right now. > > > > Please confirm if I correctly referred to identifiers in the ChangeLog > > entry though, as my experience WRT the D programming language and its > > syntax in particular is nil. > > > > My understanding is changes to `libphobos' are supposed to go upstream > > first, but r270522 is a local change anyway AFAICT, and technically a > > `--enable-languages=all' build regression, so we better fix it ASAP. > > > > Finally my WDC copyright assignment with FSF is still in the works, but I > > believe this change can be considered legally insignificant for copyright > > purposes, i.e. having at most 15 lines or so, unless adding white space > > for indentation counts against that limit as well (which I doubt). > > > > With all of the above in mind, OK to apply to trunk and to GCC 9? > > > > Looks OK to me. The change is ok for 9.1 if it can be committed to gcc-9-branch today. Jakub
Re: [RFC][PATCH] Postpone print of --help=* option.
On Mon, Apr 01, 2019 at 02:11:17PM +0200, Martin Liška wrote: > 2019-04-01 Martin Liska > > * gcc.c (process_command): Add dummy file only > if n_infiles == 0. > * opts-global.c (decode_options): Pass lang_mask. > * opts.c (print_help): New function. > (finish_options): Print --help if help_option_argument > is set. > (common_handle_option): Factor out content of OPT__help_ > into print_help. > * opts.h (finish_options): Add new argument. As reported by Ulrich Drepper on IRC, this broke --enable-as-accelerator-for=... build, tree-streamer-in.c calls finish_options too and that caller has not been adjusted. Any reason why you've called print_help from finish_options rather than decode_options after it calls finish_options? Or should tree-streamer-in.c pass CL_LTO as the lang_mask, or say CL_DRIVER so that print_help does nothing in that case? Jakub
Re: [wwwdocs] Add some info on LTO/IPA changes for GCC 9
Hi.
I'm sending updated version.
Martin
diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index 6123310..c2aedd0 100644
--- a/htdocs/gcc-9/changes.html
+++ b/htdocs/gcc-9/changes.html
@@ -195,6 +195,11 @@ v.c:10:7: missed: statement clobbers memory: __asm__ __volatile__("" :
metadata such as the inlining chain, and profile information (if
available).
+ Inter-procedural propagation of stack alignment can now be controlled by
+ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fipa-stack-alignment";>-fipa-stack-alignment.
+ Propagation of addressability, readonly and writeonly flags on
+ static variables can now be controlled by
+ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fipa-reference-addressable";>-fipa-reference-addressable.
The following built-in functions have been introduced.
@@ -246,6 +251,52 @@ foo (int how)
can be transformed into 100 * how + 5 (for values defined
in the switch statement).
+Inter-procedural optimization improvements:
+
+ Inliner defaults was tuned to better suits modern C++ codebases
+ especially when built with link time optimizations.
+ New parameters max-inline-insns-small,
+ max-inline-insns-size,
+ uninlined-function-insns,
+ uninlined-function-time, uninlined-thunk-insns,
+ and uninlined-thunk-time were added.
+ Hot/cold partitioning is now more precise and aggressive.
+ Improved scalability for very large translation units (especially
+ when link-time optimizing large programs).
+
+Profile driven optimization improvements:
+
+ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fprofile-use";>-fprofile-use now enables
+ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fversion-loops-for-strides";>-fversion-loops-for-strides,
+ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-floop-interchange";>-floop-interchange,
+ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-floop-unroll-and-jam";>-floop-unroll-and-jam,
+ https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftree-loop-distribution";>-ftree-loop-distribution.
+Streaming of counter histograms was removed. This reduces
+ the size of profile files. Histogram is computed on the fly
+ with link-time optimization.
+Parameter hot-bb-count-ws-permille was reduced
+from 999 to 990 to account for more precise histograms.
+
+Link-time optimization improvements:
+
+Types are now simplified prior streaming resulting in significant
+ reductions of the LTO object files, link-time memory use, and
+ improvements of link-time parallelism.
+Default number of partitions (--param lto-partitions) was
+ increased from 32 to 128 enabling effective use of CPUs with more than
+ 32 hyperthreads. --param lto-max-streaming-parallelism
+ can now be used to control number of streaming processes.
+Warnings on C++ One Decl Rule violations (-Wodr) are
+ now more informative and produce fewer redundant results.
+
+ Overal compile time of Firefox and LibreOffice was reduced by about 5%
+ compared to GCC 8.3. Size of LTO object files is reduced by 7%.
+ LTO link-time improves by 11% on 8-core machine and scales significantly better
+ for more parallel build environments. Serial stage of the link-time
+ optimization is 28% faster consuming 20% less memory.
+ Parallel stage now partitions to 128 partitions rather than 32 and
+ reduces memory use for every worker by 30%.
+
The following improvements to the gcov command-line utility
have been made.
Re: [wwwdocs] Add some info on LTO/IPA changes for GCC 9
On 4/30/19 7:21 PM, Jan Hubicka wrote: > Hi, > this patch adds some notes on LTO/IPA changes and some statistics > on bulid-time/memory use improvements I collected this weekend. > I also added some of FDO changes I rememebr. Martin, perhaps you can > do more. Hi. I'm fine with the changes (and numbers) you provided. Please apply following patch that corrects some typos: --- xxx.eml 2019-05-02 10:26:03.187395558 +0200 +++ xxx.eml.new 2019-05-02 10:30:30.340814818 +0200 @@ -21,7 +21,7 @@ can be transformed into 100 * how + 5 (for values defined in the switch statement). -+Inter-prodcedural optimization improvements: ++Inter-procedural optimization improvements: + + Inliner defaults was tuned to better suits modern C++ codebases + especially when built with link time optimizations. @@ -29,8 +29,8 @@ + max-inline-insns-size, + uninlined-function-insns, + uninlined-function-time, uninlined-thunk-insns, -+ and uninlined-thunk-time was added. -+ Hot/cold partitioning is now more precise and agressive. ++ and uninlined-thunk-time were added. ++ Hot/cold partitioning is now more precise and aggressive. + Improved scalability for very large translation units (especially + when link-time optimizing large programs). +
Re: [PATCH][DOC] Define email limit for gcc-patches mailing list.
On 4/30/19 8:54 PM, Segher Boessenkool wrote: > On Mon, Apr 29, 2019 at 06:29:50PM +, Iain Sandoe wrote: >> >>> On 26 Apr 2019, at 15:08, Gerald Pfeifer wrote: >>> >>> On Fri, 26 Apr 2019, Martin Liška wrote: The patch clarifies that gcc-patches mailing list allows up to 400kB size of an email. >> >>> As one minor detail, note we have KB in one place and with the >>> patch would have kB. Technically it's probably KiB, but that >>> may confuse people more than it helps, so KB which is generally >>> more commonly used in our documentation? >> >> Do we really use ‘K’ rather than ‘k’ ? (as I understand things the latter is >> correct even if use of K is widespread). > > I agree that kB is correct and KB is not. I've just done that. > (And KiB... Let's just not > talk about people who prefer that; Pluto is a planet, too!) But not a planet of the Solar System! Martin > > > Segher >
Re: [RFC][PATCH] Postpone print of --help=* option.
On 4/30/19 6:18 PM, Jeff Law wrote:
> On 4/1/19 6:11 AM, Martin Liška wrote:
>> Hi.
>>
>> Last week I was curious which warnings are disabled by default on top
>> of -Wall and -Wextra. Thus I used --help=warning and noticed some discrepancy
>> in between documentation and output of the --help option.
>>
>> I created PR89885 where I explained that OPT__help_ option handling happens
>> early. That's why LangEnabledBy are not reflected and similarly target
>> overrides
>> don't take place.
>>
>> I'm attaching diff for --help=warning for C++ and -Ofast.
>>
>> Thoughts?
>>
>> gcc/ChangeLog:
>>
>> 2019-04-01 Martin Liska
>>
>> * gcc.c (process_command): Add dummy file only
>> if n_infiles == 0.
>> * opts-global.c (decode_options): Pass lang_mask.
>> * opts.c (print_help): New function.
>> (finish_options): Print --help if help_option_argument
>> is set.
>> (common_handle_option): Factor out content of OPT__help_
>> into print_help.
>> * opts.h (finish_options): Add new argument.
>> ---
>> gcc/gcc.c | 3 +-
>> gcc/opts-global.c | 2 +-
>> gcc/opts.c| 267 --
>> gcc/opts.h| 3 +-
>> 4 files changed, 146 insertions(+), 129 deletions(-)
>>
>>
>>
>> 0001-Postpone-print-of-help-option.patch
>>
>> diff --git a/gcc/gcc.c b/gcc/gcc.c
>> index 4f57765b012..7ce1cae28a7 100644
>> --- a/gcc/gcc.c
>> +++ b/gcc/gcc.c
>> @@ -4751,7 +4751,8 @@ process_command (unsigned int decoded_options_count,
>> }
>>
>>/* Ensure we only invoke each subprocess once. */
>> - if (print_subprocess_help || print_help_list || print_version)
>> + if (n_infiles == 0
>> + && (print_subprocess_help || print_help_list || print_version))
>> {
>>n_infiles = 0;
> The assignment to n_infiles is redundant after your change. I suspect
> the optimizers will catch this, so if you want to keep it for clarity
> that's fine with me.
>
> OK for the trunk. Your call whether or not to remove the redundant
> assignment.
Thank you for review. I've removed the redundancy assignment before
commit.
Martin
>
> jeff
>
[PATCH] Fix up gfor_cdir
Hi! On Wed, May 01, 2019 at 03:18:00PM -0400, Arvind Sankar wrote: > Including Paul -- looks like the file gets installed in different places > in fortran-dev branch vs trunk? I agree this is a bug on both sides, on the GCC side because installing the header which is the same on all targets in different multilib subdirs doesn't make any sense and is inconsistent with all other headers, on the glibc side because broken assumptions that there is just one header directory, there can be many. Let's just deal with the GCC side here. We intentionally do install finclude files into $(MULTISUBDIR)/finclude, because those are architecture specific, but for C/C++ headers want instead to use preprocessor conditionals if possible to deal with possible differences between targets in a single file. Examples from other GCC libraries: grep 'dir = .*/f\?include' lib*/Makefile.am libgomp/Makefile.am:fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude libgomp/Makefile.am:libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include libitm/Makefile.am:fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude libitm/Makefile.am:libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include liboffloadmic/Makefile.am:coi_inc_dir = $(top_srcdir)/include/coi liboffloadmic/Makefile.am:libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include libquadmath/Makefile.am:libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include libsanitizer/Makefile.am:sanincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include/sanitizer libssp/Makefile.am:libsubincludedir = $(libdir)/gcc/$(target_noncanonical)/$(gcc_version)/include libvtv/Makefile.am:libvtv_includedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include No idea why libitm has fincludedir when it doesn't install any finclude files. In the Fedora gcc 9 rpms, I'm including only the 9/include/ISO_Fortran_binding.h header and not 9/32/include/ISO_Fortran_binding.h for quite some time and it works just fine. Ok for trunk/9.1? 2019-05-02 Jakub Jelinek * Makefile.am (gfor_cdir): Remove $(MULTISUBDIR). * Makefile.in: Regenerated. --- libgfortran/Makefile.am.jj 2019-01-17 13:20:17.196206846 +0100 +++ libgfortran/Makefile.am 2019-05-02 09:44:15.558608723 +0200 @@ -31,7 +31,7 @@ version_dep = endif gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h -gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include +gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ $(lt_host_flags) --- libgfortran/Makefile.in.jj 2019-01-17 13:20:12.481283311 +0100 +++ libgfortran/Makefile.in 2019-05-02 09:44:55.968959734 +0200 @@ -717,7 +717,7 @@ gcc_version := $(shell @get_gcc_base_ver @LIBGFOR_USE_SYMVER_GNU_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = $(srcdir)/gfortran.map @LIBGFOR_USE_SYMVER_SUN_TRUE@@LIBGFOR_USE_SYMVER_TRUE@version_dep = gfortran.map-sun gfor_c_HEADERS = $(srcdir)/ISO_Fortran_binding.h -gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include +gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS)) \ $(lt_host_flags) Jakub
Re: [PATCH] libphobos: RISC-V: Fix soft-float build errors with IEEE exception flags
On Thu, 2 May 2019 at 03:14, Maciej Rozycki wrote:
>
> From: Maciej W. Rozycki
>
> 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 ,
> where the problematic code has originated from.
>
> libphobos/
> * std/math.d (IeeeFlags.getIeeeFlags): Handle RISC-V soft-float
> ABI.
> (IeeeFlags.resetIeeeFlags): Likewise.
> (FloatingPointControl.getControlState): Likewise.
> (FloatingPointControl.setControlState): Likewise.
> ---
> Hi,
>
> I believe this change is obviously correct, and I also verified generated
> code using `objdump -d'. I have no way to regression-test it right now.
>
> Please confirm if I correctly referred to identifiers in the ChangeLog
> entry though, as my experience WRT the D programming language and its
> syntax in particular is nil.
>
> My understanding is changes to `libphobos' are supposed to go upstream
> first, but r270522 is a local change anyway AFAICT, and technically a
> `--enable-languages=all' build regression, so we better fix it ASAP.
>
> Finally my WDC copyright assignment with FSF is still in the works, but I
> believe this change can be considered legally insignificant for copyright
> purposes, i.e. having at most 15 lines or so, unless adding white space
> for indentation counts against that limit as well (which I doubt).
>
> With all of the above in mind, OK to apply to trunk and to GCC 9?
>
Hi,
Looks OK to me.
--
Iain.
