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 diffe
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 compl
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
co
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(); // fugl
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])
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 8
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
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
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 generi
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 mat
> 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
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 3
12 matches
Mail list logo
