On Thu, Feb 12, 2015 at 06:55:30PM -0500, Rich Felker wrote:
> On Fri, Feb 13, 2015 at 10:12:11AM +1030, Alan Modra wrote:
> > I posted support for TLSDESC on powerpc back in 2009 (search for
> > powerpc _tls_get_addr call optimization). The patch wasn't reviewed,
> > and I didn't push it because
On Fri, Feb 13, 2015 at 10:12:11AM +1030, Alan Modra wrote:
> On Thu, Feb 12, 2015 at 12:07:24PM -0500, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 08:56:26AM -0800, H.J. Lu wrote:
> > > On Thu, Feb 12, 2015 at 8:11 AM, Jakub Jelinek wrote:
> > > > On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich
On Thu, Feb 12, 2015 at 12:07:24PM -0500, Rich Felker wrote:
> On Thu, Feb 12, 2015 at 08:56:26AM -0800, H.J. Lu wrote:
> > On Thu, Feb 12, 2015 at 8:11 AM, Jakub Jelinek wrote:
> > > On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> > >> On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulri
On Thu, Feb 12, 2015 at 06:23:12PM +, Andrew Haley wrote:
> On 02/12/2015 04:16 PM, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 05:11:45PM +0100, Jakub Jelinek wrote:
> >> On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> >>>
> >>> This usage is supposed to be deprecated. Why is
On 12-02-15 14:57, Michael Matz wrote:
Hi,
On Wed, 11 Feb 2015, Tom de Vries wrote:
My idea was to not generate temporaries and hence copies for
non-scalar types, but rather construct the "result" of va_arg directly
into the original LHS (that would then also trivially solve the
problem of nno
Snapshot gcc-4.8-20150212 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 02/12/2015 04:16 PM, Rich Felker wrote:
> On Thu, Feb 12, 2015 at 05:11:45PM +0100, Jakub Jelinek wrote:
>> On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
>>>
>>> This usage is supposed to be deprecated. Why isn't libgomp using
>>> TLSDESC/gnu2 model?
>>
>> Because it is significan
On Thu, Feb 12, 2015 at 08:56:26AM -0800, H.J. Lu wrote:
> On Thu, Feb 12, 2015 at 8:11 AM, Jakub Jelinek wrote:
> > On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> >> On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> >> > Hello,
> >> >
> >> > we're running into a pr
> Hello All:
>
> The large functions are the important part of high performance application.
> They contribute to performance bottleneck with many
> respect. Some of the large hot functions are frequently executed but many
> regions inside the functions are cold regions. The large
> Function blo
On Thu, Feb 12, 2015 at 8:11 AM, Jakub Jelinek wrote:
> On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
>> On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
>> > Hello,
>> >
>> > we're running into a problem related to use of initial-exec access to
>> > TLS variables in
On Thu, Feb 12, 2015 at 05:11:45PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> > On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> > > Hello,
> > >
> > > we're running into a problem related to use of initial-exec access to
> > > TLS
On Thu, Feb 12, 2015 at 11:09:59AM -0500, Rich Felker wrote:
> On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> > Hello,
> >
> > we're running into a problem related to use of initial-exec access to
> > TLS variables in dynamically-loaded libraries. Now, in general, this
> > is a
On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> Hello,
>
> we're running into a problem related to use of initial-exec access to
> TLS variables in dynamically-loaded libraries. Now, in general, this
> is actually not supported. However, there seems to an "inofficial"
> extensi
On Thu, Feb 12, 2015 at 06:42:17PM +0300, Ilya Verbin wrote:
> Hi,
>
> On Wed, Feb 11, 2015 at 21:33:47 -0800, Nicholas Yue wrote:
> > I would like to find out if this is the correct forum to
> > ask/discuss about GCC 5's OpenMP 4.0 implementation, in particular
> > the new accelerator feature
Alexander Monakov wrote:
>
> There's a pending patch for glibc that addresses this issue among others:
> https://sourceware.org/ml/libc-alpha/2014-11/msg00469.html
>
> ([BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS
> limit)
Ah, indeed, that would fix the issue! Thanks
Hi,
On Wed, Feb 11, 2015 at 21:33:47 -0800, Nicholas Yue wrote:
> I would like to find out if this is the correct forum to
> ask/discuss about GCC 5's OpenMP 4.0 implementation, in particular
> the new accelerator feature which from what I understand, allows the
> compute to be offloaded to ex
There's a pending patch for glibc that addresses this issue among others:
https://sourceware.org/ml/libc-alpha/2014-11/msg00469.html
([BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS
limit)
Alexander
On Thu, Feb 12, 2015 at 3:18 PM, Ulrich Weigand wrote:
> Hello,
>
> we're running into a problem related to use of initial-exec access to
> TLS variables in dynamically-loaded libraries. Now, in general, this
> is actually not supported. However, there seems to an "inofficial"
> extension that a
On Thu, Feb 12, 2015 at 04:18:57PM +0100, Ulrich Weigand wrote:
> we're running into a problem related to use of initial-exec access to
> TLS variables in dynamically-loaded libraries. Now, in general, this
> is actually not supported. However, there seems to an "inofficial"
> extension that allo
Hello,
we're running into a problem related to use of initial-exec access to
TLS variables in dynamically-loaded libraries. Now, in general, this
is actually not supported. However, there seems to an "inofficial"
extension that allows selected system libraries to use small amounts
of static TLS
Hello All:
The unaligned array access are the blocking factor in the vectorization. This
is due to unaligned load and stores with respect to
SIMD instructions are costly operations.
To enable the vectorizations for unaligned array access the loop peeling is
done to make the multiversioning of
Hi,
On Wed, 11 Feb 2015, Tom de Vries wrote:
> > My idea was to not generate temporaries and hence copies for
> > non-scalar types, but rather construct the "result" of va_arg directly
> > into the original LHS (that would then also trivially solve the
> > problem of nno-copyable types).
>
>
Hello All:
The large functions are the important part of high performance application.
They contribute to performance bottleneck with many
respect. Some of the large hot functions are frequently executed but many
regions inside the functions are cold regions. The large
Function blocks the functi
Hello,
I am trying to build a cross-compiler for arm, like I did so for years. I am
keen on not having depencies on libraries, so that the compiler can be used on
multiple systems.
Up until 4.9 the only depency is libc, I tried using the gcc-5-20150208
snapshot, and now I get depencies on the buil
On Thu, 2015-02-12 at 10:09 +, Ajit Kumar Agarwal wrote:
> Hello All:
>
> The Loop unrolling without good unrolling factor heuristics becomes the
> performance bottleneck. The Unrolling factor heuristics based on minimum
> Initiation interval is quite useful with respect to better ILP. The
Hello All:
The Loop unrolling without good unrolling factor heuristics becomes the
performance bottleneck. The Unrolling factor heuristics based on minimum
Initiation interval is quite useful with respect to better ILP. The minimum
Initiation interval based on recurrence and resource calculati
26 matches
Mail list logo
