On 01/26/2012 12:36 AM, Aldy Hernandez wrote:
> I would like another approval, just in case you disagree with the way I
> changed the dummy declarations in the LTO testsuite.
Still ok.
r~
On Wed, Jan 25, 2012 at 3:27 PM, Aldy Hernandez wrote:
> On 01/25/12 08:23, Richard Guenther wrote:
>>
>> On Wed, Jan 25, 2012 at 2:00 PM, Aldy Hernandez wrote:
>>>
>>>
> Second, it seems that by design, LTO prefers builtins to user-provided
> versions of them. In particular, lto_symtab_
On 01/25/12 08:23, Richard Guenther wrote:
On Wed, Jan 25, 2012 at 2:00 PM, Aldy Hernandez wrote:
Second, it seems that by design, LTO prefers builtins to user-provided
versions of them. In particular, lto_symtab_prevailing_decl() stipulates
that builtins are their own prevailing decl. So e
On Wed, Jan 25, 2012 at 2:00 PM, Aldy Hernandez wrote:
>
>>> Second, it seems that by design, LTO prefers builtins to user-provided
>>> versions of them. In particular, lto_symtab_prevailing_decl() stipulates
>>> that builtins are their own prevailing decl. So even if we lowered TM
>>> before LT
On 01/24/12 17:24, Richard Henderson wrote:
On 01/25/2012 10:16 AM, Aldy Hernandez wrote:
The attached patch fixes the ICE in the PR, though it won't do what
the user ultimately wants to do, given the limitations described.
Perhaps we could create another PR and tag it with an enhancement
reques
Second, it seems that by design, LTO prefers builtins to user-provided
versions of them. In particular, lto_symtab_prevailing_decl() stipulates
that builtins are their own prevailing decl. So even if we lowered TM
before LTO streaming, user provided builtins wouldn't be preferred (and thus
inl
On Wed, Jan 25, 2012 at 12:16 AM, Aldy Hernandez wrote:
> The problem here is that -flto cannot equate the instrumentation functions
> being generated with a user supplied version of the library functions. This
> would happen if the user tried to link a transactional program with libitm
> with -f
On 01/25/2012 10:16 AM, Aldy Hernandez wrote:
> The attached patch fixes the ICE in the PR, though it won't do what
> the user ultimately wants to do, given the limitations described.
> Perhaps we could create another PR and tag it with an enhancement
> request.
An enhancement request pr sounds go
The problem here is that -flto cannot equate the instrumentation
functions being generated with a user supplied version of the library
functions. This would happen if the user tried to link a transactional
program with libitm with -flto (as in -fwhole-program, etc).
This is an easy problem to
