Hello everybody,
(I'm not a member, CC me in replies)
I'm trying to force gcc to trust me that my memory allocation function
is returning aligned memory. So far I tried everything I found with no
luck. What I have is:
#define MP_ALIGN (2*sizeof(size_t)<__alignof__(long
double)?__alignof__(l
On Tue, 28 May 2013, Anton Titov wrote:
I'm trying to force gcc to trust me that my memory allocation function is
returning aligned memory. So far I tried everything I found with no luck.
Did you try using __builtin_assume_aligned?
--
Marc Glisse
On 28.05.2013 12:19, Marc Glisse wrote:
On Tue, 28 May 2013, Anton Titov wrote:
I'm trying to force gcc to trust me that my memory allocation
function is returning aligned memory. So far I tried everything I
found with no luck.
Did you try using __builtin_assume_aligned?
I've tried it now a
On Tue, May 28, 2013 at 12:15:58PM +0300, Anton Titov wrote:
> Hello everybody,
>
> (I'm not a member, CC me in replies)
>
> I'm trying to force gcc to trust me that my memory allocation
> function is returning aligned memory. So far I tried everything I
> found with no luck. What I have is:
>
s
On 28.05.2013 12:35, Ondřej Bílka wrote:
Did you tried if following gets optimized out?
(((long)atpr)%16 != 0) abort();
No, it is not, it generates:
406eb0: a8 0f test $0xf,%al
406eb2: 48 89 44 24 58 mov%rax,0x58(%rsp) // unrelated
406eb7
Hello,
I'm using a machine where it is instaled gfortran 4.5.1. I'd like to know
if there are serious bugs solved from that version. Optionally, I would be
interested also in how much optimization has been improved since that
version.
How can I reach that information?
Thanks
On 05/28/2013 12:20 AM, Ryan Johnson wrote:
> Hi all,
>
> (please CC me in replies, not a list member)
>
> I have a large C++ app that throws exceptions to unwind anywhere from
> 5-20 stack frames when an error prevents the request from being served
> (which happens rather frequently). Works fine
On 2013-05-28 11:55 , lluvia_li...@lavabit.com wrote:
How can I reach that information?
http://gcc.gnu.org
See the section 'Release Series and Status'.
Diego.
On 05/28/2013 08:09 PM, Václav Zeman wrote:
If the bottleneck is really in glibc, then you should probably ask them
to fix it. Could the mutex be changed rwlock instead?
rwlocks don't eliminate hardware contention, so I doubt they'd be a win
here.
You'd need brlocks or some RCU-like approac
On Mon, May 27, 2013 at 3:20 PM, Ryan Johnson
wrote:
>
> I have a large C++ app that throws exceptions to unwind anywhere from 5-20
> stack frames when an error prevents the request from being served (which
> happens rather frequently). Works fine single-threaded, but performance is
> terrible for
On 28/05/2013 8:47 PM, Ian Lance Taylor wrote:
On Mon, May 27, 2013 at 3:20 PM, Ryan Johnson
wrote:
I have a large C++ app that throws exceptions to unwind anywhere from 5-20
stack frames when an error prevents the request from being served (which
happens rather frequently). Works fine single-t
On Tue, May 28, 2013 at 09:19:48PM -0400, Ryan Johnson wrote:
> On 28/05/2013 8:47 PM, Ian Lance Taylor wrote:
> >On Mon, May 27, 2013 at 3:20 PM, Ryan Johnson
> > wrote:
> >>I'm bringing the issue up here, rather than filing a bug, because I'm not
> >>sure whether this is an oversight, a known pro
On Tue, May 28, 2013 at 6:19 PM, Ryan Johnson
wrote:
>
> That last point makes me really wonder why we bother grabbing the mutex
> during unwind at all... at the very least, it would seem profitable to
> verify the object header cache at throw time---perhaps using the nadds/nsubs
> trick---and ref
On 28/05/2013 11:05 PM, Alan Modra wrote:
On Tue, May 28, 2013 at 09:19:48PM -0400, Ryan Johnson wrote:
On 28/05/2013 8:47 PM, Ian Lance Taylor wrote:
On Mon, May 27, 2013 at 3:20 PM, Ryan Johnson
wrote:
I'm bringing the issue up here, rather than filing a bug, because I'm not
sure whether th
On Tue, May 28, 2013 at 8:50 PM, Ryan Johnson
wrote:
>
> For example, it should be reasonably safe to let __cxa_allocate_exception
> call dl_iterate_phdr in order to build a list of object headers valid at the
> time unwind begins. It already calls malloc, so allocating space for a cache
> (holdin
On 28/05/2013 11:49 PM, Ian Lance Taylor wrote:
On Tue, May 28, 2013 at 6:19 PM, Ryan Johnson
wrote:
That last point makes me really wonder why we bother grabbing the mutex
during unwind at all... at the very least, it would seem profitable to
verify the object header cache at throw time---perh
On 29/05/2013 12:01 AM, Ian Lance Taylor wrote:
On Tue, May 28, 2013 at 8:50 PM, Ryan Johnson
wrote:
For example, it should be reasonably safe to let __cxa_allocate_exception
call dl_iterate_phdr in order to build a list of object headers valid at the
time unwind begins. It already calls malloc
2013/5/29 Diego Novillo :
> On 2013-05-28 11:55 , lluvia_li...@lavabit.com wrote:
>>
>> How can I reach that information?
>
>
> http://gcc.gnu.org
>
> See the section 'Release Series and Status'.
>
>
> Diego.
>From the section, you can find the information by
reviewing the 'changes' of each mainta
18 matches
Mail list logo
