Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux
Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html Thanks. Gui Haochen On 6/11/2020 上午 9:02, HAO CHEN GUI wrote: Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html Thanks. Gui Haochen On 15/10/2020 下午 4:46, HAO CHEN GUI wrote: Segher, I re-wrote the patch based on parameterized name. The attachments are the patch diff file and change log file. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Any recommendations? Thanks a lot. On 29/9/2020 上午 6:46, Segher Boessenkool wrote: Hi hao Chen, On Wed, Sep 09, 2020 at 04:55:29PM +0800, HAO CHEN GUI wrote: Thanks for your advice. I removed macros defined in linux64.h and linux.h. So they take relative jump tables by default. When no-relative-jumptables is set, the absolute jump tables are taken. All things relevant to section relocations are put in another patch. Thanks again. [ Please do not insert patches into discussions ] +/* Implement TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC. + Return true if rs6000_relative_jumptables is set. */ Don't just say what the code does (we can see that ;-) ); say *why*. Of course it is terribly simple in this case, so maybe just that first line is plenty. +/* Specify the machine mode that this machine uses + for the index in the tablejump instruction. */ +#define CASE_VECTOR_MODE \ + (TARGET_32BIT || rs6000_relative_jumptables ? SImode : Pmode) If TARGET_32BIT is true, SImode and Pmode are the same, so this is simpler said as #define CASE_VECTOR_MODE (rs6000_relative_jumptables ? SImode : Pmode) I'll have the tablejump* patterns converted to paremeterized names hopefully tonight or tomorrow, which will make your patch much easier to read. It looks like it will be fine, thanks :-) Segher
[PATCH] [tree-optimization] Optimize or+and+or pattern to and+or
Simplify
((b | c) & a) | b
to
(a & c) | b.
This fixes PR96679.
Tested on x86_64-pc-linux-gnu.
int f(int a, int b, int c)
{
return ((b | c) & a) | b;
}
Code without the patch:
or edx,esi
andedx,edi
moveax,edx
or eax,esi
ret
Code with the patch:
andedi,edx
moveax,edi
or eax,esi
ret
Eugene
0001-Optimize-or-and-or-pattern-to-and-or.patch
Description: 0001-Optimize-or-and-or-pattern-to-and-or.patch
Re: Document --with-build-config=bootstrap-asan option.
On Fri, 20 Nov 2020, Matthew Malcomson wrote: >>> The patch is okay modulo the question above. > Apologies for bringing up something from this far back, but I've just > noticed I never actually committed this patch. Actually thank you for doing so! (And I am known to sometimes bring up things quite older than this. ;-) > Did the above line mean approval once the option was moved into the > existing table? Or was it just explaining that the position was the > only problem you saw? Yes - the former. > In other words: is the patch I proposed below Ok for trunk? Yes, please. (I believe there may be an overly long line in the patch, which will be good to wrap before committing, but please go ahead in any case.) (This is also okay to backport to GCC 10.) Thanks, Gerald
Re: [PATCH] libstdc++: Add C++2a synchronization support
On 20/11/2020 23:44, Thomas Rodgers wrote:
Tested x86_64-pc-linux-gnu, committed.
...and there are multiple definition complaints from the linker because
of two missing "include":
index 7b2682a577e..23ab2018ca8 100644
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -223,7 +223,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ _M_w._M_do_wait(_M_version); }
};
-void
+inline void
__thread_relax() noexcept
{
#if defined __i386__ || defined __x86_64__
@@ -233,7 +233,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#endif
}
-void
+inline void
__thread_yield() noexcept
{
#if defined _GLIBCXX_USE_SCHED_YIELD
[PATCH] i386: Use SWI48DWI mode iterator for abs and maxmin [PR97873]
Generate special double mode sequence also for TImode on 64bit targets.
2020-11-22 Uroš Bizjak
PR target/97873
gcc/
* config/i386/i386.md (abs2): Use SWI48DWI mode iterator.
(*abs2_doubleword): Use DWIH mode iterator.
(3): Use SWI48DWI mode iterator.
(*3_doubleword): Use DWIH mode iterator.
gcc/testsuite/
* gcc.target/i386/pr97873-2.c: New test.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Pushed to mainline.
Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 2b2ba2f3a20..2beaee5418d 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -10180,9 +10180,9 @@
(define_expand "abs2"
[(parallel
-[(set (match_operand:SWI48x 0 "register_operand")
- (abs:SWI48x
- (match_operand:SWI48x 1 "general_operand")))
+[(set (match_operand:SWI48DWI 0 "register_operand")
+ (abs:SWI48DWI
+ (match_operand:SWI48DWI 1 "general_operand")))
(clobber (reg:CC FLAGS_REG))])]
"TARGET_CMOVE"
{
@@ -10208,37 +10208,12 @@
}
})
-(define_insn_and_split "*abs2_1"
- [(set (match_operand:SWI48 0 "register_operand")
- (abs:SWI48
- (match_operand:SWI48 1 "general_operand")))
- (clobber (reg:CC FLAGS_REG))]
- "TARGET_CMOVE && ix86_pre_reload_split ()"
- "#"
- "&& 1"
- [(parallel
- [(set (reg:CCGOC FLAGS_REG)
- (compare:CCGOC
-(neg:SWI48 (match_dup 1))
-(const_int 0)))
- (set (match_dup 2)
- (neg:SWI48 (match_dup 1)))])
- (set (match_dup 0)
-(if_then_else:SWI48
- (ge (reg:CCGOC FLAGS_REG) (const_int 0))
- (match_dup 2)
- (match_dup 1)))]
-{
- operands[1] = force_reg (mode, operands[1]);
- operands[2] = gen_reg_rtx (mode);
-})
-
-(define_insn_and_split "*absdi2_doubleword"
- [(set (match_operand:DI 0 "register_operand")
- (abs:DI
- (match_operand:DI 1 "general_operand")))
+(define_insn_and_split "*abs2_doubleword"
+ [(set (match_operand: 0 "register_operand")
+ (abs:
+ (match_operand: 1 "general_operand")))
(clobber (reg:CC FLAGS_REG))]
- "!TARGET_64BIT && TARGET_CMOVE
+ "TARGET_CMOVE
&& ix86_pre_reload_split ()"
"#"
"&& 1"
@@ -10255,25 +10230,51 @@
(parallel
[(set (reg:CCGOC FLAGS_REG)
(compare:CCGOC
-(neg:SI (match_dup 5))
+(neg:DWIH (match_dup 5))
(const_int 0)))
(set (match_dup 5)
- (neg:SI (match_dup 5)))])
+ (neg:DWIH (match_dup 5)))])
(set (match_dup 0)
-(if_then_else:SI
+(if_then_else:DWIH
(ge (reg:CCGOC FLAGS_REG) (const_int 0))
(match_dup 2)
(match_dup 1)))
(set (match_dup 3)
-(if_then_else:SI
+(if_then_else:DWIH
(ge (reg:CCGOC FLAGS_REG) (const_int 0))
(match_dup 5)
(match_dup 4)))]
{
- operands[1] = force_reg (DImode, operands[1]);
- operands[2] = gen_reg_rtx (DImode);
+ operands[1] = force_reg (mode, operands[1]);
+ operands[2] = gen_reg_rtx (mode);
- split_double_mode (DImode, [0], 3, [0], [3]);
+ split_double_mode (mode, [0], 3, [0], [3]);
+})
+
+(define_insn_and_split "*abs2_1"
+ [(set (match_operand:SWI48 0 "register_operand")
+ (abs:SWI48
+ (match_operand:SWI48 1 "general_operand")))
+ (clobber (reg:CC FLAGS_REG))]
+ "TARGET_CMOVE
+ && ix86_pre_reload_split ()"
+ "#"
+ "&& 1"
+ [(parallel
+ [(set (reg:CCGOC FLAGS_REG)
+ (compare:CCGOC
+(neg:SWI48 (match_dup 1))
+(const_int 0)))
+ (set (match_dup 2)
+ (neg:SWI48 (match_dup 1)))])
+ (set (match_dup 0)
+(if_then_else:SWI48
+ (ge (reg:CCGOC FLAGS_REG) (const_int 0))
+ (match_dup 2)
+ (match_dup 1)))]
+{
+ operands[1] = force_reg (mode, operands[1]);
+ operands[2] = gen_reg_rtx (mode);
})
(define_expand "tf2"
@@ -18966,13 +18967,71 @@
(define_expand "3"
[(parallel
-[(set (match_operand:SWI48x 0 "register_operand")
- (maxmin:SWI48x
- (match_operand:SWI48x 1 "register_operand")
- (match_operand:SWI48x 2 "general_operand")))
+[(set (match_operand:SWI48DWI 0 "register_operand")
+ (maxmin:SWI48DWI
+ (match_operand:SWI48DWI 1 "register_operand")
+ (match_operand:SWI48DWI 2 "general_operand")))
(clobber (reg:CC FLAGS_REG))])]
"TARGET_CMOVE")
+(define_insn_and_split "*3_doubleword"
+ [(set (match_operand: 0 "register_operand")
+ (maxmin:
+ (match_operand: 1 "register_operand")
+ (match_operand: 2 "general_operand")))
+ (clobber (reg:CC FLAGS_REG))]
+ "TARGET_CMOVE
+ && ix86_pre_reload_split ()"
+ "#"
+ "&& 1"
+ [(set (match_dup 0)
+ (if_then_else:DWIH (match_dup 6)
+ (match_dup 1)
+ (match_dup 2)))
+ (set (match_dup 3)
+ (if_then_else:DWIH (match_dup 6)
+ (match_dup 4)
+ (match_dup 5)))]
+{
+ operands[2] = force_reg
Re: [PATCH] libstdc++: Add C++2a synchronization support
On 20/11/2020 23:44, Thomas Rodgers wrote:
Tested x86_64-pc-linux-gnu, committed.
Clang complains:
$ cat test.cc
#include
$ clang++ --gcc-toolchain=~/gcc/trunk/inst -std=c++20 -fsyntax-only test.cc
In file included from test.cc:1:
In file included from
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/semaphore:36:
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/semaphore_base.h:145:22:
error: no viable conversion from 'std::chrono::system_clock::time_point' (aka
'time_point>>')
to 'const std::__platform_semaphore::__clock_t' (aka 'const std::chrono::system_clock')
const __clock_t __s_entry = __clock_t::now();
^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/chrono:1101:12:
note: candidate constructor (the implicit copy constructor) not viable: no known conversion from
'std::chrono::system_clock::time_point' (aka 'time_point>>') to 'const std::chrono::system_clock &' for
1st argument
struct system_clock
^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/chrono:1101:12: note:
candidate constructor (the implicit move constructor) not viable: no known conversion from
'std::chrono::system_clock::time_point' (aka 'time_point>>') to 'std::chrono::system_clock &&' for 1st argument
1 error generated.
which
diff --git a/libstdc++-v3/include/bits/semaphore_base.h
b/libstdc++-v3/include/bits/semaphore_base.h
index 78a0b6ba26e..f25c9fdb325 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -142,7 +142,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
else
{
const typename _Clock::time_point __c_entry = _Clock::now();
- const __clock_t __s_entry = __clock_t::now();
+ const __clock_t::time_point __s_entry = __clock_t::now();
const auto __delta = __atime - __c_entry;
const auto __s_atime = __s_entry + __delta;
if (_M_try_acquire_until_impl(__s_atime))
~
would fix.
[committed] d: Fix OutOfMemoryError thrown when appending to an array with a side effect (PR97889)
Hi,
When appending a character to an array, the result of that concat
assignment was not the new value of the array, similarly, when appending
an array to another array, side effects were evaluated in reverse to the
expected order of evaluation.
As of this change, the address of the left-hand side expression is
saved and re-used as the result. Its evaluation is now also forced to
occur before the concat operation itself is called.
Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline, and backported to the release/gcc-10 branch as it is obviously
wrong code.
Regards
Iain.
---
gcc/d/ChangeLog:
PR d/97889
* expr.cc (ExprVisitor::visit (CatAssignExp *)): Enforce LTR order of
evaluation on left and right hand side expressions.
gcc/testsuite/ChangeLog:
PR d/97889
* gdc.dg/torture/pr97889.d: New test.
---
gcc/d/expr.cc | 67 +-
gcc/testsuite/gdc.dg/torture/pr97889.d | 29 +++
2 files changed, 72 insertions(+), 24 deletions(-)
create mode 100644 gcc/testsuite/gdc.dg/torture/pr97889.d
diff --git a/gcc/d/expr.cc b/gcc/d/expr.cc
index ef2bf5f2e36..2a1818ab4e5 100644
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -838,62 +838,81 @@ public:
Type *tb2 = e->e2->type->toBasetype ();
Type *etype = tb1->nextOf ()->toBasetype ();
+/* Save the address of `e1', so it can be evaluated first.
+ As all D run-time library functions for concat assignments update `e1'
+ in-place and then return its value, the saved address can also be used
as
+ the result of this expression as well. */
+tree lhs = build_expr (e->e1);
+tree lexpr = stabilize_expr ();
+tree ptr = d_save_expr (build_address (lhs));
+tree result = NULL_TREE;
+
if (tb1->ty == Tarray && tb2->ty == Tdchar
&& (etype->ty == Tchar || etype->ty == Twchar))
{
- /* Append a dchar to a char[] or wchar[] */
+ /* Append a dchar to a char[] or wchar[]:
+ The assignment is handled by the D run-time library, so only
+ need to call `_d_arrayappend[cw]d(, e2)' */
libcall_fn libcall = (etype->ty == Tchar)
? LIBCALL_ARRAYAPPENDCD : LIBCALL_ARRAYAPPENDWD;
- this->result_ = build_libcall (libcall, e->type, 2,
- build_address (build_expr (e->e1)),
- build_expr (e->e2));
+ result = build_libcall (libcall, e->type, 2,
+ ptr, build_expr (e->e2));
}
else
{
gcc_assert (tb1->ty == Tarray || tb2->ty == Tsarray);
- tree tinfo = build_typeinfo (e->loc, e->type);
- tree ptr = build_address (build_expr (e->e1));
-
if ((tb2->ty == Tarray || tb2->ty == Tsarray)
&& same_type_p (etype, tb2->nextOf ()->toBasetype ()))
{
- /* Append an array. */
- this->result_ = build_libcall (LIBCALL_ARRAYAPPENDT, e->type, 3,
- tinfo, ptr, d_array_convert (e->e2));
-
+ /* Append an array to another array:
+ The assignment is handled by the D run-time library, so only
+ need to call `_d_arrayappendT(ti, , e2)' */
+ result = build_libcall (LIBCALL_ARRAYAPPENDT, e->type, 3,
+ build_typeinfo (e->loc, e->type),
+ ptr, d_array_convert (e->e2));
}
else if (same_type_p (etype, tb2))
{
- /* Append an element. */
- tree result = build_libcall (LIBCALL_ARRAYAPPENDCTX, e->type, 3,
-tinfo, ptr, size_one_node);
- result = d_save_expr (result);
+ /* Append an element to an array:
+ The assignment is generated inline, so need to handle temporaries
+ here, and ensure that they are evaluated in the correct order.
+
+ The generated code should end up being equivalent to:
+ _d_arrayappendcTX(ti, , 1)[e1.length - 1] = e2
+*/
+ tree callexp = build_libcall (LIBCALL_ARRAYAPPENDCTX, e->type, 3,
+ build_typeinfo (e->loc, e->type),
+ ptr, size_one_node);
+ callexp = d_save_expr (callexp);
/* Assign e2 to last element. */
- tree offexp = d_array_length (result);
+ tree offexp = d_array_length (callexp);
offexp = build2 (MINUS_EXPR, TREE_TYPE (offexp),
offexp, size_one_node);
- tree ptrexp = d_array_ptr (result);
+ tree ptrexp = d_array_ptr (callexp);
ptrexp = void_okay_p (ptrexp);
ptrexp = build_array_index (ptrexp, offexp);
/* Evaluate expression before appending. */
- tree t2 = build_expr (e->e2);
- tree expr =
Re: Go patch committed: Change name mangling convention
Hi Ian, > This patch to the Go frontend and libgo changes the name mangling > convention. The previous convention (which was actually the second > one) turned out to be ambiguous when the path to a package contained a > dot; this is a common case, as many package paths are of the form > "github.com/name/package". The previous convention also did not > support package paths that start with a digit, which is less common > but does occur (https://golang.org/issue/41862). > > This patch rewrites and somewhat simplifies the naming convention. > Now dot is used only as a separator character and for special names. > Actual name mangling, for representing Unicode characters and other > non-ASCII alphanumerics, is now done with an underscore. This has the > advantage of being simpler, in that it avoids the overloading that the > previous convention applied to dot. It has the disadvantage that > mangled symbol names look somewhat like valid Go names, since valid Go > names can of course contain underscore. Still, it seems like the best > choice. > > This patch increments the libgo major version number, since many > symbol names have changed. > > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed > to mainline. this patch broke Solaris bootstrap: linking in gotools fails with Undefined first referenced symbol in file log_1syslog.syslog__c ../i386-pc-solaris2.11/libgo/.libs/libgo.so ld: fatal: symbol referencing errors collect2: error: ld returned 1 exit status make[2]: *** [Makefile:829: buildid] Error 1 The following patch fixed this for me: diff --git a/libgo/go/log/syslog/syslog_c.c b/libgo/go/log/syslog/syslog_c.c --- a/libgo/go/log/syslog/syslog_c.c +++ b/libgo/go/log/syslog/syslog_c.c @@ -12,7 +12,7 @@ can't represent a C varargs function in Go. */ void syslog_c(intgo, const char*) - __asm__ (GOSYM_PREFIX "log_1syslog.syslog_c"); + __asm__ (GOSYM_PREFIX "log_1syslog.syslog__c"); void syslog_c (intgo priority, const char *msg) Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[committed] Partially revert recent H8 patch for conditional branches
Partially revert recent H8 patch for conditional branches
So I'd forgotten an important tidbit on the H8 port. Specifically
for a branch instruction, the target label must be operand 0 for
the length computations.
This really only affects the main conditional branch pattern.
The other conditional branch patterns are split and ultimately
funnel into the main pattern. This patch fixes the issue by
partially reverting an earlier change. This issue didn't show up
until late in the optimization work on cc0 removal of the H8 port,
but was caught by the testsuite. So there's no new test.
Built and regression tested H8 with this change, with and without
the cc0 removal patches.
Installing on the trunk momentarily.
jeff
commit 86148e6754fd5745190b381bd3e45eee11faaef9
Author: Jeff Law
Date: Sun Nov 22 10:53:14 2020 -0700
Partially revert recent H8 patch for conditional branches
So I'd forgotten an important tidbit on the H8 port. Specifically
for a branch instruction, the target label must be operand 0 for
the length computations.
This really only affects the main conditional branch pattern.
The other conditional branch patterns are split and ultimately
funnel into the main pattern. This patch fixes the issue by
partially reverting an earlier change. This issue didn't show up
until late in the optimization work on cc0 removal of the H8 port,
but was caught by the testsuite. So there's no new test.
Built and regression tested H8 with this change, with and without
the cc0 removal patches.
gcc/
* config/h8300/jumpcallmd (branch_true, branch_false): Revert
recent change. Ensure operand[0] is always the target label.
diff --git a/gcc/config/h8300/jumpcall.md b/gcc/config/h8300/jumpcall.md
index 3917cf18920..650b5e6fb70 100644
--- a/gcc/config/h8300/jumpcall.md
+++ b/gcc/config/h8300/jumpcall.md
@@ -37,44 +37,60 @@
DONE;
})
-(define_insn "branch"
+(define_insn "branch_true"
[(set (pc)
- (if_then_else (match_operator 2 "comparison_operator"
+ (if_then_else (match_operator 1 "comparison_operator"
[(cc0) (const_int 0)])
- (match_operand 0 "pc_or_label_operand" "")
- (match_operand 1 "pc_or_label_operand" "")))]
- "operands[0] == pc_rtx || operands[1] == pc_rtx"
+ (label_ref (match_operand 0 "" ""))
+ (pc)))]
+ ""
{
if ((cc_status.flags & CC_OVERFLOW_UNUSABLE) != 0
- && (GET_CODE (operands[2]) == GT
- || GET_CODE (operands[2]) == GE
- || GET_CODE (operands[2]) == LE
- || GET_CODE (operands[2]) == LT))
+ && (GET_CODE (operands[1]) == GT
+ || GET_CODE (operands[1]) == GE
+ || GET_CODE (operands[1]) == LE
+ || GET_CODE (operands[1]) == LT))
{
cc_status.flags &= ~CC_OVERFLOW_UNUSABLE;
return 0;
}
- if (operands[0] != pc_rtx)
-{
- if (get_attr_length (insn) == 2)
- return "b%j2%l0";
- else if (get_attr_length (insn) == 4)
- return "b%j2%l0:16";
- else
- return "b%k2.Lh8BR%=\;jmp @%l0\\n.Lh8BR%=:";
-}
+ if (get_attr_length (insn) == 2)
+return "b%j1 %l0";
+ else if (get_attr_length (insn) == 4)
+return "b%j1 %l0:16";
else
+return "b%k1 .Lh8BR%=\;jmp @%l0\\n.Lh8BR%=:";
+}
+ [(set_attr "type" "branch")
+ (set_attr "cc" "none")])
+
+(define_insn "branch_false"
+ [(set (pc)
+ (if_then_else (match_operator 1 "comparison_operator"
+ [(cc0) (const_int 0)])
+ (pc)
+ (label_ref (match_operand 0 "" ""]
+ ""
+{
+ if ((cc_status.flags & CC_OVERFLOW_UNUSABLE) != 0
+ && (GET_CODE (operands[1]) == GT
+ || GET_CODE (operands[1]) == GE
+ || GET_CODE (operands[1]) == LE
+ || GET_CODE (operands[1]) == LT))
{
- if (get_attr_length (insn) == 2)
- return "b%k2%l1";
- else if (get_attr_length (insn) == 4)
- return "b%k2%l1:16";
- else
- return "b%j2.Lh8BR%=\;jmp @%l1\\n.Lh8BR%=:";
+ cc_status.flags &= ~CC_OVERFLOW_UNUSABLE;
+ return 0;
}
+
+ if (get_attr_length (insn) == 2)
+return "b%k1 %l0";
+ else if (get_attr_length (insn) == 4)
+return "b%k1 %l0:16";
+ else
+return "b%j1 .Lh8BR%=\;jmp @%l0\\n.Lh8BR%=:";
}
- [(set_attr "type" "branch")
+ [(set_attr "type" "branch")
(set_attr "cc" "none")])
;; The brabc/brabs patterns have been disabled because their length computation
Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)
On 2020-11-21 12:27, J.W. Jagersma wrote:
> ...
> Another idea I had is to introduce a new operand modifier, eg. '-', which
> would signify that the output *must* be considered clobbered on exception,
> and it would be an error if a copy is not possible. Then the meaning of '+'
> can be extended to say that the output must be valid regardless of whether an
> exception occured or not. Modifier '=' would mean the same as '+' with the
> additional implication that it is okay to eliminate earlier assignments, so
> that its value on the EH edge would be undefined.
I've been working on implementing this, but I ran into an issue:
First of all, in the first version of this patch I had to make sure that
debug stmts were inserted across the fallthrough edge, so that they don't
appear at the end a basic block. I was surprised to find that this is no
longer necessary.
Next I discovered that the following test case fails (returns -1):
int f ()
{
int i = 0;
try { asm ("mov %0, 1; ud2" : "+r" (i)); }
catch (...) { }
return i - 1;
}
And this does succeed with a memory operand.
It seems that something changed in the past few months, and now asm register
outputs are already being assigned via a temporary variable, somewhere. Does
anyone know where that might be?
[pushed] Darwin : Avoid a C++ ODR violation seen with LTO.
Hi
We have a similar code pattern in darwin-c.c to one in c-pragmas
(most likely a cut & paste) with a struct type used locally to the
TU. With C++ we need to rename the type to avoid an ODR violation.
tested on x86_64-darwin19 ‘—with-build-config=bootstrap-lto-noplugin’
pushed to master,
thanks
Iain
gcc/ChangeLog:
* config/darwin-c.c (struct f_align_stack): Rename
to type from align_stack to f_align_stack.
(push_field_alignment): Likewise.
(pop_field_alignment): Likewise.
---
gcc/config/darwin-c.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/gcc/config/darwin-c.c b/gcc/config/darwin-c.c
index 9034f49908e..96172305711 100644
--- a/gcc/config/darwin-c.c
+++ b/gcc/config/darwin-c.c
@@ -44,13 +44,12 @@ static bool using_frameworks = false;
static const char *find_subframework_header (cpp_reader *pfile, const char
*header,
cpp_dir **dirp);
-typedef struct align_stack
-{
- int alignment;
- struct align_stack * prev;
-} align_stack;
+struct fld_align_stack {
+ int alignment;
+ struct fld_align_stack * prev;
+};
-static struct align_stack * field_align_stack = NULL;
+static struct fld_align_stack * field_align_stack;
/* Maintain a small stack of alignments. This is similar to pragma
pack's stack, but simpler. */
@@ -58,7 +57,7 @@ static struct align_stack * field_align_stack = NULL;
static void
push_field_alignment (int bit_alignment)
{
- align_stack *entry = XNEW (align_stack);
+ fld_align_stack *entry = XNEW (fld_align_stack);
entry->alignment = maximum_field_alignment;
entry->prev = field_align_stack;
@@ -72,7 +71,7 @@ pop_field_alignment (void)
{
if (field_align_stack)
{
- align_stack *entry = field_align_stack;
+ fld_align_stack *entry = field_align_stack;
maximum_field_alignment = entry->alignment;
field_align_stack = entry->prev;
--
2.24.1
Re: [PATCH] libstdc++: Add C++2a synchronization support
On Sun, 22 Nov 2020, 12:29 Iain Sandoe, wrote: > thanks for looking at this over the weekend. > > Jonathan Wakely via Gcc-patches wrote: > > > On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++ > > wrote: > >> I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's > >> fixes. And a few c++ failures with similar symptoms. I'm not certain > >> that it is due to this patch, but it's the likely suspect. > > Yes, it's that patch. > > > > This should fix most of those errors, but I haven't finished testing > > it, and can't commit it now anyway. > > > > with r11-5235 + this patch there are still quite a few fails on Darwin - > but > all seem to be the same ( so maybe only problem ;) ): > “sem_timedwait was not declared in this scope”. > > It looks like the semaphore header is optional in SUSv3 (AFAIK that’s still > the claimed edition for Darwin) - and although Darwin has the semaphore > header, it doesn’t seem to have an impl. of sem_timedwait. > > just: > int sem_trywait(sem_t *); > int sem_wait(sem_t *) ; > It probably depends on the _POSIX_TIMEOUTS option which MacOS doesn't support (optional in POSIX 2001, but not 2008). > >
Re: [PATCH] libstdc++: Add C++2a synchronization support
thanks for looking at this over the weekend. Jonathan Wakely via Gcc-patches wrote: On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++ wrote: I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's fixes. And a few c++ failures with similar symptoms. I'm not certain that it is due to this patch, but it's the likely suspect. Yes, it's that patch. This should fix most of those errors, but I haven't finished testing it, and can't commit it now anyway. with r11-5235 + this patch there are still quite a few fails on Darwin - but all seem to be the same ( so maybe only problem ;) ): “sem_timedwait was not declared in this scope”. It looks like the semaphore header is optional in SUSv3 (AFAIK that’s still the claimed edition for Darwin) - and although Darwin has the semaphore header, it doesn’t seem to have an impl. of sem_timedwait. just: int sem_trywait(sem_t *); int sem_wait(sem_t *) ; thanks Iain
Re: [Committed] patch fixing LRA crash on s390x
On Sun, Nov 15, 2020 at 12:08:22PM -0500, Vladimir Makarov via Gcc-patches
wrote:
> --- a/gcc/lra.c
> +++ b/gcc/lra.c
> @@ -1903,15 +1903,23 @@ lra_process_new_insns (rtx_insn *insn, rtx_insn
> *before, rtx_insn *after,
> {
> /* We already made the edge no-critical in ira.c::ira */
> lra_assert (!EDGE_CRITICAL_P (e));
> - rtx_insn *tmp = BB_HEAD (e->dest);
> + rtx_insn *curr, *tmp = BB_HEAD (e->dest);
> if (LABEL_P (tmp))
> tmp = NEXT_INSN (tmp);
> if (NOTE_INSN_BASIC_BLOCK_P (tmp))
> tmp = NEXT_INSN (tmp);
> - start_sequence ();
> - for (rtx_insn *curr = after;
> - curr != NULL_RTX;
> + for (curr = tmp;
> + curr != NULL
> +&& (!INSN_P (curr) || BLOCK_FOR_INSN (curr) == e->dest);
>curr = NEXT_INSN (curr))
> + ;
> + /* Do not put reload insns if it is the last BB
> +without actual insns. In this case the reload insns
> +can get null BB after emitting. */
What the above loop does doesn't match what the comment says.
Because the loop will result in curr == NULL even if e->dest contains any
number of actual insns, only cares about whether e->dest's next_bb has no
actual insns or there is no next bb at all.
Did you mean something like
for (curr = tmp; curr != NULL; curr = NEXT_INSN (curr))
if (INSN_P (curr))
break;
(i.e. it would be non-NULL if the e->dest bb contains any actual insns, or
if it isn't the last bb and there is at least one further bb with actual
insns after it)?
See PR97933 for details.
Jakub
[PATCH] Avoid atomic for guard acquire when that is expensive
Hi,
this avoids the need to use -fno-threadsafe-statics on
arm-none-eabi or working around that problem by supplying
a dummy __sync_synchronize function which might
just lead to silent code failure of the worst kind
(non-reproducable, racy) at runtime, as was pointed out
on previous discussions here.
When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.
This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.
Regression tested successfully on arm-none-eabi with newlib-3.3.0.
Is it OK for trunk?
Thanks
Bernd.
From 9fd070407408cf10789f5e9eb5ddda2fb3798e6f Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Sun, 22 Nov 2020 08:11:14 +0100
Subject: [PATCH] Avoid atomic for guard acquire when that is expensive
When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.
This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.
gcc:
2020-11-22 Bernd Edlinger
* target.def (guard_atomic_expensive): New hook.
* doc/tm.texi: Document TARGET_CXX_GUARD_ATOMIC_EXPENSIVE.
* doc/tm.texi.in: Likewise.
* config/arm/arm.c (arm_cxx_guard_atomic_expensive): New callback.
gcc/cp:
2020-11-22 Bernd Edlinger
* decl2.c: (build_atomic_load_byte): Rename to...
(build_atomic_load_type): ... and add new parameter type.
(get_guard_cond): Skip the atomic here if that is expensive.
Use the correct type for the atomic load on certain targets.
---
gcc/config/arm/arm.c | 13 +
gcc/cp/decl2.c | 12
gcc/doc/tm.texi | 7 +++
gcc/doc/tm.texi.in | 2 ++
gcc/target.def | 10 ++
5 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 04190b1..04ca1fe 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -235,6 +235,7 @@ static rtx arm_dwarf_register_span (rtx);
static tree arm_cxx_guard_type (void);
static bool arm_cxx_guard_mask_bit (void);
+static bool arm_cxx_guard_atomic_expensive (void);
static tree arm_get_cookie_size (tree);
static bool arm_cookie_has_size (void);
static bool arm_cxx_cdtor_returns_this (void);
@@ -593,6 +594,9 @@ static const struct attribute_spec arm_attribute_table[] =
#undef TARGET_CXX_GUARD_MASK_BIT
#define TARGET_CXX_GUARD_MASK_BIT arm_cxx_guard_mask_bit
+#undef TARGET_CXX_GUARD_ATOMIC_EXPENSIVE
+#define TARGET_CXX_GUARD_ATOMIC_EXPENSIVE arm_cxx_guard_atomic_expensive
+
#undef TARGET_CXX_GET_COOKIE_SIZE
#define TARGET_CXX_GET_COOKIE_SIZE arm_get_cookie_size
@@ -28882,6 +28886,15 @@ arm_cxx_guard_mask_bit (void)
}
+/* Return true if atomics involve a call to __sync_synchronize. */
+
+static bool
+arm_cxx_guard_atomic_expensive (void)
+{
+ return TARGET_AAPCS_BASED && !TARGET_HAVE_DMB && !TARGET_HAVE_DMB_MCR;
+}
+
+
/* The EABI specifies that all array cookies are 8 bytes long. */
static tree
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 1bc7b7e..e2b29a6 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -3300,15 +3300,15 @@ get_guard (tree decl)
/* Return an atomic load of src with the appropriate memory model. */
static tree
-build_atomic_load_byte (tree src, HOST_WIDE_INT model)
+build_atomic_load_type (tree src, HOST_WIDE_INT model, tree type)
{
- tree ptr_type = build_pointer_type (char_type_node);
+ tree ptr_type = build_pointer_type (type);
tree mem_model = build_int_cst (integer_type_node, model);
tree t, addr, val;
unsigned int size;
int fncode;
- size = tree_to_uhwi (TYPE_SIZE_UNIT (char_type_node));
+ size = tree_to_uhwi (TYPE_SIZE_UNIT (type));
fncode = BUILT_IN_ATOMIC_LOAD_N + exact_log2 (size) + 1;
t = builtin_decl_implicit ((enum built_in_function) fncode);
@@ -3350,8 +3350,12 @@ get_guard_cond (tree guard, bool thread_safe)
if (!thread_safe)
guard = get_guard_bits (guard);
+ else if (targetm.cxx.guard_atomic_expensive ())
+guard = integer_zero_node;
else
-guard = build_atomic_load_byte (guard, MEMMODEL_ACQUIRE);
+guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE,
+targetm.cxx.guard_mask_bit ()
+? TREE_TYPE (guard) : char_type_node);
/* Mask off all but the low bit. */
if (targetm.cxx.guard_mask_bit ())
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 2b88f78..92215cf 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -10728,6 +10728,13 @@ This hook determines how guard variables are used. It should return
@code{true} indicates that only the least significant bit should be used.
@end deftypefn
+@deftypefn {Target Hook} bool TARGET_CXX_GUARD_ATOMIC_EXPENSIVE (void)
+This
