On 01/19/2012 06:26 AM, Uros Bizjak wrote:
2012-01-18 Uros Bizjak ubiz...@gmail.com
PR libitm/51830
* builtin-types.def (BT_FN_UINT_UINT_VAR): New.
* gtm-builtins.def (BUILT_IN_TM_START): Declare as BT_FN_UINT_UINT_VAR.
libitm/ChangeLog:
2012-01-18 Uros Bizjak
On 01/20/2012 12:51 AM, Uros Bizjak wrote:
OTOH, in GTM_beginTransaction we can
still access other variable arguments through the pointer to CFA.
Well, no, not really.
If we really want GTM_beginTransaction to have access to the
variadic portions, we'll need to have the sjlj stub pass in
a
On Wed, 2012-01-18 at 22:25 +0100, Uros Bizjak wrote:
On Wed, Jan 18, 2012 at 10:16 PM, Patrick Marlier
patrick.marl...@gmail.com wrote:
IMO, whatever the future decision would be, we shouldn't leave one
part of the compiler out-of-sync from the other. Proposed patch fixes
_current_
On Thu, 2012-01-19 at 13:24 +0100, Torvald Riegel wrote:
Note that if we remove the regparm, we should also remove it on the
other functions associated with txn begin (GTM_beginTransaction etc.).
And update libitm.texi ...
On Thu, Jan 19, 2012 at 1:24 PM, Torvald Riegel trie...@redhat.com wrote:
The spec does say that all function should be regparm(2), but I agree
that the above is less confusing. The attribute is ignored, but
perhaps a comment would clear this confusion even more.
Uros, thanks for spotting
On 01/18/2012 02:26 PM, Uros Bizjak wrote:
Hello!
Attached three-liner patch fixes the declaration of BUILT_IN_TM_START
(AKA _ITM_beginTransaction) to match its declaration from the libitm.h
ABI. This mismatch was the core problem for FAILed
libitm.c/mem(cpy|set)-1.c execution tests on x86_32.
On Wed, Jan 18, 2012 at 8:44 PM, Patrick Marlier
patrick.marl...@gmail.com wrote:
There was some discussion on where to pass arguments to regparm
decorated vararg functions. Well, as the ABI is pretty clear - regparm
should be ignored in this case, so all function arguments have to be
passed
On Wed, Jan 18, 2012 at 10:16 PM, Patrick Marlier
patrick.marl...@gmail.com wrote:
IMO, whatever the future decision would be, we shouldn't leave one
part of the compiler out-of-sync from the other. Proposed patch fixes
_current_ situation, where in the future, it is expected that compiler
