Re: [C++14] Admit C++ keywords as literal suffixes.
Ed Smith-Rowland <3dw...@verizon.net> writes: > constexpr complex > operator"" if(); According to 2.14.8#10 this is ill-formed. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [C++14] Admit C++ keywords as literal suffixes.
On 18 June 2013 07:04, Ed Smith-Rowland wrote: > I understand that the literal operators for complex numbers for C++14 > faltered at least in part because of the perceived ugliness of the float > operator: > > constexpr complex > operator"" i_f(); // fugly > > The obvious choice > constexpr complex > operator"" if(); > > failed because 'if' is a keyword. The 'if' keyword can never be exposed in > this context either by usage in a literal or by explicit call. > > Allowing keywords as literal operator suffixes turns out to be a 6-liner if > gcc. I actually think *disallowing* them is a bit of a bug. (Not sure if > it was me or the standard). The standard disallowed them, but that was changed by DR 1473 so you can define operator ""if now (with no whitespace between the string-literal and suffix, IIUC) See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1473 IMHO you should implement exactly that resolution, not just a kluge to allow keywords.
Re: [C++14] Admit C++ keywords as literal suffixes.
On 18 June 2013 08:35, Andreas Schwab wrote: > According to 2.14.8#10 this is ill-formed. It's ill-formed for users to define it, but not ill-formed according to the language grammar, and the compiler would need to implement that grammar if operator""if gets added to the standard library (which could happen if an NB insists on the complex literals being in C++14, which can be done without the horrifically ugly i_f suffix now thanks to DR 1473.)
Re: Re: [C++14] Admit C++ keywords as literal suffixes.
On 06/18/13, Jonathan Wakely wrote: On 18 June 2013 07:04, Ed Smith-Rowland wrote: > I understand that the literal operators for complex numbers for C++14 > faltered at least in part because of the perceived ugliness of the float > operator: > > constexpr complex > operator"" i_f(); // fugly > > The obvious choice > constexpr complex > operator"" if(); > > failed because 'if' is a keyword. The 'if' keyword can never be exposed in > this context either by usage in a literal or by explicit call. > > Allowing keywords as literal operator suffixes turns out to be a 6-liner if > gcc. I actually think *disallowing* them is a bit of a bug. (Not sure if > it was me or the standard). The standard disallowed them, but that was changed by DR 1473 so you can define operator ""if now (with no whitespace between the string-literal and suffix, IIUC) See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1473 IMHO you should implement exactly that resolution, not just a kluge to allow keywords. I did not see this DR and that it passed. I just heard "something was in the works". This resolution seems eminently sensible. I withdraw my kludge and will work on DR 1473 implementation. Thanks, Ed
reload_cse_simplify_operands
If I'm running into
/* Figure out which alternative currently matches. */
if (! constrain_operands (1))
fatal_insn_not_found (insn);
'insn does not satisfy its constraints'
By the way, the instruction is
(insn 325 31 44 0 (nil) (set (mem/s:DI (plus:SI (reg:SI 58 r58 [884])
(symbol_ref:SI ("acpi_lr_stat"))) [7427 sec 0 space 0,
cmsmode 0 S8 A64])
(reg:DI 56 r56)) 67 {*movdi} (nil)
(nil))
Asking abstractly, does this mean that I need to support more
constraints in movdi, or does it mean that reload did something wrong?
Thanks,
- Hendrik
Re: reload_cse_simplify_operands
Little more information:
>From lreg:
[..]
(insn 31 30 44 0 0x2cf51000 (set (mem/s:DI (plus:SI (reg:SI 884)
(symbol_ref:SI ("acpi_lr_stat"))) [7427 sec 0 space 0,
cmsmode 0 S8 A64])
(const_int 0 [0x0])) 67 {*movdi} (insn_list 26 (nil))
(expr_list:REG_DEAD (reg:SI 884)
(nil)))
[..]
>From greg:
(insn 31 30 325 0 0x2cf51000 (set (reg:DI 56 r56)
(const_int 0 [0x0])) 67 {*movdi} (insn_list 26 (nil))
(nil))
(insn 325 31 44 0 (nil) (set (mem/s:DI (plus:SI (reg:SI 58 r58 [884])
(symbol_ref:SI ("acpi_lr_stat"))) [7427 sec 0 space 0,
cmsmode 0 S8 A64])
(reg:DI 56 r56)) 67 {*movdi} (nil)
(nil))
- Hendrik Greving
On Tue, Jun 18, 2013 at 8:43 AM, Hendrik Greving
wrote:
> If I'm running into
>
> /* Figure out which alternative currently matches. */
> if (! constrain_operands (1))
> fatal_insn_not_found (insn);
>
> 'insn does not satisfy its constraints'
>
> By the way, the instruction is
>
> (insn 325 31 44 0 (nil) (set (mem/s:DI (plus:SI (reg:SI 58 r58 [884])
> (symbol_ref:SI ("acpi_lr_stat"))) [7427 sec 0 space 0,
> cmsmode 0 S8 A64])
> (reg:DI 56 r56)) 67 {*movdi} (nil)
> (nil))
>
>
> Asking abstractly, does this mean that I need to support more
> constraints in movdi, or does it mean that reload did something wrong?
>
> Thanks,
> - Hendrik
Re: Libitm issues porting to POWER8 HTM
On Fri, 2013-06-14 at 19:44 -0500, Peter Bergner wrote: > I'm currently implementing support for hardware transactional memory in > the rs6000 backend for POWER8. Things seem to be mostly working, but I > have run into a few issues I'm wondering whether other people are seeing. > > For me, all of the libitm execution test cases in libitm/testsuite/libitm.c/ > compile and execute without error, except for reentrant.c, which hangs for me. > My gdb hasn't been ported to support HTM on Power yet, so debugging has been > slow, but what I've learned is, that my tbegin. instruction succeeds, but I > fail the test (meaning someone has the write lock) at beginend.cc:200: > > if (unlikely(serial_lock.is_write_locked())) > htm_abort(); > > ...so we abort the transaction. The failure is not persistent, so we do > not break out of the loop due to: > > if (!htm_abort_should_retry(ret)) > break; > > We then fall into the following code, where we hang trying to get the > read lock: > > serial_lock.read_lock(tx); > > I have yet to track down who has the write lock and why, but I am working > towards that. Talking with Andreas, he said he is seeing the same failure > on S390, so I'm wondering whether this might be a generic libitm issue > and it might hit Intel too. I think that this is a bug in libitm's HTM fastpath. What I suppose happens is that we have a relaxed outermost transaction that executes unsafe code (see reentrant.c), thus switches to serial-irrevocable mode, and then tries to start a nested transaction. The nested txn then observes in the HTM fastpath that there is a serial-mode txn already, but it never checks whether it is enclosed in an already serial outermost transaction. > Does anyone know whether this executes correctly > on Intel hardware with RTM? I don't know currently, but I suppose the bug should trigger there too (unless, for some reason, the nested txn always aborts immediately with RTM). > I'll note that if I hack the call to > htm_abort_should_retry(ret) so that we break of of the loop and fallback > to SW TM, then the test case executes correctly. That matches what I suppose the bug is. Please feel free to create a bug report. I will work on a patch. Torvald
Re: Libitm issues porting to POWER8 HTM
Peter Bergner writes: > > I have yet to track down who has the write lock and why, but I am working > towards that. Talking with Andreas, he said he is seeing the same failure > on S390, so I'm wondering whether this might be a generic libitm issue > and it might hit Intel too. Does anyone know whether this executes correctly > on Intel hardware with RTM? I'll note that if I hack the call to FWIW on a TSX system I get the following for libitm with current trunk. So no hangs on reentrant at least. Native configuration is x86_64-unknown-linux-gnu === libitm tests === Schedule of variations: unix Running target unix Running /home/ak/gcc/gcc/libitm/testsuite/libitm.c/c.exp ... PASS: libitm.c/cancel.c (test for excess errors) PASS: libitm.c/cancel.c execution test PASS: libitm.c/clone-1.c (test for excess errors) PASS: libitm.c/clone-1.c execution test PASS: libitm.c/dropref-2.c (test for excess errors) XFAIL: libitm.c/dropref-2.c execution test PASS: libitm.c/dropref.c (test for excess errors) XFAIL: libitm.c/dropref.c execution test PASS: libitm.c/memcpy-1.c (test for excess errors) PASS: libitm.c/memcpy-1.c execution test PASS: libitm.c/memset-1.c (test for excess errors) PASS: libitm.c/memset-1.c execution test PASS: libitm.c/notx.c (test for excess errors) PASS: libitm.c/notx.c execution test PASS: libitm.c/reentrant.c (test for excess errors) PASS: libitm.c/reentrant.c execution test PASS: libitm.c/simple-1.c (test for excess errors) PASS: libitm.c/simple-1.c execution test PASS: libitm.c/simple-2.c (test for excess errors) PASS: libitm.c/simple-2.c execution test PASS: libitm.c/stackundo.c (test for excess errors) PASS: libitm.c/stackundo.c execution test PASS: libitm.c/txrelease.c (test for excess errors) PASS: libitm.c/txrelease.c execution test Running /home/ak/gcc/gcc/libitm/testsuite/libitm.c++/c++.exp ... PASS: libitm.c++/dropref.C (test for excess errors) XFAIL: libitm.c++/dropref.C execution test PASS: libitm.c++/eh-1.C (test for excess errors) PASS: libitm.c++/eh-1.C execution test UNSUPPORTED: libitm.c++/static_ctor.C PASS: libitm.c++/throwdown.C (test for excess errors) === libitm Summary === # of expected passes26 # of expected failures 3 # of unsupported tests 1 -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: Libitm issues porting to POWER8 HTM
On Tue, 2013-06-18 at 11:22 -0700, Andi Kleen wrote: > Peter Bergner writes: > > > > I have yet to track down who has the write lock and why, but I am working > > towards that. Talking with Andreas, he said he is seeing the same failure > > on S390, so I'm wondering whether this might be a generic libitm issue > > and it might hit Intel too. Does anyone know whether this executes > > correctly > > on Intel hardware with RTM? I'll note that if I hack the call to > > FWIW on a TSX system I get the following for libitm with current > trunk. So no hangs on reentrant at least. Given Torvald's comment, can you verify whether your hw txn succeeds (all the way to commit) or whether it is failing and somehow skips the fall through code that is hanging for us (Power and S390)? Thanks! Peter
Re: Libitm issues porting to POWER8 HTM
On Tue, 2013-06-18 at 18:41 +0200, Torvald Riegel wrote: > On Fri, 2013-06-14 at 19:44 -0500, Peter Bergner wrote: > > I'll note that if I hack the call to > > htm_abort_should_retry(ret) so that we break of of the loop and fallback > > to SW TM, then the test case executes correctly. > > That matches what I suppose the bug is. > > Please feel free to create a bug report. I will work on a patch. Done. http://gcc.gnu.org/PR57643 Since this seems to pass on x86, let me know if you want me to test a patch on our power8 system. Peter
Re: Libitm issues porting to POWER8 HTM
> Given Torvald's comment, can you verify whether your hw txn succeeds > (all the way to commit) or whether it is failing and somehow skips > the fall through code that is hanging for us (Power and S390)? All the 3 transactions in reentrant.c abort. That's not surprising, because there are usually lots of aborts in the startup phase of programs, and the test doesn't use a loop. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: reload_cse_simplify_operands
On Tue, Jun 18, 2013 at 8:43 AM, Hendrik Greving
wrote:
> If I'm running into
>
> /* Figure out which alternative currently matches. */
> if (! constrain_operands (1))
> fatal_insn_not_found (insn);
>
> 'insn does not satisfy its constraints'
>
> By the way, the instruction is
>
> (insn 325 31 44 0 (nil) (set (mem/s:DI (plus:SI (reg:SI 58 r58 [884])
> (symbol_ref:SI ("acpi_lr_stat"))) [7427 sec 0 space 0,
> cmsmode 0 S8 A64])
> (reg:DI 56 r56)) 67 {*movdi} (nil)
> (nil))
>
>
> Asking abstractly, does this mean that I need to support more
> constraints in movdi, or does it mean that reload did something wrong?
It means that your predicate accepts operands that do not match your
constraints. So you need to support more constraints or you need to
tighten your predicates.
Ian
