LWG2593 Move from allocator state is preserved
Hi
Let's apply this resolution first before moving forward with the
std::deque implementation.
Move from state of allocators (LWG2593)
* include/bits/stl_deque.h
(_Deque_base(_Deque_base&&, false_type)): Remove.
(_Deque_base(_Deque_base&&, true_type)): Remove.
(_Deque_base(_Deque_base&&)): Adapt.
(_Deque_base::_M_move_impl()): Remove.
* testsuite/util/testsuite_allocator.h
(propagating_allocator(propagating_allocator&&)): Preserve move from
state.
* testsuite/23_containers/deque/allocator/move_assign.cc (test02):
Adapt.
* testsuite/23_containers/forward_list/allocator/move_assign.cc
(test02):
Adapt.
* testsuite/23_containers/list/allocator/move_assign.cc (test02):
Adapt.
* testsuite/23_containers/map/allocator/move_assign.cc (test02): Adapt.
* testsuite/23_containers/multimap/allocator/move_assign.cc (test02):
Adapt.
* testsuite/23_containers/multiset/allocator/move_assign.cc (test02):
Adapt.
* testsuite/23_containers/set/allocator/move_assign.cc (test02): Adapt.
* testsuite/23_containers/unordered_map/allocator/move_assign.cc
(test02): Adapt.
* testsuite/23_containers/unordered_multimap/allocator/move_assign.cc
(test02): Adapt.
* testsuite/23_containers/unordered_multiset/allocator/move_assign.cc
(test02): Adapt.
* testsuite/23_containers/unordered_set/allocator/move_assign.cc
(test02): Adapt.
* testsuite/23_containers/vector/allocator/move_assign.cc (test02):
Adapt.
* testsuite/23_containers/vector/bool/allocator/move_assign.cc
(test02):
Adapt.
I only run 23_containers tests with success so far, I'll complete the
run before committing.
Ok to commit ?
François
diff --git a/libstdc++-v3/include/bits/stl_deque.h b/libstdc++-v3/include/bits/stl_deque.h
index c050d1bf023..358bbda3902 100644
--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -428,11 +428,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{ /* Caller must initialize map. */ }
#if __cplusplus >= 201103L
- _Deque_base(_Deque_base&& __x, false_type)
- : _M_impl(__x._M_move_impl())
- { }
-
- _Deque_base(_Deque_base&& __x, true_type)
+ _Deque_base(_Deque_base&& __x)
: _M_impl(std::move(__x._M_get_Tp_allocator()))
{
_M_initialize_map(0);
@@ -440,10 +436,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
this->_M_impl._M_swap_data(__x._M_impl);
}
- _Deque_base(_Deque_base&& __x)
- : _Deque_base(std::move(__x), typename _Alloc_traits::is_always_equal{})
- { }
-
_Deque_base(_Deque_base&& __x, const allocator_type& __a, size_t __n)
: _M_impl(__a)
{
@@ -555,29 +547,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
enum { _S_initial_map_size = 8 };
_Deque_impl _M_impl;
-
-#if __cplusplus >= 201103L
-private:
- _Deque_impl
- _M_move_impl()
- {
- if (!_M_impl._M_map)
- return std::move(_M_impl);
-
- // Create a copy of the current allocator.
- _Tp_alloc_type __alloc{_M_get_Tp_allocator()};
- // Put that copy in a moved-from state.
- _Tp_alloc_type __sink __attribute((__unused__)) {std::move(__alloc)};
- // Create an empty map that allocates using the moved-from allocator.
- _Deque_base __empty{__alloc};
- __empty._M_initialize_map(0);
- // Now safe to modify current allocator and perform non-throwing swaps.
- _Deque_impl __ret{std::move(_M_get_Tp_allocator())};
- _M_impl._M_swap_data(__ret);
- _M_impl._M_swap_data(__empty._M_impl);
- return __ret;
- }
-#endif
};
template
diff --git a/libstdc++-v3/testsuite/23_containers/deque/allocator/move_assign.cc b/libstdc++-v3/testsuite/23_containers/deque/allocator/move_assign.cc
index 49d9c24ae9e..2eb66af9040 100644
--- a/libstdc++-v3/testsuite/23_containers/deque/allocator/move_assign.cc
+++ b/libstdc++-v3/testsuite/23_containers/deque/allocator/move_assign.cc
@@ -45,7 +45,7 @@ void test02()
test_type v2(1, alloc_type(2));
v2 = std::move(v1);
VERIFY( it == v2.begin() );
- VERIFY(0 == v1.get_allocator().get_personality());
+ VERIFY(1 == v1.get_allocator().get_personality());
VERIFY(1 == v2.get_allocator().get_personality());
}
diff --git a/libstdc++-v3/testsuite/23_containers/forward_list/allocator/move_assign.cc b/libstdc++-v3/testsuite/23_containers/forward_list/allocator/move_assign.cc
index 44592baf1a6..118ac235391 100644
--- a/libstdc++-v3/testsuite/23_containers/forward_list/allocator/move_assign.cc
+++ b/libstdc++-v3/testsuite/23_containers/forward_list/allocator/move_assign.cc
@@ -48,7 +48,7 @@ void test02()
test_type v2(alloc_type(2));
v2.push_front(T());
v2 = std::move(v1);
- VERIFY(0 == v1.get_allocator().get_personality());
+ VERIFY(1 == v1.get_allocator().get_personality());
VERIFY(1 == v2.get_allocator().get_personality());
VERIFY( it == v2.begin() );
}
diff --git a/libstdc++-v3/testsuite/23_containers/list/allocator/move_assign.cc
Re: [PATCH] Remove redundant accessors in hash tables
On 5/15/19 5:37 PM, Jonathan Wakely wrote:
François,
I noticed that _Hash_code_base and _Hashtable_base have a number of
member functions which are overloaded for const and non-const:
const _Equal&
_M_eq() const { return _EqualEBO::_S_cget(*this); }
_Equal&
_M_eq() { return _EqualEBO::_S_get(*this); }
The non-const ones seem to be unnecessary. They're used in the _M_swap
member functions, but all other uses could (and probably should) call
the const overload to get a const reference to the function object.
If we make the _M_swap members use the EBO accessors directly then we
can get rid of the non-const accessors. That makes overload resolution
simpler for the compiler (as there's only one function to choose from)
and should result in slightly smaller code when inlining is not
enabled.
Do you see any problem with this patch?
I think it is more a Pavlov behavior, always providing const and
non-const no matter what.
No problem to simplify this.
Go patch committed: Improve escape analysis on interface conversions
This patch to the Go frontend by Cherry Zhang improves escape analysis
on interface conversions.
If an interface does not escape, it doesn't need a heap allocation to
hold the data (for non-direct interface type). This CL improves the
escape analysis to track interface conversions, and reduces these
allocations.
Implicit interface conversions were mostly added late in the
compilation pipeline, after the escape analysis. For the escape
analysis to see them, we move the introduction of these conversions
earlier, right before the escape analysis.
Now that the compiler can generate interface conversions inlined,
gcc/testsuite/go.test/test/nilptr2.go needs to be adjusted as in
golang.org/cl/176579, so the use function does an actual use.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
2019-05-15 Cherry Zhang
* go.test/test/nilptr2.go: Change use function to actually do
something.
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 271182)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-6112f9b8fa9d57d2db8a709cc8b44a94d778d08a
+2df0879e7880057293c0a59be6868a3e6ea5105b
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: gcc/go/gofrontend/escape.cc
===
--- gcc/go/gofrontend/escape.cc (revision 271182)
+++ gcc/go/gofrontend/escape.cc (working copy)
@@ -2407,9 +2407,11 @@ Escape_analysis_assign::assign(Node* dst
Type* tt = tce->type();
if ((ft->is_string_type() && tt->is_slice_type())
|| (ft->is_slice_type() && tt->is_string_type())
-|| (ft->integer_type() != NULL && tt->is_string_type()))
+|| (ft->integer_type() != NULL && tt->is_string_type())
+|| tt->interface_type() != NULL)
{
-// string([]byte), string([]rune), []byte(string),
[]rune(string), string(rune)
+// string([]byte), string([]rune), []byte(string),
[]rune(string), string(rune),
+// interface(T)
this->flows(dst, src);
break;
}
@@ -3151,14 +3153,24 @@ Escape_analysis_flood::flood(Level level
Type* tt = tce->type();
if ((ft->is_string_type() && tt->is_slice_type())
|| (ft->is_slice_type() && tt->is_string_type())
- || (ft->integer_type() != NULL && tt->is_string_type()))
+ || (ft->integer_type() != NULL && tt->is_string_type())
+ || tt->interface_type() != NULL)
{
- // string([]byte), string([]rune), []byte(string),
[]rune(string), string(rune)
+ // string([]byte), string([]rune), []byte(string),
[]rune(string), string(rune),
+ // interface(T)
src->set_encoding(Node::ESCAPE_HEAP);
if (debug_level != 0 && osrcesc != src->encoding())
go_inform(src->location(), "%s escapes to heap",
src->ast_format(gogo).c_str());
extra_loop_depth = mod_loop_depth;
+ if (tt->interface_type() != NULL
+ && ft->has_pointer()
+ && !ft->is_direct_iface_type())
+// We're converting from a non-direct interface type.
+// The interface will hold a heap copy of the data
+// Flow the data to heap. See issue 29353.
+this->flood(level, this->context_->sink(),
+Node::make_node(tce->expr()), -1);
}
}
else if (e->array_index_expression() != NULL
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 271182)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -184,11 +184,10 @@ Expression::convert_for_assignment(Gogo*
NULL);
if (!are_identical && lhs_type->interface_type() != NULL)
{
- if (rhs_type->interface_type() == NULL)
-return Expression::convert_type_to_interface(lhs_type, rhs, location);
- else
-return Expression::convert_interface_to_interface(lhs_type, rhs, false,
- location);
+ // Type to interface conversions have been made explicit early.
+ go_assert(rhs_type->interface_type() != NULL);
+ return Expression::convert_interface_to_interface(lhs_type, rhs, false,
+location);
}
else if (!are_identical && rhs_type->interface_type() != NULL)
return Expression::convert_interface_to_type(lhs_type, rhs, location);
@@ -231,11 +230,12 @@ Expression::convert_for_assignment(Gogo*
}
// Return an
Re: [PATCH v2 3/3] Consider doloop cmp use in ivopts
on 2019/5/15 下午4:47, Richard Biener wrote: > On Wed, 15 May 2019, Kewen.Lin wrote: > >> on 2019/5/14 下午3:26, Richard Biener wrote: >>> On Tue, May 14, 2019 at 5:10 AM wrote: From: Kewen Lin Previous version link for background: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html Firstly, it's to call predict_doloop_p hook to check this loop will be transformed to doloop or not, if yes, find the expected comp iv use and its dependent original iv, set the iv candidate as bind_cand of the group. In following candidate selection process, we will bypass the group with bind_cand, since we don't want to affect global decision making for an iv use which will be eliminated eventually. At the time of iv candidate set finalization, we will fill the cost pair for the group with bind_cand. If the bind_cand is already in the final set, then just use it. Otherwise, we can check whether one of existing final set is better and fill with that if so. Bootstrapped and regression testing passed on powerpc64le. Is it ok for trunk? >>> >>> I wonder what prevents IVOPTs to consider a counter IV >>> (eventually such candidate needs to be added if that's not >>> already done) to be the most profitable variant w/o any >>> of the other changes? I guess that would be costing of >>> the IV adjust plus branch which we would need to lower >>> in case there's nothing inside the loop that would make >>> later doloop transform fail? >>> >>> Richard. >>> >> >> If the question is for "w/o this patch", I think IVOPTs >> can find counter IV as the most profitable one for the cmp >> use in most time. But the key issue is that it may stop >> us to bring in more iv cands. We have to add on iv cost >> of new cand desirable for some iv use, it's probably more >> than the cost of just using counter IV for the interest >> use. >> >> If the question is for "w/i this patch", since we bypass >> the doloop cmp use in candidate determination algorithm, >> it's possible that some other iv cands are preferred for >> the remaining uses rather than the counter IV. For example, >> for some address type iv use, iv cand with memory based is >> mostly better. > > Ah, so the key issue is that the doloop IV is "free"? That > is, it doesn't consume a general register and whatnot? That > is allocating this IV doesn't really interfere with other IVs? > But can other uses be based on the doloop IV easily (if the > IV doesn't reside in a general reg?)? Yes, it takes one special hardware register "counter register" on Power. For other uses based on doloop IV, if there are no more suitable IVs, we still need one general reg for update and use. In the current patch, although we bypass this doloop cmp use, it's still allowed to have other uses to choose this doloop IV candidate. The costing is as usual. Since the doloop cmp use is actually free, we don't want ivopts to consider it and affect optimal IV set. > > Otherwise I understand that IVOPTs doesn't properly cost > the doloop IV update and conditional branch. That's clearly > something we should fix (maybe even indepenently on other > changes). One important thing is that we need to base costs > on a common base to not compare apples and oranges, didn't > dig into your patch in detail enough to see whether it > fits into the general cost model or whether it is a hack > ontop of everything. > In the previous version of patch, it's to make this doloop cmp use as zero cost with any iv cands (like it's invisible), sounds better fit in general cost model? But it requires us to preserve the doloop IV incase it's not chosen. The current version is to bind the doloop IV at the first place, bypass the choosing process and fill it directly if no better found later. For Power, either zero cost or bypass can coexist with the cost model framework. Thanks, Kewen > Richard. >
Re: [PATCH 2/2] aarch64 back-end changes
Hi Richard, On Wed, 15 May 2019 at 23:24, Richard Earnshaw (lists) wrote: > > On 15/05/2019 13:48, Richard Earnshaw (lists) wrote: > > On 15/05/2019 03:39, kugan.vivekanandara...@linaro.org wrote: > >> From: Kugan Vivekanandarajah > >> > > > > The subject line to this email is not helpful. Why should I be > > interested in reviewing this patch? Also, why does it claim to be 2/2 > > when there's no 1/2 to go with it? > > Ah, just noticed that there is a part 1/2 (and a part 0/2) but they hit > a different filter in my mailer so ended up in a different folder. That > doesn't affect the other comments, though: each patch should be > self-contained, even if there's an overall covering letter. My bad. I will do as you suggested from now on. Thanks, Kugan > > R. > > > > > Please include with all patches a justification giving background to why > > you believe the patch is correct. All patches need this sort of > > description - don't assume that the reviewer is familiar with the code > > or will just accept your word for it. > > > > R. > >
[PATCH 2/2] [PR88836][aarch64] Fix CSE to process parallel rtx dest one by one
From: Kugan Vivekanandarajah
This patch changes cse_insn to process parallel rtx one by one such that
any destination rtx in cse list is invalidated before processing the
next.
gcc/ChangeLog:
2019-05-16 Kugan Vivekanandarajah
PR target/88834
* cse.c (safe_hash): Handle VEC_DUPLICATE.
(exp_equiv_p): Likewise.
(hash_rtx_cb): Change to accept const_rtx.
(struct set): Add field to record if uses of dest is invalidated.
(cse_insn): For parallel rtx, invalidate register set by first rtx
before processing the next.
gcc/testsuite/ChangeLog:
2019-05-16 Kugan Vivekanandarajah
PR target/88834
* gcc.target/aarch64/pr88834.c: New test.
Change-Id: I7c3a61f034128f38abe0c2b7dab5d81dec28146c
---
gcc/cse.c | 67 ++
gcc/testsuite/gcc.target/aarch64/pr88836.c | 14 +++
2 files changed, 73 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/aarch64/pr88836.c
diff --git a/gcc/cse.c b/gcc/cse.c
index 6c9cda1..9dc31f5 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -570,7 +570,7 @@ static void invalidate_for_call (void);
static rtx use_related_value (rtx, struct table_elt *);
static inline unsigned canon_hash (rtx, machine_mode);
-static inline unsigned safe_hash (rtx, machine_mode);
+static inline unsigned safe_hash (const_rtx, machine_mode);
static inline unsigned hash_rtx_string (const char *);
static rtx canon_reg (rtx, rtx_insn *);
@@ -2369,6 +2369,11 @@ hash_rtx_cb (const_rtx x, machine_mode mode,
hash += fixed_hash (CONST_FIXED_VALUE (x));
return hash;
+case VEC_DUPLICATE:
+ return hash_rtx_cb (XEXP (x, 0), VOIDmode,
+ do_not_record_p, hash_arg_in_memory_p,
+ have_reg_qty, cb);
+
case CONST_VECTOR:
{
int units;
@@ -2599,7 +2604,7 @@ canon_hash (rtx x, machine_mode mode)
and hash_arg_in_memory are not changed. */
static inline unsigned
-safe_hash (rtx x, machine_mode mode)
+safe_hash (const_rtx x, machine_mode mode)
{
int dummy_do_not_record;
return hash_rtx (x, mode, _do_not_record, NULL, true);
@@ -2630,6 +2635,16 @@ exp_equiv_p (const_rtx x, const_rtx y, int validate,
bool for_gcse)
return x == y;
code = GET_CODE (x);
+ if ((code == CONST_VECTOR && GET_CODE (y) == VEC_DUPLICATE)
+ || (code == VEC_DUPLICATE && GET_CODE (y) == CONST_VECTOR))
+{
+ if (code == VEC_DUPLICATE)
+ std::swap (x, y);
+ if (const_vector_encoded_nelts (x) != 1)
+ return 0;
+ return exp_equiv_p (CONST_VECTOR_ENCODED_ELT (x, 0), XEXP (y, 0),
+ validate, for_gcse);
+}
if (code != GET_CODE (y))
return 0;
@@ -4192,7 +4207,8 @@ struct set
char src_in_memory;
/* Nonzero if the SET_SRC contains something
whose value cannot be predicted and understood. */
- char src_volatile;
+ char src_volatile : 1;
+ char invalidate_dest_p : 1;
/* Original machine mode, in case it becomes a CONST_INT.
The size of this field should match the size of the mode
field of struct rtx_def (see rtl.h). */
@@ -4639,7 +4655,7 @@ cse_insn (rtx_insn *insn)
for (i = 0; i < n_sets; i++)
{
bool repeat = false;
- bool mem_noop_insn = false;
+ bool noop_insn = false;
rtx src, dest;
rtx src_folded;
struct table_elt *elt = 0, *p;
@@ -4736,6 +4752,7 @@ cse_insn (rtx_insn *insn)
sets[i].src = src;
sets[i].src_hash = HASH (src, mode);
sets[i].src_volatile = do_not_record;
+ sets[i].invalidate_dest_p = 1;
sets[i].src_in_memory = hash_arg_in_memory;
/* If SRC is a MEM, there is a REG_EQUIV note for SRC, and DEST is
@@ -5365,7 +5382,7 @@ cse_insn (rtx_insn *insn)
|| insn_nothrow_p (insn)))
{
SET_SRC (sets[i].rtl) = trial;
- mem_noop_insn = true;
+ noop_insn = true;
break;
}
@@ -5418,6 +5435,19 @@ cse_insn (rtx_insn *insn)
src_folded_cost = constant_pool_entries_cost;
src_folded_regcost = constant_pool_entries_regcost;
}
+ else if (n_sets == 1
+ && REG_P (trial)
+ && REG_P (SET_DEST (sets[i].rtl))
+ && GET_MODE_CLASS (mode) == MODE_CC
+ && REGNO (trial) == REGNO (SET_DEST (sets[i].rtl))
+ && !side_effects_p (dest)
+ && (cfun->can_delete_dead_exceptions
+ || insn_nothrow_p (insn)))
+ {
+ SET_SRC (sets[i].rtl) = trial;
+ noop_insn = true;
+ break;
+ }
}
/* If we changed the insn too much, handle this set from scratch. */
@@ -5588,7 +5618,7 @@ cse_insn (rtx_insn *insn)
}
/* Similarly for no-op MEM moves. */
- else if (mem_noop_insn)
+ else if
[PATCH 1/2] [PR88836][aarch64] Set CC_REGNUM instead of clobber
From: Kugan Vivekanandarajah For aarch64 sve while_ult pattern, Set CC_REGNUM instead of clobbering. gcc/ChangeLog: 2019-05-16 Kugan Vivekanandarajah PR target/88834 * config/aarch64/aarch64-sve.md (while_ult): Set CC_REGNUM instead of clobbering. Change-Id: I96f16b8f81140fb4a6897d31d427c62bcc1e7997 --- gcc/config/aarch64/aarch64-sve.md | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-sve.md index 3f39c4c..a18eb80 100644 --- a/gcc/config/aarch64/aarch64-sve.md +++ b/gcc/config/aarch64/aarch64-sve.md @@ -1331,13 +1331,18 @@ ) ;; Set element I of the result if operand1 + J < operand2 for all J in [0, I]. -;; with the comparison being unsigned. +;; with the comparison being unsigned. Als set CC_REFNUM with the flags. (define_insn "while_ult" [(set (match_operand:PRED_ALL 0 "register_operand" "=Upa") (unspec:PRED_ALL [(match_operand:GPI 1 "aarch64_reg_or_zero" "rZ") (match_operand:GPI 2 "aarch64_reg_or_zero" "rZ")] UNSPEC_WHILE_LO)) - (clobber (reg:CC CC_REGNUM))] + (set (reg:CC CC_REGNUM) + (compare:CC + (unspec:SI [(vec_duplicate:PRED_ALL (const_int 1)) + (match_dup 0)] +UNSPEC_PTEST_PTRUE) + (const_int 0)))] "TARGET_SVE" "whilelo\t%0., %1, %2" ) -- 2.7.4
[PATCH 0/2][RFC][PR88836][AARCH64] Fix redundant ptest instruction
From: Kugan Vivekanandarajah
Inorder to fix this PR.
* We need to change the whilelo pattern in backend
* Change RTL CSE such that:
- Add support for VEC_DUPLICATE
- When handling PARALLEL rtx in cse_insn, we kill CSE defined by all the
parallel rtx at the end.
For example, with patch1, we now have rtl insn as follows:
(insn 19 18 20 3 (parallel [
(set (reg:VNx4BI 93 [ next_mask_18 ])
(unspec:VNx4BI [
(const_int 0 [0])
(reg:DI 95 [ _33 ])
] UNSPEC_WHILE_LO))
(set (reg:CC 66 cc)
(compare:CC (unspec:SI [
(vec_duplicate:VNx4BI (const_int 1 [0x1]))
(reg:VNx4BI 93 [ next_mask_18 ])
] UNSPEC_PTEST_PTRUE)
(const_int 0 [0])))
]) 4244 {while_ultdivnx4bi}
When cse_insn process the first, it records the CSE set in reg 93. Then after
processing both the instruction in the parallel rtx, we invalidate all
expression with reg 93 which means expression in the second instruction is
invalidated for CSE. Attached patch relaxes this by invalidating before
processing the
second.
Bootstrap and regression testing for the current version is ongoing.
Thanks,
Kugan
Kugan Vivekanandarajah (2):
[PR88836][aarch64] Set CC_REGNUM instead of clobber
[PR88836][aarch64] Fix CSE to process parallel rtx dest one by one
gcc/config/aarch64/aarch64-sve.md | 9 +++-
gcc/cse.c | 67 ++
gcc/testsuite/gcc.target/aarch64/pr88836.c | 14 +++
3 files changed, 80 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/aarch64/pr88836.c
--
2.7.4
Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git
> On May 15, 2019, at 2:42 PM, Eric Gallager wrote: > >> ... > > Wasn't Eric S. Raymond working on his own conversion of the GCC repo > from SVN to Git? Whatever happened to his? Yes, and from what I recall he found that doing it fully correctly is an extremely hard task. It might be a good idea to ask him to comment. paul
Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada
Maciej W. Rozycki wrote:
Unrecognized `gnatmake' switches are not implicitly passed on to the
linker, so just pasting board `ldflags' and any other linker flags
verbatim into `add_flags' to use for the invocation line of `gnatmake'
will make them ignored at best.
[...]
For `gnatmake' to pass switches on to the linker the `-largs' switch has
to be used, which affects all the switches that follow until a switch is
seen that changes the selection, like `-margs', which resets to the
initial state of the switch interpretation machine.
Wrap linker flags into `-largs'/`-margs' for Ada then, carefully
preserving the place these flags are placed within `add_flags', as
surely someone will have depended on that, [...]
Fortunately, `add_flags' is a procedure local variable in
default_target_compile, so it is not visible outside of that procedure.
This patch really exposes a significant deficiency in our current
implementation of default_target_compile: the order of various flags
can be significant, but we only have that order implicitly expressed in
the code, which goes all the way back to (of course) the "Initial
revision" that is probably from a time before Tcl had the features that
will allow significant cleanup in here.
Rather than introducing more variables, I propose changing add_flags to
an array and collecting each category of flags into its own element,
then emitting those elements in a fixed order to build the `opts' list.
This would also allow us to easily support other cases, for example,
prefixing "special" linker flags with "-Wl," or similar handling for
other frontends. I think we only need to support GCC command syntax,
which simplifies the issue a bit, but even GCC frontends are not 100%
consistent, as this issue with gnatmake shows.
What categories do the flags currently accumulated in `add_flags'
cover? I see at least:
- compiler flags (adaflags/cxxflags/dflags/f77flags/f90flags)
- explicit additional flags ("additional_flags=" option)
- explicit ldflags ("ldflags=" option)
- libraries ("libs=" option)
- preprocessor search paths ("incdir=" option)
- linker search paths ("libdir=" option and [board_info $dest libs])
- linker script ("ldscript=" option or [board_info $dest ldscript])
- optimization flags ("optimize=" option)
- target compiler flags from host ([board_info $host cflags_for_target])
- type selection flag ("-c"/"-E"/"-S")
- target compiler flags ([board_info $dest cflags] *regardless* of
the compiler selected)
- target linker flags ([board_info $dest ldflags])
- special flags for C++ ([g++_link_flags])
- an attempt to locate libstdc++, also regardless of compiler
- debug flags, if the "debug" option is given
- the math library
- "-Wl,-r" if board_info knows a "remote_link" key
- "-Wl,-oformat,[board_info $dest output_format]" if that is defined
- multilib flags, currently *prepended* if defined
- a destination file
Some of these could probably be combined and I may have combined
categories that should be separate in the above list. The GNU toolchain
has always been a kind of "magic box that just works" (until it doesn't
and the manual explains the problem) for me, so I am uncertain what the
ordering rules for combining these categories should be. Anyone know
the traditional rules and, perhaps more importantly, what systems need
which rules?
-- Jacob
Re: [PATCH 2/3][GCC] GNAT/testsuite: Pass the `ada' option to target compilation
Maciej W. Rozycki wrote:
[...]
---
gcc/testsuite/lib/gnat.exp |2 ++
1 file changed, 2 insertions(+)
gcc-test-gnat-options-ada.diff
Index: gcc/gcc/testsuite/lib/gnat.exp
===
--- gcc.orig/gcc/testsuite/lib/gnat.exp
+++ gcc/gcc/testsuite/lib/gnat.exp
@@ -167,6 +167,8 @@ proc gnat_target_compile { source dest t
set options [concat "additional_flags=$TOOL_OPTIONS" $options]
}
+set options [concat "{ada}" $options]
+
return [target_compile $source $dest $type $options]
}
Your Tcl syntax looks suspicious to me. Is there a reason for "ada" to
be in both double quotes and braces?
Perhaps {lappend options ada} might be simpler? Is placing ada at the
beginning of the list important?
-- Jacob
[PATCH] Fix PR90394, [10 Regression] ICE in is_value_included_in, at tree-ssa-uninit.c:1055
Hi!
Here is a simple patch fixing the regression introduced in r270660.
gcc/testsuite/ChangeLog:
PR tree-optimization/90394
* gcc.dg/uninit-pr90394-1-gimple.c: New test.
* gcc.dg/uninit-pr90394.c: New test.
gcc/ChangeLog:
PR tree-optimization/90394
* tree-ssa-uninit.c (is_pred_expr_subset_of): Potentially give false
positives rather than ICE for cases where (code2 == NE_EXPR
&& code1 == BIT_AND_EXPR).
---
.../gcc.dg/uninit-pr90394-1-gimple.c | 47 +++
gcc/testsuite/gcc.dg/uninit-pr90394.c | 33 +
gcc/tree-ssa-uninit.c | 2 +-
3 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/uninit-pr90394-1-gimple.c
create mode 100644 gcc/testsuite/gcc.dg/uninit-pr90394.c
diff --git a/gcc/testsuite/gcc.dg/uninit-pr90394-1-gimple.c b/gcc/testsuite/gcc.dg/uninit-pr90394-1-gimple.c
new file mode 100644
index 000..f8feb6b8967
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr90394-1-gimple.c
@@ -0,0 +1,47 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple -O -Wmaybe-uninitialized" } */
+
+unsigned int __GIMPLE (ssa,startwith("uninit1"))
+foo (unsigned int v)
+{
+ /* The warning is not bogus, because (5 & 3) != 0 and therefore if v == 5,
+ the value of undef is used without being initialized. */
+ unsigned int undef;/* { dg-warning "may be used uninitialized" } */
+ unsigned int _2;
+ unsigned int _9;
+ unsigned int _10;
+ unsigned pred;
+
+ __BB(2):
+ if (v_4(D) != 5u)
+goto __BB3;
+ else
+goto __BB4;
+
+ /* 'undef' is defined conditionally (under 'v != 5' predicate) */
+ __BB(3):
+ undef_8 = 8u;
+ goto __BB4;
+
+ /* An undef value flows into a phi. */
+ __BB(4):
+ undef_1 = __PHI (__BB2: undef_5(D), __BB3: undef_8);
+ pred = v_4(D) & 3u;
+ if (pred != 0u)
+goto __BB5;
+ else
+goto __BB6;
+
+ /* The phi value is used here (under 'v & 3' predicate). */
+ __BB(5):
+ _9 = undef_1;
+ goto __BB7;
+
+ __BB(6):
+ _10 = v_4(D);
+ goto __BB7;
+
+ __BB(7):
+ _2 = __PHI (__BB5: _9, __BB6: _10);
+ return _2;
+}
diff --git a/gcc/testsuite/gcc.dg/uninit-pr90394.c b/gcc/testsuite/gcc.dg/uninit-pr90394.c
new file mode 100644
index 000..16e750d6b33
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr90394.c
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fno-tree-fre -Wuninitialized" } */
+int pz;
+int zi;
+
+void
+uk (void)
+{
+ int th = 1;
+ int *gw =
+
+ for (zi = 0; zi < 2; ++zi)
+{
+ int a2 = 0;
+
+ for (zi = 0; zi < 1; ++zi)
+{
+ th = a2 * 2;
+
+ og:
+ for (pz = 0; pz < 1; ++pz)
+{
+}
+}
+
+ pz = !!*gw ? *gw : pz;
+ pz = (!!th ? (pz & 1) : 0);
+ if (pz == 0)
+++a2;
+}
+
+ goto og;
+}
diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index 7362e374dea..b89da4017e8 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -1471,7 +1471,7 @@ is_pred_expr_subset_of (pred_info expr1, pred_info expr2)
if (code2 == NE_EXPR && code1 == NE_EXPR)
return false;
- if (code2 == NE_EXPR)
+ if (code2 == NE_EXPR && code1 != BIT_AND_EXPR)
return !is_value_included_in (expr2.pred_rhs, expr1.pred_rhs, code1);
if ((code1 == EQ_EXPR || code1 == BIT_AND_EXPR) && code2 == BIT_AND_EXPR)
--
2.20.1
Regtested and bootstrapped with `BOOT_CFLAGS="-O
-Wno-error=maybe-uninitialized -Wuninitialized"` on x86_64-pc-linux-gnu.
OK for trunk?
It is not the ideal solution, but it is the simplest (and safest). So
let's roll with it and then I've already prepared an improvement, but
need your input.
The case where code2 == NE_EXPR and code1 == BIT_AND_EXPR is now (with
this patch) caught by
if (code1 != code2)
return false;
This means a false positive in some cases: e.g. if we change 5u to 16u
in the gimple test case above, we'll have
if (v != 16)
u = sth;
...
if (v & 3)
use (u);
for which a warning will be generated (and it's an FP: u is uninit iff
v == 16, but in that case u is not used).
This can be fixed with something like this:
if (code2 == NE_EXPR)
{
if (code1 == BIT_AND_EXPR)
return !((wi::to_wide (expr1.pred_rhs) & wi::to_wide (expr2.pred_rhs))
.to_uhwi());
else
return !is_value_included_in (expr2.pred_rhs, expr1.pred_rhs, code1);
}
But actually I would rather extend is_value_included_in to handle
BIT_AND_EXPR. OTOH, its other callers don't seem to need it. My
concern is that handling BIT_AND_EXPR in is_value_included_in as I would
like to do would make the assertion in is_value_included_in weaker.
Frankly, I don't completely understand where BIT_AND_EXPR can and cannot
appear.
Would you have any suggestions?
Thank you.
Vlad
[committed] Fix up pr90478.c testcase (was Re: [PATCH] Check for overflow in tree-switch-conversion (PR middle-end/90478).)
On Wed, May 15, 2019 at 12:20:42PM +0200, Martin Liška wrote:
> 2019-05-15 Martin Liska
>
> PR middle-end/90478
> * tree-switch-conversion.c (jump_table_cluster::can_be_handled):
> Check for overflow.
>
> gcc/testsuite/ChangeLog:
>
> 2019-05-15 Martin Liska
>
> PR middle-end/90478
> * gcc.dg/tree-ssa/pr90478-2.c: New test.
> * gcc.dg/tree-ssa/pr90478.c: New test.
The pr90478.c test fails on i686-linux:
FAIL: gcc.dg/tree-ssa/pr90478.c (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr90478.c:14:3: error:
integer constant is too large for 'long' type [-Wlong-long]
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr90478.c:14:3: warning:
overflow in conversion from 'long long int' to 'long int' changes value from
'2057594037927936' to '-239534080' [-Woverflow]
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr90478.c:16:3: error:
integer constant is too large for 'long' type [-Wlong-long]
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr90478.c:16:3: warning:
overflow in conversion from 'long long int' to 'long int' changes value from
'4611686018427387904' to '0' [-Woverflow]
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr90478.c:16:3: error:
duplicate case value
Fixed thusly, tested on x86_64-linux with -m32/-m64, committed to trunk as
obvious:
2019-05-16 Jakub Jelinek
PR middle-end/90478
* gcc.dg/tree-ssa/pr90478.c: Add empty dg-options. Use long long type
instead of long.
--- gcc/testsuite/gcc.dg/tree-ssa/pr90478.c.jj 2019-05-15 23:36:44.476116559
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr90478.c 2019-05-16 00:41:58.088087596
+0200
@@ -1,7 +1,8 @@
/* { dg-do compile } */
+/* { dg-options "" } */
typedef struct {
- long a;
+ long long a;
} c;
void e();
Jakub
Re: [PATCH 1/12] implement -Wformat-diag to detect quoting and spelling issues in GCC diagnostics
On 5/15/19 8:50 AM, Martin Sebor wrote:
On 5/15/19 5:40 AM, Martin Liška wrote:
On 5/14/19 11:31 PM, Martin Sebor wrote:
The attached patch implements the -Wformat-diag warning to help find
quoting, spelling, and other formatting issues in diagnostics issued
by GCC.
Just a general comment about this part. Wouldn't it make sense to use
regex
for some of the string patterns that you address in the patch?
I'm not sure. Are you wondering about the variants of type
names like "signed int" and "unsigned int" and the contractions?
The plain format checker scans and advances one word at a time
to be efficient. It does linearly loop over the black-listed
words and operators and that could be made more efficient by
using a binary search. Let me do that. I would expect
introducing regexp to the checking to slow it down but
I suppose I could try it and see if you think it's worth it.
I tried both approaches for the operators and keywords:
1) using bsearch
2) using regex
I finished (1) but did only a proof of concept of (2). Neither
made a noticeable difference in my (admittedly very simple)
benchmarks but both have drawbacks:
(1) means that the entries in the tables of known operators and
keywords have to be sorted. For operators, the sort order is
different between ASCII and EBCDIC, and would mean duplicating
the operator table and making sure it stays sorted in each
encoding after a change. That seems like a pain in the butt
for little gain.
In my prototype of (2), the regular expression quickly started
to get complicated and hard to read as I tried to handle some
of the same special cases as I'm handling now. It might be
possible to redo the whole thing using regex but it would mean
starting from scratch. I'm not convinced it's worth the effort
(in fact, I would worry about the regular expressions becoming
too complex to easily extend).
So I'm inclined to leave things as they are. I did make a few
simplifications to the code in the process of this experiment
and beefed up the test a little bit so I attach an updated
revision.
Martin
gcc/c-family/ChangeLog:
* c-common.h (GCC_DIAG_STYLE): Adjust.
(GCC_DIAG_RAW_STYLE): New macro.
c-format.c (function_format_info::format_type): Adjust type.
(function_format_info::is_raw): New member.
(decode_format_type): Adjust signature. Handle "raw" diag attributes.
(decode_format_attr): Adjust call to decode_format_type.
Avoid a redundant call to convert_format_name_to_system_name.
Avoid abbreviating the word "arguments" in a diagnostic.
(format_warning_substr): New function.
(avoid_dollar_number): Quote dollar sign in a diagnostic.
(finish_dollar_format_checking): Same.
(check_format_info): Same.
(struct baltoks_t, c_opers, cxx_opers): New.
(c_keywords, cxx_keywords): New.
(maybe_diag_unbalanced_tokens, check_tokens, check_plain): New
functions.
(check_format_info_main): Call check_plain. Use baltoks_t. Call
maybe_diag_unbalanced_tokens.
(handle_format_attribute): Spell out the word "arguments" in
a diagnostic.
* c.opt (-Wformat-diag): New option.
gcc/testsuite/ChangeLog:
* gcc.dg/format/gcc_diag-11.c: New test.
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 1cf2cae6395..9d067028416 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -39,7 +39,10 @@ framework extensions, you must include this file before diagnostic-core.h \
never after.
#endif
#ifndef GCC_DIAG_STYLE
-#define GCC_DIAG_STYLE __gcc_cdiag__
+# define GCC_DIAG_STYLE __gcc_cdiag__
+#endif
+#ifndef GCC_DIAG_RAW_STYLE
+# define GCC_DIAG_RAW_STYLE __gcc_cdiag_raw__
#endif
#include "diagnostic-core.h"
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index a7f76c1c01d..696d3c8ccb6 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -52,7 +52,13 @@ enum format_type { printf_format_type, asm_fprintf_format_type,
struct function_format_info
{
- int format_type; /* type of format (printf, scanf, etc.) */
+ enum format_type format_type; /* type of format (printf, scanf, etc.) */
+ /* IS_RAW is relevant only for GCC diagnostic format functions.
+ It is set for "raw" formatting functions like pp_printf that
+ are not intended to produce complete diagnostics according to
+ GCC guidelines, and clear for others like error and warning
+ whose format string is checked for proper quoting and spelling. */
+ bool is_raw;
unsigned HOST_WIDE_INT format_num; /* number of format argument */
unsigned HOST_WIDE_INT first_arg_num; /* number of first arg (zero for varargs) */
};
@@ -65,7 +71,7 @@ static GTY(()) tree locus;
static bool decode_format_attr (const_tree, tree, tree, function_format_info *,
bool);
-static int decode_format_type (const char *);
+static format_type decode_format_type (const char *, bool * = NULL);
static bool check_format_string (const_tree argument,
unsigned HOST_WIDE_INT format_num,
@@ -111,6 +117,32 @@
[PATCH] OpenMP simd if clause support with runtime determined argument
Hi!
The following patch implements what I've failed to do in time for 9.x,
in particular, if #pragma omp simd has if clause and the argument is
not constant zero (handled by the previous patch), or constant non-zero
(ignored, we want normal vectorization in that case as before), this patch
arranges for that information to be preserved until vectorization in the IL
through the .GOMP_SIMD_LANE ifn (whether it is used for some data
privatization or not) argument and during vectorization makes sure we
version such loop with that runtime condition (either solely or together
with say runtime checks for aliasing, alignment etc.).
Bootstrapped/regtested on x86_64-linux and i686-linux. Richard, is this
approach ok with you?
2019-05-15 Jakub Jelinek
* omp-low.c (lower_rec_input_clauses): If OMP_CLAUSE_IF
has non-constant expression, force sctx.lane and use two
argument IFN_GOMP_SIMD_LANE instead of single argument.
* tree-ssa-dce.c (eliminate_unnecessary_stmts): Don't DCE
two argument IFN_GOMP_SIMD_LANE without lhs.
* tree-vectorizer.h (struct _loop_vec_info): Add simd_if_cond
member.
(LOOP_VINFO_SIMD_IF_COND, LOOP_REQUIRES_VERSIONING_FOR_SIMD_IF_COND):
Define.
(LOOP_REQUIRES_VERSIONING): Or in
LOOP_REQUIRES_VERSIONING_FOR_SIMD_IF_COND.
* tree-vect-loop.c (vect_determine_vectorization_factor): Punt
for IFN_GOMP_SIMD_LANE with zero second argument. Initialize
LOOP_VINFO_SIMD_IF_COND from IFN_GOMP_SIMD_LANE second argument.
(_loop_vec_info::_loop_vec_info): Clear simd_if_cond.
* tree-vect-loop-manip.c (vect_loop_versioning): Add runtime check
from simd if clause if needed.
* gcc.dg/vect/vect-simd-1.c: New test.
* gcc.dg/vect/vect-simd-2.c: New test.
* gcc.dg/vect/vect-simd-3.c: New test.
* gcc.dg/vect/vect-simd-4.c: New test.
--- gcc/omp-low.c.jj2019-05-15 14:56:19.564136934 +0200
+++ gcc/omp-low.c 2019-05-15 16:59:38.686639583 +0200
@@ -3783,6 +3783,7 @@ lower_rec_input_clauses (tree clauses, g
tree simt_lane = NULL_TREE, simtrec = NULL_TREE;
tree ivar = NULL_TREE, lvar = NULL_TREE, uid = NULL_TREE;
gimple_seq llist[3] = { };
+ tree nonconst_simd_if = NULL_TREE;
copyin_seq = NULL;
sctx.is_simt = is_simd && omp_find_clause (clauses, OMP_CLAUSE__SIMT_);
@@ -3814,6 +3815,8 @@ lower_rec_input_clauses (tree clauses, g
case OMP_CLAUSE_IF:
if (integer_zerop (OMP_CLAUSE_IF_EXPR (c)))
sctx.max_vf = 1;
+ else if (TREE_CODE (OMP_CLAUSE_IF_EXPR (c)) != INTEGER_CST)
+ nonconst_simd_if = OMP_CLAUSE_IF_EXPR (c);
break;
case OMP_CLAUSE_SIMDLEN:
if (integer_onep (OMP_CLAUSE_SIMDLEN_EXPR (c)))
@@ -5190,6 +5193,17 @@ lower_rec_input_clauses (tree clauses, g
if (known_eq (sctx.max_vf, 1U))
sctx.is_simt = false;
+ if (nonconst_simd_if)
+{
+ if (sctx.lane == NULL_TREE)
+ {
+ sctx.idx = create_tmp_var (unsigned_type_node);
+ sctx.lane = create_tmp_var (unsigned_type_node);
+ }
+ /* FIXME: For now. */
+ sctx.is_simt = false;
+}
+
if (sctx.lane || sctx.is_simt)
{
uid = create_tmp_var (ptr_type_node, "simduid");
@@ -5219,8 +5233,9 @@ lower_rec_input_clauses (tree clauses, g
}
if (sctx.lane)
{
- gimple *g
- = gimple_build_call_internal (IFN_GOMP_SIMD_LANE, 1, uid);
+ gimple *g = gimple_build_call_internal (IFN_GOMP_SIMD_LANE,
+ 1 + (nonconst_simd_if != NULL),
+ uid, nonconst_simd_if);
gimple_call_set_lhs (g, sctx.lane);
gimple_stmt_iterator gsi = gsi_start_1 (gimple_omp_body_ptr (ctx->stmt));
gsi_insert_before_without_update (, g, GSI_SAME_STMT);
--- gcc/tree-ssa-dce.c.jj 2019-05-03 09:27:00.236840002 +0200
+++ gcc/tree-ssa-dce.c 2019-05-15 17:22:31.176822544 +0200
@@ -1328,12 +1328,16 @@ eliminate_unnecessary_stmts (void)
update_stmt (stmt);
release_ssa_name (name);
- /* GOMP_SIMD_LANE or ASAN_POISON without lhs is not
-needed. */
+ /* GOMP_SIMD_LANE (unless two argument) or ASAN_POISON
+without lhs is not needed. */
if (gimple_call_internal_p (stmt))
switch (gimple_call_internal_fn (stmt))
{
case IFN_GOMP_SIMD_LANE:
+ if (gimple_call_num_args (stmt) >= 2
+ && !integer_nonzerop (gimple_call_arg (stmt, 1)))
+ break;
+ /* FALLTHRU */
case IFN_ASAN_POISON:
remove_dead_stmt (, bb, to_remove_edges);
break;
--- gcc/tree-vectorizer.h.jj2019-04-10 14:19:14.946896353 +0200
+++ gcc/tree-vectorizer.h
Re: [PATCH] gcc: move assemble_start_function / assemble_end_function to output_mi_thunk
Max Filippov writes: > Let backends call assemble_start_function after they have generated > thunk function body so that a constant pool could be output if it is > required. This may help backends to avoid implementing custom constant > loading code specifically for the MI thunk and reuse existing > functionality. > > gcc/ > 2019-01-08 Max Filippov > > * cgraphunit.c (cgraph_node::expand_thunk): Remove > assemble_start_function and assemble_end_function calls. > * config/alpha/alpha.c (alpha_output_mi_thunk_osf): Call > assemble_start_function and assemble_end_function. > * config/arc/arc.c (arc_output_mi_thunk): Likewise. > * config/arm/arm.c (arm_output_mi_thunk): Likewise. > * config/bfin/bfin.c (bfin_output_mi_thunk): Likewise. > * config/c6x/c6x.c (c6x_output_mi_thunk): Likewise. > * config/cris/cris.c (cris_asm_output_mi_thunk): Likewise. > * config/csky/csky.c (csky_output_mi_thunk): Likewise. > * config/epiphany/epiphany.c (epiphany_output_mi_thunk): Likewise. > * config/frv/frv.c (frv_asm_output_mi_thunk): Likewise. > * config/i386/i386.c (x86_output_mi_thunk): Likewise. > * config/ia64/ia64.c (ia64_output_mi_thunk): Likewise. > * config/m68k/m68k.c (m68k_output_mi_thunk): Likewise. > * config/microblaze/microblaze.c (microblaze_asm_output_mi_thunk): > Likewise. > * config/mips/mips.c (mips_output_mi_thunk): Likewise. > * config/mmix/mmix.c (mmix_asm_output_mi_thunk): Likewise. > * config/mn10300/mn10300.c (mn10300_asm_output_mi_thunk): Likewise. > * config/nds32/nds32.c (nds32_asm_output_mi_thunk): Likewise. > * config/nios2/nios2.c (nios2_asm_output_mi_thunk): Likewise. > * config/or1k/or1k.c (or1k_output_mi_thunk): Likewise. > * config/pa/pa.c (pa_asm_output_mi_thunk): Likewise. > * config/riscv/riscv.c (riscv_output_mi_thunk): Likewise. > * config/rs6000/rs6000.c (rs6000_output_mi_thunk): Likewise. > * config/s390/s390.c (s390_output_mi_thunk): Likewise. > * config/sh/sh.c (sh_output_mi_thunk): Likewise. > * config/sparc/sparc.c (sparc_output_mi_thunk): Likewise. > * config/spu/spu.c (spu_output_mi_thunk): Likewise. > * config/stormy16/stormy16.c (xstormy16_asm_output_mi_thunk): > Likewise. > * config/tilegx/tilegx.c (tilegx_output_mi_thunk): Likewise. > * config/tilepro/tilepro.c (tilepro_asm_output_mi_thunk): Likewise. > * config/vax/vax.c (vax_output_mi_thunk): Likewise. OK, thanks. The new placement of assemble_start_function after shorten_branches certainly makes more conceptual sense than what we had before. Richard
[committed] Small OpenMP simd if and simdlen clause tweak
Hi!
If simdlen clause is specified, it is the preferred number of concurrent
simd lanes in the loop, though if if clause is specified and evaluates to
false, the preferred number of simd lanes is 1 (i.e. no vectorization).
This patch handles just the easy part, when simdlen argument is 1 or when
if clause has constant argument which is false.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued for eventual backport to 9.2.
2019-05-15 Jakub Jelinek
* omp-low.c (lower_rec_input_clauses): For if (0) or simdlen (1) set
max_vf to 1.
* omp-expand.c (expand_omp_simd): For if (0) or simdlen (1) clear
safelen_int and set loop->dont_vectorize.
* c-c++-common/gomp/simd8.c: New test.
--- gcc/omp-low.c.jj2019-03-28 23:32:44.813393829 +0100
+++ gcc/omp-low.c 2019-05-15 14:56:19.564136934 +0200
@@ -3811,6 +3811,14 @@ lower_rec_input_clauses (tree clauses, g
|| is_variable_sized (OMP_CLAUSE_DECL (c)))
sctx.max_vf = 1;
break;
+ case OMP_CLAUSE_IF:
+ if (integer_zerop (OMP_CLAUSE_IF_EXPR (c)))
+ sctx.max_vf = 1;
+ break;
+case OMP_CLAUSE_SIMDLEN:
+ if (integer_onep (OMP_CLAUSE_SIMDLEN_EXPR (c)))
+ sctx.max_vf = 1;
+ break;
default:
continue;
}
--- gcc/omp-expand.c.jj 2019-03-07 20:45:39.170938327 +0100
+++ gcc/omp-expand.c2019-05-15 14:55:22.493079461 +0200
@@ -4664,10 +4664,15 @@ expand_omp_simd (struct omp_region *regi
tree *counts = NULL;
int i;
int safelen_int = INT_MAX;
+ bool dont_vectorize = false;
tree safelen = omp_find_clause (gimple_omp_for_clauses (fd->for_stmt),
OMP_CLAUSE_SAFELEN);
tree simduid = omp_find_clause (gimple_omp_for_clauses (fd->for_stmt),
OMP_CLAUSE__SIMDUID_);
+ tree ifc = omp_find_clause (gimple_omp_for_clauses (fd->for_stmt),
+ OMP_CLAUSE_IF);
+ tree simdlen = omp_find_clause (gimple_omp_for_clauses (fd->for_stmt),
+ OMP_CLAUSE_SIMDLEN);
tree n1, n2;
if (safelen)
@@ -4681,6 +4686,12 @@ expand_omp_simd (struct omp_region *regi
if (safelen_int == 1)
safelen_int = 0;
}
+ if ((ifc && integer_zerop (OMP_CLAUSE_IF_EXPR (ifc)))
+ || (simdlen && integer_onep (OMP_CLAUSE_SIMDLEN_EXPR (simdlen
+{
+ safelen_int = 0;
+ dont_vectorize = true;
+}
type = TREE_TYPE (fd->loop.v);
entry_bb = region->entry;
cont_bb = region->cont;
@@ -4965,6 +4976,8 @@ expand_omp_simd (struct omp_region *regi
loop->force_vectorize = true;
cfun->has_force_vectorize_loops = true;
}
+ else if (dont_vectorize)
+ loop->dont_vectorize = true;
}
else if (simduid)
cfun->has_simduid_loops = true;
--- gcc/testsuite/c-c++-common/gomp/simd8.c.jj 2019-05-15 14:24:44.656430757
+0200
+++ gcc/testsuite/c-c++-common/gomp/simd8.c 2019-05-15 15:44:08.161617663
+0200
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-options "-fopenmp -O3 -fdump-tree-vect-details" } */
+/* { dg-final { scan-tree-dump-times "vectorized 0 loops in function" 4 "vect"
} } */
+
+int a[1024];
+
+void
+foo (void)
+{
+ #pragma omp simd if (0)
+ for (int i = 0; i < 1024; ++i)
+a[i] = a[i] + 1;
+}
+
+void
+bar (void)
+{
+ #pragma omp simd if (0) safelen (256) simdlen (8)
+ for (int i = 0; i < 512; ++i)
+a[i] = a[i] + 1;
+}
+
+void
+baz (void)
+{
+ #pragma omp simd safelen (256) simdlen (1)
+ for (int i = 0; i < 512; ++i)
+a[i] = a[i] + 1;
+}
+
+void
+qux (void)
+{
+ #pragma omp simd simdlen (1) if (1)
+ for (int i = 0; i < 512; ++i)
+a[i] = a[i] + 1;
+}
Jakub
Re: PING^1: [PATCH] i386: Add standard scalar operation patterns
"H.J. Lu" writes:
> On Thu, Feb 7, 2019 at 9:49 AM H.J. Lu wrote:
>>
>> Standard scalar operation patterns which preserve the rest of the vector
>> look like
>>
>> (vec_merge:V2DF
>>(vec_duplicate:V2DF
>> (op:DF (vec_select:DF (reg/v:V2DF 85 [ x ])
>> (parallel [ (const_int 0 [0])]))
>> (reg:DF 87))
>>(reg/v:V2DF 85 [ x ])
>>(const_int 1 [0x1])]))
>>
>> Add such pattens to i386 backend and convert VEC_CONCAT patterns to
>> standard standard scalar operation patterns.
It looks like there's some variety in the patterns used, e.g.:
(define_insn
"_vm3"
[(set (match_operand:VF_128 0 "register_operand" "=x,v")
(vec_merge:VF_128
(smaxmin:VF_128
(match_operand:VF_128 1 "register_operand" "0,v")
(match_operand:VF_128 2 "vector_operand"
"xBm,"))
(match_dup 1)
(const_int 1)))]
"TARGET_SSE"
"@
\t{%2, %0|%0, %2}
v\t{%2,
%1, %0|%0, %1,
%2}"
[(set_attr "isa" "noavx,avx")
(set_attr "type" "sse")
(set_attr "btver2_sse_attr" "maxmin")
(set_attr "prefix" "")
(set_attr "mode" "")])
makes the operand a full vector operation, which seems simpler.
The above would then be:
(vec_merge:V2DF
(op:V2DF
(reg:V2DF 85)
(vec_duplicate:V2DF (reg:DF 87)))
(reg/v:V2DF 85 [ x ])
(const_int 1 [0x1])]))
I guess technically the two have different faulting behaviour though,
since the smaxmin gets applied to all elements, not just element 0.
The patch seems very specific. E.g. why just PLUS, MINUS, MULT and DIV?
Thanks,
Richard
>>
>> gcc/
>>
>> PR target/54855
>> * simplify-rtx.c (simplify_binary_operation_1): Convert
>> VEC_CONCAT patterns to standard standard scalar operation
>> patterns.
>> * config/i386/sse.md (*_vm3): New.
>> (*_vm3): Likewise.
>>
>> gcc/testsuite/
>>
>> PR target/54855
>> * gcc.target/i386/pr54855-1.c: New test.
>> * gcc.target/i386/pr54855-2.c: Likewise.
>> * gcc.target/i386/pr54855-3.c: Likewise.
>> * gcc.target/i386/pr54855-4.c: Likewise.
>> * gcc.target/i386/pr54855-5.c: Likewise.
>> * gcc.target/i386/pr54855-6.c: Likewise.
>> * gcc.target/i386/pr54855-7.c: Likewise.
>
> PING:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00398.html
Re: [PATCH] Add __raw_visit and __raw_idx_visit, use INVOKE
On 14/05/19 17:46 +0100, Jonathan Wakely wrote:
This change simplifies visitation for variants, by using INVOKE for
the visit form, and explicitly specifying the tag types for raw
visitation, instead of inferring them from the return types of the
lambda functions used as visitors.
An additional tiny tweak.
Tested powerpc64le-linux, committed to trunk.
commit 10724a3fea78ab58b8e2fec3416c940e02739514
Author: Jonathan Wakely
Date: Wed May 15 22:01:47 2019 +0100
Qualify calls in std::visit and std::visit
* include/std/variant (visit, visit): Qualify calls to __do_visit.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index dc4bbb7f356..8c710c30de5 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1637,8 +1637,8 @@ namespace __variant
using _Tag = __detail::__variant::__deduce_visit_result<_Result_type>;
- return __do_visit<_Tag>(std::forward<_Visitor>(__visitor),
- std::forward<_Variants>(__variants)...);
+ return std::__do_visit<_Tag>(std::forward<_Visitor>(__visitor),
+ std::forward<_Variants>(__variants)...);
}
#if __cplusplus > 201703L
@@ -1649,8 +1649,8 @@ namespace __variant
if ((__variants.valueless_by_exception() || ...))
__throw_bad_variant_access("Unexpected index");
- return __do_visit<_Res>(std::forward<_Visitor>(__visitor),
- std::forward<_Variants>(__variants)...);
+ return std::__do_visit<_Res>(std::forward<_Visitor>(__visitor),
+ std::forward<_Variants>(__variants)...);
}
#endif
Re: preserve more debug stmts in gimple jump threading
On May 15, 2019, Richard Biener wrote: > On Wed, May 15, 2019 at 10:20 AM Alexandre Oliva wrote: >> >> Gimple jump threading does not duplicate forwarder blocks that might >> be present before or after the copied block. > Empty forwarder blocks I presume? Empty except for debug stmts and possibly a final conditional jump that, in the threading path, becomes unconditional. > I wonder if not copying empty forwarders is premature optimization > in that (hopefully) CFG cleanup is run after jump threading anyways? I don't think it's so much of an optimization as it is an extension. The code as it is can only really handle copying the initial block and another subsequent block. Threading through other "empty" blocks didsn't require as significant changes as copying them would have. If we were to change that, then we'd be extending jump threading to actually copy multiple blocks, empty or not. Not necessarily a bad thing, but there are comments in the code suggesting that hasn't really been tried. > If we'd copy the blocks the patch would be moot? Yes, but with a caveat. It's true that cfgcleanup would pretty much end up having the same or similar effect, consolidating debug stmts from empty blocks into successor or predecessor if possible and dropping them otherwise. What it would not do is to consolidate binds from the now-split paths into the confluence, like propagate_threaded_block_debug_into does. The proposed patch does not change that, and it shouldn't: the confluence binds stand on their own (*), very much like the binds we add after PHI nodes when entering SSA. That reduces the loss when we don't have a place to hold the debug stmts, and it helps bind resolution in var-tracking even when the incoming paths seem to have diverged in where they hold a variable, at least when the binds don't end up being reset for this very reason even when var-tracking dataflow could have figured out a common location among the incoming blocks. (*) though memory references in them might become wrong if they're before the second block and the second block changes the memory locations, it occurs to me now, without actually going back and checking whether the consolidation pays any attention to that. We shouldn't assume that just because we're now copying all intermediate blocks, debug info and all, the confluence binds cease to be useful. Rather, we should probably consider introducing them in other passes that split paths and introduce new confluences. -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
Re: C++ PATCH for CWG 2096, constraints on literal unions
On 5/13/19 6:07 PM, Marek Polacek wrote: This patch implements CWG 2096 which relaxes the constraints for literal unions. [basic.types]/p10 now says: A type is a literal type if... -- it is a union, at least one of its non-static data members is of non-volatile literal type, [...] check_field_decls is called with CLASSTYPE_LITERAL_P set to true, so we can re-set it after we've processed all fields. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2019-05-13 Marek Polacek CWG 2096 - constraints on literal unions. * class.c (check_field_decls): Initialize booleans directly. A union is literal if at least one of its non-static data members is of non-volatile literal type. OK, thanks. Jason
Re: [C++ PATCH] Fix up C++ loop construct debug info without -gno-statement-frontiers (PR debug/90197, take 2)
On 5/10/19 7:14 PM, Jakub Jelinek wrote: On Fri, May 10, 2019 at 04:26:47PM -0400, Jason Merrill wrote: That is strange. That seems to go back to Surely we should only set the incr location if it doesn't already have one, as would have been the case before that patch. So, like this then? Bootstrapped/regtested again on x86_64-linux and i686-linux: 2019-05-11 Jakub Jelinek PR debug/90197 * cp-gimplify.c (genericize_cp_loop): Emit a DEBUG_BEGIN_STMT before the condition (or if missing or constant non-zero at the end of the loop. Emit a DEBUG_BEGIN_STMT before the increment expression if any. Don't call protected_set_expr_location on incr if it already has a location. OK, thanks. Jason
Re: [PATCH] fortran: C++ support for generating C prototypes
On Wed, May 15, 2019 at 4:41 PM Jakub Jelinek wrote:
>
> On Sun, May 12, 2019 at 12:47:04AM +0300, Janne Blomqvist wrote:
> > --- a/gcc/fortran/parse.c
> > +++ b/gcc/fortran/parse.c
> > @@ -6331,6 +6331,24 @@ done:
> >}
> >
> >/* Dump C prototypes. */
> > + if (flag_c_prototypes || flag_c_prototypes_external)
> > +{
> > + fprintf (stdout,
> > +_("#include \n"
> > + "#ifdef __cplusplus\n"
> > + "#include \n"
> > + "#define FLOAT_COMPLEX std::complex\n"
> > + "#define DOUBLE_COMPLEX std::complex\n"
> > + "#define LONG_DOUBLE_COMPLEX std::complex\n"
> > + "extern \"C\" {\n"
> > + "#else\n"
> > + "#define FLOAT_COMPLEX float _Complex\n"
> > + "#define DOUBLE_COMPLEX double _Complex\n"
> > + "#define LONG_DOUBLE_COMPLEX long double _Complex\n"
> > + "#endif\n\n"));
>
> Two more things:
> 1) why the _() around the code snippet? Do you expect translators
>to translate the C snippets to something else or what?
Er, because originally I printed out these definitons as part of the
other fprintf call where a comment was printed, and when I moved it to
another location I forgot to remove the translation markers.
Committed r271261 and r271264 as obvious.
> 2) I don't think float _Complex is
>passed the same as std::complex and similar for others;
>std::complex is in libstdc++ a C++ class with with
>__complex__ float as its sole non-static data member and with non-trivial
>constructors; which means it is passed/returned via a hidden reference;
>when the argument is actually FLOAT_COMPLEX * or FLOAT_COMPLEX &,
>you except for aliasing don't have to care that much, but if
>that complex argument has VALUE attribute in Fortran and so the
>C prototype would be FLOAT_COMPLEX, then std::complex is
>passed in the end as std::complex &, while float _Complex
>the same as __complex__ float; and ditto for functions returning
>complex
Ugh, I guess that's right. Any good way around it? Except print a
warning in the header that passing std::complex<> by value doesn't
work?
--
Janne Blomqvist
Re: [PATCH] Allow opening file on multiple units
On Wed, May 15, 2019 at 9:30 PM Damian Rouson wrote: > > Could someone please update the Fortran 2018 status page on the wiki > to reflect this patch? Thanks for the reminder, done. -- Janne Blomqvist
PING^1: [PATCH] i386: Add standard scalar operation patterns
On Thu, Feb 7, 2019 at 9:49 AM H.J. Lu wrote: > > Standard scalar operation patterns which preserve the rest of the vector > look like > > (vec_merge:V2DF >(vec_duplicate:V2DF > (op:DF (vec_select:DF (reg/v:V2DF 85 [ x ]) > (parallel [ (const_int 0 [0])])) > (reg:DF 87)) >(reg/v:V2DF 85 [ x ]) >(const_int 1 [0x1])])) > > Add such pattens to i386 backend and convert VEC_CONCAT patterns to > standard standard scalar operation patterns. > > gcc/ > > PR target/54855 > * simplify-rtx.c (simplify_binary_operation_1): Convert > VEC_CONCAT patterns to standard standard scalar operation > patterns. > * config/i386/sse.md (*_vm3): New. > (*_vm3): Likewise. > > gcc/testsuite/ > > PR target/54855 > * gcc.target/i386/pr54855-1.c: New test. > * gcc.target/i386/pr54855-2.c: Likewise. > * gcc.target/i386/pr54855-3.c: Likewise. > * gcc.target/i386/pr54855-4.c: Likewise. > * gcc.target/i386/pr54855-5.c: Likewise. > * gcc.target/i386/pr54855-6.c: Likewise. > * gcc.target/i386/pr54855-7.c: Likewise. PING: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00398.html -- H.J.
Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git
On Wed, May 15, 2019 at 11:34:34AM +0300, Maxim Kuvyrkov wrote: > > On May 15, 2019, at 12:20 AM, Segher Boessenkool > > wrote: > > On Tue, May 14, 2019 at 07:11:18PM +0300, Maxim Kuvyrkov wrote: > >> This patch adds scripts to contrib/ to migrate full history of GCC's > >> subversion repository to git. My hope is that these scripts will > >> finally allow GCC project to migrate to Git. > > > > Thank you for doing this. > > > >> The result of the conversion is at > >> https://github.com/maxim-kuvyrkov/gcc/branches/all . Branches with > >> "@rev" suffixes represent branch points. The conversion is still > >> running, so not all branches may appear right away. > > > > What exactly is a branch point here? > > Branch point corresponds to parent branch's revision at fork. > > > Why is it useful to have tags > > at branch points? > > This is to speedup git-svn, which creates uses such entries internally. We > need them for conversion's internals; I deleted them from github copy to > avoid clutter. Ah! Great. Looks better now :-) Has it finished conversion yet? I don't see all branches. Segher
Re: PATCH, testsuite, x86] Make the requires test for CET a bit stronger.
On Wed, May 15, 2019 at 8:29 PM Iain Sandoe wrote:
>
>
> > On 15 May 2019, at 19:02, Uros Bizjak wrote:
> >
> > On Wed, May 15, 2019 at 6:48 PM Iain Sandoe wrote:
> >>
> >> Hi,
> >>
> >> There is at least one assembler that supports ‘setssbsy' but not “endbr*”.
> >> We can catch this by adding "-fcf-protection” to the
> >> check_effective_target_cet test.
> >
> > How about adding asm ("endbr") to the source?
>
> it would have to be ‘endbr32’ or ‘endbr64’ I suppose.. I guess
>
> #if __LP64__
> asm (“endbr64”);
> #else
> asm (“endbr32”):
> #endif
>
> would work?
>
> AFAICT that’s effectively what adding -fcf-protection does.
>
> I’m happy with either.
No need to complicate things too much, your original patch is OK.
Thanks,
Uros.
> Iain
>
>
Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git
On 5/15/19, Maxim Kuvyrkov wrote: >> On May 15, 2019, at 2:19 PM, Richard Biener >> wrote: >> >> On Tue, May 14, 2019 at 6:11 PM Maxim Kuvyrkov >> wrote: >>> >>> This patch adds scripts to contrib/ to migrate full history of GCC's >>> subversion repository to git. My hope is that these scripts will finally >>> allow GCC project to migrate to Git. >>> >>> The result of the conversion is at >>> https://github.com/maxim-kuvyrkov/gcc/branches/all . Branches with "@rev" >>> suffixes represent branch points. The conversion is still running, so >>> not all branches may appear right away. >>> >>> The scripts are not specific to GCC repo and are usable for other >>> projects. In particular, they should be able to convert downstream GCC >>> svn repos. >>> >>> The scripts convert svn history branch by branch. They rely on git-svn >>> on convert individual branches. Git-svn is a good tool for converting >>> individual branches. It is, however, either very slow at converting the >>> entire GCC repo, or goes into infinite loop. >>> >>> There are 3 scripts: >>> >>> - svn-git-repo.sh: top level script to convert entire repo or a part of >>> it (e.g., branches/), >>> - svn-list-branches.sh: helper script to output branches and their >>> parents in bottom-up order, >>> - svn-git-branch.sh: helper script to convert a single branch. >>> >>> Whenever possible, svn-git-branch.sh uses existing git branches as >>> caches. >>> >>> What are your questions and comments? >> >> Any comments on how it deals with "errors" like removing trunk which >> happened a few times? >> (not sure what other "errors" Eric refers to reposurgeon "deals" with...) > > Stock git-svn can deal with deleted parents; e.g., for the first deletion of > trunk, git-svn treats trunk@180802 as a /generic/ parent path for trunk, and > happily follows its history. > >> >> I suppose it converts only history of not deleted branches? > > The scripts can convert history of deleted and moved branches. E.g., > branches/gcc-3_2-rhl8-branch was moved (which is copy and delete for svn) to > branches/redhat/gcc-3_2-rhl8-branch around revision 95470, so one would need > to point the scripts to branches/gcc-3_2-rhl8-branch@95470 to convert its > history. Something like: > > ./svn-git-repo.sh --repo $HOME/gcc-branches --svnpath > branches/gcc-3_2-rhl8-branch@95470 > >> >> For the official converted repo do we really want all (old) >> development branches to be in the >> main git repo? I suppose we could create a readonly git from the >> state of the whole repository >> at the point of conversion (and also keep the SVN in readonly mode), >> just to make migration >> of content we want easy in the future? > > Having a single full repo is simpler than having the main repo and the full > one with all the history. So, unless full repo is twice the size of the > main one, let's keep all the branches. > > We can also give a shout to representatives of RedHat, Google, and others to > voluntarily remove their old maintenance branches from the repo, and, > possibly, stash them somewhere on github. > >> >>> The attached is cleaned up version, which hasn't been fully tested yet; >>> typos and other silly mistakes are likely. OK to commit after testing? >> >> Thanks for taking up this ball! > > -- > Maxim Kuvyrkov > www.linaro.org > Wasn't Eric S. Raymond working on his own conversion of the GCC repo from SVN to Git? Whatever happened to his?
Re: [PATCH] Allow opening file on multiple units
Could someone please update the Fortran 2018 status page on the wiki to reflect this patch? I would volunteer to do it myself, but I've tried on at least 3 occasions (including today) to set up an account or generate a new password and every attempt fails with a warning that I'm being locked out because of too many requests in a short period of time. Is anyone aware of other lines in the status page that can also be updated based on recent patches. If so, please update those too. Keeping the wiki up-to-date would be a great time-savings to whomever takes on responding to the Fortran compiler status survey that Ian Chivers and Jane Sleightholme publish periodically in the ACM Fortran Forum. I think Paul is usually the one to respond and I know it costs him a great deal of time to do so. I wish I could help by keeping the wiki up-to-date. I promise to do so if I ever manage to survive the login setup process. Damian On Wed, May 15, 2019 at 9:02 AM Steve Kargl wrote: > > On Wed, May 15, 2019 at 04:24:47PM +0300, Janne Blomqvist wrote: > > As of Fortran 2018 it's allowed to open the same file on multiple > > units. > > > > fortran/ChangeLog: > > > > 2019-05-15 Janne Blomqvist > > > > PR fortran/90461 > > * io/open.c (new_unit): Don't check if the file is already open > > for F2018. > > > > testsuite/ChangeLog: > > > > 2019-05-15 Janne Blomqvist > > > > PR fortran/90461 > > * gfortran.dg/open_errors_2.f90: Add -std=f2008, adjust line number. > > * gfortran.dg/open_errors_3.f90: New test. > > > > Regtested on x86_64-pc-linux-gnu, Ok for trunk? > > Yes. > > -- > Steve
Re: PATCH, testsuite, x86] Make the requires test for CET a bit stronger.
> On 15 May 2019, at 19:02, Uros Bizjak wrote:
>
> On Wed, May 15, 2019 at 6:48 PM Iain Sandoe wrote:
>>
>> Hi,
>>
>> There is at least one assembler that supports ‘setssbsy' but not “endbr*”.
>> We can catch this by adding "-fcf-protection” to the
>> check_effective_target_cet test.
>
> How about adding asm ("endbr") to the source?
it would have to be ‘endbr32’ or ‘endbr64’ I suppose.. I guess
#if __LP64__
asm (“endbr64”);
#else
asm (“endbr32”):
#endif
would work?
AFAICT that’s effectively what adding -fcf-protection does.
I’m happy with either.
Iain
Re: [PATCH, i386]: Macroize DIVMOD patterns
On Wed, May 15, 2019 at 2:29 PM Uros Bizjak wrote:
>
> I somehow missed this testsuite failure...
>
> Attached patch is needed. I'll commit it later today.
Now regtested on x86_64-linux-gnu {,-m32} and committed with the
following ChangeLog:
2019-05-15 Uroš Bizjak
* config/i386/i386-expand.c (ix86_split_idivmod): Rename
signed_p argument to unsigned_p. Update all uses for changed polarity.
* config/i386/i386.md (u_bool): Handle DIV and UDIV RTXes.
(divmod splitters): Use u_bool macro in the call to ix86_split_idivmod.
Uros.
> On Wed, May 15, 2019 at 2:16 PM Richard Biener
> wrote:
> >
> > On Tue, May 14, 2019 at 6:23 PM Uros Bizjak wrote:
> > >
> > > Recent work by Richard Sandiford [1] enabled the possibility to
> > > macroize DIVMOD patterns in i386.md.
> > >
> > > 2019-05-14 Uroš Bizjak
> > >
> > > * config/i386/i386.md (any_div): New code iterator.
> > > (paired_mod): New code attribute.
> > > (sgnprefix): Handle DIV and UDIV RTXes.
> > > (u): Ditto.
> > > (divmod4): Macroize expander from divmod4
> > > and udivmod4 patterns using any_div code iterator.
> > > (divmod splitters): Macroize splitters using any_div code iterator.
> > > (*udivmodsi4_pow2_zext_1): Use exactl_log2 in insn condition.
> > > (*udivmodsi4_pow2_zext_2): Ditto.
> > > (*divmod4_noext): Macroize insn from *divmod4_noext
> > > and *udivmod4_noext patterns using any_div code iterator.
> > > (*divmod4_noext_zext_1): Macroize insn from
> > > *divmod4_noext_zext_1 and *udivmod4_noext_zext_1
> > > patterns using any_div code iterator.
> > > (*divmod4_noext_zext_2): Macroize insn from
> > > *divmod4_noext_zext_2 and *udivmod4_noext_zext_2
> > > patterns using any_div code iterator.
> > > (divmodhiqi3): Macroize insn from divmodhiqi3 and
> > > udivmodhiqi3 patterns using any_extend code iterator.
> > >
> > > The patch also reorders DIVMOD patterns a bit.
> > >
> > > Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> > >
> > > Committed to mainline SVN.
> >
> > I see
> >
> > FAIL: gcc.target/i386/udivmod-1.c execution test
> >
> > on x86_64.
> >
> > > [1] https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00560.html
> > >
> > > Uros.
Re: PATCH, testsuite, x86] Make the requires test for CET a bit stronger.
On Wed, May 15, 2019 at 6:48 PM Iain Sandoe wrote:
>
> Hi,
>
> There is at least one assembler that supports ‘setssbsy' but not “endbr*”.
> We can catch this by adding "-fcf-protection” to the
> check_effective_target_cet test.
How about adding asm ("endbr") to the source?
Uros.
> OK for trunk?
> Iain
>
> gcc/testsuite/
>
> *lib/target-supports.exp (check_effective_target_cet): Add the
> fcf-protection flag to tet CET test.
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index da132369a4..b7c6bb67ce 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -9212,7 +9212,7 @@ proc check_effective_target_cet { } {
> {
> asm ("setssbsy");
> }
> -} "-O2" ]
> +} "-O2 -fcf-protection" ]
> }
>
> # Return 1 if target supports floating point "infinite"
> --
> 2.17.1
Re: [PATCH, Darwin, PowerPC, testsuite] Exclude Darwin from VSX, Power8 and Power9 tests.
Hi Segher, > On 15 May 2019, at 18:24, Segher Boessenkool > wrote: > > On Wed, May 15, 2019 at 12:54:03PM +0100, Iain Sandoe wrote: >> If we build Darwin with a modern assembler, then it might well >> recognise insns that cannot be used on current Darwin systems. >> >> The patch augments the tests for feature support for VSX, >> power8 and power9 to exclude Darwin even if the assembler can >> handle the instructions. > > Cannot be used, in what way? *_ok test only if we can *compile* for > some subtarget. What blows up? It cISTR there were other problems too - I could revert the patch locally and remind myself (I am motivated to have parity between the cctools and newer assemblers in coverage on Darwin for now, and then to try expanding the horizons when the basics are working well). > The current tests aren't great, we should compile some actual code to > test if the compiler allows building for p8 for example -- more than > just the assembler. Maybe it is enough to have some register input > that requires VSX registers on the asm in the test, for example. Yes, that could be more general (AIX also has similar exclusions to Darwin), if the test results are cached it doesn’t hurt to try a bit harder. Iain
Re: [PATCH, Darwin, PowerPC, testsuite] Exclude Darwin from VSX, Power8 and Power9 tests.
Hi Iain, On Wed, May 15, 2019 at 12:54:03PM +0100, Iain Sandoe wrote: > If we build Darwin with a modern assembler, then it might well > recognise insns that cannot be used on current Darwin systems. > > The patch augments the tests for feature support for VSX, > power8 and power9 to exclude Darwin even if the assembler can > handle the instructions. Cannot be used, in what way? *_ok test only if we can *compile* for some subtarget. What blows up? The current tests aren't great, we should compile some actual code to test if the compiler allows building for p8 for example -- more than just the assembler. Maybe it is enough to have some register input that requires VSX registers on the asm in the test, for example. Segher
PATCH, testsuite, x86] Make the requires test for CET a bit stronger.
Hi,
There is at least one assembler that supports ‘setssbsy' but not “endbr*”.
We can catch this by adding "-fcf-protection” to the check_effective_target_cet
test.
OK for trunk?
Iain
gcc/testsuite/
*lib/target-supports.exp (check_effective_target_cet): Add the
fcf-protection flag to tet CET test.
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index da132369a4..b7c6bb67ce 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9212,7 +9212,7 @@ proc check_effective_target_cet { } {
{
asm ("setssbsy");
}
-} "-O2" ]
+} "-O2 -fcf-protection" ]
}
# Return 1 if target supports floating point "infinite"
--
2.17.1
Re: [PATCH v2 2/3] Add predict_doloop_p target hook
On Wed, May 15, 2019 at 10:53:43AM +0200, Richard Biener wrote: > I wonder if making the doloop patterns (tried to find them in rs6000.md, > but I only see define_expands with no predicates/alternatives...) "doloop_end" --> "ctr" --> "_" (all consecutive in rs6000.md btw.) Alternative 0 in "_" are the actual looping instructions; the other alternatives are for the uncommon case where we ended up not being able to use this insn after all. > accept any counter register, just have a preference on that special > counter reg and have the define_insn deal with RA allocating another > one by emitting a regular update & branch-on-zero? That is what those other alternatives do. It is expensive, and cannot even *work* in all cases. We have no generic "branch on (not) zero" in Power, btw. Archs that do can use that as a doloop, if they choose IVs that end the loop at 0. > That is, the penalty of doing that shouldn't be too big and thus > we can more optimistically cost & handle "doloops"? We have done that for ages, in the RTL level doloop handling. With newer hardware it becomes more and more expensive to guess wrong. > I guess > the doloop.c checks are quite too strict because we have to > rely on RA being able to allocate that reg and as soon as we > need to spill it using a general reg with update & branch-on-zero > will be cheaper anyways? (Update, compare, branch, for us). We can predict quite well where the count register will be unavailable to our doloops. The cost if we are allocated a GPR isn't so bad: it costs an insn or maybe two more than if we made optimal code (without doloop). But we can be allocated a floating point register, or memory, instead. That is heavily discouraged (by making it more expensive), but it can still happen. This is a jump_insn so it cannot get any reloads, either; but even if it could, that is an *expensive* thing to do. Segher
Re: abstract out EH propagation cleanups
Sorry, I meant to PING this one.
Aldy
On Wed, May 8, 2019 at 5:08 PM Aldy Hernandez wrote:
>
> On 5/8/19 2:30 AM, Richard Biener wrote:
> > On Tue, May 7, 2019 at 11:55 PM Jeff Law wrote:
> >>
> >> On 5/7/19 3:45 AM, Richard Biener wrote:
> >>> On Tue, May 7, 2019 at 11:13 AM Aldy Hernandez wrote:
>
> Hi.
>
> We seem to have numerous copies of the same EH propagation cleanups
> scattered throughout the compiler. The attached patch moves all the
> logic into one class that allows for easy marking of statements and
> automatic cleanup once it goes out of scope.
>
> Tested on x86-64 Linux.
>
> OK for trunk? (*)
> >>>
> >>> Ugh :/
> >>>
> >>> First of all I don't like the fact that the actual cleanup is done
> >>> upon constructor execution. Please make it explicit
> >>> and in the constructor assert that nothing is to be done.
> >> I'm of a mixed mind here. I have railed against implicit code being run
> >> behind my back for decades.
> >>
> >> However as I've had to debug locking issues and the like in other C++
> >> codebases I've become more and more of a fan of RAII and its basic
> >> concepts. This has made me more open to code running behind my back
> >> like this implicitly when the object gets destroyed.
> >>
> >> There's something to be said for embedding this little class into other
> >> objects like Aldy has done and just letting things clean up
> >> automatically as the object goes out of scope. No more missing calls to
> >> run the cleanup bits, it "just works".
> >>
> >> But I won't object if you want it to be more explicit. I've been there
> >> and understand why one might want the cleanup step to be explicit.
> >>
> >>
> >>
> >>>
> >>> Then I'm not sure this is a 1:1 transform since for example
> >>>
> >>> @@ -1061,8 +1173,6 @@
> >>> substitute_and_fold_dom_walker::before_dom_children (basic_block bb)
> >>> }
> >>>
> >>> gimple *old_stmt = stmt;
> >>> - bool was_noreturn = (is_gimple_call (stmt)
> >>> - && gimple_call_noreturn_p (stmt));
> >>>
> >>> /* Replace real uses in the statement. */
> >>> did_replace |= substitute_and_fold_engine->replace_uses_in (stmt);
> >>> @@ -1110,25 +1220,7 @@
> >>> substitute_and_fold_dom_walker::before_dom_children (basic_block bb)
> >>> /* Now cleanup. */
> >>> if (did_replace)
> >>> {
> >>> ...
> >>> + fixups.record_change (old_stmt, stmt);
> >>>
> >>> here we no longer can reliably determine whether old_stmt was noreturn
> >>> since
> >>> we substitute into stmt itself. It's no longer a correctness issue if
> >>> we do _not_
> >>> fixup_noreturn since we now have GF_CALL_CTRL_ALTERING, it's merely
> >>> an optimization issue. So there may be no testcase for this (previously
> >>> such
> >>> cases ICEd).
> >> But AFAICT we don't care in the case Aldy is changing. If we really
> >> want to know if the old statement was a noreturn we can test prior to
> >> queing it.
> >
> > The code isn't doing what it did before after the change. That's a bug.
>
> If this is indeed a problem in the cases that I changed, it's easily
> fixed by marking the statement ahead of time and keeping track of the
> noreturn bit (as I have done in the attached patch).
>
> >
> > To be more explicit here - adding this kind of new and fancy C++ stuff
> > just for the sake of it, thereby adding yet _another_ way of handling these
> > things instead of forcing it a new way (remove the other APIs this
> > encapsulates) is very bad(TM) IMHO, both for maintainance and for
> > new people coming around trying to understand GCC.
>
> I'm not adding them for the sake of it. I'm adding them because we have
> 5 copies of the virtually the same code, and if I add any (additional)
> propagation smarts to the compiler, I'm going to have to add a 6th copy.
> My patch abstracts away 4 out of the 5 versions, and I am volunteering
> to fix the last one (forwprop) as an incremental patch.
>
> I don't agree that this is worse. On the contrary, I am transforming
> multiple copies of this:
>
> - bool was_noreturn = (is_gimple_call (stmt)
> - && gimple_call_noreturn_p (stmt));
> ...
> ...
> - /* If we cleaned up EH information from the statement,
> -remove EH edges. */
> - if (maybe_clean_or_replace_eh_stmt (old_stmt, stmt))
> - bitmap_set_bit (need_eh_cleanup, bb->index);
> -
> - /* If we turned a not noreturn call into a noreturn one
> -schedule it for fixup. */
> - if (!was_noreturn
> - && is_gimple_call (stmt)
> - && gimple_call_noreturn_p (stmt))
> - stmts_to_fixup.safe_push (stmt);
> -
> - if (gimple_assign_single_p (stmt))
> - {
> - tree rhs = gimple_assign_rhs1 (stmt);
> - if (TREE_CODE (rhs) == ADDR_EXPR)
> - recompute_tree_invariant_for_addr_expr
Re: abstract out EH propagation cleanups
PING
On Wed, May 8, 2019 at 5:18 PM Aldy Hernandez wrote:
>
>
>
> On 5/8/19 2:30 AM, Richard Biener wrote:
> > On Tue, May 7, 2019 at 11:55 PM Jeff Law wrote:
> >>
> >> On 5/7/19 3:45 AM, Richard Biener wrote:
> >>> On Tue, May 7, 2019 at 11:13 AM Aldy Hernandez wrote:
>
> Hi.
>
> We seem to have numerous copies of the same EH propagation cleanups
> scattered throughout the compiler. The attached patch moves all the
> logic into one class that allows for easy marking of statements and
> automatic cleanup once it goes out of scope.
>
> Tested on x86-64 Linux.
>
> OK for trunk? (*)
> >>>
> >>> Ugh :/
> >>>
> >>> First of all I don't like the fact that the actual cleanup is done
> >>> upon constructor execution. Please make it explicit
> >>> and in the constructor assert that nothing is to be done.
> >> I'm of a mixed mind here. I have railed against implicit code being run
> >> behind my back for decades.
> >>
> >> However as I've had to debug locking issues and the like in other C++
> >> codebases I've become more and more of a fan of RAII and its basic
> >> concepts. This has made me more open to code running behind my back
> >> like this implicitly when the object gets destroyed.
> >>
> >> There's something to be said for embedding this little class into other
> >> objects like Aldy has done and just letting things clean up
> >> automatically as the object goes out of scope. No more missing calls to
> >> run the cleanup bits, it "just works".
> >>
> >> But I won't object if you want it to be more explicit. I've been there
> >> and understand why one might want the cleanup step to be explicit.
> >>
> >>
> >>
> >>>
> >>> Then I'm not sure this is a 1:1 transform since for example
> >>>
> >>> @@ -1061,8 +1173,6 @@
> >>> substitute_and_fold_dom_walker::before_dom_children (basic_block bb)
> >>> }
> >>>
> >>> gimple *old_stmt = stmt;
> >>> - bool was_noreturn = (is_gimple_call (stmt)
> >>> - && gimple_call_noreturn_p (stmt));
> >>>
> >>> /* Replace real uses in the statement. */
> >>> did_replace |= substitute_and_fold_engine->replace_uses_in (stmt);
> >>> @@ -1110,25 +1220,7 @@
> >>> substitute_and_fold_dom_walker::before_dom_children (basic_block bb)
> >>> /* Now cleanup. */
> >>> if (did_replace)
> >>> {
> >>> ...
> >>> + fixups.record_change (old_stmt, stmt);
> >>>
> >>> here we no longer can reliably determine whether old_stmt was noreturn
> >>> since
> >>> we substitute into stmt itself. It's no longer a correctness issue if
> >>> we do _not_
> >>> fixup_noreturn since we now have GF_CALL_CTRL_ALTERING, it's merely
> >>> an optimization issue. So there may be no testcase for this (previously
> >>> such
> >>> cases ICEd).
> >> But AFAICT we don't care in the case Aldy is changing. If we really
> >> want to know if the old statement was a noreturn we can test prior to
> >> queing it.
> >
> > The code isn't doing what it did before after the change. That's a bug.
> >
> > To be more explicit here - adding this kind of new and fancy C++ stuff
> > just for the sake of it, thereby adding yet _another_ way of handling these
> > things instead of forcing it a new way (remove the other APIs this
> > encapsulates) is very bad(TM) IMHO, both for maintainance and for
> > new people coming around trying to understand GCC.
> >
> > Not to say that all the places that are refactored with this patch
> > look sligtly different and thus the pattern doesnt' exactly match
> > (leading to issues like the one I pointed out above).
> >
> > So - please no.
> >
> > Richard.
> >
> >>
> >>>
> >>> I'm also not sure I like to put all these (unrelated) things into a
> >>> single class,
> >>> it really also hides the details of what is performed immediately and what
> >>> delayed and what kind of changes - this makes understanding of pass
> >>> transforms hard.
> >> On the other hand this class defines a contract for what it can and will
> >> do for us and allows us to bring consistency in that handling. We
> >> declare manual management of this stuff verboten. Ideally we'd declare
> >> the class final and avoid derivation, but I doubt we can do that
> >> immediately.
> >>
> >> Jeff
>
> BTW, in case it wasn't clear. I do understand that not all copies are
> identical, that is why the interface has the recompute_invariants and
> m_todo_flags fields. It is *supposed* to work as before, and it if
> isn't, it's a bug and I'll gladly fix it.
>
> Aldy
Re: [PATCH v2 3/3] Consider doloop cmp use in ivopts
On Wed, May 15, 2019 at 10:47:31AM +0200, Richard Biener wrote: > Ah, so the key issue is that the doloop IV is "free"? That > is, it doesn't consume a general register and whatnot? That > is allocating this IV doesn't really interfere with other IVs? That is one half of it, yes. > But can other uses be based on the doloop IV easily (if the > IV doesn't reside in a general reg?)? Getting the value of the count reg can be expensive, that is the other half of it. > Otherwise I understand that IVOPTs doesn't properly cost > the doloop IV update and conditional branch. Currently it doesn't even *know* something is or isn't a doloop. And yeah that matters a lot for proper costing, on all targets that have a doloop. > That's clearly > something we should fix (maybe even indepenently on other > changes). One important thing is that we need to base costs > on a common base to not compare apples and oranges, didn't > dig into your patch in detail enough to see whether it > fits into the general cost model or whether it is a hack > ontop of everything. The different cost for a doloop is pretty easy... Might have to be a target hook though; on Power the decrement + compare-to-zero are "free", while on some other targets only the "compare" is. The cost for using the IV... For us we could just disallow it being used at all (except for the looping itself of course), but not sure what is optimal in general. Another hook? Segher
Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided
On Wed, May 15, 2019 at 03:59:39PM +, Szabolcs Nagy wrote: > On 15/05/2019 16:37, Rich Felker wrote: > > On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote: > >> On Wed, 15 May 2019 at 16:37, Rich Felker wrote: > >>> On Wed, May 15, 2019 at 01:55:30PM +, Szabolcs Nagy wrote: > can support both normal elf and fdpic elf so you can test/use > an fdpic toolchain on a system with mmu, but this requires > different dynamic linker name ..otherwise one has to run > executables in a chroot or separate mount namespace to change > the dynamic linker) > >>> > >>> Indeed, it's a bad idea to make them clash. > >>> > >> > >> Not sure to understand your point: indeed FDPIC binaries work > >> on a system with mmu, provided you have the right dynamic > >> linker in the right place, as well as the needed runtime libs (libc, > >> etc) > >> > >> Do you want me to change anything here? > > > > I think the concern is that if the PT_INTERP name is the same for > > binaries with different ABIs, you wouldn't be able to have both > > present in the same root fs, and this would make it more of a pain to > > debug fdpic binaries on a full (with-mmu) host. > > > > musl always uses a different PT_INTERP name for each ABI combination, > > so I guess the question is whether uclibc or whatever other libc > > you're intending people to use would also want to do this. > > glibc uses different names now for new abis, so i was expecting > some *_DYNAMIC_LINKER update, but it seems uclibc always uses > the same fixed name > > /lib/ld-uClibc.so.0 > > i guess it makes sense for them since iirc uclibc can change > its runtime abi based on lot of build time config so having > different name for each abi variant may be impractical. Yes, this "feature" of uclibc was was of the key motivations behind the creation of musl... :-) Rich
Re: [PATCH] Allow opening file on multiple units
On Wed, May 15, 2019 at 04:24:47PM +0300, Janne Blomqvist wrote: > As of Fortran 2018 it's allowed to open the same file on multiple > units. > > fortran/ChangeLog: > > 2019-05-15 Janne Blomqvist > > PR fortran/90461 > * io/open.c (new_unit): Don't check if the file is already open > for F2018. > > testsuite/ChangeLog: > > 2019-05-15 Janne Blomqvist > > PR fortran/90461 > * gfortran.dg/open_errors_2.f90: Add -std=f2008, adjust line number. > * gfortran.dg/open_errors_3.f90: New test. > > Regtested on x86_64-pc-linux-gnu, Ok for trunk? Yes. -- Steve
[PATCH] Testsuite: Add s390 exceptions for gen-vect
Hi,
this patch changes three gen-vect testcases so they do not expect
vectorization of an unaligned access. Vectorization happens regardless,
we just ignore misalignment.
Regards
Robin
--
gcc/testsuite/ChangeLog:
2019-05-15 Robin Dapp
* gcc.dg/tree-ssa/gen-vect-26.c: Do not expect unaligned access
vectorization on s390.
* gcc.dg/tree-ssa/gen-vect-28.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-32.c: Likewise.
commit 52f15c1c49040c55a50c22e793f4ce5600a8324a
Author: Robin Dapp
Date: Tue May 14 12:15:05 2019 +0200
Add s390 exception to gen-vect tests.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c
index 8e5f1410612..4293b480815 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c
@@ -30,5 +30,5 @@ int main ()
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { ! avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { target { ! avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! "avr-*-* s390-*-*" } } } } */
+/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { target { ! "avr-*-* s390-*-*" } } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c
index ce97e0970b5..70cfe9d60ed 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c
@@ -38,5 +38,5 @@ int main (void)
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { ! avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { target { ! avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! "avr-*-* s390-*-*" } } } } */
+/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { target { ! "avr-*-* s390-*-*" } } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c
index 8fce4385d0b..62c84b8b982 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c
@@ -30,4 +30,4 @@ int main ()
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { ! avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! "avr-*-* s390-*-*" } } } } */
Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided
On 15/05/2019 16:37, Rich Felker wrote: > On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote: >> On Wed, 15 May 2019 at 16:37, Rich Felker wrote: >>> On Wed, May 15, 2019 at 01:55:30PM +, Szabolcs Nagy wrote: can support both normal elf and fdpic elf so you can test/use an fdpic toolchain on a system with mmu, but this requires different dynamic linker name ..otherwise one has to run executables in a chroot or separate mount namespace to change the dynamic linker) >>> >>> Indeed, it's a bad idea to make them clash. >>> >> >> Not sure to understand your point: indeed FDPIC binaries work >> on a system with mmu, provided you have the right dynamic >> linker in the right place, as well as the needed runtime libs (libc, etc) >> >> Do you want me to change anything here? > > I think the concern is that if the PT_INTERP name is the same for > binaries with different ABIs, you wouldn't be able to have both > present in the same root fs, and this would make it more of a pain to > debug fdpic binaries on a full (with-mmu) host. > > musl always uses a different PT_INTERP name for each ABI combination, > so I guess the question is whether uclibc or whatever other libc > you're intending people to use would also want to do this. glibc uses different names now for new abis, so i was expecting some *_DYNAMIC_LINKER update, but it seems uclibc always uses the same fixed name /lib/ld-uClibc.so.0 i guess it makes sense for them since iirc uclibc can change its runtime abi based on lot of build time config so having different name for each abi variant may be impractical.
[PATCH] soft-fp: Update soft-fp from glibc
This patch is updating all soft-fp from glibc, most changes are copyright years update, and changes other than years update are * soft-fp/extenddftf2.c: Use "_FP_W_TYPE_SIZE < 64" to check if 4_FP_W_TYPEs are used for IEEE quad precision. * soft-fp/extendhftf2.c: Likewise. * soft-fp/extendsftf2.c: Likewise. * soft-fp/extendxftf2.c: Likewise. * soft-fp/trunctfdf2.c: Likewise. * soft-fp/trunctfhf2.c: Likewise. * soft-fp/trunctfsf2.c: Likewise. * soft-fp/trunctfxf2.c: Likewise. * config/rs6000/ibm-ldouble.c: Likewise. OK for trunk? Thanks. H.J. --- libgcc/config/rs6000/ibm-ldouble.c | 4 ++-- libgcc/soft-fp/adddf3.c| 2 +- libgcc/soft-fp/addsf3.c| 2 +- libgcc/soft-fp/addtf3.c| 2 +- libgcc/soft-fp/divdf3.c| 2 +- libgcc/soft-fp/divsf3.c| 2 +- libgcc/soft-fp/divtf3.c| 2 +- libgcc/soft-fp/double.h| 2 +- libgcc/soft-fp/eqdf2.c | 2 +- libgcc/soft-fp/eqsf2.c | 2 +- libgcc/soft-fp/eqtf2.c | 2 +- libgcc/soft-fp/extenddftf2.c | 4 ++-- libgcc/soft-fp/extended.h | 2 +- libgcc/soft-fp/extendhftf2.c | 4 ++-- libgcc/soft-fp/extendsfdf2.c | 2 +- libgcc/soft-fp/extendsftf2.c | 4 ++-- libgcc/soft-fp/extendxftf2.c | 4 ++-- libgcc/soft-fp/fixdfdi.c | 2 +- libgcc/soft-fp/fixdfsi.c | 2 +- libgcc/soft-fp/fixdfti.c | 2 +- libgcc/soft-fp/fixhfti.c | 2 +- libgcc/soft-fp/fixsfdi.c | 2 +- libgcc/soft-fp/fixsfsi.c | 2 +- libgcc/soft-fp/fixsfti.c | 2 +- libgcc/soft-fp/fixtfdi.c | 2 +- libgcc/soft-fp/fixtfsi.c | 2 +- libgcc/soft-fp/fixtfti.c | 2 +- libgcc/soft-fp/fixunsdfdi.c| 2 +- libgcc/soft-fp/fixunsdfsi.c| 2 +- libgcc/soft-fp/fixunsdfti.c| 2 +- libgcc/soft-fp/fixunshfti.c| 2 +- libgcc/soft-fp/fixunssfdi.c| 2 +- libgcc/soft-fp/fixunssfsi.c| 2 +- libgcc/soft-fp/fixunssfti.c| 2 +- libgcc/soft-fp/fixunstfdi.c| 2 +- libgcc/soft-fp/fixunstfsi.c| 2 +- libgcc/soft-fp/fixunstfti.c| 2 +- libgcc/soft-fp/floatdidf.c | 2 +- libgcc/soft-fp/floatdisf.c | 2 +- libgcc/soft-fp/floatditf.c | 2 +- libgcc/soft-fp/floatsidf.c | 2 +- libgcc/soft-fp/floatsisf.c | 2 +- libgcc/soft-fp/floatsitf.c | 2 +- libgcc/soft-fp/floattidf.c | 2 +- libgcc/soft-fp/floattihf.c | 2 +- libgcc/soft-fp/floattisf.c | 2 +- libgcc/soft-fp/floattitf.c | 2 +- libgcc/soft-fp/floatundidf.c | 2 +- libgcc/soft-fp/floatundisf.c | 2 +- libgcc/soft-fp/floatunditf.c | 2 +- libgcc/soft-fp/floatunsidf.c | 2 +- libgcc/soft-fp/floatunsisf.c | 2 +- libgcc/soft-fp/floatunsitf.c | 2 +- libgcc/soft-fp/floatuntidf.c | 2 +- libgcc/soft-fp/floatuntihf.c | 2 +- libgcc/soft-fp/floatuntisf.c | 2 +- libgcc/soft-fp/floatuntitf.c | 2 +- libgcc/soft-fp/gedf2.c | 2 +- libgcc/soft-fp/gesf2.c | 2 +- libgcc/soft-fp/getf2.c | 2 +- libgcc/soft-fp/half.h | 2 +- libgcc/soft-fp/ledf2.c | 2 +- libgcc/soft-fp/lesf2.c | 2 +- libgcc/soft-fp/letf2.c | 2 +- libgcc/soft-fp/muldf3.c| 2 +- libgcc/soft-fp/mulsf3.c| 2 +- libgcc/soft-fp/multf3.c| 2 +- libgcc/soft-fp/negdf2.c| 2 +- libgcc/soft-fp/negsf2.c| 2 +- libgcc/soft-fp/negtf2.c| 2 +- libgcc/soft-fp/op-1.h | 2 +- libgcc/soft-fp/op-2.h | 2 +- libgcc/soft-fp/op-4.h | 2 +- libgcc/soft-fp/op-8.h | 2 +- libgcc/soft-fp/op-common.h | 2 +- libgcc/soft-fp/quad.h | 2 +- libgcc/soft-fp/single.h| 2 +- libgcc/soft-fp/soft-fp.h | 2 +- libgcc/soft-fp/subdf3.c| 2 +- libgcc/soft-fp/subsf3.c| 2 +- libgcc/soft-fp/subtf3.c| 2 +- libgcc/soft-fp/truncdfsf2.c| 2 +- libgcc/soft-fp/trunctfdf2.c| 4 ++-- libgcc/soft-fp/trunctfhf2.c| 4 ++-- libgcc/soft-fp/trunctfsf2.c| 4 ++-- libgcc/soft-fp/trunctfxf2.c| 4 ++-- libgcc/soft-fp/unorddf2.c | 2 +- libgcc/soft-fp/unordsf2.c | 2 +- libgcc/soft-fp/unordtf2.c | 2 +- 89 files changed, 98 insertions(+), 98 deletions(-) diff --git a/libgcc/config/rs6000/ibm-ldouble.c b/libgcc/config/rs6000/ibm-ldouble.c index f9118d8fc394..0e1c443af011 100644 --- a/libgcc/config/rs6000/ibm-ldouble.c +++ b/libgcc/config/rs6000/ibm-ldouble.c @@ -407,7 +407,7 @@ fmsub (double a, double b, double c) FP_UNPACK_RAW_D (C, c); /* Extend double to quad. */ -#if (2 * _FP_W_TYPE_SIZE) < _FP_FRACBITS_Q +#if _FP_W_TYPE_SIZE < 64 FP_EXTEND(Q,D,4,2,X,A); FP_EXTEND(Q,D,4,2,Y,B);
Re: [PATCH] PR libstdc++/85965 delay static assertions until types are complete
On 26/03/19 15:28 +, Jonathan Wakely wrote: The static assertions added for PR libstdc++/48101 were at class scope and so were evaluated too eagerly, when it might not be possible to determine whether the function objects are invocable with the key types. The problematic cases are where the key type is not known to be convertible to the argument type(s) of the function object until later, after a type has been completed. Specifically, if the key type is a pointer to a derived class and the function object's argument type is a pointer to a base class, then the derived-to-base conversion is only valid once the derived type is complete. By moving the static assertions to the destructor they will only be evaluated when the destructor is instantiated, at which point whether the key type can be passed to the function object should be knowable. The ideal place to do the checks would be only when the function objects are actually invoked, but that would mean adding the checks in numerous places, so the destructor is used instead. The tests need to be adjusted because the "required from here" line is now the location of the destructor, not the point of instantiation in the test file. For the map and multimap tests which check two specializations, the dg-error matching the assertion text matches both cases. Also check the diagnostic output for the template arguments, to ensure both specializations trigger the assertion. PR libstdc++/85965 * include/bits/hashtable.h (_Hashtable): Move static assertions to destructor so they are not evaluated until the _Key type is complete. * include/bits/stl_tree.h (_Rb_tree): Likewise. * testsuite/23_containers/set/85965.cc: New test. * testsuite/23_containers/unordered_set/85965.cc: New test. * testsuite/23_containers/map/48101_neg.cc: Replace "here" errors with regexp matching the corresponding _Rb_tree specialization. * testsuite/23_containers/multimap/48101_neg.cc: Likewise. * testsuite/23_containers/multiset/48101_neg.cc: Remove "here" error. * testsuite/23_containers/set/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_map/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_set/48101_neg.cc: Likewise. Tested powerpc64le-linux, committed to trunk. Backport for gcc-8-branch to follow. That patch (r269949 on trunk) fixed the original PR 85965 example, but there are other uses of maps and sets where checking in the destructor is still too strict. This is another attempt to reduce how often the assertions are evaluated, so that code which doesn't try to use the function objects doesn't need them to be invocable. For _Rb_tree we access the _M_key_compare object directly, so can't put the assertions in an accessor function for it. However, every invocation of _M_key_compare is accompanied by a use of _S_key, so the assertions can be put in there. For _Hashtable there are member functions that are consistently used to obtain a hash code or test for equality, so the assertions can go in those members. PR libstdc++/85965 * include/bits/hashtable.h (_Hashtable::~_Hashtable()): Remove static assertions from the destructor. * include/bits/hashtable_policy.h (_Hash_code_base::_M_hash_code): Move static_assert for hash function to here. (_Hash_table_base::_M_equals): Move static_assert for equality predicate to here. * include/bits/stl_tree.h (_Rb_tree::_S_value(_Const_Link_type)): Remove. (_Rb_tree::_S_key(_Const_Link_type)): Move assertions here. Access the value directly instead of calling _S_value. (_Rb_tree::_S_value(_Const_Base_ptr)): Remove. (_Rb_tree::_S_key(_Const_Base_ptr)): Do downcast and forward to _S_key(_Const_Link_type). * testsuite/23_containers/set/85965.cc: Check construction, destruction, assignment and size() do not trigger the assertions. * testsuite/23_containers/unordered_set/85965.cc: Likewise. * testsuite/23_containers/map/48101_neg.cc: Call find and adjust expected errors. * testsuite/23_containers/multimap/48101_neg.cc: Likewise. * testsuite/23_containers/multiset/48101_neg.cc: Likewise. * testsuite/23_containers/set/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_map/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise. * testsuite/23_containers/unordered_set/48101_neg.cc: Likewise. This makes it possible for function objects to be unusable in any member functions of the containers that doesn't actually perform lookups, e.g. construction, destruction, assignment, empty(),
[PATCH] S/390: Add -march to test case
Hi,
this patch adds -march=z900 to a test case that expects larl for loading
a value via the GOT. On z10 and later, lgrl is used which is tested in
a new test case.
Regards
Robin
--
gcc/testsuite/ChangeLog:
2019-05-15 Robin Dapp
* gcc.target/s390/global-array-element-pic.c: Add -march=z900.
* gcc.target/s390/global-array-element-pic2.c: New test for z10+.
commit 55b586bca052b697605b6f3b29248a91f6bb19d1
Author: Robin Dapp
Date: Tue May 14 12:15:57 2019 +0200
Change larl/lgrl fPIC test cases.
diff --git a/gcc/testsuite/gcc.target/s390/global-array-element-pic.c b/gcc/testsuite/gcc.target/s390/global-array-element-pic.c
index 78721206151..3569d5b2be7 100644
--- a/gcc/testsuite/gcc.target/s390/global-array-element-pic.c
+++ b/gcc/testsuite/gcc.target/s390/global-array-element-pic.c
@@ -1,6 +1,6 @@
/* Test accesses to global array elements in PIC code. */
/* { dg-do compile } */
-/* { dg-options "-O1 -fPIC" } */
+/* { dg-options "-O1 -march=z900 -fPIC" } */
extern char a[] __attribute__ ((aligned (2)));
extern char *b;
diff --git a/gcc/testsuite/gcc.target/s390/global-array-element-pic2.c b/gcc/testsuite/gcc.target/s390/global-array-element-pic2.c
new file mode 100644
index 000..b9398a8042f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/global-array-element-pic2.c
@@ -0,0 +1,13 @@
+/* Test accesses to global array elements in PIC code. */
+/* { dg-do compile } */
+/* { dg-options "-O1 -march=z10 -fPIC" } */
+
+extern char a[] __attribute__ ((aligned (2)));
+extern char *b;
+
+void c()
+{
+ b = a + 4;
+ /* { dg-final { scan-assembler {(?n)\n\tlgrl\t%r\d+,a@GOTENT\n} } } */
+ /* { dg-final { scan-assembler-not {(?n)\n\tlarl\t%r\d+,a[^@]} } } */
+}
Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided
On Wed, May 15, 2019 at 05:12:11PM +0200, Christophe Lyon wrote:
> On Wed, 15 May 2019 at 16:37, Rich Felker wrote:
> >
> > On Wed, May 15, 2019 at 01:55:30PM +, Szabolcs Nagy wrote:
> > > On 15/05/2019 13:39, Christophe Lyon wrote:
> > > > In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
> > > > -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
> > > > for executables rather than shared libraries by default.
> > > >
> > > > We also make sure to use the --fdpic assembler option, and select the
> > > > appropriate linker emulation.
> > > >
> > > > At link time, we also default to -pie, unless we are generating a
> > > > shared library or a relocatable file (-r). Note that even for static
> > > > link, we must specify the dynamic linker because the executable still
> > > > has to relocate itself at startup.
> > > >
> > > > We also force 'now' binding since lazy binding is not supported.
> > > >
> > > > We should also apply the same behavior for -Wl,-Ur as for -r, but I
> > > > couldn't find how to describe that in the specs fragment.
> > > ...
> > > > +/* Unless we generate a shared library or a relocatable object, we
> > > > + force -pie. */
> > > > +/* Even with -static, we have to define the dynamic-linker, as we
> > > > + have some relocations to resolve at load time. */
> > > > +#undef SUBTARGET_EXTRA_LINK_SPEC
> > > > +#define SUBTARGET_EXTRA_LINK_SPEC \
> > > > + "%{!mno-fdpic: -m " TARGET_FDPIC_LINKER_EMULATION\
> > > > + "%{!shared:%{!r: -pie}} \
> > > > +%{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \
> > > > + "%{mno-fdpic: -m " TARGET_LINKER_EMULATION "}" \
> > > > + "%{!r:%{!mno-fdpic: -z now}}"
> > >
> > > i think -dynamic-linker can be avoided for -static using
> > > -static-pie linking with rcrt0.o
> >
> > Yes, -dynamic-linker should never be used with -static.
>
> So, do you mean dropping completely the line:
> +%{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \
> and thus make -static unsupported, forcing users to use -static-pie instead?
Rather I would have -static behave the same as -static-pie. The intent
on musl when we added static pie (before glibc had it) was that
-static plus -pie (including default-pie, if built as default-pie)
would yield static pie output, and our patches still do this. When
static-pie was upstreamed in gcc, it was done differently for
compatibility with legacy versions of glibc. That's not a
consideration for fdpic.
> > > but more importantly: does the abi spec require the sysv dynamic
> > > linker name? that sounds suboptimal (in principle the same os
> >
> > ABI specs typically do this and we just ignore it. BFD contains
> > default dynamic linker strings for all sorts of ABIs, and they're all
> > wrong -- things like /lib/ld64.so.1, etc. I don't think it's worth
> > bothering with fighting the desire of folks writing ABI specs to do
> > this again and again. GCC overrides them all with the actually-correct
> > values when !static.
> >
> > > can support both normal elf and fdpic elf so you can test/use
> > > an fdpic toolchain on a system with mmu, but this requires
> > > different dynamic linker name ..otherwise one has to run
> > > executables in a chroot or separate mount namespace to change
> > > the dynamic linker)
> >
> > Indeed, it's a bad idea to make them clash.
> >
>
> Not sure to understand your point: indeed FDPIC binaries work
> on a system with mmu, provided you have the right dynamic
> linker in the right place, as well as the needed runtime libs (libc, etc)
>
> Do you want me to change anything here?
I think the concern is that if the PT_INTERP name is the same for
binaries with different ABIs, you wouldn't be able to have both
present in the same root fs, and this would make it more of a pain to
debug fdpic binaries on a full (with-mmu) host.
musl always uses a different PT_INTERP name for each ABI combination,
so I guess the question is whether uclibc or whatever other libc
you're intending people to use would also want to do this.
> > > > +#undef STARTFILE_SPEC
> > > > +#define STARTFILE_SPEC "%{!mno-fdpic:%{!shared:crtreloc.o%s}} " \
> > > > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC,
> > > > ANDROID_STARTFILE_SPEC)
> > > > diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> > > > index b241ddb..c38b3f4 100644
> > > > --- a/libsanitizer/configure.tgt
> > > > +++ b/libsanitizer/configure.tgt
> > > > @@ -45,6 +45,9 @@ case "${target}" in
> > > > ;;
> > > >sparc*-*-solaris2.11*)
> > > > ;;
> > > > + arm*-*-uclinuxfdpiceabi)
> > > > + UNSUPPORTED=1
> > > > + ;;
> > >
> > > musl libc has fdpic support on sh (e.g. with sh2eb-linux-muslfdpic
> > > target and --enable-fdpic), it can probably support fdpic on arm
> > > too with minimal changes, i assume the target name for that would
> > > be arm-linux-muslfdpiceabi.
> >
> > I plan to
[PATCH] Remove redundant accessors in hash tables
François,
I noticed that _Hash_code_base and _Hashtable_base have a number of
member functions which are overloaded for const and non-const:
const _Equal&
_M_eq() const { return _EqualEBO::_S_cget(*this); }
_Equal&
_M_eq() { return _EqualEBO::_S_get(*this); }
The non-const ones seem to be unnecessary. They're used in the _M_swap
member functions, but all other uses could (and probably should) call
the const overload to get a const reference to the function object.
If we make the _M_swap members use the EBO accessors directly then we
can get rid of the non-const accessors. That makes overload resolution
simpler for the compiler (as there's only one function to choose from)
and should result in slightly smaller code when inlining is not
enabled.
Do you see any problem with this patch?
diff --git a/libstdc++-v3/include/bits/hashtable_policy.h b/libstdc++-v3/include/bits/hashtable_policy.h
index 9505fb8d261..5ff90c952ba 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -1229,21 +1229,16 @@ namespace __detail
void
_M_swap(_Hash_code_base& __x)
{
- std::swap(_M_extract(), __x._M_extract());
- std::swap(_M_ranged_hash(), __x._M_ranged_hash());
+ std::swap(__ebo_extract_key::_S_get(*this),
+ __ebo_extract_key::_S_get(__x));
+ std::swap(__ebo_hash::_S_get(*this), __ebo_hash::_S_get(__x));
}
const _ExtractKey&
_M_extract() const { return __ebo_extract_key::_S_cget(*this); }
- _ExtractKey&
- _M_extract() { return __ebo_extract_key::_S_get(*this); }
-
const _Hash&
_M_ranged_hash() const { return __ebo_hash::_S_cget(*this); }
-
- _Hash&
- _M_ranged_hash() { return __ebo_hash::_S_get(*this); }
};
// No specialization for ranged hash function while caching hash codes.
@@ -1326,28 +1321,20 @@ namespace __detail
void
_M_swap(_Hash_code_base& __x)
{
- std::swap(_M_extract(), __x._M_extract());
- std::swap(_M_h1(), __x._M_h1());
- std::swap(_M_h2(), __x._M_h2());
+ std::swap(__ebo_extract_key::_S_get(*this),
+ __ebo_extract_key::_S_get(__x));
+ std::swap(__ebo_h1::_S_get(*this), __ebo_h1::_S_get(__x));
+ std::swap(__ebo_h2::_S_get(*this), __ebo_h2::_S_get(__x));
}
const _ExtractKey&
_M_extract() const { return __ebo_extract_key::_S_cget(*this); }
- _ExtractKey&
- _M_extract() { return __ebo_extract_key::_S_get(*this); }
-
const _H1&
_M_h1() const { return __ebo_h1::_S_cget(*this); }
- _H1&
- _M_h1() { return __ebo_h1::_S_get(*this); }
-
const _H2&
_M_h2() const { return __ebo_h2::_S_cget(*this); }
-
- _H2&
- _M_h2() { return __ebo_h2::_S_get(*this); }
};
/// Specialization: hash function and range-hashing function,
@@ -1418,28 +1405,20 @@ namespace __detail
void
_M_swap(_Hash_code_base& __x)
{
- std::swap(_M_extract(), __x._M_extract());
- std::swap(_M_h1(), __x._M_h1());
- std::swap(_M_h2(), __x._M_h2());
+ std::swap(__ebo_extract_key::_S_get(*this),
+ __ebo_extract_key::_S_get(__x));
+ std::swap(__ebo_h1::_S_get(*this), __ebo_h1::_S_get(__x));
+ std::swap(__ebo_h2::_S_get(*this), __ebo_h2::_S_get(__x));
}
const _ExtractKey&
_M_extract() const { return __ebo_extract_key::_S_cget(*this); }
- _ExtractKey&
- _M_extract() { return __ebo_extract_key::_S_get(*this); }
-
const _H1&
_M_h1() const { return __ebo_h1::_S_cget(*this); }
- _H1&
- _M_h1() { return __ebo_h1::_S_get(*this); }
-
const _H2&
_M_h2() const { return __ebo_h2::_S_cget(*this); }
-
- _H2&
- _M_h2() { return __ebo_h2::_S_get(*this); }
};
/**
@@ -1851,14 +1830,11 @@ namespace __detail
_M_swap(_Hashtable_base& __x)
{
__hash_code_base::_M_swap(__x);
- std::swap(_M_eq(), __x._M_eq());
+ std::swap(_EqualEBO::_S_get(*this), _EqualEBO::_S_get(__x));
}
const _Equal&
_M_eq() const { return _EqualEBO::_S_cget(*this); }
-
-_Equal&
-_M_eq() { return _EqualEBO::_S_get(*this); }
};
/**
Re: [PATCH] gcc: move assemble_start_function / assemble_end_function to output_mi_thunk
On Tue, May 14, 2019 at 10:28 AM Max Filippov wrote: > > Let backends call assemble_start_function after they have generated > thunk function body so that a constant pool could be output if it is > required. This may help backends to avoid implementing custom constant > loading code specifically for the MI thunk and reuse existing > functionality. Approved for xtensa.
Re: [PATCH] [aarch64] Introduce flags for SVE2.
> Matthew Malcomson writes:
>> @@ -326,16 +326,22 @@ int opt_ext_cmp (const void* a, const void* b)
Cheers Richard -- modified patch attached and inlined.
MM
### Attachment also inlined for ease of reply###
diff --git a/gcc/common/config/aarch64/aarch64-common.c
b/gcc/common/config/aarch64/aarch64-common.c
index
bab3ab3fa36c66906d1b4367e2b7bfb1bf6aa08c..f9051056589861ce0ffe1bae4fa04cf44d34b9a2
100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -170,9 +170,9 @@ aarch64_handle_option (struct gcc_options *opts,
struct aarch64_option_extension
{
const char *const name;
- const unsigned long flag_canonical;
- const unsigned long flags_on;
- const unsigned long flags_off;
+ const uint64_t flag_canonical;
+ const uint64_t flags_on;
+ const uint64_t flags_off;
const bool is_synthetic;
};
@@ -201,14 +201,14 @@ struct processor_name_to_arch
{
const std::string processor_name;
const enum aarch64_arch arch;
- const unsigned long flags;
+ const uint64_t flags;
};
struct arch_to_arch_name
{
const enum aarch64_arch arch;
const std::string arch_name;
- const unsigned long flags;
+ const uint64_t flags;
};
/* Map processor names to the architecture revision they implement and
@@ -238,7 +238,7 @@ static const struct arch_to_arch_name all_architectures[] =
a copy of the string is created and stored to INVALID_EXTENSION. */
enum aarch64_parse_opt_result
-aarch64_parse_extension (const char *str, unsigned long *isa_flags,
+aarch64_parse_extension (const char *str, uint64_t *isa_flags,
std::string *invalid_extension)
{
/* The extension string is parsed left to right. */
@@ -326,18 +326,21 @@ int opt_ext_cmp (const void* a, const void* b)
turns on as a dependency. As an example +dotprod turns on FL_DOTPROD and
FL_SIMD. As such the set of bits represented by this option is
{FL_DOTPROD, FL_SIMD}. */
- unsigned long total_flags_a = opt_a->flag_canonical & opt_a->flags_on;
- unsigned long total_flags_b = opt_b->flag_canonical & opt_b->flags_on;
+ uint64_t total_flags_a = opt_a->flag_canonical & opt_a->flags_on;
+ uint64_t total_flags_b = opt_b->flag_canonical & opt_b->flags_on;
int popcnt_a = popcount_hwi ((HOST_WIDE_INT)total_flags_a);
int popcnt_b = popcount_hwi ((HOST_WIDE_INT)total_flags_b);
int order = popcnt_b - popcnt_a;
/* If they have the same amount of bits set, give it a more
deterministic ordering by using the value of the bits themselves. */
- if (order == 0)
-return total_flags_b - total_flags_a;
+ if (order != 0)
+return order;
- return order;
+ if (total_flags_a != total_flags_b)
+return total_flags_a < total_flags_b ? 1 : -1;
+
+ return 0;
}
/* Implement TARGET_OPTION_INIT_STRUCT. */
@@ -373,9 +376,9 @@ aarch64_option_init_struct (struct gcc_options *opts
ATTRIBUTE_UNUSED)
*/
static bool
-aarch64_contains_opt (unsigned long isa_flag_bits, opt_ext *opt)
+aarch64_contains_opt (uint64_t isa_flag_bits, opt_ext *opt)
{
- unsigned long flags_check
+ uint64_t flags_check
= opt->is_synthetic ? opt->flags_on : opt->flag_canonical;
return (isa_flag_bits & flags_check) == flags_check;
@@ -388,13 +391,13 @@ aarch64_contains_opt (unsigned long isa_flag_bits,
opt_ext *opt)
that all the "+" flags come before the "+no" flags. */
std::string
-aarch64_get_extension_string_for_isa_flags (unsigned long isa_flags,
- unsigned long default_arch_flags)
+aarch64_get_extension_string_for_isa_flags (uint64_t isa_flags,
+ uint64_t default_arch_flags)
{
const struct aarch64_option_extension *opt = NULL;
std::string outstr = "";
- unsigned long isa_flag_bits = isa_flags;
+ uint64_t isa_flag_bits = isa_flags;
/* Pass one: Minimize the search space by reducing the set of options
to the smallest set that still turns on the same features as before in
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
b/gcc/config/aarch64/aarch64-option-extensions.def
index
53dcd03590d2e4eebac83f03039c442fca7f5d5d..4b10c62d20401a66374eb68e36531d73df300af1
100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -57,17 +57,20 @@
/* Enabling "fp" just enables "fp".
Disabling "fp" also disables "simd", "crypto", "fp16", "aes", "sha2",
- "sha3", sm3/sm4 and "sve". */
-AARCH64_OPT_EXTENSION("fp", AARCH64_FL_FP, 0, AARCH64_FL_SIMD |
AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2 |
AARCH64_FL_SHA3 | AARCH64_FL_SM4 | AARCH64_FL_SVE, false, "fp")
+ "sha3", sm3/sm4, "sve", "sve2", "sve2-aes", "sve2-sha3", "sve2-sm4", and
+ "bitperm". */
+AARCH64_OPT_EXTENSION("fp", AARCH64_FL_FP, 0, AARCH64_FL_SIMD |
AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2 |
AARCH64_FL_SHA3
Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided
On Wed, 15 May 2019 at 16:37, Rich Felker wrote:
>
> On Wed, May 15, 2019 at 01:55:30PM +, Szabolcs Nagy wrote:
> > On 15/05/2019 13:39, Christophe Lyon wrote:
> > > In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
> > > -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
> > > for executables rather than shared libraries by default.
> > >
> > > We also make sure to use the --fdpic assembler option, and select the
> > > appropriate linker emulation.
> > >
> > > At link time, we also default to -pie, unless we are generating a
> > > shared library or a relocatable file (-r). Note that even for static
> > > link, we must specify the dynamic linker because the executable still
> > > has to relocate itself at startup.
> > >
> > > We also force 'now' binding since lazy binding is not supported.
> > >
> > > We should also apply the same behavior for -Wl,-Ur as for -r, but I
> > > couldn't find how to describe that in the specs fragment.
> > ...
> > > +/* Unless we generate a shared library or a relocatable object, we
> > > + force -pie. */
> > > +/* Even with -static, we have to define the dynamic-linker, as we
> > > + have some relocations to resolve at load time. */
> > > +#undef SUBTARGET_EXTRA_LINK_SPEC
> > > +#define SUBTARGET_EXTRA_LINK_SPEC \
> > > + "%{!mno-fdpic: -m " TARGET_FDPIC_LINKER_EMULATION\
> > > + "%{!shared:%{!r: -pie}} \
> > > +%{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \
> > > + "%{mno-fdpic: -m " TARGET_LINKER_EMULATION "}" \
> > > + "%{!r:%{!mno-fdpic: -z now}}"
> >
> > i think -dynamic-linker can be avoided for -static using
> > -static-pie linking with rcrt0.o
>
> Yes, -dynamic-linker should never be used with -static.
So, do you mean dropping completely the line:
+%{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \
and thus make -static unsupported, forcing users to use -static-pie instead?
> > but more importantly: does the abi spec require the sysv dynamic
> > linker name? that sounds suboptimal (in principle the same os
>
> ABI specs typically do this and we just ignore it. BFD contains
> default dynamic linker strings for all sorts of ABIs, and they're all
> wrong -- things like /lib/ld64.so.1, etc. I don't think it's worth
> bothering with fighting the desire of folks writing ABI specs to do
> this again and again. GCC overrides them all with the actually-correct
> values when !static.
>
> > can support both normal elf and fdpic elf so you can test/use
> > an fdpic toolchain on a system with mmu, but this requires
> > different dynamic linker name ..otherwise one has to run
> > executables in a chroot or separate mount namespace to change
> > the dynamic linker)
>
> Indeed, it's a bad idea to make them clash.
>
Not sure to understand your point: indeed FDPIC binaries work
on a system with mmu, provided you have the right dynamic
linker in the right place, as well as the needed runtime libs (libc, etc)
Do you want me to change anything here?
> > > +
> > > +#undef STARTFILE_SPEC
> > > +#define STARTFILE_SPEC "%{!mno-fdpic:%{!shared:crtreloc.o%s}} " \
> > > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC,
> > > ANDROID_STARTFILE_SPEC)
> > > diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> > > index b241ddb..c38b3f4 100644
> > > --- a/libsanitizer/configure.tgt
> > > +++ b/libsanitizer/configure.tgt
> > > @@ -45,6 +45,9 @@ case "${target}" in
> > > ;;
> > >sparc*-*-solaris2.11*)
> > > ;;
> > > + arm*-*-uclinuxfdpiceabi)
> > > + UNSUPPORTED=1
> > > + ;;
> >
> > musl libc has fdpic support on sh (e.g. with sh2eb-linux-muslfdpic
> > target and --enable-fdpic), it can probably support fdpic on arm
> > too with minimal changes, i assume the target name for that would
> > be arm-linux-muslfdpiceabi.
>
> I plan to add ARM FDPIC support as soon as there is (1) published ABI
> for relocation types, entry point contract, etc., and (2) there's
The ABI is here:
https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
> tooling to support it that's either upstream or can be applied as
> clean patches to recent gcc (as opposed to some fork of gcc4 or
> whatever it was this got started as). I think those conditions are
> mostly met now.
This patch series applies on gcc trunk as of ~2 weeks ago
> > so i think it is better to check arm*-*fdpiceabi where the libc
> > does not matter (so we dont have to patch the same files when
> > *-muslfdpiceabi support is added).
>
Looks sane.
> Yes, that would be appreciated. Maybe we could get musl ldso names
> added at the same time, too? I think they should just be the same as
> the existing musl ldso names but with "-fdpic" appended before
> ".so.1".
Do you mean updating config/arm/linux-eabi.h and adding -fdpic to the
4 musl dynamic linker names?
> Rich
Re: [PATCH 1/12] implement -Wformat-diag to detect quoting and spelling issues in GCC diagnostics
On 5/15/19 5:40 AM, Martin Liška wrote: On 5/14/19 11:31 PM, Martin Sebor wrote: The attached patch implements the -Wformat-diag warning to help find quoting, spelling, and other formatting issues in diagnostics issued by GCC. Just a general comment about this part. Wouldn't it make sense to use regex for some of the string patterns that you address in the patch? I'm not sure. Are you wondering about the variants of type names like "signed int" and "unsigned int" and the contractions? The plain format checker scans and advances one word at a time to be efficient. It does linearly loop over the black-listed words and operators and that could be made more efficient by using a binary search. Let me do that. I would expect introducing regexp to the checking to slow it down but I suppose I could try it and see if you think it's worth it. Martin
Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided
On Wed, May 15, 2019 at 01:55:30PM +, Szabolcs Nagy wrote:
> On 15/05/2019 13:39, Christophe Lyon wrote:
> > In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
> > -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
> > for executables rather than shared libraries by default.
> >
> > We also make sure to use the --fdpic assembler option, and select the
> > appropriate linker emulation.
> >
> > At link time, we also default to -pie, unless we are generating a
> > shared library or a relocatable file (-r). Note that even for static
> > link, we must specify the dynamic linker because the executable still
> > has to relocate itself at startup.
> >
> > We also force 'now' binding since lazy binding is not supported.
> >
> > We should also apply the same behavior for -Wl,-Ur as for -r, but I
> > couldn't find how to describe that in the specs fragment.
> ...
> > +/* Unless we generate a shared library or a relocatable object, we
> > + force -pie. */
> > +/* Even with -static, we have to define the dynamic-linker, as we
> > + have some relocations to resolve at load time. */
> > +#undef SUBTARGET_EXTRA_LINK_SPEC
> > +#define SUBTARGET_EXTRA_LINK_SPEC \
> > + "%{!mno-fdpic: -m " TARGET_FDPIC_LINKER_EMULATION\
> > + "%{!shared:%{!r: -pie}} \
> > +%{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \
> > + "%{mno-fdpic: -m " TARGET_LINKER_EMULATION "}" \
> > + "%{!r:%{!mno-fdpic: -z now}}"
>
> i think -dynamic-linker can be avoided for -static using
> -static-pie linking with rcrt0.o
Yes, -dynamic-linker should never be used with -static.
> but more importantly: does the abi spec require the sysv dynamic
> linker name? that sounds suboptimal (in principle the same os
ABI specs typically do this and we just ignore it. BFD contains
default dynamic linker strings for all sorts of ABIs, and they're all
wrong -- things like /lib/ld64.so.1, etc. I don't think it's worth
bothering with fighting the desire of folks writing ABI specs to do
this again and again. GCC overrides them all with the actually-correct
values when !static.
> can support both normal elf and fdpic elf so you can test/use
> an fdpic toolchain on a system with mmu, but this requires
> different dynamic linker name ..otherwise one has to run
> executables in a chroot or separate mount namespace to change
> the dynamic linker)
Indeed, it's a bad idea to make them clash.
> > +
> > +#undef STARTFILE_SPEC
> > +#define STARTFILE_SPEC "%{!mno-fdpic:%{!shared:crtreloc.o%s}} " \
> > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC,
> > ANDROID_STARTFILE_SPEC)
> > diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> > index b241ddb..c38b3f4 100644
> > --- a/libsanitizer/configure.tgt
> > +++ b/libsanitizer/configure.tgt
> > @@ -45,6 +45,9 @@ case "${target}" in
> > ;;
> >sparc*-*-solaris2.11*)
> > ;;
> > + arm*-*-uclinuxfdpiceabi)
> > + UNSUPPORTED=1
> > + ;;
>
> musl libc has fdpic support on sh (e.g. with sh2eb-linux-muslfdpic
> target and --enable-fdpic), it can probably support fdpic on arm
> too with minimal changes, i assume the target name for that would
> be arm-linux-muslfdpiceabi.
I plan to add ARM FDPIC support as soon as there is (1) published ABI
for relocation types, entry point contract, etc., and (2) there's
tooling to support it that's either upstream or can be applied as
clean patches to recent gcc (as opposed to some fork of gcc4 or
whatever it was this got started as). I think those conditions are
mostly met now.
> so i think it is better to check arm*-*fdpiceabi where the libc
> does not matter (so we dont have to patch the same files when
> *-muslfdpiceabi support is added).
Yes, that would be appreciated. Maybe we could get musl ldso names
added at the same time, too? I think they should just be the same as
the existing musl ldso names but with "-fdpic" appended before
".so.1".
Rich
Re: [committed, wwwdocs] OpenACC status for GCC 9
Hi Gerald! On Sat, 11 May 2019 09:37:42 +0200, Gerald Pfeifer wrote: > On Thu, 2 May 2019, Thomas Schwinge wrote: > > +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. > > Thanks for making this addition, Thomas! Sure, and thanks for having a look. > On this I'd omit the second link if that's okay with you? (I'm > happy to make the change, wanted to check in with you first.) If you'd like to, then please do. Grüße Thomas
Re: [RFC] SHIFT_COUNT_TRUNCATED and shift_truncation_mask
> It would really help if you could provide testcases which show the > suboptimal code and any analysis you've done. I tried introducing a define_subst pattern that substitutes something one of two other subst patterns already changed. The first subst pattern helps remove a superfluous and on the shift count operand by accepting both variants, with and without an and for the insn pattern. (define_subst "masked_op_subst" [(set (match_operand:DSI 0 "" "") (shift:DSI (match_operand:DSI 1 "" "") (match_operand:SI 2 "" "")))] "" [(set (match_dup 0) (shift:DSI (match_dup 1) (and:SI (match_dup 2) (match_operand:SI 3 "const_int_6bitset_operand" "jm6"]) The second subst helps encode a shift count addition like $r1 + 1 as address style operand 1($r1) that is directly supported by the shift instruction. (define_subst "addr_style_op_subst" [(set (match_operand:DSI_VI 0 "" "") (shift:DSI_VI (match_operand:DSI_VI 1 "" "") (match_operand:SI 2 "" "")))] "" [(set (match_dup 0) (shift:DSI_VI (match_dup 1) (plus:SI (match_operand:SI 2 "register_operand" "a") (match_operand 3 "const_int_operand" "n"]) Both of these are also used in combination. Now, in order to get rid of the subregs in the pattern combine creates, I would need to be able to do something like (define_subst "subreg_subst" [(set (match_operand:DI 0 "" "") (shift:DI (match_operand:DI 1 "" "") (subreg:SI (match_dup:DI 2)))] where the (match_dup:DI 2) would capture both (and:SI ...) [with the first argument being either a register or an already substituted (plus:SI ...)] as well as a simple (plus:SI ...). As far as I can tell match_dup:mode can be used to change the mode of the top-level operation but the operands will remain the same. For this, a match_dup_deep or whatever would be useful. I'm pretty sure we don't want to open this can of worms, though :) To get rid of this, I explicitly duplicated all three subst combinations resulting in a lot of additional code. This is not necessary when the subregs are eliminated by the middle end via SHIFT_COUNT_TRUNCATED. Maybe there is a much more obvious way that I missed? Regards Robin
[C++ Patch, obvious] Remove REFERENCE_VLA_OK
Hi,
noticed this nit a few weeks ago: currently we only set the flag in one
place and nowhere read it. I'm going to commit the below as obvious
later today, barring objections.
Thanks, Paolo.
/
2019-05-15 Paolo Carlini
* cp-tree.h (REFERENCE_VLA_OK): Remove.
* lambda.c (build_capture_proxy): Remove use of the above.
Index: cp-tree.h
===
--- cp-tree.h (revision 271211)
+++ cp-tree.h (working copy)
@@ -482,7 +482,6 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
5: CLASS_TYPE_P (in RECORD_TYPE and UNION_TYPE)
ENUM_FIXED_UNDERLYING_TYPE_P (in ENUMERAL_TYPE)
AUTO_IS_DECLTYPE (in TEMPLATE_TYPE_PARM)
- REFERENCE_VLA_OK (in REFERENCE_TYPE)
6: TYPE_DEPENDENT_P_VALID
Usage of DECL_LANG_FLAG_?:
@@ -3714,11 +3713,6 @@ struct GTY(()) lang_decl {
&& TREE_TYPE (TREE_OPERAND (NODE, 0)) \
&& TYPE_REF_P (TREE_TYPE (TREE_OPERAND ((NODE), 0
-/* True if NODE is a REFERENCE_TYPE which is OK to instantiate to be a
- reference to VLA type, because it's used for VLA capture. */
-#define REFERENCE_VLA_OK(NODE) \
- (TYPE_LANG_FLAG_5 (REFERENCE_TYPE_CHECK (NODE)))
-
#define NEW_EXPR_USE_GLOBAL(NODE) \
TREE_LANG_FLAG_0 (NEW_EXPR_CHECK (NODE))
#define DELETE_EXPR_USE_GLOBAL(NODE) \
Index: lambda.c
===
--- lambda.c(revision 271211)
+++ lambda.c(working copy)
@@ -420,7 +420,6 @@ build_capture_proxy (tree member, tree init)
type = build_cplus_array_type (TREE_TYPE (TREE_TYPE (ptr)),
build_index_type (max));
type = build_reference_type (type);
- REFERENCE_VLA_OK (type) = true;
object = convert (type, ptr);
}
Re: OpenACC 2.5 Profiling Interface
Hi Jakub! On Tue, 4 Dec 2018 14:13:49 +0100, Jakub Jelinek wrote: > On Sun, Nov 11, 2018 at 10:31:42PM -0600, Thomas Schwinge wrote: > > On Tue, 28 Feb 2017 18:43:36 +0100, I wrote: > > > The 2.5 versions of the OpenACC standard added a new chapter "Profiling > > > Interface". > > > > I'd like to get that into trunk. It's not yet complete (that is, doesn't > > provide all the information specified), but it's very useful already, and > > the missing pieces can later be added incrementally. > > > > Jakub, would you please especially review the non-OpenACC-specific > > changes here, including the libgomp ABI changes? > > > > (Note that this patch doesn't apply on top of trunk. I extracted it out > > of openacc-gcc-8-branch, plus additional changes, and it depends on a > > number of other pending patches. Due to the many regions of code > > touched, there are a lot of "textual" conflicts when porting it to > > current trunk, but the "structure" will be the same.) > > Seems rather expensive to me, especially with the dependence on > libbacktrace and the unconditional initialization of the profiling from the > library constructor. Could e.g. libbacktrace or some libgomp plugin that is > linked against libbacktrace be dlopened only when apps ask for this stuff? Thanks, that seems plausible, and I'm looking into that. > OpenMP 5 has a profiling API too (OMPT) (... which I'm not familiar with...) > there the rough plan for when it > will be implemented is that libgomp as the library will implement only the > absolute required minimum and perhaps have a variant library that is a > replacement for libgomp if more detailed instrumentation is needed. The "problem" with the OpenACC Profiling Interface is that the user can enable the callbacks etc. anytime dynamically at run time. So, as I understand, that rules out the "variant library" approach? Grüße Thomas
Re: [PATCH, lto-plugin] Make the plugin more -save-temps friendly.
> On 15 May 2019, at 14:52, Martin Liška wrote:
>
> On 5/14/19 6:45 PM, Iain Sandoe wrote:
>> Currently the lto plugin has a somewhat obscure incantation to get it to
>> save its temp files, and at least one is not named in any
>
> libtool: compile: gcc -DHAVE_CONFIG_H -I.
> -I/home/marxin/Programming/gcc/lto-plugin
> -I/home/marxin/Programming/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -g
> -O2 -c /home/marxin/Programming/gcc/lto-plugin/lto-plugin.c -fPIC -DPIC -o
> .libs/lto-plugin.o
> /home/marxin/Programming/gcc/lto-plugin/lto-plugin.c: In function
> ‘cleanup_handler’:
> /home/marxin/Programming/gcc/lto-plugin/lto-plugin.c:809:7: warning: unused
> variable ‘t’ [-Wunused-variable]
> int t;
sorry about that, fixed
Iain
lto-plugin/
2019-05-15 Iain Sandoe
* lto-plugin.c (cleanup_handler): Remove unused var.
Index: lto-plugin/lto-plugin.c
===
--- lto-plugin/lto-plugin.c (revision 271211)
+++ lto-plugin/lto-plugin.c (working copy)
@@ -806,7 +806,6 @@
cleanup_handler (void)
{
unsigned int i;
- int t;
if (debug)
return LDPS_OK;
Re: [ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided
On 15/05/2019 13:39, Christophe Lyon wrote:
> In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
> -fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
> for executables rather than shared libraries by default.
>
> We also make sure to use the --fdpic assembler option, and select the
> appropriate linker emulation.
>
> At link time, we also default to -pie, unless we are generating a
> shared library or a relocatable file (-r). Note that even for static
> link, we must specify the dynamic linker because the executable still
> has to relocate itself at startup.
>
> We also force 'now' binding since lazy binding is not supported.
>
> We should also apply the same behavior for -Wl,-Ur as for -r, but I
> couldn't find how to describe that in the specs fragment.
...
> +/* Unless we generate a shared library or a relocatable object, we
> + force -pie. */
> +/* Even with -static, we have to define the dynamic-linker, as we
> + have some relocations to resolve at load time. */
> +#undef SUBTARGET_EXTRA_LINK_SPEC
> +#define SUBTARGET_EXTRA_LINK_SPEC\
> + "%{!mno-fdpic: -m " TARGET_FDPIC_LINKER_EMULATION \
> + "%{!shared:%{!r: -pie}} \
> +%{static:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}" \
> + "%{mno-fdpic: -m " TARGET_LINKER_EMULATION "}" \
> + "%{!r:%{!mno-fdpic: -z now}}"
i think -dynamic-linker can be avoided for -static using
-static-pie linking with rcrt0.o
but more importantly: does the abi spec require the sysv dynamic
linker name? that sounds suboptimal (in principle the same os
can support both normal elf and fdpic elf so you can test/use
an fdpic toolchain on a system with mmu, but this requires
different dynamic linker name ..otherwise one has to run
executables in a chroot or separate mount namespace to change
the dynamic linker)
> +
> +#undef STARTFILE_SPEC
> +#define STARTFILE_SPEC "%{!mno-fdpic:%{!shared:crtreloc.o%s}} " \
> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC,
> ANDROID_STARTFILE_SPEC)
> diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
> index b241ddb..c38b3f4 100644
> --- a/libsanitizer/configure.tgt
> +++ b/libsanitizer/configure.tgt
> @@ -45,6 +45,9 @@ case "${target}" in
> ;;
>sparc*-*-solaris2.11*)
> ;;
> + arm*-*-uclinuxfdpiceabi)
> + UNSUPPORTED=1
> + ;;
musl libc has fdpic support on sh (e.g. with sh2eb-linux-muslfdpic
target and --enable-fdpic), it can probably support fdpic on arm
too with minimal changes, i assume the target name for that would
be arm-linux-muslfdpiceabi.
so i think it is better to check arm*-*fdpiceabi where the libc
does not matter (so we dont have to patch the same files when
*-muslfdpiceabi support is added).
Re: [PATCH, lto-plugin] Make the plugin more -save-temps friendly.
On 5/14/19 6:45 PM, Iain Sandoe wrote: > Currently the lto plugin has a somewhat obscure incantation to get it to save > its temp files, and at least one is not named in any sensible way for > development examination. > > This patch makes it follow the same approach as collect2. > > -save-temps causes the temp file to be named meaningfully, and for the > relevant input files to be saved in CWD. > -v, —version causes the save actions to be output to stderr. > > —— > > one can get this to happen by just putting -save-temps, -v on the regular > link line or (for compatibility with the way the -debug flag works, by > appending -plugin-opt=-save-temps, etc. > > (the latter change might be a bit OTT, I was in two minds about deleting that > part, but …) > > tested on x86_64-linux-gnu. > > OK for trunk? > Iain > > lto-plugin/ > > * lto-plugin.c (exec_lto_wrapper): Make the wrapper > arguments filename more user-friendly. > (file_exists, maybe_unlink): New. > (cleanup_handler): Use maybe unlink to handle the > case when temps should be saved. > (process_option): Look for -v, —version, -save-temps. > (onload): Record the linker output file name. > Check for -v, —version, -save-temps in GCC collect > options environment. > Hi. I see: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/home/marxin/Programming/gcc/lto-plugin -I/home/marxin/Programming/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -g -O2 -c /home/marxin/Programming/gcc/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o /home/marxin/Programming/gcc/lto-plugin/lto-plugin.c: In function ‘cleanup_handler’: /home/marxin/Programming/gcc/lto-plugin/lto-plugin.c:809:7: warning: unused variable ‘t’ [-Wunused-variable] int t; ^ Please take a look. Martin
Re: [PATCH] fortran: C++ support for generating C prototypes
On Sun, May 12, 2019 at 12:47:04AM +0300, Janne Blomqvist wrote:
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -6331,6 +6331,24 @@ done:
>}
>
>/* Dump C prototypes. */
> + if (flag_c_prototypes || flag_c_prototypes_external)
> +{
> + fprintf (stdout,
> +_("#include \n"
> + "#ifdef __cplusplus\n"
> + "#include \n"
> + "#define FLOAT_COMPLEX std::complex\n"
> + "#define DOUBLE_COMPLEX std::complex\n"
> + "#define LONG_DOUBLE_COMPLEX std::complex\n"
> + "extern \"C\" {\n"
> + "#else\n"
> + "#define FLOAT_COMPLEX float _Complex\n"
> + "#define DOUBLE_COMPLEX double _Complex\n"
> + "#define LONG_DOUBLE_COMPLEX long double _Complex\n"
> + "#endif\n\n"));
Two more things:
1) why the _() around the code snippet? Do you expect translators
to translate the C snippets to something else or what?
2) I don't think float _Complex is
passed the same as std::complex and similar for others;
std::complex is in libstdc++ a C++ class with with
__complex__ float as its sole non-static data member and with non-trivial
constructors; which means it is passed/returned via a hidden reference;
when the argument is actually FLOAT_COMPLEX * or FLOAT_COMPLEX &,
you except for aliasing don't have to care that much, but if
that complex argument has VALUE attribute in Fortran and so the
C prototype would be FLOAT_COMPLEX, then std::complex is
passed in the end as std::complex &, while float _Complex
the same as __complex__ float; and ditto for functions returning
complex
Jakub
Re: [C++ Patch] Consistently use OVL_P
On Wed, May 15, 2019 at 03:24:52PM +0200, Paolo Carlini wrote: > Hi, > > On 15/05/19 14:29, Nathan Sidwell wrote: > > On 5/14/19 5:20 PM, Paolo Carlini wrote: > > > Hi again, > > > > > > ... so the below passes testing on x86_64-linux. In fact, I think we > > > are on a pretty safe ground, now at the beginning of Stage 1: if, > > > over the next months we get a testcase which causes one of the 4 > > > tightened gcc_assert to trip we'll comfortably deal with it. > > > > great, thanks for trying that. Marek found the nits. > > Thus, I'm going ahead with those obvious formatting changes, agreed? Go ahead. Marek
Re: [C++ Patch] Consistently use OVL_P
Hi, On 15/05/19 14:29, Nathan Sidwell wrote: On 5/14/19 5:20 PM, Paolo Carlini wrote: Hi again, ... so the below passes testing on x86_64-linux. In fact, I think we are on a pretty safe ground, now at the beginning of Stage 1: if, over the next months we get a testcase which causes one of the 4 tightened gcc_assert to trip we'll comfortably deal with it. great, thanks for trying that. Marek found the nits. Thus, I'm going ahead with those obvious formatting changes, agreed? Paolo.
[PATCH] Allow opening file on multiple units
As of Fortran 2018 it's allowed to open the same file on multiple
units.
fortran/ChangeLog:
2019-05-15 Janne Blomqvist
PR fortran/90461
* io/open.c (new_unit): Don't check if the file is already open
for F2018.
testsuite/ChangeLog:
2019-05-15 Janne Blomqvist
PR fortran/90461
* gfortran.dg/open_errors_2.f90: Add -std=f2008, adjust line number.
* gfortran.dg/open_errors_3.f90: New test.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
---
gcc/testsuite/gfortran.dg/open_errors_2.f90 | 3 ++-
gcc/testsuite/gfortran.dg/open_errors_3.f90 | 11 +++
libgfortran/io/open.c | 3 ++-
3 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/open_errors_3.f90
diff --git a/gcc/testsuite/gfortran.dg/open_errors_2.f90
b/gcc/testsuite/gfortran.dg/open_errors_2.f90
index 5b418349e19..72d63bb3a39 100644
--- a/gcc/testsuite/gfortran.dg/open_errors_2.f90
+++ b/gcc/testsuite/gfortran.dg/open_errors_2.f90
@@ -1,6 +1,7 @@
! { dg-do run }
+! { dg-options "-std=f2008" }
! { dg-shouldfail "runtime error" }
-! { dg-output "At line 13.*File already opened" }
+! { dg-output "At line 14.*File already opened" }
! PR 65563 - this used to segfault for some versions.
variable_1 = 0
diff --git a/gcc/testsuite/gfortran.dg/open_errors_3.f90
b/gcc/testsuite/gfortran.dg/open_errors_3.f90
new file mode 100644
index 000..da9495610d4
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/open_errors_3.f90
@@ -0,0 +1,11 @@
+! { dg-do run }
+! PR 90461 Open file on multiple units as of F2018
+program openmult
+ implicit none
+ character(len=*), parameter :: fname="pr90461.dat"
+ open(10, file=fname, form="unformatted")
+ open(11, file=fname, form="unformatted")
+ close(11)
+ close(10, status="delete")
+end program openmult
+! { dg-final { remote_file build delete "pr90461.dat" } }
diff --git a/libgfortran/io/open.c b/libgfortran/io/open.c
index b48afabf7a3..d3bb11f5965 100644
--- a/libgfortran/io/open.c
+++ b/libgfortran/io/open.c
@@ -515,7 +515,8 @@ new_unit (st_parameter_open *opp, gfc_unit *u, unit_flags
*flags)
Do not error if opening file preconnected to stdin, stdout, stderr. */
u2 = NULL;
- if ((opp->common.flags & IOPARM_OPEN_HAS_FILE) != 0)
+ if ((opp->common.flags & IOPARM_OPEN_HAS_FILE) != 0
+ && !(compile_options.allow_std & GFC_STD_F2018))
u2 = find_file (opp->file, opp->file_len);
if (u2 != NULL
&& (options.stdin_unit < 0 || u2->unit_number != options.stdin_unit)
--
2.17.1
Re: [PATCH 2/2] aarch64 back-end changes
On 15/05/2019 13:48, Richard Earnshaw (lists) wrote: > On 15/05/2019 03:39, kugan.vivekanandara...@linaro.org wrote: >> From: Kugan Vivekanandarajah >> > > The subject line to this email is not helpful. Why should I be > interested in reviewing this patch? Also, why does it claim to be 2/2 > when there's no 1/2 to go with it? Ah, just noticed that there is a part 1/2 (and a part 0/2) but they hit a different filter in my mailer so ended up in a different folder. That doesn't affect the other comments, though: each patch should be self-contained, even if there's an overall covering letter. R. > > Please include with all patches a justification giving background to why > you believe the patch is correct. All patches need this sort of > description - don't assume that the reviewer is familiar with the code > or will just accept your word for it. > > R. >
Re: [PATCH] PR90424 - lowpart vector set recognition
On Tue, 14 May 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 14 May 2019, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > The following makes SSA rewrite (update-address-taken) recognize
> >> > sets of aligned sub-vectors in aligned position
> >> > (v2qi into v16qi, but esp. v8qi into v16qi). It uses the
> >> > BIT_INSERT_EXPR support for this, enabling that for vector
> >> > typed values. This makes us turn for example
> >> >
> >> > typedef unsigned char v16qi __attribute__((vector_size(16)));
> >> > v16qi load (const void *p)
> >> > {
> >> > v16qi r;
> >> > __builtin_memcpy (, p, 8);
> >> > return r;
> >> > }
> >> >
> >> > into the following
> >> >
> >> > load (const void * p)
> >> > {
> >> > v16qi r;
> >> > long unsigned int _3;
> >> > v16qi _5;
> >> > vector(8) unsigned char _7;
> >> >
> >> >:
> >> > _3 = MEM[(char * {ref-all})p_2(D)];
> >> > _7 = VIEW_CONVERT_EXPR(_3);
> >> > r_9 = BIT_INSERT_EXPR ;
> >> > _5 = r_9;
> >> > return _5;
> >> >
> >> > this isn't yet nicely expanded since the BIT_INSERT_EXPR
> >> > expansion simply goes through store_bit_field and there's
> >> > no vector-mode vec_set.
> >> >
> >> > Similar as to the single-element insert SSA rewrite already
> >> > handles the transform is conditional on the involved
> >> > vector types having non-BLKmode. This is somewhat bad
> >> > since the transform is supposed to enable SSA optimizations
> >> > by rewriting memory vectors into SSA form. Since splitting
> >> > of larger generic vectors happens very much later only
> >> > this pessimizes their use. But the BIT_INSERT_EXPR
> >> > expansion doesn't cope with BLKmode entities (source or
> >> > destination).
> >> >
> >> > Extending BIT_INSERT_EXPR this way seems natural given
> >> > the support of CONSTRUCTORs with smaller vectors.
> >> > BIT_FIELD_REF isn't particularly restricted so can be
> >> > used to extract sub-vectors as well.
> >> >
> >> > Code generation is as bad as before (RTL expansion eventually
> >> > spills) but SSA optimizations are enabled on less trivial
> >> > testcases.
> >> >
> >> > Boostrap / regtest running on x86_64-unknown-linux-gnu.
> >> >
> >> > Comments?
> >> >
> >> > Richard.
> >> >
> >> > 2019-05-14 Richard Biener
> >> >
> >> > PR tree-optimization/90424
> >> > * tree-ssa.c (non_rewritable_lvalue_p): Handle inserts from
> >> > aligned subvectors.
> >> > (execute_update_addresses_taken): Likewise.
> >> > * tree-cfg.c (verify_gimple_assign_ternary): Likewise.
> >> >
> >> > * g++.target/i386/pr90424-1.C: New testcase.
> >> > * g++.target/i386/pr90424-2.C: Likewise.
> >> >
> >> > Index: gcc/tree-ssa.c
> >> > ===
> >> > --- gcc/tree-ssa.c (revision 271155)
> >> > +++ gcc/tree-ssa.c (working copy)
> >> > @@ -1521,14 +1521,28 @@ non_rewritable_lvalue_p (tree lhs)
> >> >if (DECL_P (decl)
> >> >&& VECTOR_TYPE_P (TREE_TYPE (decl))
> >> >&& TYPE_MODE (TREE_TYPE (decl)) != BLKmode
> >> > - && operand_equal_p (TYPE_SIZE_UNIT (TREE_TYPE (lhs)),
> >> > - TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE
> >> > (decl))), 0)
> >> > + && multiple_of_p (sizetype,
> >> > +TYPE_SIZE_UNIT (TREE_TYPE (decl)),
> >> > +TYPE_SIZE_UNIT (TREE_TYPE (lhs)))
> >> >&& known_ge (mem_ref_offset (lhs), 0)
> >> >&& known_gt (wi::to_poly_offset (TYPE_SIZE_UNIT (TREE_TYPE
> >> > (decl))),
> >> > mem_ref_offset (lhs))
> >> >&& multiple_of_p (sizetype, TREE_OPERAND (lhs, 1),
> >> > TYPE_SIZE_UNIT (TREE_TYPE (lhs
> >> > -return false;
> >> > +{
> >> > + if (operand_equal_p (TYPE_SIZE_UNIT (TREE_TYPE (lhs)),
> >> > + TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE
> >> > (decl))),
> >> > + 0))
> >> > +return false;
> >> > + /* For sub-vector inserts the insert vector mode has to be
> >> > + supported. */
> >> > + tree vtype = build_vector_type
> >> > + (TREE_TYPE (TREE_TYPE (decl)),
> >> > + tree_to_uhwi (TYPE_SIZE (TREE_TYPE (lhs)))
> >> > + / tree_to_uhwi (TYPE_SIZE (TREE_TYPE (TREE_TYPE
> >> > (decl);
> >>
> >> AFAICT nothing guarantees tree_fits_uhwi_p for the lhs, so this isn't
> >> poly-int clean. Is there a guarantee that lhs is a multiple of the
> >> element size even for integers? Or are we just relying on a vector
> >> of 0 elements being rejected?
> >
> > That it is a multiple of the element size is tested indirectly by
> >
> >> > + && multiple_of_p (sizetype,
> >> > + TYPE_SIZE_UNIT (TREE_TYPE (decl)),
> >> > + TYPE_SIZE_UNIT (TREE_TYPE (lhs)))
> >
> > given 'decl' has vector type. That also guarantees
[PATCH] Call update_address_taken before into-SSA
I've noticed we fail to rewrite vectors into SSA at the earliest opportunity because FEs leave us with stray TREE_ADDRESSABLE set or IL that is not suitable for SSA but can be easily rewritten. The earliest opportunity to fix this is when we rewrite into SSA where it has low overhead (no operand cache or extra SSA rewrite necessary). Only doing it when optimizing though. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2019-05-15 Richard Biener * tree-into-ssa.c (pass_build_ssa::execute): Run update_address_taken before going into SSA. Index: gcc/tree-into-ssa.c === --- gcc/tree-into-ssa.c (revision 271202) +++ gcc/tree-into-ssa.c (working copy) @@ -2425,6 +2425,12 @@ pass_build_ssa::execute (function *fun) bitmap_head *dfs; basic_block bb; + /* Increase the set of variables we can rewrite into SSA form + by clearing TREE_ADDRESSABLE and setting DECL_GIMPLE_REG_P + and transform the IL to support this. */ + if (optimize) +execute_update_addresses_taken (); + /* Initialize operand data structures. */ init_ssa_operands (fun);
Re: [PATCH 2/2] aarch64 back-end changes
On 15/05/2019 03:39, kugan.vivekanandara...@linaro.org wrote:
> From: Kugan Vivekanandarajah
>
The subject line to this email is not helpful. Why should I be
interested in reviewing this patch? Also, why does it claim to be 2/2
when there's no 1/2 to go with it?
Please include with all patches a justification giving background to why
you believe the patch is correct. All patches need this sort of
description - don't assume that the reviewer is familiar with the code
or will just accept your word for it.
R.
> gcc/ChangeLog:
>
> 2019-05-15 Kugan Vivekanandarajah
>
> PR target/88834
> * config/aarch64/aarch64.c (aarch64_classify_address): Relax
> allow_reg_index_p.
>
> gcc/testsuite/ChangeLog:
>
> 2019-05-15 Kugan Vivekanandarajah
>
> PR target/88834
> * gcc.target/aarch64/pr88834.c: New test.
> * gcc.target/aarch64/sve/struct_vect_1.c: Adjust.
> * gcc.target/aarch64/sve/struct_vect_14.c: Likewise.
> * gcc.target/aarch64/sve/struct_vect_15.c: Likewise.
> * gcc.target/aarch64/sve/struct_vect_16.c: Likewise.
> * gcc.target/aarch64/sve/struct_vect_17.c: Likewise.
> * gcc.target/aarch64/sve/struct_vect_7.c: Likewise.
>
> Change-Id: I840d08dc89a845b3913204228bae1bed40601d07
> ---
> gcc/config/aarch64/aarch64.c | 2 +-
> gcc/testsuite/gcc.target/aarch64/pr88834.c| 15 +++
> gcc/testsuite/gcc.target/aarch64/sve/struct_vect_1.c | 8
> gcc/testsuite/gcc.target/aarch64/sve/struct_vect_14.c | 8
> gcc/testsuite/gcc.target/aarch64/sve/struct_vect_15.c | 8
> gcc/testsuite/gcc.target/aarch64/sve/struct_vect_16.c | 8
> gcc/testsuite/gcc.target/aarch64/sve/struct_vect_17.c | 8
> gcc/testsuite/gcc.target/aarch64/sve/struct_vect_7.c | 8
> 8 files changed, 40 insertions(+), 25 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/aarch64/pr88834.c
>
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 1f90467..34292eb 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -6592,7 +6592,7 @@ aarch64_classify_address (struct aarch64_address_info
> *info,
>bool allow_reg_index_p = (!load_store_pair_p
> && (known_lt (GET_MODE_SIZE (mode), 16)
> || vec_flags == VEC_ADVSIMD
> - || vec_flags == VEC_SVE_DATA));
> + || vec_flags & VEC_SVE_DATA));
>
>/* For SVE, only accept [Rn], [Rn, Rm, LSL #shift] and
> [Rn, #offset, MUL VL]. */
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr88834.c
> b/gcc/testsuite/gcc.target/aarch64/pr88834.c
> new file mode 100644
> index 000..ea00967
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr88834.c
> @@ -0,0 +1,15 @@
> +/* { dg-do compile } */
> +/* { dg-options "-S -O3 -march=armv8.2-a+sve" } */
> +
> +void
> +f (int *restrict x, int *restrict y, int *restrict z, int n)
> +{
> + for (int i = 0; i < n; i += 2)
> +{
> + x[i] = y[i] + z[i];
> + x[i + 1] = y[i + 1] - z[i + 1];
> +}
> +}
> +
> +/* { dg-final { scan-assembler-times {\tld2w\t{z[0-9]+.s - z[0-9]+.s},
> p[0-7]/z, \[x[0-9]+, x[0-9]+, lsl 2\]\n} 2 } } */
> +/* { dg-final { scan-assembler-times {\tst2w\t{z[0-9]+.s - z[0-9]+.s},
> p[0-7], \[x[0-9]+, x[0-9]+, lsl 2\]\n} 1 } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_1.c
> b/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_1.c
> index 6e3c889..918a581 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_1.c
> @@ -83,9 +83,9 @@ NAME(g4) (TYPE *__restrict a, TYPE *__restrict b, TYPE
> *__restrict c,
> }
> }
>
> -/* { dg-final { scan-assembler {\tld2b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7]/z,
> \[x[0-9]+\]\n} } } */
> +/* { dg-final { scan-assembler {\tld2b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7]/z,
> \[x[0-9]+, x[0-9]+\]\n} } } */
> /* { dg-final { scan-assembler {\tld3b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7]/z,
> \[x[0-9]+\]\n} } } */
> -/* { dg-final { scan-assembler {\tld4b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7]/z,
> \[x[0-9]+\]\n} } } */
> -/* { dg-final { scan-assembler {\tst2b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7],
> \[x[0-9]+\]\n} } } */
> +/* { dg-final { scan-assembler {\tld4b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7]/z,
> \[x[0-9]+, x[0-9]+\]\n} } } */
> +/* { dg-final { scan-assembler {\tst2b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7],
> \[x[0-9]+, x[0-9]+\]\n} } } */
> /* { dg-final { scan-assembler {\tst3b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7],
> \[x[0-9]+\]\n} } } */
> -/* { dg-final { scan-assembler {\tst4b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7],
> \[x[0-9]+\]\n} } } */
> +/* { dg-final { scan-assembler {\tst4b\t{z[0-9]+.b - z[0-9]+.b}, p[0-7],
> \[x[0-9]+, x[0-9]+\]\n} } } */
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_14.c
>
@代@理@税@票@
+ 开 各 地 正 规 普 通 税 票 详电：刘小姐 电话：136-0190-4137 ( V信：同号） QQ：195-133-0600 ++ 2019/5/15
[ARM/FDPIC v5 21/21] [ARM] FDPIC: Handle stack-protector combined patterns
The recent stack_protect_combined_set_insn and
stack_protect_combined_test_insn force recomputing of GOT base, but
need to take into account that in FDPIC mode, the PIC register is
fixed by the ABI (r9).
2019-XX-XX Christophe Lyon
* config/arm/arm.md (stack_protect_combined_set_insn): Handle
FDPIC mode.
(stack_protect_combined_test_insn): Likewise.
Change-Id: Ib243fab0791fc883ca7b1c1205af1e0893f3e8c5
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 0edcb1d..5a4dd00 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -8869,8 +8869,19 @@
{
if (flag_pic)
{
+ rtx pic_reg;
+
+ if (TARGET_FDPIC)
+{
+ pic_reg = gen_rtx_REG (Pmode, FDPIC_REGNUM);
+ }
+ else
+{
+ pic_reg = operands[3];
+ }
+
/* Forces recomputing of GOT base now. */
- legitimize_pic_address (operands[1], SImode, operands[2], operands[3],
+ legitimize_pic_address (operands[1], SImode, operands[2], pic_reg,
true /*compute_now*/);
}
else
@@ -8943,8 +8954,19 @@
if (flag_pic)
{
+ rtx pic_reg;
+
+ if (TARGET_FDPIC)
+{
+ pic_reg = gen_rtx_REG (Pmode, FDPIC_REGNUM);
+}
+ else
+{
+ pic_reg = operands[4];
+ }
+
/* Forces recomputing of GOT base now. */
- legitimize_pic_address (operands[1], SImode, operands[3], operands[4],
+ legitimize_pic_address (operands[1], SImode, operands[3], pic_reg,
true /*compute_now*/);
}
else
--
2.6.3
[ARM/FDPIC v5 20/21] [ARM][testsuite] FDPIC: Skip tests using architectures unsupported by FDPIC
Since FDPIC currently supports arm and thumb-2 modes only, these tests
fail because they enforce an architecture version that doesn't match
these restrictions.
This patch introduces new values for the arm_arch effective-target
(v4t_thumb, v5t_thumb, v5te_thumb, v6_thumb, v6k_thumb, v6z_thumb) as
needed, and adds them to the relevant tests. It also adds the
corresponding non-thumb effective-target to the tests that were
missing it.
2019-XX-XX Christophe Lyon
* lib/target-supports.exp
(check_effective_target_arm_arch_FUNC_ok): Add v4t_thumb,
v5t_thumb, v5te_thumb, v6_thumb, v6k_thumb, v6z_thumb.
* gcc.target/arm/armv6-unaligned-load-ice.c: Add arm_arch
effective-target.
* gcc.target/arm/attr-unaligned-load-ice.c: Likewise.
* gcc.target/arm/attr_arm-err.c: Likewise.
* gcc.target/arm/ftest-armv4-arm.c: Likewise.
* gcc.target/arm/ftest-armv4t-arm.c: Likewise.
* gcc.target/arm/ftest-armv4t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5t-arm.c: Likewise.
* gcc.target/arm/ftest-armv5t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5te-arm.c: Likewise.
* gcc.target/arm/ftest-armv5te-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6-arm.c: Likewise.
* gcc.target/arm/ftest-armv6-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6k-arm.c: Likewise.
* gcc.target/arm/ftest-armv6k-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6m-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6t2-arm.c: Likewise.
* gcc.target/arm/ftest-armv6t2-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6z-arm.c: Likewise.
* gcc.target/arm/ftest-armv6z-thumb.c: Likewise.
* gcc.target/arm/g2.c: Likewise.
* gcc.target/arm/macro_defs1.c: Likewise.
* gcc.target/arm/pr59858.c: Likewise.
* gcc.target/arm/pr65647-2.c: Likewise.
* gcc.target/arm/pr79058.c: Likewise.
* gcc.target/arm/pr83712.c: Likewise.
* gcc.target/arm/pragma_arch_switch_2.c: Likewise.
* gcc.target/arm/scd42-1.c: Likewise.
* gcc.target/arm/scd42-2.c: Likewise.
* gcc.target/arm/scd42-3.c: Likewise.
* gcc.c-torture/compile/pr82096.c: Fix arm_arch effective-target.
Change-Id: I0845b262b241026561cc52a19ff8bb1659675e49
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr82096.c
b/gcc/testsuite/gcc.c-torture/compile/pr82096.c
index d144b70..4e695cd 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr82096.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr82096.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target arm_arch_v5t_ok { target arm*-*-* } } */
+/* { dg-require-effective-target arm_arch_v5t_thumb_ok { target arm*-*-* } } */
/* { dg-skip-if "Do not combine float-abi values" { arm*-*-* } {
"-mfloat-abi=*" } { "-mfloat-abi=soft" } } */
/* { dg-additional-options "-march=armv5t -mthumb -mfloat-abi=soft" { target
arm*-*-* } } */
diff --git a/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
b/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
index 88528f1..886a012 100644
--- a/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
+++ b/gcc/testsuite/gcc.target/arm/armv6-unaligned-load-ice.c
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" }
{ "-march=armv6k" } } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" } {
"" } } */
+/* { dg-require-effective-target arm_arch_v6k_thumb_ok } */
/* { dg-options "-mthumb -Os -mfloat-abi=softfp" } */
/* { dg-add-options arm_arch_v6k } */
diff --git a/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c
b/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c
index e1ed1c1..2eeb522 100644
--- a/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c
+++ b/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c
@@ -2,6 +2,7 @@
Verify that unaligned_access is correctly with attribute target. */
/* { dg-do compile } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" }
{ "-march=armv6" } } */
+/* { dg-require-effective-target arm_arch_v6_ok } */
/* { dg-options "-Os -mfloat-abi=softfp -mtp=soft" } */
/* { dg-add-options arm_arch_v6 } */
diff --git a/gcc/testsuite/gcc.target/arm/attr_arm-err.c
b/gcc/testsuite/gcc.target/arm/attr_arm-err.c
index 630c06a..d410056 100644
--- a/gcc/testsuite/gcc.target/arm/attr_arm-err.c
+++ b/gcc/testsuite/gcc.target/arm/attr_arm-err.c
@@ -2,6 +2,7 @@
/* { dg-do compile } */
/* { dg-require-effective-target arm_arm_ok } */
/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" }
{ "-march=armv6-m" } } */
+/* { dg-require-effective-target arm_arch_v6m_ok } */
/* { dg-add-options arm_arch_v6m } */
int __attribute__((target("arm")))
diff --git a/gcc/testsuite/gcc.target/arm/ftest-armv4-arm.c
b/gcc/testsuite/gcc.target/arm/ftest-armv4-arm.c
index 4b48ef8..447a8ec 100644
---
[ARM/FDPIC v5 19/21] [ARM][testsuite] FDPIC: Adjust pr43698.c to avoid clash with uclibc.
uclibc defines bswap_32, so use a different name in this test.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* gcc.target/arm/pr43698.c (bswap_32): Rename as my_bswap_32.
Change-Id: I2591bd911030814331cabf97ee5cf6cf8124b4f3
diff --git a/gcc/testsuite/gcc.target/arm/pr43698.c
b/gcc/testsuite/gcc.target/arm/pr43698.c
index 1fc497c..3b5dad0 100644
--- a/gcc/testsuite/gcc.target/arm/pr43698.c
+++ b/gcc/testsuite/gcc.target/arm/pr43698.c
@@ -6,7 +6,7 @@
char do_reverse_endian = 0;
-# define bswap_32(x) \
+# define my_bswap_32(x) \
x) & 0xff00) >> 24) | \
(((x) & 0x00ff) >> 8) | \
(((x) & 0xff00) << 8) | \
@@ -16,7 +16,7 @@ char do_reverse_endian = 0;
(__extension__ ({ \
uint64_t __res; \
if (!do_reverse_endian) {__res = (X); \
- } else if (sizeof(X) == 4) { __res = bswap_32((X)); \
+ } else if (sizeof(X) == 4) { __res = my_bswap_32((X)); \
} \
__res; \
}))
--
2.6.3
[ARM/FDPIC v5 18/21] [ARM][testsuite] FDPIC: Enable tests on pie_enabled targets
Some tests have the "nonpic" guard, but pass on
arm*-*-uclinuxfdpiceabi because it is in PIE mode by default. Rather
than adding this target to all these tests, add the "pie_enabled"
effective target.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* g++.dg/cpp0x/noexcept03.C: Add pie_enabled.
* g++.dg/ipa/devirt-c-7.C: Likewise.
* g++.dg/ipa/ivinline-1.C: Likewise.
* g++.dg/ipa/ivinline-2.C: Likewise.
* g++.dg/ipa/ivinline-3.C: Likewise.
* g++.dg/ipa/ivinline-4.C: Likewise.
* g++.dg/ipa/ivinline-5.C: Likewise.
* g++.dg/ipa/ivinline-7.C: Likewise.
* g++.dg/ipa/ivinline-8.C: Likewise.
* g++.dg/ipa/ivinline-9.C: Likewise.
* g++.dg/tls/pr79288.C: Likewise.
* gcc.dg/addr_equal-1.c: Likewise.
* gcc.dg/const-1.c: Likewise.
* gcc.dg/ipa/pure-const-1.c: Likewise.
* gcc.dg/noreturn-8.c: Likewise.
* gcc.dg/pr33826.c: Likewise.
* gcc.dg/torture/ipa-pta-1.c: Likewise.
* gcc.dg/tree-ssa/alias-2.c: Likewise.
* gcc.dg/tree-ssa/ipa-split-5.c: Likewise.
* gcc.dg/tree-ssa/loadpre6.c: Likewise.
* gcc.dg/uninit-19.c: Likewise.
Change-Id: I1a0d836b892c23891f739fccdc467d0f354ab82c
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept03.C
b/gcc/testsuite/g++.dg/cpp0x/noexcept03.C
index 2d37867..906a44d 100644
--- a/gcc/testsuite/g++.dg/cpp0x/noexcept03.C
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept03.C
@@ -1,6 +1,6 @@
// Runtime test for noexcept-specification.
// { dg-options "-Wnoexcept" }
-// { dg-do run { target nonpic } }
+// { dg-do run { target { nonpic || pie_enabled } } }
// { dg-require-effective-target c++11 }
#include
diff --git a/gcc/testsuite/g++.dg/ipa/devirt-c-7.C
b/gcc/testsuite/g++.dg/ipa/devirt-c-7.C
index 2e76cbe..efb65c2 100644
--- a/gcc/testsuite/g++.dg/ipa/devirt-c-7.C
+++ b/gcc/testsuite/g++.dg/ipa/devirt-c-7.C
@@ -1,7 +1,6 @@
/* Verify that ipa-cp will not get confused by placement new constructing an
object within another one when looking for dynamic type change . */
-/* { dg-do run } */
-/* { dg-require-effective-target nonpic } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
/* { dg-options "-O3 -Wno-attributes" } */
extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-1.C
b/gcc/testsuite/g++.dg/ipa/ivinline-1.C
index 9b10d20..2d988bc 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-1.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-1.C
@@ -1,6 +1,6 @@
/* Verify that simple virtual calls are inlined even without early
inlining. */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
/* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp" } */
extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-2.C
b/gcc/testsuite/g++.dg/ipa/ivinline-2.C
index 21cd46f..d978638 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-2.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-2.C
@@ -1,6 +1,6 @@
/* Verify that simple virtual calls using this pointer are inlined
even without early inlining.. */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
/* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp" } */
extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-3.C
b/gcc/testsuite/g++.dg/ipa/ivinline-3.C
index 1e24644..f756a16 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-3.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-3.C
@@ -1,6 +1,6 @@
/* Verify that simple virtual calls on an object refrence are inlined
even without early inlining. */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
/* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp" } */
extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-4.C
b/gcc/testsuite/g++.dg/ipa/ivinline-4.C
index cf0d980..5fbd3ef 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-4.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-4.C
@@ -1,7 +1,7 @@
/* Verify that simple virtual calls are inlined even without early
inlining, even when a typecast to an ancestor is involved along the
way. */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
/* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining -fno-ipa-cp" } */
extern "C" void abort (void);
diff --git a/gcc/testsuite/g++.dg/ipa/ivinline-5.C
b/gcc/testsuite/g++.dg/ipa/ivinline-5.C
index f15ebf2..6c19907 100644
--- a/gcc/testsuite/g++.dg/ipa/ivinline-5.C
+++ b/gcc/testsuite/g++.dg/ipa/ivinline-5.C
@@ -1,6 +1,6 @@
/* Verify that virtual call inlining does not pick a wrong method when
there is a user defined ancestor in an object. */
-/* { dg-do run { target nonpic } } */
+/* { dg-do run { target { nonpic || pie_enabled } } } */
/* { dg-options "-O3 -fdump-ipa-inline -fno-early-inlining
[ARM/FDPIC v5 17/21] [ARM][testsuite] FDPIC: Handle *-*-uclinux*
Add *-*-uclinux* to tests that work on this target.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* g++.dg/abi/forced.C: Add *-*-uclinux*.
* g++.dg/abi/guard2.C: Likewise.
* g++.dg/ext/cleanup-10.C: Likewise.
* g++.dg/ext/cleanup-11.C: Likewise.
* g++.dg/ext/cleanup-8.C: Likewise.
* g++.dg/ext/cleanup-9.C: Likewise.
* g++.dg/ext/sync-4.C: Likewise.
* g++.dg/ipa/comdat.C: Likewise.
* gcc.dg/20041106-1.c: Likewise.
* gcc.dg/cleanup-10.c: Likewise.
* gcc.dg/cleanup-11.c: Likewise.
* gcc.dg/cleanup-8.c: Likewise.
* gcc.dg/cleanup-9.c: Likewise.
* gcc.dg/fdata-sections-1.c: Likewise.
* gcc.dg/fdata-sections-2.c: Likewise.
* gcc.dg/pr39323-1.c: Likewise.
* gcc.dg/pr39323-2.c: Likewise.
* gcc.dg/pr39323-3.c: Likewise.
* gcc.dg/pr65780-1.c: Likewise.
* gcc.dg/pr65780-2.c: Likewise.
* gcc.dg/pr67338.c: Likewise.
* gcc.dg/pr78185.c: Likewise.
* gcc.dg/pr83100-1.c: Likewise.
* gcc.dg/pr83100-4.c: Likewise.
* gcc.dg/strlenopt-12g.c: Likewise.
* gcc.dg/strlenopt-14g.c: Likewise.
* gcc.dg/strlenopt-14gf.c: Likewise.
* gcc.dg/strlenopt-16g.c: Likewise.
* gcc.dg/strlenopt-17g.c: Likewise.
* gcc.dg/strlenopt-18g.c: Likewise.
* gcc.dg/strlenopt-1f.c: Likewise.
* gcc.dg/strlenopt-22g.c: Likewise.
* gcc.dg/strlenopt-2f.c: Likewise.
* gcc.dg/strlenopt-31g.c: Likewise.
* gcc.dg/strlenopt-33g.c: Likewise.
* gcc.dg/strlenopt-4g.c: Likewise.
* gcc.dg/strlenopt-4gf.c: Likewise.
* gcc.dg/strncmp-2.c: Likewise.
* gcc.dg/struct-ret-3.c: Likewise.
* gcc.dg/torture/pr69760.c: Likewise.
* gcc.target/arm/div64-unwinding.c: Likewise.
* gcc.target/arm/stack-checking.c: Likewise.
* gcc.target/arm/synchronize.c: Likewise.
* gcc.target/arm/pr66912.c: Add arm*-*-uclinuxfdpiceabi.
* lib/target-supports.exp (check_effective_target_pie): Likewise.
(check_effective_target_sync_long_long_runtime): Likewise.
(check_effective_target_sync_int_long): Likewise.
(check_effective_target_sync_char_short): Likewise.
Change-Id: I89bfea79d4490c5df0b6470def5a31d7f31ac2cc
diff --git a/gcc/testsuite/g++.dg/abi/forced.C
b/gcc/testsuite/g++.dg/abi/forced.C
index 0e6be28..2d1ec53 100644
--- a/gcc/testsuite/g++.dg/abi/forced.C
+++ b/gcc/testsuite/g++.dg/abi/forced.C
@@ -1,4 +1,4 @@
-// { dg-do run { target *-*-linux* *-*-gnu* } }
+// { dg-do run { target *-*-linux* *-*-gnu* *-*-uclinux* } }
// { dg-options "-pthread" }
#include
diff --git a/gcc/testsuite/g++.dg/abi/guard2.C
b/gcc/testsuite/g++.dg/abi/guard2.C
index c35fa7e..74139a8 100644
--- a/gcc/testsuite/g++.dg/abi/guard2.C
+++ b/gcc/testsuite/g++.dg/abi/guard2.C
@@ -1,6 +1,6 @@
// PR c++/41611
// Test that the guard gets its own COMDAT group.
-// { dg-final { scan-assembler "_ZGVZN1A1fEvE1i,comdat" { target *-*-linux*
*-*-gnu* } } }
+// { dg-final { scan-assembler "_ZGVZN1A1fEvE1i,comdat" { target *-*-linux*
*-*-gnu* *-*-uclinux* } } }
struct A {
static int f()
diff --git a/gcc/testsuite/g++.dg/ext/cleanup-10.C
b/gcc/testsuite/g++.dg/ext/cleanup-10.C
index 66c7b76..56aeb66 100644
--- a/gcc/testsuite/g++.dg/ext/cleanup-10.C
+++ b/gcc/testsuite/g++.dg/ext/cleanup-10.C
@@ -1,4 +1,4 @@
-/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin*
*-*-darwin[912]* } } */
+/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin*
*-*-darwin[912]* *-*-uclinux* } } */
/* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
/* Verify that cleanups work with exception handling through signal frames
on alternate stack. */
diff --git a/gcc/testsuite/g++.dg/ext/cleanup-11.C
b/gcc/testsuite/g++.dg/ext/cleanup-11.C
index 6e96521..c6d3560 100644
--- a/gcc/testsuite/g++.dg/ext/cleanup-11.C
+++ b/gcc/testsuite/g++.dg/ext/cleanup-11.C
@@ -1,4 +1,4 @@
-/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin*
*-*-darwin[912]* } } */
+/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin*
*-*-darwin[912]* *-*-uclinux* } } */
/* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
/* Verify that cleanups work with exception handling through realtime signal
frames on alternate stack. */
diff --git a/gcc/testsuite/g++.dg/ext/cleanup-8.C
b/gcc/testsuite/g++.dg/ext/cleanup-8.C
index ccf9bef..e99508d 100644
--- a/gcc/testsuite/g++.dg/ext/cleanup-8.C
+++ b/gcc/testsuite/g++.dg/ext/cleanup-8.C
@@ -1,4 +1,4 @@
-/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin*
*-*-darwin[912]* } } */
+/* { dg-do run { target hppa*-*-hpux* *-*-linux* *-*-gnu* powerpc*-*-darwin*
*-*-darwin[912]* *-*-uclinux* } } */
/* { dg-options "-fexceptions -fnon-call-exceptions -O2" } */
/* Verify that cleanups work with
[ARM/FDPIC v5 15/21] [ARM][testsuite] FDPIC: Adjust scan-assembler patterns.
In FDPIC mode, r9 is saved in addition to other registers, so update
the expected patterns accordingly.
2019-XX-XX Christophe Lyon
Mickaël Guêné
* gcc/testsuite/
* gcc.target/arm/interrupt-1.c: Add scan-assembler pattern for
arm*-*-uclinuxfdpiceabi.
* gcc.target/arm/interrupt-2.c: Likewise.
* gcc.target/arm/pr70830.c: Likewise.
Change-Id: Id946b79bacc32be585c31e60a355191f104cc29e
diff --git a/gcc/testsuite/gcc.target/arm/interrupt-1.c
b/gcc/testsuite/gcc.target/arm/interrupt-1.c
index fe94877..493763d 100644
--- a/gcc/testsuite/gcc.target/arm/interrupt-1.c
+++ b/gcc/testsuite/gcc.target/arm/interrupt-1.c
@@ -13,5 +13,7 @@ void foo ()
bar (0);
}
-/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, fp, ip, lr}" } } */
-/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, fp, ip,
pc}\\^" } } */
+/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, fp, ip, lr}" {
target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, fp, ip,
pc}\\^" { target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, r5, r9, fp, ip,
lr}" { target arm*-*-uclinuxfdpiceabi } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, r9, fp,
ip, pc}\\^" { target arm*-*-uclinuxfdpiceabi } } } */
diff --git a/gcc/testsuite/gcc.target/arm/interrupt-2.c
b/gcc/testsuite/gcc.target/arm/interrupt-2.c
index 289eca0..5be1f16 100644
--- a/gcc/testsuite/gcc.target/arm/interrupt-2.c
+++ b/gcc/testsuite/gcc.target/arm/interrupt-2.c
@@ -15,5 +15,7 @@ void test()
foo = 0;
}
-/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, r5, ip, lr}" } } */
-/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, ip,
pc}\\^" } } */
+/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, r5, ip, lr}" {
target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, ip,
pc}\\^" { target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "push\t{r0, r1, r2, r3, r4, r5, r6, r9, ip,
lr}" { target arm*-*-uclinuxfdpiceabi } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r5, r6, r9,
ip, pc}\\^" { target arm*-*-uclinuxfdpiceabi } } } */
diff --git a/gcc/testsuite/gcc.target/arm/pr70830.c
b/gcc/testsuite/gcc.target/arm/pr70830.c
index cad903b..cd84c42 100644
--- a/gcc/testsuite/gcc.target/arm/pr70830.c
+++ b/gcc/testsuite/gcc.target/arm/pr70830.c
@@ -11,4 +11,5 @@ void __attribute__ ((interrupt ("IRQ")))
dm3730_IRQHandler(void)
{
prints("IRQ" );
}
-/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, ip, pc}\\^" } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, ip, pc}\\^" {
target { ! arm*-*-uclinuxfdpiceabi } } } } */
+/* { dg-final { scan-assembler "ldmfd\tsp!, {r0, r1, r2, r3, r4, r9, ip,
pc}\\^" { target arm*-*-uclinuxfdpiceabi } } } */
--
2.6.3
[ARM/FDPIC v5 16/21] [ARM][testsuite] FDPIC: Skip tests that don't work in PIC mode
Some tests fail on arm*-*-uclinuxfdpiceabi because it generates PIC
code and they don't support it: skip them. They also fail on
arm*-linux* when forcing -fPIC.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* gcc.target/arm/eliminate.c: Accept only nonpic targets.
* g++.dg/other/anon5.C: Likewise.
Change-Id: I8efb8d356ce25b020c44a84b07f79a996dca0358
diff --git a/gcc/testsuite/g++.dg/other/anon5.C
b/gcc/testsuite/g++.dg/other/anon5.C
index ee4601e..dadd92e 100644
--- a/gcc/testsuite/g++.dg/other/anon5.C
+++ b/gcc/testsuite/g++.dg/other/anon5.C
@@ -1,5 +1,6 @@
// PR c++/34094
// { dg-do link { target { ! { *-*-darwin* *-*-hpux* *-*-solaris2.* } } } }
+// { dg-require-effective-target nonpic }
// { dg-options "-gdwarf-2" }
// Ignore additional message on powerpc-ibm-aix
// { dg-prune-output "obtain more information" } */
diff --git a/gcc/testsuite/gcc.target/arm/eliminate.c
b/gcc/testsuite/gcc.target/arm/eliminate.c
index f254dd8..299d4df 100644
--- a/gcc/testsuite/gcc.target/arm/eliminate.c
+++ b/gcc/testsuite/gcc.target/arm/eliminate.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { nonpic } } } */
/* { dg-options "-O2" } */
struct X
--
2.6.3
[ARM/FDPIC v5 13/21] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture
Without this, when we are unwinding across a signal frame we can jump to an even address which leads to an exception. This is needed in __gnu_persnality_sigframe_fdpic() when restoring the PC from the signal frame since the PC saved by the kernel has the LSB bit set to zero. 2019-XX-XX Christophe Lyon Mickaël Guêné libgcc/ * config/arm/unwind-arm.c (_Unwind_VRS_Set): Handle v7m architecture. Change-Id: Ie84de548226bcf1751e19a09e8f091fb3013ccea diff --git a/libgcc/config/arm/unwind-arm.c b/libgcc/config/arm/unwind-arm.c index 9ba73e7..ba47150 100644 --- a/libgcc/config/arm/unwind-arm.c +++ b/libgcc/config/arm/unwind-arm.c @@ -199,6 +199,11 @@ _Unwind_VRS_Result _Unwind_VRS_Set (_Unwind_Context *context, return _UVRSR_FAILED; vrs->core.r[regno] = *(_uw *) valuep; +#if defined(__ARM_ARCH_7M__) + /* Force LSB bit since we always run thumb code. */ + if (regno == 15) + vrs->core.r[regno] |= 1; +#endif return _UVRSR_OK; case _UVRSC_VFP: -- 2.6.3
[ARM/FDPIC v5 14/21] [ARM][testsuite] FDPIC: Skip unsupported tests
Several tests cannot work on ARM-FDPIC for various reasons: skip them,
or skip some directives.
gcc.dg/20020312-2.c: Skip since it forces -fno-pic.
gcc.target/arm/:
* Skip since r9 is clobbered by assembly code:
20051215-1.c
mmx-1.c
pr61948.c
pr77933-1.c
pr77933-2.c
* Skip since the test forces armv5te which is not supported by FDPIC:
pr40887.c
pr19599.c
* Skip since FDPIC disables sibcall to external functions:
sibcall-1.c
tail-long-call
vfp-longcall-apcs
* Skip size check since it's different for FDPIC:
ivopts-2.c
ivopts-3.c
ivopts-4.c
ivopts-5.c
pr43597.c
pr43920-2.c
* Disable assembler scanning invalid for FDPIC:
pr45701-1.c
pr45701-2.c
stack-red-zone.c
* gnu2 TLS dialect is not supported by FDPIC:
tlscall.c
* Test relies on symbols not generated in FDPIC:
data-rel-2.c
data-rel-3.c
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/testsuite/
* gcc.dg/20020312-2.c: Skip on arm*-*-uclinuxfdpiceabi.
* gcc.target/arm/20051215-1.c: Likewise.
* gcc.target/arm/mmx-1.c: Likewise.
* gcc.target/arm/pr19599.c: Likewise.
* gcc.target/arm/pr40887.c: Likewise.
* gcc.target/arm/pr61948.c: Likewise.
* gcc.target/arm/pr77933-1.c: Likewise.
* gcc.target/arm/pr77933-2.c: Likewise.
* gcc.target/arm/sibcall-1.c: Likewise.
* gcc.target/arm/data-rel-2.c: Likewise.
* gcc.target/arm/data-rel-3.c: Likewise.
* gcc.target/arm/tail-long-call: Likewise.
* gcc.target/arm/tlscall.c: Likewise.
* gcc.target/arm/vfp-longcall-apcs: Likewise.
* gcc.target/arm/ivopts-2.c: Skip object-size test on
arm*-*-uclinuxfdpiceabi.
* gcc.target/arm/ivopts-3.c: Likewise.
* gcc.target/arm/ivopts-4.c: Likewise.
* gcc.target/arm/ivopts-5.c: Likewise.
* gcc.target/arm/pr43597.c: Likewise.
* gcc.target/arm/pr43920-2.c: Likewise.
* gcc.target/arm/pr45701-1.c: Skip scan-assembler on
arm*-*-uclinuxfdpiceabi.
* gcc.target/arm/pr45701-2.c: Likewise.
* gcc.target/arm/stack-red-zone.c: Likewise.
Change-Id: Icada7ce52537901fdac10403e7997571b7e2c509
diff --git a/gcc/testsuite/gcc.dg/20020312-2.c
b/gcc/testsuite/gcc.dg/20020312-2.c
index c584d35..3df99d9 100644
--- a/gcc/testsuite/gcc.dg/20020312-2.c
+++ b/gcc/testsuite/gcc.dg/20020312-2.c
@@ -9,6 +9,7 @@
/* { dg-options "-O -fno-pic" } */
/* { dg-additional-options "-no-pie" { target pie_enabled } } */
/* { dg-require-effective-target nonlocal_goto } */
+/* { dg-skip-if "" { arm*-*-uclinuxfdpiceabi } "*" "" } */
extern void abort (void);
diff --git a/gcc/testsuite/gcc.target/arm/20051215-1.c
b/gcc/testsuite/gcc.target/arm/20051215-1.c
index 0519dc7..cc07693 100644
--- a/gcc/testsuite/gcc.target/arm/20051215-1.c
+++ b/gcc/testsuite/gcc.target/arm/20051215-1.c
@@ -3,6 +3,7 @@
the call would need an output reload. */
/* { dg-do run } */
/* { dg-options "-O2 -fno-omit-frame-pointer" } */
+/* { dg-skip-if "r9 is reserved in FDPIC" { arm*-*-uclinuxfdpiceabi } "*" "" }
*/
extern void abort (void);
typedef void (*callback) (void);
diff --git a/gcc/testsuite/gcc.target/arm/data-rel-2.c
b/gcc/testsuite/gcc.target/arm/data-rel-2.c
index 6ba47d6..7d37a8c 100644
--- a/gcc/testsuite/gcc.target/arm/data-rel-2.c
+++ b/gcc/testsuite/gcc.target/arm/data-rel-2.c
@@ -1,3 +1,4 @@
+/* { dg-skip-if "Not supported in FDPIC" { arm*-*-uclinuxfdpiceabi } "*" "" }
*/
/* { dg-options "-fPIC -mno-pic-data-is-text-relative -mno-single-pic-base" }
*/
/* { dg-final { scan-assembler-not "j-\\(.LPIC" } } */
/* { dg-final { scan-assembler "_GLOBAL_OFFSET_TABLE_-\\(.LPIC" } } */
diff --git a/gcc/testsuite/gcc.target/arm/data-rel-3.c
b/gcc/testsuite/gcc.target/arm/data-rel-3.c
index 2ce1e66..534c6c4 100644
--- a/gcc/testsuite/gcc.target/arm/data-rel-3.c
+++ b/gcc/testsuite/gcc.target/arm/data-rel-3.c
@@ -1,3 +1,4 @@
+/* { dg-skip-if "Not supported in FDPIC" { arm*-*-uclinuxfdpiceabi } "*" "" }
*/
/* { dg-options "-fPIC -mpic-data-is-text-relative" } */
/* { dg-final { scan-assembler "j-\\(.LPIC" } } */
/* { dg-final { scan-assembler-not "_GLOBAL_OFFSET_TABLE_-\\(.LPIC" } } */
diff --git a/gcc/testsuite/gcc.target/arm/ivopts-2.c
b/gcc/testsuite/gcc.target/arm/ivopts-2.c
index afe91aa..f1d5edb 100644
--- a/gcc/testsuite/gcc.target/arm/ivopts-2.c
+++ b/gcc/testsuite/gcc.target/arm/ivopts-2.c
@@ -14,4 +14,4 @@ tr4 (short array[], int n)
/* { dg-final { scan-tree-dump-times "PHI
[ARM/FDPIC v5 11/21] [ARM] FDPIC: Add support to unwind FDPIC signal frame
2019-XX-XX Christophe Lyon
Mickaël Guêné
libgcc/
* unwind-arm-common.inc (ARM_SET_R7_RT_SIGRETURN)
(THUMB2_SET_R7_RT_SIGRETURN, FDPIC_LDR_R12_WITH_FUNCDESC)
(FDPIC_LDR_R9_WITH_GOT, FDPIC_LDR_PC_WITH_RESTORER)
(FDPIC_FUNCDESC_OFFSET, ARM_NEW_RT_SIGFRAME_UCONTEXT)
(ARM_UCONTEXT_SIGCONTEXT, ARM_SIGCONTEXT_R0,
FDPIC_T2_LDR_R12_WITH_FUNCDESC)
(FDPIC_T2_LDR_R9_WITH_GOT, FDPIC_T2_LDR_PC_WITH_RESTORER): New.
(__gnu_personality_sigframe_fdpic): New.
(get_eit_entry): Add FDPIC signal frame support.
Change-Id: I7f9527cc50665dd1a731b7badf71c319fb38bf57
diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc
index 0bacc11..c9a82b7 100644
--- a/libgcc/unwind-arm-common.inc
+++ b/libgcc/unwind-arm-common.inc
@@ -30,6 +30,26 @@
#include
#endif
+#if __FDPIC__
+/* Load r7 with rt_sigreturn value. */
+#define ARM_SET_R7_RT_SIGRETURN0xe3a070ad /* mov r7,
#0xad */
+#define THUMB2_SET_R7_RT_SIGRETURN 0x07adf04f /* mov.w r7, #0xad */
+
+/* FDPIC jump to restorer sequence. */
+#define FDPIC_LDR_R12_WITH_FUNCDESC0xe59fc004 /* ldr r12, [pc, #4]
*/
+#define FDPIC_LDR_R9_WITH_GOT 0xe59c9004 /* ldr r9, [r12, #4]
*/
+#define FDPIC_LDR_PC_WITH_RESTORER 0xe59cf000 /* ldr pc, [r12] */
+#define FDPIC_T2_LDR_R12_WITH_FUNCDESC 0xc008f8df /* ldr.w r12, [pc, #8]
*/
+#define FDPIC_T2_LDR_R9_WITH_GOT 0x9004f8dc /* ldr.w r9, [r12, #4]
*/
+#define FDPIC_T2_LDR_PC_WITH_RESTORER 0xf000f8dc /* ldr.w pc, [r12] */
+#define FDPIC_FUNCDESC_OFFSET 12
+
+/* Signal frame offsets. */
+#define ARM_NEW_RT_SIGFRAME_UCONTEXT 0x80
+#define ARM_UCONTEXT_SIGCONTEXT0x14
+#define ARM_SIGCONTEXT_R0 0xc
+#endif
+
/* We add a prototype for abort here to avoid creating a dependency on
target headers. */
extern void abort (void);
@@ -199,6 +219,45 @@ search_EIT_table (const __EIT_entry * table, int nrec, _uw
return_address)
}
}
+#if __FDPIC__
+/* VFP is not restored, but this is sufficient to allow unwinding. */
+static _Unwind_Reason_Code
+__gnu_personality_sigframe_fdpic (_Unwind_State state,
+ _Unwind_Control_Block *ucbp,
+ _Unwind_Context *context)
+{
+unsigned int sp;
+unsigned int pc;
+unsigned int funcdesc;
+unsigned int handler;
+unsigned int first_handler_instruction;
+int i;
+
+_Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, );
+_Unwind_VRS_Get (context, _UVRSC_CORE, R_PC, _UVRSD_UINT32, );
+
+funcdesc = *(unsigned int *)((pc & ~1) + FDPIC_FUNCDESC_OFFSET);
+handler = *(unsigned int *)(funcdesc);
+first_handler_instruction = *(unsigned int *)(handler & ~1);
+
+/* Adjust SP to point to the start of registers according to
+ signal type. */
+if (first_handler_instruction == ARM_SET_R7_RT_SIGRETURN
+ || first_handler_instruction == THUMB2_SET_R7_RT_SIGRETURN)
+ sp += ARM_NEW_RT_SIGFRAME_UCONTEXT
+ + ARM_UCONTEXT_SIGCONTEXT
+ + ARM_SIGCONTEXT_R0;
+else
+ sp += ARM_UCONTEXT_SIGCONTEXT
+ + ARM_SIGCONTEXT_R0;
+/* Restore regs saved on stack by the kernel. */
+for (i = 0; i < 16; i++)
+ _Unwind_VRS_Set (context, _UVRSC_CORE, i, _UVRSD_UINT32, sp + 4 * i);
+
+return _URC_CONTINUE_UNWIND;
+}
+#endif
+
/* Find the exception index table eintry for the given address.
Fill in the relevant fields of the UCB.
Returns _URC_FAILURE if an error occurred, _URC_OK on success. */
@@ -222,6 +281,27 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
return_address)
);
if (!eitp)
{
+#if __FDPIC__
+ /* If we are unwinding a signal handler then perhaps we have
+reached a trampoline. Try to detect jump to restorer
+sequence. */
+ _uw *pc = (_uw *)((return_address+2) & ~1);
+ if ((pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
+ && pc[1] == FDPIC_LDR_R9_WITH_GOT
+ && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
+ || (pc[0] == FDPIC_T2_LDR_R12_WITH_FUNCDESC
+ && pc[1] == FDPIC_T2_LDR_R9_WITH_GOT
+ && pc[2] == FDPIC_T2_LDR_PC_WITH_RESTORER))
+ {
+ struct funcdesc_t *funcdesc
+ = (struct funcdesc_t *) &__gnu_personality_sigframe_fdpic;
+
+ UCB_PR_ADDR (ucbp) = funcdesc->ptr;
+ UCB_PR_GOT (ucbp) = funcdesc->got;
+
+ return _URC_OK;
+ }
+#endif
UCB_PR_ADDR (ucbp) = 0;
return _URC_FAILURE;
}
@@ -236,6 +316,27 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
return_address)
if (!eitp)
{
+#if __FDPIC__
+ /* If we are unwinding a signal handler then perhaps we have
+reached a trampoline. Try to detect jump to restorer
+
[ARM/FDPIC v5 10/21] [ARM] FDPIC: Implement TLS support.
Support additional relocations: TLS_GD32_FDPIC, TLS_LDM32_FDPIC, and
TLS_IE32_FDPIC.
We do not support the GNU2 TLS dialect.
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (tls_reloc): Add TLS_GD32_FDPIC,
TLS_LDM32_FDPIC and TLS_IE32_FDPIC.
(arm_call_tls_get_addr): Add FDPIC support.
(legitimize_tls_address): Likewise.
(arm_emit_tls_decoration): Likewise.
Change-Id: I4ea5034ff654540c4658d0a79fb92f70550cdf4a
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 99d13bf..5fc7a20 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -2379,9 +2379,12 @@ char arm_arch_name[] = "__ARM_ARCH_PROFILE__";
enum tls_reloc {
TLS_GD32,
+ TLS_GD32_FDPIC,
TLS_LDM32,
+ TLS_LDM32_FDPIC,
TLS_LDO32,
TLS_IE32,
+ TLS_IE32_FDPIC,
TLS_LE32,
TLS_DESCSEQ /* GNU scheme */
};
@@ -8760,20 +8763,34 @@ arm_call_tls_get_addr (rtx x, rtx reg, rtx *valuep, int
reloc)
gcc_assert (reloc != TLS_DESCSEQ);
start_sequence ();
- labelno = GEN_INT (pic_labelno++);
- label = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, labelno), UNSPEC_PIC_LABEL);
- label = gen_rtx_CONST (VOIDmode, label);
+ if (TARGET_FDPIC)
+{
+ sum = gen_rtx_UNSPEC (Pmode,
+ gen_rtvec (2, x, GEN_INT (reloc)),
+ UNSPEC_TLS);
+}
+ else
+{
+ labelno = GEN_INT (pic_labelno++);
+ label = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, labelno), UNSPEC_PIC_LABEL);
+ label = gen_rtx_CONST (VOIDmode, label);
- sum = gen_rtx_UNSPEC (Pmode,
- gen_rtvec (4, x, GEN_INT (reloc), label,
- GEN_INT (TARGET_ARM ? 8 : 4)),
- UNSPEC_TLS);
+ sum = gen_rtx_UNSPEC (Pmode,
+ gen_rtvec (4, x, GEN_INT (reloc), label,
+ GEN_INT (TARGET_ARM ? 8 : 4)),
+ UNSPEC_TLS);
+}
reg = load_tls_operand (sum, reg);
- if (TARGET_ARM)
-emit_insn (gen_pic_add_dot_plus_eight (reg, reg, labelno));
+ if (TARGET_FDPIC)
+{
+ emit_insn (gen_addsi3 (reg, reg, gen_rtx_REG (Pmode, FDPIC_REGNUM)));
+}
else
-emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
+if (TARGET_ARM)
+ emit_insn (gen_pic_add_dot_plus_eight (reg, reg, labelno));
+else
+ emit_insn (gen_pic_add_dot_plus_four (reg, reg, labelno));
*valuep = emit_library_call_value (get_tls_get_addr (), NULL_RTX,
LCT_PURE, /* LCT_CONST? */
@@ -8808,6 +8825,7 @@ arm_tls_descseq_addr (rtx x, rtx reg)
return reg;
}
+
rtx
legitimize_tls_address (rtx x, rtx reg)
{
@@ -8820,6 +8838,9 @@ legitimize_tls_address (rtx x, rtx reg)
case TLS_MODEL_GLOBAL_DYNAMIC:
if (TARGET_GNU2_TLS)
{
+ if (TARGET_FDPIC)
+ gcc_unreachable();
+
reg = arm_tls_descseq_addr (x, reg);
tp = arm_load_tp (NULL_RTX);
@@ -8829,7 +8850,10 @@ legitimize_tls_address (rtx x, rtx reg)
else
{
/* Original scheme */
- insns = arm_call_tls_get_addr (x, reg, , TLS_GD32);
+ if (TARGET_FDPIC)
+ insns = arm_call_tls_get_addr (x, reg, , TLS_GD32_FDPIC);
+ else
+ insns = arm_call_tls_get_addr (x, reg, , TLS_GD32);
dest = gen_reg_rtx (Pmode);
emit_libcall_block (insns, dest, ret, x);
}
@@ -8838,6 +8862,9 @@ legitimize_tls_address (rtx x, rtx reg)
case TLS_MODEL_LOCAL_DYNAMIC:
if (TARGET_GNU2_TLS)
{
+ if (TARGET_FDPIC)
+ gcc_unreachable();
+
reg = arm_tls_descseq_addr (x, reg);
tp = arm_load_tp (NULL_RTX);
@@ -8846,7 +8873,10 @@ legitimize_tls_address (rtx x, rtx reg)
}
else
{
- insns = arm_call_tls_get_addr (x, reg, , TLS_LDM32);
+ if (TARGET_FDPIC)
+ insns = arm_call_tls_get_addr (x, reg, , TLS_LDM32_FDPIC);
+ else
+ insns = arm_call_tls_get_addr (x, reg, , TLS_LDM32);
/* Attach a unique REG_EQUIV, to allow the RTL optimizers to
share the LDM result with other LD model accesses. */
@@ -8865,23 +8895,35 @@ legitimize_tls_address (rtx x, rtx reg)
return dest;
case TLS_MODEL_INITIAL_EXEC:
- labelno = GEN_INT (pic_labelno++);
- label = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, labelno), UNSPEC_PIC_LABEL);
- label = gen_rtx_CONST (VOIDmode, label);
- sum = gen_rtx_UNSPEC (Pmode,
- gen_rtvec (4, x, GEN_INT (TLS_IE32), label,
- GEN_INT (TARGET_ARM ? 8 : 4)),
- UNSPEC_TLS);
- reg = load_tls_operand (sum, reg);
-
- if (TARGET_ARM)
- emit_insn (gen_tls_load_dot_plus_eight (reg, reg, labelno));
- else if (TARGET_THUMB2)
- emit_insn (gen_tls_load_dot_plus_four (reg, NULL, reg, labelno));
+ if
[ARM/FDPIC v5 12/21] [ARM] FDPIC: Restore r9 after we call __aeabi_read_tp
We call __aeabi_read_tp() to get the thread pointer. Since this is a
function call, we have to restore the FDPIC register afterwards.
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (arm_load_tp): Add FDPIC support.
* config/arm/arm.md (load_tp_soft_fdpic): New pattern.
(load_tp_soft): Disable in FDPIC mode.
Change-Id: I1f6dfaee6260ecb453270f4971b3c5124317a186
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 5fc7a20..26f29c7 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -8732,7 +8732,25 @@ arm_load_tp (rtx target)
rtx tmp;
- emit_insn (gen_load_tp_soft ());
+ if (TARGET_FDPIC)
+ {
+ rtx par = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (3));
+ rtx fdpic_reg = gen_rtx_REG (Pmode, FDPIC_REGNUM);
+ rtx initial_fdpic_reg = get_hard_reg_initial_val (Pmode,
FDPIC_REGNUM);
+
+ emit_insn (gen_load_tp_soft_fdpic ());
+
+ /* Restore r9. */
+ XVECEXP (par, 0, 0) = gen_rtx_UNSPEC (VOIDmode,
+ gen_rtvec (2, fdpic_reg,
+ initial_fdpic_reg),
+ UNSPEC_PIC_RESTORE);
+ XVECEXP (par, 0, 1) = gen_rtx_USE (VOIDmode, initial_fdpic_reg);
+ XVECEXP (par, 0, 2) = gen_rtx_CLOBBER (VOIDmode, fdpic_reg);
+ emit_insn (par);
+ }
+ else
+ emit_insn (gen_load_tp_soft ());
tmp = gen_rtx_REG (SImode, R0_REGNUM);
emit_move_insn (target, tmp);
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 9036255..0edcb1d 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -11759,12 +11759,25 @@
)
;; Doesn't clobber R1-R3. Must use r0 for the first operand.
+(define_insn "load_tp_soft_fdpic"
+ [(set (reg:SI 0) (unspec:SI [(const_int 0)] UNSPEC_TLS))
+ (clobber (reg:SI 9))
+ (clobber (reg:SI LR_REGNUM))
+ (clobber (reg:SI IP_REGNUM))
+ (clobber (reg:CC CC_REGNUM))]
+ "TARGET_SOFT_TP && TARGET_FDPIC"
+ "bl\\t__aeabi_read_tp\\t@ load_tp_soft"
+ [(set_attr "conds" "clob")
+ (set_attr "type" "branch")]
+)
+
+;; Doesn't clobber R1-R3. Must use r0 for the first operand.
(define_insn "load_tp_soft"
[(set (reg:SI 0) (unspec:SI [(const_int 0)] UNSPEC_TLS))
(clobber (reg:SI LR_REGNUM))
(clobber (reg:SI IP_REGNUM))
(clobber (reg:CC CC_REGNUM))]
- "TARGET_SOFT_TP"
+ "TARGET_SOFT_TP && !TARGET_FDPIC"
"bl\\t__aeabi_read_tp\\t@ load_tp_soft"
[(set_attr "conds" "clob")
(set_attr "type" "branch")]
--
2.6.3
[ARM/FDPIC v5 09/21] [ARM] FDPIC: Add support for taking address of nested function
In FDPIC mode, the trampoline generated to support pointers to nested
functions looks like:
.wordtrampoline address
.wordtrampoline GOT address
ldr r12, [pc, #8]
ldr r9, [pc, #8]
ldr pc, [pc, #8]
.wordstatic chain value
.wordGOT address
.wordfunction's address
because in FDPIC function pointers are actually pointers to function
descriptors, we have to actually generate a function descriptor for
the trampoline.
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (arm_asm_trampoline_template): Add FDPIC
support.
(arm_trampoline_init): Likewise.
(arm_trampoline_init): Likewise.
* config/arm/arm.h (TRAMPOLINE_SIZE): Likewise.
Change-Id: Idc4d5f629ae4f8d79bdf9623517481d524a0c144
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 40e3f3b..99d13bf 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3976,13 +3976,50 @@ arm_warn_func_return (tree decl)
.wordstatic chain value
.wordfunction's address
XXX FIXME: When the trampoline returns, r8 will be clobbered. */
+/* In FDPIC mode, the trampoline looks like:
+ .wordtrampoline address
+ .wordtrampoline GOT address
+ ldr r12, [pc, #8] ; #4 for Thumb2
+ ldr r9, [pc, #8] ; #4 for Thumb2
+ ldr pc, [pc, #8] ; #4 for Thumb2
+ .wordstatic chain value
+ .wordGOT address
+ .wordfunction's address
+*/
static void
arm_asm_trampoline_template (FILE *f)
{
fprintf (f, "\t.syntax unified\n");
- if (TARGET_ARM)
+ if (TARGET_FDPIC)
+{
+ /* The first two words are a function descriptor pointing to the
+trampoline code just below. */
+ if (TARGET_ARM)
+ fprintf (f, "\t.arm\n");
+ else if (TARGET_THUMB2)
+ fprintf (f, "\t.thumb\n");
+ else
+ /* Only ARM and Thumb-2 are supported. */
+ gcc_unreachable ();
+
+ assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
+ assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
+ /* Trampoline code which sets the static chain register but also
+PIC register before jumping into real code. */
+ asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
+ STATIC_CHAIN_REGNUM, PC_REGNUM,
+ TARGET_THUMB2 ? 8 : 4);
+ asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
+ PIC_OFFSET_TABLE_REGNUM, PC_REGNUM,
+ TARGET_THUMB2 ? 8 : 4);
+ asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
+ PC_REGNUM, PC_REGNUM,
+ TARGET_THUMB2 ? 8 : 4);
+ assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
+}
+ else if (TARGET_ARM)
{
fprintf (f, "\t.arm\n");
asm_fprintf (f, "\tldr\t%r, [%r, #0]\n", STATIC_CHAIN_REGNUM, PC_REGNUM);
@@ -4023,12 +4060,40 @@ arm_trampoline_init (rtx m_tramp, tree fndecl, rtx
chain_value)
emit_block_move (m_tramp, assemble_trampoline_template (),
GEN_INT (TRAMPOLINE_SIZE), BLOCK_OP_NORMAL);
- mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 8 : 12);
- emit_move_insn (mem, chain_value);
+ if (TARGET_FDPIC)
+{
+ rtx funcdesc = XEXP (DECL_RTL (fndecl), 0);
+ rtx fnaddr = gen_rtx_MEM (Pmode, funcdesc);
+ rtx gotaddr = gen_rtx_MEM (Pmode, plus_constant (Pmode, funcdesc, 4));
+ /* The function start address is at offset 8, but in Thumb mode
+we want bit 0 set to 1 to indicate Thumb-ness, hence 9
+below. */
+ rtx trampoline_code_start
+ = plus_constant (Pmode, XEXP (m_tramp, 0), TARGET_THUMB2 ? 9 : 8);
+
+ /* Write initial funcdesc which points to the trampoline. */
+ mem = adjust_address (m_tramp, SImode, 0);
+ emit_move_insn (mem, trampoline_code_start);
+ mem = adjust_address (m_tramp, SImode, 4);
+ emit_move_insn (mem, gen_rtx_REG (Pmode, PIC_OFFSET_TABLE_REGNUM));
+ /* Setup static chain. */
+ mem = adjust_address (m_tramp, SImode, 20);
+ emit_move_insn (mem, chain_value);
+ /* GOT + real function entry point. */
+ mem = adjust_address (m_tramp, SImode, 24);
+ emit_move_insn (mem, gotaddr);
+ mem = adjust_address (m_tramp, SImode, 28);
+ emit_move_insn (mem, fnaddr);
+}
+ else
+{
+ mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 8 : 12);
+ emit_move_insn (mem, chain_value);
- mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 12 : 16);
- fnaddr = XEXP (DECL_RTL (fndecl), 0);
- emit_move_insn (mem, fnaddr);
+ mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 12 : 16);
+ fnaddr = XEXP (DECL_RTL (fndecl), 0);
+ emit_move_insn (mem, fnaddr);
+}
a_tramp = XEXP (m_tramp, 0);
emit_library_call
[ARM/FDPIC v5 08/21] [ARM] FDPIC: Enforce local/global binding for function descriptors
Use local binding rules to decide whether we can use GOTOFFFUNCDESC to
compute the function address.
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (arm_local_funcdesc_p): New function.
(legitimize_pic_address): Enforce binding rules on function
pointers in FDPIC mode.
(arm_assemble_integer): Likewise.
Change-Id: I3fa0b63bc0f672903f405aa72cc46052de1c0feb
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index dbd1671..40e3f3b 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3790,6 +3790,42 @@ arm_options_perform_arch_sanity_checks (void)
}
}
+/* Test whether a local function descriptor is canonical, i.e.,
+ whether we can use GOTOFFFUNCDESC to compute the address of the
+ function. */
+static bool
+arm_fdpic_local_funcdesc_p (rtx fnx)
+{
+ tree fn;
+ enum symbol_visibility vis;
+ bool ret;
+
+ if (!TARGET_FDPIC)
+return TRUE;
+
+ if (! SYMBOL_REF_LOCAL_P (fnx))
+return FALSE;
+
+ fn = SYMBOL_REF_DECL (fnx);
+
+ if (! fn)
+return FALSE;
+
+ vis = DECL_VISIBILITY (fn);
+
+ if (vis == VISIBILITY_PROTECTED)
+/* Private function descriptors for protected functions are not
+ canonical. Temporarily change the visibility to global so that
+ we can ensure uniqueness of funcdesc pointers. */
+DECL_VISIBILITY (fn) = VISIBILITY_DEFAULT;
+
+ ret = default_binds_local_p_1 (fn, flag_pic);
+
+ DECL_VISIBILITY (fn) = vis;
+
+ return ret;
+}
+
static void
arm_add_gc_roots (void)
{
@@ -7563,7 +7599,9 @@ legitimize_pic_address (rtx orig, machine_mode mode, rtx
reg, rtx pic_reg,
|| (GET_CODE (orig) == SYMBOL_REF
&& SYMBOL_REF_LOCAL_P (orig)
&& (SYMBOL_REF_DECL (orig)
- ? !DECL_WEAK (SYMBOL_REF_DECL (orig)) : 1)))
+ ? !DECL_WEAK (SYMBOL_REF_DECL (orig)) : 1)
+ && (!SYMBOL_REF_FUNCTION_P (orig)
+ || arm_fdpic_local_funcdesc_p (orig
&& NEED_GOT_RELOC
&& arm_pic_data_is_text_relative)
insn = arm_pic_static_addr (orig, reg);
@@ -23231,7 +23269,9 @@ arm_assemble_integer (rtx x, unsigned int size, int
aligned_p)
|| (GET_CODE (x) == SYMBOL_REF
&& (!SYMBOL_REF_LOCAL_P (x)
|| (SYMBOL_REF_DECL (x)
- ? DECL_WEAK (SYMBOL_REF_DECL (x)) : 0
+ ? DECL_WEAK (SYMBOL_REF_DECL (x)) : 0)
+ || (SYMBOL_REF_FUNCTION_P (x)
+ && !arm_fdpic_local_funcdesc_p (x)
{
if (TARGET_FDPIC && SYMBOL_REF_FUNCTION_P (x))
fputs ("(GOTFUNCDESC)", asm_out_file);
--
2.6.3
[ARM/FDPIC v5 07/21] [ARM] FDPIC: Avoid saving/restoring r9 on stack since it is read-only
2019-XX-XX Christophe Lyon Mickaël Guêné gcc/ * config/arm/arm.h (PIC_REGISTER_MAY_NEED_SAVING): New helper. * config/arm/arm.c (arm_compute_save_reg0_reg12_mask): Handle FDPIC. Change-Id: I0f3b2023ab2a2a0433dfe081dac6bbb194b7a76c diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index d9397b5..dbd1671 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -19651,9 +19651,7 @@ arm_compute_save_reg0_reg12_mask (void) save_reg_mask |= (1 << reg); /* Also save the pic base register if necessary. */ - if (flag_pic - && !TARGET_SINGLE_PIC_BASE - && arm_pic_register != INVALID_REGNUM + if (PIC_REGISTER_MAY_NEED_SAVING && crtl->uses_pic_offset_table) save_reg_mask |= 1 << PIC_OFFSET_TABLE_REGNUM; } @@ -19685,9 +19683,7 @@ arm_compute_save_reg0_reg12_mask (void) /* If we aren't loading the PIC register, don't stack it even though it may be live. */ - if (flag_pic - && !TARGET_SINGLE_PIC_BASE - && arm_pic_register != INVALID_REGNUM + if (PIC_REGISTER_MAY_NEED_SAVING && (df_regs_ever_live_p (PIC_OFFSET_TABLE_REGNUM) || crtl->uses_pic_offset_table)) save_reg_mask |= 1 << PIC_OFFSET_TABLE_REGNUM; diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index 7b50ef5..45c0e2b 100644 --- a/gcc/config/arm/arm.h +++ b/gcc/config/arm/arm.h @@ -1967,6 +1967,13 @@ extern unsigned arm_pic_register; || label_mentioned_p (get_pool_constant (X) \ || tls_mentioned_p (X)) +/* We may want to save the PIC register if it is a dedicated one. */ +#define PIC_REGISTER_MAY_NEED_SAVING \ + (flag_pic\ + && !TARGET_SINGLE_PIC_BASE \ + && !TARGET_FDPIC\ + && arm_pic_register != INVALID_REGNUM) + /* We need to know when we are making a constant pool; this determines whether data needs to be in the GOT or can be referenced via a GOT offset. */ -- 2.6.3
[ARM/FDPIC v5 06/21] [ARM] FDPIC: Add support for c++ exceptions
The main difference with existing support is that function addresses
are function descriptor addresses instead. This means that all code
dealing with function pointers now has to cope with function
descriptors instead.
For the same reason, Linux kernel helpers can no longer be called by
dereferencing their address, so we implement wrappers that directly
call the kernel helpers.
When restoring a function address, we also have to restore the FDPIC
register value (r9).
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* ginclude/unwind-arm-common.h (unwinder_cache): Add reserved5
field.
(FDPIC_REGNUM): New define.
libgcc/
* config/arm/linux-atomic.c (__kernel_cmpxchg): Add FDPIC support.
(__kernel_dmb): Likewise.
(__fdpic_cmpxchg): New function.
(__fdpic_dmb): New function.
* config/arm/unwind-arm.h (FDPIC_REGNUM): New define.
(gnu_Unwind_Find_got): New function.
(_Unwind_decode_typeinfo_ptr): Add FDPIC support.
* unwind-arm-common.inc (UCB_PR_GOT): New.
(funcdesc_t): New struct.
(get_eit_entry): Add FDPIC support.
(unwind_phase2): Likewise.
(unwind_phase2_forced): Likewise.
(__gnu_Unwind_RaiseException): Likewise.
(__gnu_Unwind_Resume): Likewise.
(__gnu_Unwind_Backtrace): Likewise.
* unwind-pe.h (read_encoded_value_with_base): Likewise.
libstdc++/
* libsupc++/eh_personality.cc (get_ttype_entry): Add FDPIC
support.
Change-Id: I64b81cfaf390a05f2fd121f44ba1912cb4b47cae
diff --git a/gcc/ginclude/unwind-arm-common.h b/gcc/ginclude/unwind-arm-common.h
index 6df783e..d4eb03e 100644
--- a/gcc/ginclude/unwind-arm-common.h
+++ b/gcc/ginclude/unwind-arm-common.h
@@ -91,7 +91,7 @@ extern "C" {
_uw reserved2; /* Personality routine address */
_uw reserved3; /* Saved callsite address */
_uw reserved4; /* Forced unwind stop arg */
- _uw reserved5;
+ _uw reserved5; /* Personality routine GOT value in FDPIC mode. */
}
unwinder_cache;
/* Propagation barrier cache (valid after phase 1): */
diff --git a/libgcc/config/arm/linux-atomic.c b/libgcc/config/arm/linux-atomic.c
index 06a6d46..565f829 100644
--- a/libgcc/config/arm/linux-atomic.c
+++ b/libgcc/config/arm/linux-atomic.c
@@ -25,11 +25,62 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
/* Kernel helper for compare-and-exchange. */
typedef int (__kernel_cmpxchg_t) (int oldval, int newval, int *ptr);
-#define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0x0fc0)
+
+#define STR(X) #X
+#define XSTR(X) STR(X)
+
+#define KERNEL_CMPXCHG 0x0fc0
+
+#if __FDPIC__
+/* Non-FDPIC ABIs call __kernel_cmpxchg directly by dereferencing its
+ address, but under FDPIC we would generate a broken call
+ sequence. That's why we have to implement __kernel_cmpxchg and
+ __kernel_dmb here: this way, the FDPIC call sequence works. */
+#define __kernel_cmpxchg __fdpic_cmpxchg
+#else
+#define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) KERNEL_CMPXCHG)
+#endif
/* Kernel helper for memory barrier. */
typedef void (__kernel_dmb_t) (void);
-#define __kernel_dmb (*(__kernel_dmb_t *) 0x0fa0)
+
+#define KERNEL_DMB 0x0fa0
+
+#if __FDPIC__
+#define __kernel_dmb __fdpic_dmb
+#else
+#define __kernel_dmb (*(__kernel_dmb_t *) KERNEL_DMB)
+#endif
+
+#if __FDPIC__
+static int __fdpic_cmpxchg (int oldval, int newval, int *ptr)
+{
+ int result;
+
+ asm volatile (
+ "ldrip, 1f\n\t"
+ "bx ip\n\t"
+ "1:\n\t"
+ ".word " XSTR(KERNEL_CMPXCHG) "\n\t"
+ : "=r" (result)
+ : "r" (oldval) , "r" (newval), "r" (ptr)
+ : "r3", "memory");
+ /* The result is actually returned by the kernel helper, we need
+ this to avoid a warning. */
+ return result;
+}
+
+static void __fdpic_dmb (void)
+{
+ asm volatile (
+ "ldrip, 1f\n\t"
+ "bx ip\n\t"
+ "1:\n\t"
+ ".word " XSTR(KERNEL_DMB) "\n\t"
+ );
+}
+
+#endif
/* Note: we implement byte, short and int versions of atomic operations using
the above kernel helpers; see linux-atomic-64bit.c for "long long" (64-bit)
diff --git a/libgcc/config/arm/unwind-arm.h b/libgcc/config/arm/unwind-arm.h
index 43c5379..2bf320a 100644
--- a/libgcc/config/arm/unwind-arm.h
+++ b/libgcc/config/arm/unwind-arm.h
@@ -33,9 +33,33 @@
/* Use IP as a scratch register within the personality routine. */
#define UNWIND_POINTER_REG 12
+#define FDPIC_REGNUM 9
+
+#define STR(x) #x
+#define XSTR(x) STR(x)
+
#ifdef __cplusplus
extern "C" {
#endif
+_Unwind_Ptr __attribute__((weak)) __gnu_Unwind_Find_got (_Unwind_Ptr);
+
+static inline _Unwind_Ptr gnu_Unwind_Find_got (_Unwind_Ptr ptr)
+{
+_Unwind_Ptr res;
+
+if (__gnu_Unwind_Find_got)
+ res = __gnu_Unwind_Find_got (ptr);
+else
+
[ARM/FDPIC v5 05/21] [ARM] FDPIC: Fix __do_global_dtors_aux and frame_dummy generation
In FDPIC, we need to make sure __do_global_dtors_aux and frame_dummy
are referenced by their address, not by pointers to the function
descriptors.
2019-XX-XX Christophe Lyon
Mickaël Guêné
* libgcc/crtstuff.c: Add support for FDPIC.
Change-Id: I0bc4b1232fbf3c69068fb23a1b9cafc895d141b1
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 4927a9f..159b461 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -429,9 +429,18 @@ __do_global_dtors_aux (void)
#ifdef FINI_SECTION_ASM_OP
CRT_CALL_STATIC_FUNCTION (FINI_SECTION_ASM_OP, __do_global_dtors_aux)
#elif defined (FINI_ARRAY_SECTION_ASM_OP)
+#if defined(__FDPIC__)
+__asm__(
+" .section .fini_array\n"
+" .align 2\n"
+" .word __do_global_dtors_aux\n"
+);
+asm (TEXT_SECTION_ASM_OP);
+#else /* defined(__FDPIC__) */
static func_ptr __do_global_dtors_aux_fini_array_entry[]
__attribute__ ((__used__, section(".fini_array"), aligned(sizeof(func_ptr
= { __do_global_dtors_aux };
+#endif /* defined(__FDPIC__) */
#else /* !FINI_SECTION_ASM_OP && !FINI_ARRAY_SECTION_ASM_OP */
static void __attribute__((used))
__do_global_dtors_aux_1 (void)
@@ -473,9 +482,18 @@ frame_dummy (void)
#ifdef __LIBGCC_INIT_SECTION_ASM_OP__
CRT_CALL_STATIC_FUNCTION (__LIBGCC_INIT_SECTION_ASM_OP__, frame_dummy)
#else /* defined(__LIBGCC_INIT_SECTION_ASM_OP__) */
+#if defined(__FDPIC__)
+__asm__(
+" .section .init_array\n"
+" .align 2\n"
+" .word frame_dummy\n"
+);
+asm (TEXT_SECTION_ASM_OP);
+#else /* defined(__FDPIC__) */
static func_ptr __frame_dummy_init_array_entry[]
__attribute__ ((__used__, section(".init_array"), aligned(sizeof(func_ptr
= { frame_dummy };
+#endif /* defined(__FDPIC__) */
#endif /* !defined(__LIBGCC_INIT_SECTION_ASM_OP__) */
#endif /* USE_EH_FRAME_REGISTRY || USE_TM_CLONE_REGISTRY */
--
2.6.3
[ARM/FDPIC v5 03/21] [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided
In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
-fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
for executables rather than shared libraries by default.
We also make sure to use the --fdpic assembler option, and select the
appropriate linker emulation.
At link time, we also default to -pie, unless we are generating a
shared library or a relocatable file (-r). Note that even for static
link, we must specify the dynamic linker because the executable still
has to relocate itself at startup.
We also force 'now' binding since lazy binding is not supported.
We should also apply the same behavior for -Wl,-Ur as for -r, but I
couldn't find how to describe that in the specs fragment.
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config.gcc: Handle arm*-*-uclinuxfdpiceabi.
* config/arm/bpabi.h (TARGET_FDPIC_ASM_SPEC): New.
(SUBTARGET_EXTRA_ASM_SPEC): Use TARGET_FDPIC_ASM_SPEC.
* config/arm/linux-eabi.h (FDPIC_CC1_SPEC): New.
(CC1_SPEC): Use FDPIC_CC1_SPEC.
* config/arm/uclinuxfdpiceabi.h: New file.
libsanitizer/
* configure.tgt (arm*-*-uclinuxfdpiceabi): Sanitizers are
unsupported in this configuration.
Change-Id: If369e0a10bb916fd72e38f71498d3c640fa85c4c
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 67780fb..495cbc2 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1177,6 +1177,11 @@ arm*-*-linux-* | arm*-*-uclinuxfdpiceabi)
# ARM GNU/Linux with ELF
esac
tmake_file="${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi
arm/t-linux-eabi"
tm_file="$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h arm/arm.h"
+ case $target in
+ arm*-*-uclinuxfdpiceabi)
+ tm_file="$tm_file arm/uclinuxfdpiceabi.h"
+ ;;
+ esac
# Generation of floating-point instructions requires at least ARMv5te.
if [ "$with_float" = "hard" -o "$with_float" = "softfp" ] ; then
target_cpu_cname="arm10e"
diff --git a/gcc/config/arm/bpabi.h b/gcc/config/arm/bpabi.h
index e1bacf4..6c25a1a 100644
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -55,6 +55,8 @@
#define TARGET_FIX_V4BX_SPEC " %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*"\
"|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}"
+#define TARGET_FDPIC_ASM_SPEC ""
+
#define BE8_LINK_SPEC \
"%{!r:%{!mbe32:%:be8_linkopt(%{mlittle-endian:little}" \
" %{mbig-endian:big}" \
@@ -64,7 +66,7 @@
/* Tell the assembler to build BPABI binaries. */
#undef SUBTARGET_EXTRA_ASM_SPEC
#define SUBTARGET_EXTRA_ASM_SPEC \
- "%{mabi=apcs-gnu|mabi=atpcs:-meabi=gnu;:-meabi=5}" TARGET_FIX_V4BX_SPEC
+ "%{mabi=apcs-gnu|mabi=atpcs:-meabi=gnu;:-meabi=5}" TARGET_FIX_V4BX_SPEC
TARGET_FDPIC_ASM_SPEC
#ifndef SUBTARGET_EXTRA_LINK_SPEC
#define SUBTARGET_EXTRA_LINK_SPEC ""
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 66ec0ea..67edb42 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -101,11 +101,14 @@
#undef ASAN_CC1_SPEC
#define ASAN_CC1_SPEC "%{%:sanitize(address):-funwind-tables}"
+#define FDPIC_CC1_SPEC ""
+
#undef CC1_SPEC
#define CC1_SPEC \
- LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC " " ASAN_CC1_SPEC, \
+ LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC " " ASAN_CC1_SPEC " " \
+ FDPIC_CC1_SPEC, \
GNU_USER_TARGET_CC1_SPEC " " ASAN_CC1_SPEC " " \
- ANDROID_CC1_SPEC)
+ ANDROID_CC1_SPEC "" FDPIC_CC1_SPEC)
#define CC1PLUS_SPEC \
LINUX_OR_ANDROID_CC ("", ANDROID_CC1PLUS_SPEC)
diff --git a/gcc/config/arm/uclinuxfdpiceabi.h
b/gcc/config/arm/uclinuxfdpiceabi.h
new file mode 100644
index 000..43a17de
--- /dev/null
+++ b/gcc/config/arm/uclinuxfdpiceabi.h
@@ -0,0 +1,53 @@
+/* Configuration file for ARM GNU/Linux FDPIC EABI targets.
+ Copyright (C) 2018 Free Software Foundation, Inc.
+ Contributed by STMicroelectronics.
+
+ This file is part of GCC.
+
+ GCC 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.
+
+ GCC 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 GCC; see the file COPYING3. If not see
+
[ARM/FDPIC v5 04/21] [ARM] FDPIC: Add support for FDPIC for arm architecture
The FDPIC register is hard-coded to r9, as defined in the ABI.
We have to disable tailcall optimizations if we don't know if the
target function is in the same module. If not, we have to set r9 to
the value associated with the target module.
When generating a symbol address, we have to take into account whether
it is a pointer to data or to a function, because different
relocations are needed.
2019-XX-XX Christophe Lyon
Mickaël Guêné
* config/arm/arm-c.c (__FDPIC__): Define new pre-processor macro
in FDPIC mode.
* config/arm/arm-protos.h (arm_load_function_descriptor): Declare
new function.
* config/arm/arm.c (arm_option_override): Define pic register to
FDPIC_REGNUM.
(arm_function_ok_for_sibcall): Disable sibcall optimization if we
have no decl or go through PLT.
(arm_load_pic_register): Handle TARGET_FDPIC.
(arm_is_segment_info_known): New function.
(arm_pic_static_addr): Add support for FDPIC.
(arm_load_function_descriptor): New function.
(arm_assemble_integer): Add support for FDPIC.
* config/arm/arm.h (PIC_OFFSET_TABLE_REG_CALL_CLOBBERED):
Define. (FDPIC_REGNUM): New define.
* config/arm/arm.md (call): Add support for FDPIC.
(call_value): Likewise.
(*restore_pic_register_after_call): New pattern.
(untyped_call): Disable if FDPIC.
(untyped_return): Likewise.
* config/arm/unspecs.md (UNSPEC_PIC_RESTORE): New.
Change-Id: I8fb1a6b85ace672184013568c5d28fbda2f7fda4
diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
index 6e256ee..34695fa 100644
--- a/gcc/config/arm/arm-c.c
+++ b/gcc/config/arm/arm-c.c
@@ -203,6 +203,8 @@ arm_cpu_builtins (struct cpp_reader* pfile)
builtin_define ("__ARM_EABI__");
}
+ def_or_undef_macro (pfile, "__FDPIC__", TARGET_FDPIC);
+
def_or_undef_macro (pfile, "__ARM_ARCH_EXT_IDIV__", TARGET_IDIV);
def_or_undef_macro (pfile, "__ARM_FEATURE_IDIV", TARGET_IDIV);
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 485bc68..272968a 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -139,6 +139,7 @@ extern int arm_max_const_double_inline_cost (void);
extern int arm_const_double_inline_cost (rtx);
extern bool arm_const_double_by_parts (rtx);
extern bool arm_const_double_by_immediates (rtx);
+extern rtx arm_load_function_descriptor (rtx funcdesc);
extern void arm_emit_call_insn (rtx, rtx, bool);
bool detect_cmse_nonsecure_call (tree);
extern const char *output_call (rtx *);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 45abcd8..d9397b5 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3485,6 +3485,15 @@ arm_option_override (void)
if (flag_pic && TARGET_VXWORKS_RTP)
arm_pic_register = 9;
+ /* If in FDPIC mode then force arm_pic_register to be r9. */
+ if (TARGET_FDPIC)
+{
+ arm_pic_register = FDPIC_REGNUM;
+ if (! TARGET_ARM && ! TARGET_THUMB2)
+ sorry ("FDPIC mode is supported on architecture versions that "
+ "support ARM or Thumb-2 only.");
+}
+
if (arm_pic_register_string != NULL)
{
int pic_register = decode_reg_name (arm_pic_register_string);
@@ -7295,6 +7304,21 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
if (cfun->machine->sibcall_blocked)
return false;
+ if (TARGET_FDPIC)
+{
+ /* In FDPIC, never tailcall something for which we have no decl:
+the target function could be in a different module, requiring
+a different FDPIC register value. */
+ if (decl == NULL)
+ return false;
+
+ /* Don't tailcall if we go through the PLT since the FDPIC
+register is then corrupted and we don't restore it after
+static function calls. */
+ if (!targetm.binds_local_p (decl))
+ return false;
+}
+
/* Never tailcall something if we are generating code for Thumb-1. */
if (TARGET_THUMB1)
return false;
@@ -7711,7 +7735,9 @@ arm_load_pic_register (unsigned long saved_regs
ATTRIBUTE_UNUSED, rtx pic_reg)
{
rtx l1, labelno, pic_tmp, pic_rtx;
- if (crtl->uses_pic_offset_table == 0 || TARGET_SINGLE_PIC_BASE)
+ if (crtl->uses_pic_offset_table == 0
+ || TARGET_SINGLE_PIC_BASE
+ || TARGET_FDPIC)
return;
gcc_assert (flag_pic);
@@ -7780,28 +7806,142 @@ arm_load_pic_register (unsigned long saved_regs
ATTRIBUTE_UNUSED, rtx pic_reg)
emit_use (pic_reg);
}
+/* Try to determine whether an object, referenced via ORIG, will be
+ placed in the text or data segment. This is used in FDPIC mode, to
+ decide which relocations to use when accessing ORIG. IS_READONLY
+ is set to true if ORIG is a read-only location, false otherwise.
+ Return true if we could determine the location of ORIG, false
+ otherwise. IS_READONLY is valid only when we return true. */
+static bool
+arm_is_segment_info_known (rtx orig, bool
[ARM/FDPIC v5 02/21] [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts
The new arm-uclinuxfdpiceabi target behaves pretty much like
arm-linux-gnueabi. In order the enable the same set of features, we
have to update several configure scripts that generally match targets
like *-*-linux*: in most places, we add *-uclinux* where there is
already *-linux*, or uclinux* when there is already linux*.
In gcc/config.gcc and libgcc/config.host we use *-*-uclinuxfdpiceabi
because there is already a different behaviour for *-*uclinux* target.
In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared
libraries support is required, as uclinux does not guarantee that.
2019-XX-XX Christophe Lyon
config/
* futex.m4: Handle *-uclinux*.
* tls.m4 (GCC_CHECK_TLS): Likewise.
gcc/
* config.gcc: Handle *-*-uclinuxfdpiceabi.
libatomic/
* configure.tgt: Handle arm*-*-uclinux*.
* configure: Regenerate.
libgcc/
* config.host: Handle *-*-uclinuxfdpiceabi.
libitm/
* configure.tgt: Handle *-*-uclinux*.
* configure: Regenerate.
libstdc++-v3/
* acinclude.m4: Handle uclinux*.
* configure: Regenerate.
* configure.host: Handle uclinux*
* libtool.m4: Handle uclinux*.
Change-Id: I6a1fdcd9847d8a82179a214612a3474c1f492916
diff --git a/config/futex.m4 b/config/futex.m4
index e95144d..4dffe15 100644
--- a/config/futex.m4
+++ b/config/futex.m4
@@ -9,7 +9,7 @@ AC_DEFUN([GCC_LINUX_FUTEX],[dnl
GCC_ENABLE(linux-futex,default, ,[use the Linux futex system call],
permit yes|no|default)
case "$target" in
- *-linux*)
+ *-linux* | *-uclinux*)
case "$enable_linux_futex" in
default)
# If headers don't have gettid/futex syscalls definition, then
diff --git a/config/tls.m4 b/config/tls.m4
index 1a5fc59..a487aa4 100644
--- a/config/tls.m4
+++ b/config/tls.m4
@@ -76,7 +76,7 @@ AC_DEFUN([GCC_CHECK_TLS], [
dnl Shared library options may depend on the host; this check
dnl is only known to be needed for GNU/Linux.
case $host in
- *-*-linux*)
+ *-*-linux* | -*-uclinux*)
LDFLAGS="-shared -Wl,--no-undefined $LDFLAGS"
;;
esac
diff --git a/gcc/config.gcc b/gcc/config.gcc
index c7a464c..67780fb 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -776,7 +776,7 @@ case ${target} in
*-*-fuchsia*)
native_system_header_dir=/include
;;
-*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* |
*-*-kopensolaris*-gnu)
+*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* |
*-*-kopensolaris*-gnu | *-*-uclinuxfdpiceabi)
extra_options="$extra_options gnu-user.opt"
gas=yes
gnu_ld=yes
@@ -785,7 +785,7 @@ case ${target} in
esac
tmake_file="t-slibgcc"
case $target in
-*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
+*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu |
*-*-uclinuxfdpiceabi)
:;;
*-*-gnu*)
native_system_header_dir=/include
@@ -805,7 +805,7 @@ case ${target} in
*-*-*android*)
tm_defines="$tm_defines DEFAULT_LIBC=LIBC_BIONIC"
;;
-*-*-*uclibc*)
+*-*-*uclibc* | *-*-uclinuxfdpiceabi)
tm_defines="$tm_defines DEFAULT_LIBC=LIBC_UCLIBC"
;;
*-*-*musl*)
@@ -1167,7 +1167,7 @@ arm*-*-netbsdelf*)
tmake_file="${tmake_file} arm/t-arm"
target_cpu_cname="strongarm"
;;
-arm*-*-linux-*)# ARM GNU/Linux with ELF
+arm*-*-linux-* | arm*-*-uclinuxfdpiceabi) # ARM GNU/Linux
with ELF
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
extra_options="${extra_options} linux-android.opt"
case $target in
diff --git a/libatomic/configure b/libatomic/configure
index e7076a0..10b0287 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -6055,7 +6055,7 @@ irix5* | irix6* | nonstopux*)
;;
# This must be Linux ELF.
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinuxfdpiceabi)
lt_cv_deplibs_check_method=pass_all
;;
@@ -8540,7 +8540,7 @@ $as_echo_n "checking for $compiler option to produce
PIC... " >&6; }
lt_prog_compiler_static='-non_shared'
;;
-linux* | k*bsd*-gnu | kopensolaris*-gnu)
+linux* | k*bsd*-gnu | kopensolaris*-gnu | uclinux*)
case $cc_basename in
# old Intel for x86_64 which still supported -KPIC.
ecc*)
@@ -9135,7 +9135,7 @@ _LT_EOF
archive_expsym_cmds='sed "s,^,_," $export_symbols
>$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags ${wl}-h,$soname
${wl}--retain-symbols-file,$output_objdir/$soname.expsym
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
;;
-gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
+gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu |
[ARM/FDPIC v5 01/21] [ARM] FDPIC: Add -mfdpic option support
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.opt: Add -mfdpic option.
* doc/invoke.texi: Add documentation for -mfdpic.
Change-Id: I0eabd1d11c9406fd4a43c4333689ebebbfcc4fe8
diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt
index 9067d49..2ed3bd5 100644
--- a/gcc/config/arm/arm.opt
+++ b/gcc/config/arm/arm.opt
@@ -306,3 +306,7 @@ Cost to assume for a branch insn.
mgeneral-regs-only
Target Report RejectNegative Mask(GENERAL_REGS_ONLY) Save
Generate code which uses the core registers only (r0-r14).
+
+mfdpic
+Target Report Mask(FDPIC)
+Enable Function Descriptor PIC mode.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 29585cf..805d7cc 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -703,7 +703,8 @@ Objective-C and Objective-C++ Dialects}.
-mrestrict-it @gol
-mverbose-cost-dump @gol
-mpure-code @gol
--mcmse}
+-mcmse @gol
+-mfdpic}
@emph{AVR Options}
@gccoptlist{-mmcu=@var{mcu} -mabsdata -maccumulate-args @gol
@@ -17912,6 +17913,23 @@ MOVT instruction.
Generate secure code as per the "ARMv8-M Security Extensions: Requirements on
Development Tools Engineering Specification", which can be found on
@url{http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf}.
+
+@item -mfdpic
+@itemx -mno-fdpic
+@opindex mfdpic
+@opindex mno-fdpic
+Select the FDPIC ABI, which uses function descriptors to represent
+pointers to functions. When the compiler is configured for
+@code{arm-*-uclinuxfdpiceabi} targets, this option is on by default
+and implies @option{-fPIE} if none of the PIC/PIE-related options is
+provided. On other targets, it only enables the FDPIC-specific code
+generation features, and the user should explicitly provide the
+PIC/PIE-related options as needed.
+
+The opposite @option{-mno-fdpic} option is useful (and required) to
+build the Linux kernel using the same (@code{arm-*-uclinuxfdpiceabi})
+toolchain as the one used to build the userland programs.
+
@end table
@node AVR Options
--
2.6.3
[ARM/FDPIC v5 00/21] FDPIC ABI for ARM
Hello, This patch series implements the GCC contribution of the FDPIC ABI for ARM targets. This ABI enables to run Linux on ARM MMU-less cores and supports shared libraries to reduce the memory footprint. Without MMU, text and data segments relative distances are different from one process to another, hence the need for a dedicated FDPIC register holding the start address of the data segment. One of the side effects is that function pointers require two words to be represented: the address of the code, and the data segment start address. These two words are designated as "Function Descriptor", hence the "FD PIC" name. On ARM, the FDPIC register is r9 [1], and the target name is arm-uclinuxfdpiceabi. Note that arm-uclinux exists, but uses another ABI and the BFLAT file format; it does not support code sharing. The -mfdpic option is enabled by default, and -mno-fdpic should be used to build the Linux kernel. This work was developed some time ago by STMicroelectronics, and was presented during Linaro Connect SFO15 (September 2015). You can watch the discussion and read the slides [2]. This presentation was related to the toolchain published on github [3], which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1 and qemu-2.3.0, and for which pre-built binaries are available [3]. The ABI itself is described in details in [1]. Our Linux kernel patches have been updated and committed by Nicolas Pitre (Linaro) in July 2017. They are required so that the loader is able to handle this new file type. Indeed, the ELF files are tagged with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as well as the new relocations involved. The binutils, QEMU and uclibc-ng patch series have been merged a few months ago. [4][5][6] This series provides support for architectures that support ARM and/or Thumb-2 and has been tested on arm-linux-gnueabi without regression, as well as arm-uclinuxfdpiceabi, using QEMU. arm-uclinuxfdpiceabi has a few more failures than arm-linux-gnueabi, but is quite functional. I have also booted an STM32 board (stm32f469) which uses a cortex-m4 with linux-4.20.17 and ran successfully several tools. Are the GCC patches OK for inclusion in master? Changes between v4 and v5: - rebased on top of recent gcc-10 master (April 26th, 2019) - fixed handling of stack-protector combined patterns in FDPIC mode Changes between v3 and v4: - improved documentation (patch 1) - emit an error message (sorry) if the target architecture does not support arm nor thumb-2 modes (patch 4) - handle Richard's comments on patch 4 (comments, unspec) - added .align directive (patch 5) - fixed use of kernel helpers (__kernel_cmpxchg, __kernel_dmb) (patch 6) - code factorization in patch 7 - typos/internal function name in patch 8 - improved patch 12 - dropped patch 16 - patch 20 introduces arm_arch*_thumb_ok effective targets to help skip some tests - I tested patch 2 on xtensa-buildroot-uclinux-uclibc, it adds many new tests, but a few regressions (https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00713.html) - I compiled and executed several LTP tests to exercise pthreads and signals - I wrote and executed a simple testcase to change the interaction with __kernel_cmpxchg (ie. call the kernel helper rather than use an implementation in libgcc as requested by Richard) Changes between v2 and v3: - added doc entry for -mfdpic new option - took Kyrill's comments into account (use "Armv7" instead of "7", code factorization, use preprocessor instead of hard-coding "r9", remove leftover code for thumb1 support, fixed comments) - rebase over recent trunk - patches with changes: 1, 2 (commit message), 3 (rebase), 4, 6, 7, 9, 14 (rebase), 19 (rebase) Changes between v1 and v2: - fix GNU coding style - exit with an error for pre-Armv7 - use ACLE __ARM_ARCH and remove dead code for pre-Armv4 - remove unsupported attempts of pre-Armv7/thumb1 support - add instructions in comments next to opcodes - merge patches 11 and 13 - fixed protected visibility handling in patch 8 - merged legitimize_tls_address_fdpic and legitimize_tls_address_not_fdpic as requested Thanks, Christophe. [1] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt [2] http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/ [3] https://github.com/mickael-guene/fdpic_manifest [4] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=f1ac0afe481e83c9a33f247b81fa7de789edc4d9 [5] https://git.qemu.org/?p=qemu.git;a=commit;h=e8fa72957419c11984608062c7dcb204a6003a06 [6] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=13c46fbc1e5a021f2b9ed32d83aecc93ae5e655d Christophe Lyon (21): [ARM] FDPIC: Add -mfdpic option support [ARM] FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts [ARM] FDPIC: Force FDPIC related options unless -mno-fdpic is provided [ARM] FDPIC: Add support for FDPIC for arm architecture [ARM]
Re: [PATCH, i386]: Macroize DIVMOD patterns
I somehow missed this testsuite failure...
Attached patch is needed. I'll commit it later today.
Uros.
On Wed, May 15, 2019 at 2:16 PM Richard Biener
wrote:
>
> On Tue, May 14, 2019 at 6:23 PM Uros Bizjak wrote:
> >
> > Recent work by Richard Sandiford [1] enabled the possibility to
> > macroize DIVMOD patterns in i386.md.
> >
> > 2019-05-14 Uroš Bizjak
> >
> > * config/i386/i386.md (any_div): New code iterator.
> > (paired_mod): New code attribute.
> > (sgnprefix): Handle DIV and UDIV RTXes.
> > (u): Ditto.
> > (divmod4): Macroize expander from divmod4
> > and udivmod4 patterns using any_div code iterator.
> > (divmod splitters): Macroize splitters using any_div code iterator.
> > (*udivmodsi4_pow2_zext_1): Use exactl_log2 in insn condition.
> > (*udivmodsi4_pow2_zext_2): Ditto.
> > (*divmod4_noext): Macroize insn from *divmod4_noext
> > and *udivmod4_noext patterns using any_div code iterator.
> > (*divmod4_noext_zext_1): Macroize insn from
> > *divmod4_noext_zext_1 and *udivmod4_noext_zext_1
> > patterns using any_div code iterator.
> > (*divmod4_noext_zext_2): Macroize insn from
> > *divmod4_noext_zext_2 and *udivmod4_noext_zext_2
> > patterns using any_div code iterator.
> > (divmodhiqi3): Macroize insn from divmodhiqi3 and
> > udivmodhiqi3 patterns using any_extend code iterator.
> >
> > The patch also reorders DIVMOD patterns a bit.
> >
> > Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> >
> > Committed to mainline SVN.
>
> I see
>
> FAIL: gcc.target/i386/udivmod-1.c execution test
>
> on x86_64.
>
> > [1] https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00560.html
> >
> > Uros.
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index a55d4923be48..36b27898833e 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -984,7 +984,7 @@ predict_jump (int prob)
void
ix86_split_idivmod (machine_mode mode, rtx operands[],
- bool signed_p)
+ bool unsigned_p)
{
rtx_code_label *end_label, *qimode_label;
rtx div, mod;
@@ -1000,22 +1000,22 @@ ix86_split_idivmod (machine_mode mode, rtx operands[],
if (GET_MODE (operands[0]) == SImode)
{
if (GET_MODE (operands[1]) == SImode)
- gen_divmod4_1 = signed_p ? gen_divmodsi4_1 : gen_udivmodsi4_1;
+ gen_divmod4_1 = unsigned_p ? gen_udivmodsi4_1 : gen_divmodsi4_1;
else
gen_divmod4_1
- = signed_p ? gen_divmodsi4_zext_2 : gen_udivmodsi4_zext_2;
+ = unsigned_p ? gen_udivmodsi4_zext_2 : gen_divmodsi4_zext_2;
gen_zero_extend = gen_zero_extendqisi2;
}
else
{
gen_divmod4_1
- = signed_p ? gen_divmodsi4_zext_1 : gen_udivmodsi4_zext_1;
+ = unsigned_p ? gen_udivmodsi4_zext_1 : gen_divmodsi4_zext_1;
gen_zero_extend = gen_zero_extendqidi2;
}
gen_test_ccno_1 = gen_testsi_ccno_1;
break;
case E_DImode:
- gen_divmod4_1 = signed_p ? gen_divmoddi4_1 : gen_udivmoddi4_1;
+ gen_divmod4_1 = unsigned_p ? gen_udivmoddi4_1 : gen_divmoddi4_1;
gen_test_ccno_1 = gen_testdi_ccno_1;
gen_zero_extend = gen_zero_extendqidi2;
break;
@@ -1061,15 +1061,15 @@ ix86_split_idivmod (machine_mode mode, rtx operands[],
tmp2 = lowpart_subreg (QImode, operands[3], mode);
emit_insn (gen_udivmodhiqi3 (tmp0, tmp1, tmp2));
- if (signed_p)
+ if (unsigned_p)
{
- div = gen_rtx_DIV (mode, operands[2], operands[3]);
- mod = gen_rtx_MOD (mode, operands[2], operands[3]);
+ div = gen_rtx_UDIV (mode, operands[2], operands[3]);
+ mod = gen_rtx_UMOD (mode, operands[2], operands[3]);
}
else
{
- div = gen_rtx_UDIV (mode, operands[2], operands[3]);
- mod = gen_rtx_UMOD (mode, operands[2], operands[3]);
+ div = gen_rtx_DIV (mode, operands[2], operands[3]);
+ mod = gen_rtx_MOD (mode, operands[2], operands[3]);
}
if (mode == SImode)
{
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 05411221197f..b6e44c82d217 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -939,7 +939,8 @@
(define_code_attr s [(sign_extend "s") (zero_extend "u")])
(define_code_attr u [(sign_extend "") (zero_extend "u")
(div "") (udiv "u")])
-(define_code_attr u_bool [(sign_extend "false") (zero_extend "true")])
+(define_code_attr u_bool [(sign_extend "false") (zero_extend "true")
+ (div "false") (udiv "true")])
;; Used in signed and unsigned truncations.
(define_code_iterator any_truncate [ss_truncate truncate us_truncate])
@@ -7505,7 +7506,7 @@
&& can_create_pseudo_p ()
&& !optimize_insn_for_size_p ()"
[(const_int 0)]
- "ix86_split_idivmod (mode, operands, true); DONE;")
+ "ix86_split_idivmod (mode, operands, ); DONE;")
(define_split
[(set (match_operand:DI 0
Re: [C++ Patch] Consistently use OVL_P
On 5/14/19 5:20 PM, Paolo Carlini wrote: Hi again, ... so the below passes testing on x86_64-linux. In fact, I think we are on a pretty safe ground, now at the beginning of Stage 1: if, over the next months we get a testcase which causes one of the 4 tightened gcc_assert to trip we'll comfortably deal with it. great, thanks for trying that. Marek found the nits. nathan -- Nathan Sidwell
Re: [PATCH] Check for overflow in tree-switch-conversion (PR middle-end/90478).
On Wed, May 15, 2019 at 1:30 PM Martin Liška wrote: > > On 5/15/19 1:21 PM, Richard Biener wrote: > > On Wed, May 15, 2019 at 12:21 PM Martin Liška wrote: > >> > >> Hi. > >> > >> The patch is about handling of overflow in > >> jump_table_cluster::can_be_handled. > >> I calculate 100 * range and compare it to range. If it's smaller, then > >> overflow happens. > >> > >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > >> > >> Ready to be installed? > > > > Looks good, but can the RHS overflow as well? > > That should be fine as maximal value of the PARAM is 1<32. And if I'm correct > HOST_WIDE_INT should have 64-bits? Yes. > Martin > > > I suppose changing > > the compute/compare to uint64_t would fix the overflow but downstream > > the issue would re-appear? > > > > Richard. > > > >> Thanks, > >> Martin > >> > >> gcc/ChangeLog: > >> > >> 2019-05-15 Martin Liska > >> > >> PR middle-end/90478 > >> * tree-switch-conversion.c (jump_table_cluster::can_be_handled): > >> Check for overflow. > >> > >> gcc/testsuite/ChangeLog: > >> > >> 2019-05-15 Martin Liska > >> > >> PR middle-end/90478 > >> * gcc.dg/tree-ssa/pr90478-2.c: New test. > >> * gcc.dg/tree-ssa/pr90478.c: New test. > >> --- > >> gcc/testsuite/gcc.dg/tree-ssa/pr90478-2.c | 17 + > >> gcc/testsuite/gcc.dg/tree-ssa/pr90478.c | 18 ++ > >> gcc/tree-switch-conversion.c | 6 +- > >> 3 files changed, 40 insertions(+), 1 deletion(-) > >> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr90478-2.c > >> create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr90478.c > >> > >> >
Re: [PATCH, i386]: Macroize DIVMOD patterns
On Wed, May 15, 2019 at 02:15:43PM +0200, Richard Biener wrote: > I see > > FAIL: gcc.target/i386/udivmod-1.c execution test > > on x86_64. And on i686-linux too. Jakub
Re: [PATCH, i386]: Macroize DIVMOD patterns
On Tue, May 14, 2019 at 6:23 PM Uros Bizjak wrote:
>
> Recent work by Richard Sandiford [1] enabled the possibility to
> macroize DIVMOD patterns in i386.md.
>
> 2019-05-14 Uroš Bizjak
>
> * config/i386/i386.md (any_div): New code iterator.
> (paired_mod): New code attribute.
> (sgnprefix): Handle DIV and UDIV RTXes.
> (u): Ditto.
> (divmod4): Macroize expander from divmod4
> and udivmod4 patterns using any_div code iterator.
> (divmod splitters): Macroize splitters using any_div code iterator.
> (*udivmodsi4_pow2_zext_1): Use exactl_log2 in insn condition.
> (*udivmodsi4_pow2_zext_2): Ditto.
> (*divmod4_noext): Macroize insn from *divmod4_noext
> and *udivmod4_noext patterns using any_div code iterator.
> (*divmod4_noext_zext_1): Macroize insn from
> *divmod4_noext_zext_1 and *udivmod4_noext_zext_1
> patterns using any_div code iterator.
> (*divmod4_noext_zext_2): Macroize insn from
> *divmod4_noext_zext_2 and *udivmod4_noext_zext_2
> patterns using any_div code iterator.
> (divmodhiqi3): Macroize insn from divmodhiqi3 and
> udivmodhiqi3 patterns using any_extend code iterator.
>
> The patch also reorders DIVMOD patterns a bit.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> Committed to mainline SVN.
I see
FAIL: gcc.target/i386/udivmod-1.c execution test
on x86_64.
> [1] https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00560.html
>
> Uros.
Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git
> On May 15, 2019, at 2:19 PM, Richard Biener > wrote: > > On Tue, May 14, 2019 at 6:11 PM Maxim Kuvyrkov > wrote: >> >> This patch adds scripts to contrib/ to migrate full history of GCC's >> subversion repository to git. My hope is that these scripts will finally >> allow GCC project to migrate to Git. >> >> The result of the conversion is at >> https://github.com/maxim-kuvyrkov/gcc/branches/all . Branches with "@rev" >> suffixes represent branch points. The conversion is still running, so not >> all branches may appear right away. >> >> The scripts are not specific to GCC repo and are usable for other projects. >> In particular, they should be able to convert downstream GCC svn repos. >> >> The scripts convert svn history branch by branch. They rely on git-svn on >> convert individual branches. Git-svn is a good tool for converting >> individual branches. It is, however, either very slow at converting the >> entire GCC repo, or goes into infinite loop. >> >> There are 3 scripts: >> >> - svn-git-repo.sh: top level script to convert entire repo or a part of it >> (e.g., branches/), >> - svn-list-branches.sh: helper script to output branches and their parents >> in bottom-up order, >> - svn-git-branch.sh: helper script to convert a single branch. >> >> Whenever possible, svn-git-branch.sh uses existing git branches as caches. >> >> What are your questions and comments? > > Any comments on how it deals with "errors" like removing trunk which > happened a few times? > (not sure what other "errors" Eric refers to reposurgeon "deals" with...) Stock git-svn can deal with deleted parents; e.g., for the first deletion of trunk, git-svn treats trunk@180802 as a /generic/ parent path for trunk, and happily follows its history. > > I suppose it converts only history of not deleted branches? The scripts can convert history of deleted and moved branches. E.g., branches/gcc-3_2-rhl8-branch was moved (which is copy and delete for svn) to branches/redhat/gcc-3_2-rhl8-branch around revision 95470, so one would need to point the scripts to branches/gcc-3_2-rhl8-branch@95470 to convert its history. Something like: ./svn-git-repo.sh --repo $HOME/gcc-branches --svnpath branches/gcc-3_2-rhl8-branch@95470 > > For the official converted repo do we really want all (old) > development branches to be in the > main git repo? I suppose we could create a readonly git from the > state of the whole repository > at the point of conversion (and also keep the SVN in readonly mode), > just to make migration > of content we want easy in the future? Having a single full repo is simpler than having the main repo and the full one with all the history. So, unless full repo is twice the size of the main one, let's keep all the branches. We can also give a shout to representatives of RedHat, Google, and others to voluntarily remove their old maintenance branches from the repo, and, possibly, stash them somewhere on github. > >> The attached is cleaned up version, which hasn't been fully tested yet; >> typos and other silly mistakes are likely. OK to commit after testing? > > Thanks for taking up this ball! -- Maxim Kuvyrkov www.linaro.org
[PATCH, Darwin, PowerPC, testsuite] Exclude Darwin from VSX, Power8 and Power9 tests.
Hi! If we build Darwin with a modern assembler, then it might well recognise insns that cannot be used on current Darwin systems. The patch augments the tests for feature support for VSX, power8 and power9 to exclude Darwin even if the assembler can handle the instructions. tested on powerpc-darwin9 (with llvm-based assembler and cctools) tested on powerpc-linux-gnu (power7 machine). Applied to mainline. Iain 2019-05-15 Iain Sandoe * lib/target-supports.exp (check_effective_target_powerpc_p8vector_ok): No support for Darwin. (check_effective_target_powerpc_p9vector_ok): Likewise. (check_effective_target_powerpc_float128_sw_ok): Likewise. (check_effective_target_powerpc_float128_hw_ok): Likewise. (check_effective_target_powerpc_vsx_ok): Likewise. * gcc.target/powerpc/bfp/bfp.exp: Don't try to run this for Darwin. * gcc.target/powerpc/dfp/dfp.exp: Likewise. ppc-testsuite-new-assembler.diff Description: Binary data
Re: malloc cannot alias preexisting pointers
On Tue, May 14, 2019 at 4:05 PM Marc Glisse wrote:
>
> On Tue, 14 May 2019, Richard Biener wrote:
>
> >>> In princple PTA should know the aliasing cannot happen but possibly
> >>> the info is either lost or the IL is too obfuscated at the point it gets
> >>> computed. (hello C++...)
> >>
> >> We don't need much obfuscation for this, a simple C program
> >>
> >> int g;
> >> int*f(int**p){
> >>int*q=*p;
> >>int*r=__builtin_malloc(4);
> >>*q=1;
> >>*r=2;
> >>g=*q;
> >>return r;
> >> }
> >>
> >> gives
> >>
> >>q_4 = *p_3(D);
> >>r_6 = __builtin_malloc (4);
> >>*q_4 = 1;
> >>*r_6 = 2;
> >>_1 = *q_4;
> >>g = _1;
> >>return r_6;
> >>
> >> where we clearly don't manage to prove that q and r don't alias.
> >
> > We can probably improve this one in general from inside PTA
> > by treating escapes through return specially. I wasn't looking
> > too closely at the C++ testcase but I simply assumed the
> > addition to ESCAPED happens through storing the malloc
> > result to memory that PTA cannot prove local.
>
> Yes, that is indeed the case. I only wrote the version with return to
> simplify, but the vector testcase does store the malloc result in
> non-local memory, so handling return as a special case wouldn't help it.
>
> >>> So at ldist time I see
> >>>
> >>> # PT = null { D.47989 } (escaped, escaped heap)
> >>> # ALIGN = 8, MISALIGN = 0
> >>> # USE = nonlocal null { D.47989 } (escaped, escaped heap)
> >>> # CLB = nonlocal null { D.47989 } (escaped, escaped heap)
> >>> _27 = malloc (8192);
> >>>
> >>> good. The interesting loop is the following where the allocation PTA
> >>> is good and _4 intersect because they include ESCAPED. This is
> >>> because _27 itself escapes and PTA not being flow-sensitive. I don't
> >>> see an easy way to improve things here but dislike the stmt walking
> >>> very much. That is, the proper solution is to re-write PTA in some way.
> >>
> >> I am trying to imagine what that might look like. I imagine that instead
> >> of having a single "escaped" set, we would have multiple escaped sets at
> >> different points in the function (at most one per VDEF?). Then _4 would
> >> only contain escaped3 while heap5 (*_27) only appears in escaped9 and
> >> later? It may be tricky to keep a linear-ish complexity with anything more
> >> powerful than the current PTA. I don't know what LLVM is doing, but they
> >> seem to manage.
> >
> > IIRC LLVM uses Steensgard analysis which is flow-sensitive but generally
> > less powerful. We are using Andersen constraint-based analysis because
> > Steensgard was patented back in time (that patent has now expired).
>
> In https://llvm.org/docs/AliasAnalysis.html they say that Steensgaard’s
> algorithm is flow-insensitive and context-insensitive, so it might not be
> it. They run about 5 different alias analysis engines and combine their
> results to disambiguate as much as they can.
>
> > One approach to make PTA "more" flow-sensitive is to partition the function
> > into regions (basically represent the function as a series of function calls
> > to its parts).
> >
> > For the issue above there's the long-standing issue of splitting escapes
> > from function return from escapes to functions called to properly represent
> > local variable lifetime.
> >
> > That said, your simpler patch still relies on up-to-date dominators, sth
> > not guaranteed or required previously.
>
> Ah, dom_info_available_p does not mean that the available information is
> up-to-date? :-(
Kind-of. A safer test is dom_info_state (cfun, CDI_DOMINATORS) == DOM_OK.
I think the in_gimple_form test is superfluous.
As you write the heuristic you could as well remove the malloc result
points-to set from the others after points-to analysis is finished?
One could even devise something like a "negative" live set
(all-locals & ~live-locals), pruning the points-to sets of SSA names
on the whole CFG considering that
int *p;
int y;
void foo()
{
int x;
*p =
if (p != ) abort ();
*p =
}
computes p to point to both y and x at the point of the comparison.
That is, this isn't special to malloc but to all variables that come into
scope only after function entry.
This is something I would like much more than these kinds of local
tricks in the oracle itself.
Richard.
> > We might consider implementing a separate (region-based) analysis
> > adjusting/pruning points-to information with flow-sensitive knowlege.
> > This might even work when done from inside PTA as post-processing.
>
> --
> Marc Glisse
Re: [PATCH 1/12] implement -Wformat-diag to detect quoting and spelling issues in GCC diagnostics
On 5/14/19 11:31 PM, Martin Sebor wrote: > The attached patch implements the -Wformat-diag warning to help find > quoting, spelling, and other formatting issues in diagnostics issued > by GCC. Just a general comment about this part. Wouldn't it make sense to use regex for some of the string patterns that you address in the patch? Martin
