Hi,
On Wed, 2017-07-05 at 02:02 +0200, Geza Herman wrote:
>
> Here's what happens: in callInitA(), an Object put onto the stack (which
> has a const member variable, initialized to 0). Then somefunction called
> (which is intentionally not defined). Then ~Object() is called, which
> has an "if
Hi GCC developers,
There was
extern GTY(()) struct asm_node *asm_nodes;
for GCC v4.x, but how to migrate it for v6.x? there is no asm_nodes
deprecated log in ChangeLog-201X nor git log cgraph.h... please give me
some hint, thanks a lot!
--
Regards,
Leslie Zhai https://reviews.llvm.org/p/xia
Hi Leslie,
On Wed, Jul 05, 2017 at 05:36:15PM +0800, Leslie Zhai wrote:
> There was
>
> extern GTY(()) struct asm_node *asm_nodes;
>
> for GCC v4.x, but how to migrate it for v6.x? there is no asm_nodes
> deprecated log in ChangeLog-201X nor git log cgraph.h... please give me
> some hint, than
On 5 July 2017 at 10:13, Oleg Endo wrote:
> Hi,
>
> On Wed, 2017-07-05 at 02:02 +0200, Geza Herman wrote:
>>
>> Here's what happens: in callInitA(), an Object put onto the stack (which
>> has a const member variable, initialized to 0). Then somefunction called
>> (which is intentionally not defined
On 07/05/2017 01:14 PM, Jonathan Wakely wrote:
I think the reason it's not optimized away is for this case:
void somefunction(const Object& object);
{
void* p = &object;
object.~Object();
new(p) Object();
}
This means that after calling someFunction there could be a different
object at
On Wed, 2017-07-05 at 12:14 +0100, Jonathan Wakely wrote:
>
> No, that would be undefined behaviour. The data member is defined as
> const, so it's not possible to write to that member without undefined
> behaviour. A variable defined with a const type is not the same as a
> variable accessed thro
On 07/04/2017 06:02 PM, Geza Herman wrote:
Hi,
I've included a small program at the end of my email.
Here's what happens: in callInitA(), an Object put onto the stack (which
has a const member variable, initialized to 0). Then somefunction called
(which is intentionally not defined). Then ~Obje
On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
GCCs older than GCC 4.9.4:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
continue to work even if vector instructions are used by functions called
from __tls_get_addr, which assumes 16-byte stack alignment as specif
On 07/05/2017 11:38 AM, H.J. Lu wrote:
> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
> GCCs older than GCC 4.9.4:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>
> continue to work even if vector instructions are used by functions called
> from __tls_get_
On 05/07/17 16:38, H.J. Lu wrote:
> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
> GCCs older than GCC 4.9.4:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>
> continue to work even if vector instructions are used by functions called
> from __tls_get_addr,
On Wed, Jul 05, 2017 at 08:38:50AM -0700, H.J. Lu wrote:
> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
> GCCs older than GCC 4.9.4:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>
> continue to work even if vector instructions are used by functions called
On 07/05/2017 05:38 PM, H.J. Lu wrote:
> We are considering to add an alternative interface, ___tls_get_addr, to
> glibc, which doesn't realign stack. Compilers, which properly align stack
> for TLS, call generate call to ___tls_get_addr, instead of __tls_get_addr,
> if ___tls_get_addr is availabl
On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy wrote:
> On 05/07/17 16:38, H.J. Lu wrote:
>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
>> GCCs older than GCC 4.9.4:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>>
>> continue to work even if vector inst
On Wed, Jul 5, 2017 at 8:51 AM, Carlos O'Donell wrote:
> On 07/05/2017 11:38 AM, H.J. Lu wrote:
>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
>> GCCs older than GCC 4.9.4:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>>
>> continue to work even if vect
On Wed, Jul 5, 2017 at 9:27 AM, Florian Weimer wrote:
> On 07/05/2017 06:21 PM, H.J. Lu wrote:
>> On Wed, Jul 5, 2017 at 9:18 AM, Florian Weimer wrote:
>>> On 07/05/2017 06:17 PM, H.J. Lu wrote:
On Wed, Jul 5, 2017 at 9:09 AM, Florian Weimer wrote:
> On 07/05/2017 05:38 PM, H.J. Lu wrot
On 07/05/2017 01:26 PM, Geza Herman wrote:
On 07/05/2017 01:14 PM, Jonathan Wakely wrote:
I think the reason it's not optimized away is for this case:
void somefunction(const Object& object);
{
void* p = &object;
object.~Object();
new(p) Object();
}
This means that after calling someF
On Wed, Jul 5, 2017 at 12:14 PM, Jonathan Wakely wrote:
> On 5 July 2017 at 10:13, Oleg Endo wrote:
>> Hi,
>>
>> On Wed, 2017-07-05 at 02:02 +0200, Geza Herman wrote:
>>>
>>> Here's what happens: in callInitA(), an Object put onto the stack (which
>>> has a const member variable, initialized to 0)
17 matches
Mail list logo
