05.06.2015 1:34, Andi Kleen writes:
> Ondřej Bílka writes:
>
>> As I commented on libc-alpha list that for string functions a header
>> expansion is better than builtins from maintainance perspective and also
>> that a header is lot easier to write and review than doing that in gcc
>> Jeff said t
On Thu, Jun 04, 2015 at 09:06:40PM +0100, Richard Earnshaw wrote:
> On 04/06/15 20:57, Jakub Jelinek wrote:
> > On Thu, Jun 04, 2015 at 06:36:33PM +0200, Ondřej Bílka wrote:
> >> On Thu, Jun 04, 2015 at 04:01:50PM +, Joseph Myers wrote:
> >>> On Thu, 4 Jun 2015, Richard Earnshaw wrote:
> >>>
>
On Thu, Jun 04, 2015 at 09:57:59PM +0200, Jakub Jelinek wrote:
> On Thu, Jun 04, 2015 at 06:36:33PM +0200, Ondřej Bílka wrote:
> > On Thu, Jun 04, 2015 at 04:01:50PM +, Joseph Myers wrote:
> > > On Thu, 4 Jun 2015, Richard Earnshaw wrote:
> > >
> > > > > Change that into
> > > > >
> > > > > i
Snapshot gcc-4.8-20150604 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150604/
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
I'm away on PTO for the next couple weeks, which likely means that patch
review times will suffer. Normally I'd ask Richard Henderson to help
cover, but he's going to be on PTO as well.
It's probably safe to assume that when I return there will be a bit of a
patch backlog and I'll have a hi
Ondřej Bílka writes:
> As I commented on libc-alpha list that for string functions a header
> expansion is better than builtins from maintainance perspective and also
> that a header is lot easier to write and review than doing that in gcc
> Jeff said that it belongs to gcc. When I asked about be
On 04/06/15 20:57, Jakub Jelinek wrote:
> On Thu, Jun 04, 2015 at 06:36:33PM +0200, Ondřej Bílka wrote:
>> On Thu, Jun 04, 2015 at 04:01:50PM +, Joseph Myers wrote:
>>> On Thu, 4 Jun 2015, Richard Earnshaw wrote:
>>>
> Change that into
>
> int foo(char *s)
> {
> int l = st
On Thu, Jun 04, 2015 at 06:36:33PM +0200, Ondřej Bílka wrote:
> On Thu, Jun 04, 2015 at 04:01:50PM +, Joseph Myers wrote:
> > On Thu, 4 Jun 2015, Richard Earnshaw wrote:
> >
> > > > Change that into
> > > >
> > > > int foo(char *s)
> > > > {
> > > > int l = strlen (s);
> > > > char *p = m
I start with simplest suggestion which is precomputing constant arguments
like saving multiplication cost in strchr with:
char *strchr_c(char *x, unsigned long u);
#define strchr(x,c) \
(__builtin_constant_p(c) ? strchr_c (x, c * (~0ULL / 255)) : strchr (x,c))
Then I am working on using constan
On Thu, Jun 04, 2015 at 04:01:50PM +, Joseph Myers wrote:
> On Thu, 4 Jun 2015, Richard Earnshaw wrote:
>
> > > Change that into
> > >
> > > int foo(char *s)
> > > {
> > > int l = strlen (s);
> > > char *p = memchr (s, 'a', l);
> > > return p+l;
> > > }
> > >
> >
> > Which is still me
Joseph Myers writes:
> On Thu, 4 Jun 2015, Richard Earnshaw wrote:
>
>> > Change that into
>> >
>> > int foo(char *s)
>> > {
>> > int l = strlen (s);
>> > char *p = memchr (s, 'a', l);
>> > return p+l;
>> > }
>> >
>>
>> Which is still meaningless if 'a' does not appear in s => when the
>
On Thu, 4 Jun 2015, Richard Earnshaw wrote:
> > Change that into
> >
> > int foo(char *s)
> > {
> > int l = strlen (s);
> > char *p = memchr (s, 'a', l);
> > return p+l;
> > }
> >
>
> Which is still meaningless if 'a' does not appear in s => when the
> result is NULL + l.
>
> In fact, un
On 04/06/15 15:23, Ondřej Bílka wrote:
> On Thu, Jun 04, 2015 at 02:59:20PM +0200, Jakub Jelinek wrote:
>> On Thu, Jun 04, 2015 at 02:53:31PM +0200, Ondřej Bílka wrote:
>>> On Thu, Jun 04, 2015 at 02:33:19PM +0200, Jakub Jelinek wrote:
On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wro
On Thu, Jun 4, 2015 at 11:17 PM, Andi Kleen wrote:
>> Rather than just a sequence of NOP's, should the first NOP be a
>> unconditional branch to the beginning of the real function? I don't
>> know if this applies to AArch64 cpus, but I believe some cpus can handle
>> such branches already in the
> Rather than just a sequence of NOP's, should the first NOP be a
> unconditional branch to the beginning of the real function? I don't
> know if this applies to AArch64 cpus, but I believe some cpus can handle
> such branches already in the decode unit, thus avoiding any extra cycles
> for skippi
On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
> On Thu, 4 Jun 2015, Ondřej Bílka wrote:
>
> > As I commented on libc-alpha list that for string functions a header
> > expansion is better than builtins from maintainance perspective and also
> > that a header is lot easier to write a
On Thu, Jun 04, 2015 at 02:59:20PM +0200, Jakub Jelinek wrote:
> On Thu, Jun 04, 2015 at 02:53:31PM +0200, Ondřej Bílka wrote:
> > On Thu, Jun 04, 2015 at 02:33:19PM +0200, Jakub Jelinek wrote:
> > > On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
> > > > > Again is this worth a gcc p
On 06/04/2015 06:33 AM, Jakub Jelinek wrote:
On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
Again is this worth a gcc pass?
This isn't a matter of compiler passes; it's additional checks in existing
built-in function handling. Maybe that built-in function handling should
move t
On Thu, Jun 04, 2015 at 02:53:31PM +0200, Ondřej Bílka wrote:
> On Thu, Jun 04, 2015 at 02:33:19PM +0200, Jakub Jelinek wrote:
> > On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
> > > > Again is this worth a gcc pass?
> > >
> > > This isn't a matter of compiler passes; it's addition
On Thu, Jun 04, 2015 at 02:33:19PM +0200, Jakub Jelinek wrote:
> On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
> > > Again is this worth a gcc pass?
> >
> > This isn't a matter of compiler passes; it's additional checks in existing
> > built-in function handling. Maybe that built
On Thu, Jun 04, 2015 at 12:26:03PM +, Joseph Myers wrote:
> > Again is this worth a gcc pass?
>
> This isn't a matter of compiler passes; it's additional checks in existing
> built-in function handling. Maybe that built-in function handling should
> move to the match-and-simplify infrastruc
On Thu, 4 Jun 2015, Ondřej Bílka wrote:
> As I commented on libc-alpha list that for string functions a header
> expansion is better than builtins from maintainance perspective and also
> that a header is lot easier to write and review than doing that in gcc
> Jeff said that it belongs to gcc. Whe
Hello world,
Assume I want to calculate a dot product,
s = sum(a[i]*b[i], i=1..n)
The order of summation in this case should be arbitrary.
Currently, the way to do this is to write out an explicit loop
(either by by the user or by the compliler, such as a DOT_PRODUCT)
and specify the options (f
Status
==
I plan to close the GCC 4.8 branch with a GCC 4.8.5 release around
June 19th which means a release candidate in about a week. This
is the last chance to get some regression fixes backported - please
concentrate on important and safe fixes here.
Quality Data
Priority
As I commented on libc-alpha list that for string functions a header
expansion is better than builtins from maintainance perspective and also
that a header is lot easier to write and review than doing that in gcc
Jeff said that it belongs to gcc. When I asked about benefits he
couldn't say any so
On 03/06/15 23:55, Stephen Cross wrote:
> Hello,
>
> I noticed the following comment in the GCC source (
> https://github.com/gcc-mirror/gcc/blob/7c62dfbbcd3699efcbbadc9fb3aa14f23a123add/libffi/src/aarch64/ffitarget.h#L66
> ):
>
> /* iOS reserves x18 for the system. Disable Go closures until a ne
Thank you Uros.
I will bootstrap and regtest in the all following versions one by one and
install.
gcc-4_8-branch
gcc-4_9-branch
gcc-5-branch
Trunk
regards,
Venkat.
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Wednesday, June 03, 2015 8:32 PM
> To: Ku
On 28/05/15 10:39, Maxim Kuvyrkov wrote:
> Hi,
>
> Akashi-san and I have been discussing required GCC changes to make
> kernel's livepatching work for AArch64 and other architectures. At
> the moment livepatching is supported for x86[_64] using the following
> options: "-pg -mfentry -mrecord-mcou
On Thu, May 28, 2015 at 05:37:53PM +0200, Andreas Krebbel wrote:
> On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote:
> >> On May 28, 2015, at 11:59 AM, Richard Biener
> >> wrote:
> ...
> >> Maybe follow s390 -mhotpatch instead?
> >
> > Regarding implementation of the option, it will follow what s390
29 matches
Mail list logo
