Re: Armhf dynamic linker path

[Konstantinos Margaritis]

On Tue, 10 Apr 2012 23:01:47 -0400
Mike Frysinger  wrote:
> one of the downsides of traveling down a path and upstreaming as an after 
> thought

You didn't really follow arm hardfloat progress in the past 2 years, did you 
(if you did you'd already be aware of attempts to get this thing upstreamed for 
more than a year).

Honestly, I'm curious, are you speaking your personal opinion or on behalf of 
Gentoo? If the former then consider that we're trying to get consensus amongst 
distros not people, it's impossible to make everyone happy, but we'd be content 
to get distro people to agree on a standard.

If the latter, then also have in mind that GCC upstream is waiting for distro 
agreement to include the proposed triplet (arm-linux-gnueabihf) in gcc. So, if 
distro people here agreed on that, gcc upstream would have no problem as well. 
Agreed on the redundant linux part, my mistake for proposing it. So, I guess 
something like:

/lib/ld-arm-linux-gnueabhif.so.3

or using the ABI name:

/lib/ld-linux-aapcs-vfp.so.3

are the most likely candidates to be agreed by most distros, at least as I see 
it.

Konstantinos

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Armhf dynamic linker path

[Steve McIntyre]

On Tue, Apr 10, 2012 at 11:01:47PM -0400, Mike Frysinger wrote:
>On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote:
>> We understand that not everybody may want or see the need for this for
>> themselves. We *really* get that. But we want it to be possible for
>> *us* to do it, and an ultra-important part of that is to have unique
>> loader paths wherever possible. Hence the discussion over the location
>> for the arm hard-float linker. We've built our systems using the
>> multi-arch path as that worked well for us and doesn't hurt anybody
>> else. There are problems with some of the other options here:
>> 
>>   * /lib/ld-linux.so.3
>
>no one suggested this

It's the current default.

>>   * /libhf/ld-linux.so.3
>> - it could readily clash with a future hard-float platform; look
>>   how /lib64/* could clash with amd64/ARMv8/ppc64/sparc64 all
>>   populating it in the near future
>> 
>>   * /lib/ld-linux-hf.so.3
>> - similar problem
>
>so you're saying Debian would never accept any ldso path for any arch on the 
>future possibility that it could collide with another target ?  that's a bit 
>unreasonable.

We're not saying "never", but we would rather avoid collisions if
avoidable.

>>   * /lib/ld-linux-$triplet.so.3
>> - could work fine, so long as we can agree on triplets
>
>kind of a waste of space, and the definition of "triplet" is vague, and in 
>your 
>example here, the word "linux" uselessly appears twice.

We *have* had agreement on the triplet here: arm-linux-gnueabihf. Yes,
"linux" is used twice here. Apologies.

>once the duplicate "linux" word is fixed, i wouldn't fight this.

Thanks. \o/

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Armhf dynamic linker path

[Jeff Law]

On 04/10/2012 04:42 AM, Steve McIntyre wrote:

It's one of the things we're trying to achieve with multi-arch. We can
support mixed-ABI, mixed-OS, mixed-architecture environments cleanly
on one system, using a consistent set of packages for all. Setting up
a cross-compilation environment suddenly becomes easy - install the
cross-compiler and the libs for the target platform straight from a
normal Debian mirror as binary packages.

>


See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more
rationale.
I've read it and still don't see the benefit, particularly as it relates 
to mixed instruction sets.  Or more precisely, I don't see the value in 
supporting mixed instruction sets.   Once you drop the mixed instruction 
set argument I think the whole argument for embedding the target triplet 
into the dynamic linker pathname falls apart.




We have to agree on a standard path if we're ever going to have
working cross-distro binaries, and that's increasingly important to us
in the ARM world. By all means ignore the multi-arch route that the
Debian world is following, but please accept our reasoning for the
linker location.
But the entire reason behind the need to embed the triplet into the 
dynamic linker's path is the debian multi-arch stuff AFAICT.  I think 
that's what many folks are complaining about.


I realize the goal here is to allow a single binary to run on multiple 
systems and I think that's a worthy goal.


Jeff

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Armhf dynamic linker path

[Steve McIntyre]

On Wed, Apr 11, 2012 at 06:19:38AM -0600, Jeff Law wrote:
>On 04/10/2012 04:42 AM, Steve McIntyre wrote:
>>It's one of the things we're trying to achieve with multi-arch. We can
>>support mixed-ABI, mixed-OS, mixed-architecture environments cleanly
>>on one system, using a consistent set of packages for all. Setting up
>>a cross-compilation environment suddenly becomes easy - install the
>>cross-compiler and the libs for the target platform straight from a
>>normal Debian mirror as binary packages.
>>
>>
>>See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more
>>rationale.
>I've read it and still don't see the benefit, particularly as it
>relates to mixed instruction sets.  Or more precisely, I don't see
>the value in supporting mixed instruction sets.   Once you drop the
>mixed instruction set argument I think the whole argument for
>embedding the target triplet into the dynamic linker pathname falls
>apart.

We see a value in supporting mixed instruction sets for two cases:
emulation and cross-building. If you don't want or care so much about
those, then fine - that's your call in your environment. They're both
cases that Debian/Ubuntu would like to do a much better job of
supporting in future, using existing packages instead of having to do
so much special-casing all over. I hope that you (plural) can
understand/accept that?

>>We have to agree on a standard path if we're ever going to have
>>working cross-distro binaries, and that's increasingly important to us
>>in the ARM world. By all means ignore the multi-arch route that the
>>Debian world is following, but please accept our reasoning for the
>>linker location.
>But the entire reason behind the need to embed the triplet into the
>dynamic linker's path is the debian multi-arch stuff AFAICT.  I think
>that's what many folks are complaining about.
>
>I realize the goal here is to allow a single binary to run on
>multiple systems and I think that's a worthy goal.

Cool. :-)

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Selectively disable vectorization

[Singh, Ravi Kumar (Ravi)]

All,

Are there any pragmas for selectively disabling (in one chunk of code) the 
vectorization, when its enabled globally.

regards
Ravi Singh

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

O2 optimization with vectorize

[Singh, Ravi Kumar (Ravi)]

All,

In the below code, I tried few compiler options and got following observations:


1)  arm-linux-gnueabi-gcc -O2 -mcpu=cortex-a15 -mfpu=neon 
-ftree-vectorizer-verbose=6  -ftree-vectorize



Compiler throws following info messages:



foo.c:16: note: not vectorized: unsupported use in stmt.

foo.c:16: note: not vectorized: unsupported use in stmt.

foo.c:18: note: not vectorized: unsupported use in stmt.

foo.c:18: note: not vectorized: unsupported use in stmt.





2)  -O2 -mcpu=cortex-a15 -mfpu=neon


None of the generated code contains the NEON instructions. Code generated with 
case 1 is taking 3000 cycles, and code generated by option 2 is taking 2500 
cycles.

Even if vectorization failed in case1, it should not generate more inefficient 
code than case 2. My belief was that the executables from both would take same 
cycles, any thing done for doing unsuccessful vectorization must be reverted if 
it did not succeed.

###
#define SIZE1 20
#define SIZE2 26

unsigned int array[SIZE1][SIZE2];

void  foo()
{
  unsigned int i,j;
  unsigned int max = 0;

  for(i = 0; i < SIZE1; i++)
  {
for(j = 0; j < SIZE2; j++)
{
  if (array[i][j] > max)
  {
max = array[i][j];
index = j;
  }
}
  }

  printf("Max value: %u Index: %u\n", max, index);
}



Regards
RKS
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Selectively disable vectorization

[Ulrich Weigand]

"Singh, Ravi Kumar (Ravi)"  wrote:

> Are there any pragmas for selectively disabling (in one chunk of
> code) the vectorization, when its enabled globally.

No, there are not (just like for all optimization settings).

You'd have to place the chunk of code into a separate file
and build it with a different set of options ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: O2 optimization with vectorize

[Ulrich Weigand]

"Singh, Ravi Kumar (Ravi)"  wrote:

> None of the generated code contains the NEON instructions. Code
> generated with case 1 is taking 3000 cycles, and code generated by
> option 2 is taking 2500 cycles.
>
> Even if vectorization failed in case1, it should not generate more
> inefficient code than case 2. My belief was that the executables
> from both would take same cycles, any thing done for doing
> unsuccessful vectorization must be reverted if it did not succeed.

I suspect the reason vectorization fails is the direct reference
to the loop counter in the inner loop:
 index = j;

After vectorization, the loop counter is no longer available, so
code that accesses is as in your example usually cannot be
automatically vectorized.


As to why -ftree-vectorize still generates different code, that is
probably because the flag actually enables two other optimizations
that are distinct from the vectorizer, but usually enable it to do
a better job:  if-conversion and store-sinking.

I suspect in your test case, if-conversion actually transforms the
if in the inner loop.  However, if the result is then still not
vectorizable, that transformation might happen to be a net loss ...

You can switch off those extra transformations while still enabling
vectorization using something like:
   -ftree-vectorize -fno-tree-if-conversion --param max-stores-to-sink=0

(Note that this might cause some loops that would otherwise have been
vectorized to become non-vectorizable ...)


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

RE: O2 optimization with vectorize

[Singh, Ravi Kumar (Ravi)]

Ulrich,

If I disable extra transformations as suggested by you my cycles increase to 
38xx in comparison to -O2 25xx


Regards
RKS

-Original Message-
From: Ulrich Weigand [mailto:ulrich.weig...@de.ibm.com] 
Sent: Wednesday, April 11, 2012 10:15 AM
To: Singh, Ravi Kumar (Ravi)
Cc: linaro-toolchain@lists.linaro.org
Subject: Re: O2 optimization with vectorize

"Singh, Ravi Kumar (Ravi)"  wrote:

> None of the generated code contains the NEON instructions. Code
> generated with case 1 is taking 3000 cycles, and code generated by
> option 2 is taking 2500 cycles.
>
> Even if vectorization failed in case1, it should not generate more
> inefficient code than case 2. My belief was that the executables
> from both would take same cycles, any thing done for doing
> unsuccessful vectorization must be reverted if it did not succeed.

I suspect the reason vectorization fails is the direct reference
to the loop counter in the inner loop:
 index = j;

After vectorization, the loop counter is no longer available, so
code that accesses is as in your example usually cannot be
automatically vectorized.


As to why -ftree-vectorize still generates different code, that is
probably because the flag actually enables two other optimizations
that are distinct from the vectorizer, but usually enable it to do
a better job:  if-conversion and store-sinking.

I suspect in your test case, if-conversion actually transforms the
if in the inner loop.  However, if the result is then still not
vectorizable, that transformation might happen to be a net loss ...

You can switch off those extra transformations while still enabling
vectorization using something like:
   -ftree-vectorize -fno-tree-if-conversion --param max-stores-to-sink=0

(Note that this might cause some loops that would otherwise have been
vectorized to become non-vectorizable ...)


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Selectively disable vectorization

[Mans Rullgard]

On 11 April 2012 16:16, Ulrich Weigand  wrote:
> "Singh, Ravi Kumar (Ravi)"  wrote:
>
>> Are there any pragmas for selectively disabling (in one chunk of
>> code) the vectorization, when its enabled globally.
>
> No, there are not (just like for all optimization settings).

Are you saying __attribute__((optimise("foo"))) is a lie?

-- 
Mans Rullgard / mru

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Selectively disable vectorization

[Michael Hope]

On 12 April 2012 04:21, Mans Rullgard  wrote:
> On 11 April 2012 16:16, Ulrich Weigand  wrote:
>> "Singh, Ravi Kumar (Ravi)"  wrote:
>>
>>> Are there any pragmas for selectively disabling (in one chunk of
>>> code) the vectorization, when its enabled globally.
>>
>> No, there are not (just like for all optimization settings).
>
> Are you saying __attribute__((optimise("foo"))) is a lie?

It seems to work on 4.6 on public functions:

void doubleit(int *pout, const int *pin)
{
  for (int i = 0; i < 64; i++)
{
  pout[i] = pin[i]*2;
}
}

(gets vectorised)

__attribute__((optimize("-fno-tree-vectorize")))
void novect(int *pout, const int *pin)
{
  for (int i = 0; i < 64; i++)
{
  pout[i] = pin[i]*2;
}
}

(no vector code)

The attribute applies to that function only and doesn't seem to apply
if the function is inlined, such as:

__attribute__((optimize("-fno-tree-vectorize")))
static void novect(int *pout, const int *pin)
...

void outer(int *pin, int *pout)
{
  novect(pout, pin);
}

'outer' contains vectorised code.

-- Michael

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Selectively disable vectorization

[Ramana Radhakrishnan]

On 11 April 2012 17:21, Mans Rullgard  wrote:
> On 11 April 2012 16:16, Ulrich Weigand  wrote:
>> "Singh, Ravi Kumar (Ravi)"  wrote:
>>
>>> Are there any pragmas for selectively disabling (in one chunk of
>>> code) the vectorization, when its enabled globally.
>>
>> No, there are not (just like for all optimization settings).
>
> Are you saying __attribute__((optimise("foo"))) is a lie?

Function attributes aren't really the same as pragmas :)

regards,
Ramana

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Selectively disable vectorization

[Mans Rullgard]

On 11 April 2012 22:05, Ramana Radhakrishnan
 wrote:
> On 11 April 2012 17:21, Mans Rullgard  wrote:
>> On 11 April 2012 16:16, Ulrich Weigand  wrote:
>>> "Singh, Ravi Kumar (Ravi)"  wrote:
>>>
 Are there any pragmas for selectively disabling (in one chunk of
 code) the vectorization, when its enabled globally.
>>>
>>> No, there are not (just like for all optimization settings).
>>
>> Are you saying __attribute__((optimise("foo"))) is a lie?
>
> Function attributes aren't really the same as pragmas :)

Use #pragma GCC optimize ("foo") then.  It does the same thing if
the manual is to be believed.

-- 
Mans Rullgard / mru

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Phone call (was Re: Armhf dynamic linker path)

[Steve McIntyre]

On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>
>And here's the details as promised.
>
>I've started a wiki page at 
>
>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>
>with a strawman agenda for now, and a Doodle poll at 
>
>http://www.doodle.com/93bitkqeb7auyxn7
>
>to see when the best time is for the call on Thursday/Friday. Please
>fill in the times that work for you ASAP and I'll announce the result
>during Wednesday. Ideally we'd like stakeholders from all the relevant
>distros and the upstream toolchain developers to be there, able to
>represent their groups and (importantly) able to make a decision here
>on what we should do.
>
>Apologies for the short notice, but we need a decision quickly.

And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
11:00 EDT etc.). Of the 10 people who responded in the poll, the only
person who can't make that time is Michael in .nz. Sorry, Michael.

Phone numbers are listed in the wiki page above. I'll take notes and
post minutes afterwards. Let's talk Friday and get this shaken out to
a working conclusion.

Thanks,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Armhf dynamic linker path

[Paulo César Pereira de Andrade]

Em 11 de abril de 2012 10:04, Steve McIntyre
 escreveu:
> On Wed, Apr 11, 2012 at 06:19:38AM -0600, Jeff Law wrote:
>>On 04/10/2012 04:42 AM, Steve McIntyre wrote:
>>>It's one of the things we're trying to achieve with multi-arch. We can
>>>support mixed-ABI, mixed-OS, mixed-architecture environments cleanly
>>>on one system, using a consistent set of packages for all. Setting up
>>>a cross-compilation environment suddenly becomes easy - install the
>>>cross-compiler and the libs for the target platform straight from a
>>>normal Debian mirror as binary packages.
>>>
>>>
>>>See http://wiki.debian.org/Multiarch/TheCaseForMultiarch for more
>>>rationale.
>>I've read it and still don't see the benefit, particularly as it
>>relates to mixed instruction sets.  Or more precisely, I don't see
>>the value in supporting mixed instruction sets.   Once you drop the
>>mixed instruction set argument I think the whole argument for
>>embedding the target triplet into the dynamic linker pathname falls
>>apart.
>
> We see a value in supporting mixed instruction sets for two cases:
> emulation and cross-building. If you don't want or care so much about
> those, then fine - that's your call in your environment. They're both
> cases that Debian/Ubuntu would like to do a much better job of
> supporting in future, using existing packages instead of having to do
> so much special-casing all over. I hope that you (plural) can
> understand/accept that?

  Probably beating a dead cow, but, the major problem with sysroots
would be the triplet name?

  E.g, in any architecture:

/arm-linux-gnueabi/sysroot-contents-here

and ld.so living in

/arm-linux-gnueabi/lib/ld.so.3

and arch specific package cross toolchain in:

/this-system-triplet/bin/arm-linux-gnueabi-gcc
etc

with kernel support, as already suggested in this thread, one
could omit the /x-y-z part, but that is not something to be done
"for yesterday".

  And then the triplet name problem:

/armv7hl-vendor-linux-gnueabi/lib/ld.so.3
or
/arm-linux-gnueabihf/lib/ld.so.3

  With this approach, not pretending to share files between sysroots,
that can be easily done, but requires strong policy to not allow
binaries in /usr/share if /usr/share it to be, err "shared".

>>>We have to agree on a standard path if we're ever going to have
>>>working cross-distro binaries, and that's increasingly important to us
>>>in the ARM world. By all means ignore the multi-arch route that the
>>>Debian world is following, but please accept our reasoning for the
>>>linker location.
>>But the entire reason behind the need to embed the triplet into the
>>dynamic linker's path is the debian multi-arch stuff AFAICT.  I think
>>that's what many folks are complaining about.
>>
>>I realize the goal here is to allow a single binary to run on
>>multiple systems and I think that's a worthy goal.
>
> Cool. :-)
>
> Cheers,
> --
> Steve McIntyre                                steve.mcint...@linaro.org
>  Linaro.org | Open source software for ARM SoCs
>
>
> ___
> cross-distro mailing list
> cross-dis...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/cross-distro

Paulo

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Michael Hope]

On 12 April 2012 10:38, Steve McIntyre  wrote:
> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>
>>And here's the details as promised.
>>
>>I've started a wiki page at
>>
>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>>with a strawman agenda for now, and a Doodle poll at
>>
>>http://www.doodle.com/93bitkqeb7auyxn7
>>
>>to see when the best time is for the call on Thursday/Friday. Please
>>fill in the times that work for you ASAP and I'll announce the result
>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>distros and the upstream toolchain developers to be there, able to
>>represent their groups and (importantly) able to make a decision here
>>on what we should do.
>>
>>Apologies for the short notice, but we need a decision quickly.
>
> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
> person who can't make that time is Michael in .nz. Sorry, Michael.

All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
 * is similar to /lib/ld-x86-64.so.2
 * keeps the libraries and loader in the same directory
 * doesn't invent a new /libhf directory
 * is easier to implement in GLIBC
 * is architecture and ABI unique
 * requires less change for distros where the hard float libraries are
already in /lib

I'm happy to do the GLIBC and GCC implementation.

-- Michael

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Armhf dynamic linker path

[Jon Masters]

Hi Steve,

Please ensure Jakub on our end is involved in the meeting. We discussed
compromise solutions that are acceptable to him and Dennis today and I
would like him to be involved in the discussion. He is on CET, but
cannot make calls after 10pm UTC. I prefer that we try to have this on
Friday, or Monday at this point so that everyone has chance to make it.

Jon.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

RE: O2 optimization with vectorize

[Ulrich Weigand]

"Singh, Ravi Kumar (Ravi)"  wrote on 11.04.2012
17:50:53:

> If I disable extra transformations as suggested by you my cycles
> increase to 38xx in comparison to -O2 25xx

Sorry, I misremembered the flag spelling.  It should read:

   -ftree-vectorize -fno-tree-loop-if-convert --param max-stores-to-sink=0

This gets me identical code to just -O2 on your test case.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294



___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Selectively disable vectorization

[Ulrich Weigand]

Mans Rullgard  wrote on 11.04.2012 18:21:46:
> On 11 April 2012 16:16, Ulrich Weigand  wrote:
> > "Singh, Ravi Kumar (Ravi)"  wrote:
> >
> >> Are there any pragmas for selectively disabling (in one chunk of
> >> code) the vectorization, when its enabled globally.
> >
> > No, there are not (just like for all optimization settings).
>
> Are you saying __attribute__((optimise("foo"))) is a lie?

No, you're of course correct.   __attribute__((optimize)) is
supposed to work, as is #pragma GCC optimize.

[ The reason I said otherwise was that I erroneously thought
this attribute required back-end support which we don't have
on ARM yet.  I guess I mixed this up with __attribute__((target)),
which indeed is not supported on ARM. ]

Sorry for causing extra confusion.


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Michael Hope]

2012/4/12 Paulo César Pereira de Andrade
:
> Em 11 de abril de 2012 20:22, Michael Hope  escreveu:
>> On 12 April 2012 10:38, Steve McIntyre  wrote:
>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:

And here's the details as promised.

I've started a wiki page at

https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012

with a strawman agenda for now, and a Doodle poll at

http://www.doodle.com/93bitkqeb7auyxn7

to see when the best time is for the call on Thursday/Friday. Please
fill in the times that work for you ASAP and I'll announce the result
during Wednesday. Ideally we'd like stakeholders from all the relevant
distros and the upstream toolchain developers to be there, able to
represent their groups and (importantly) able to make a decision here
on what we should do.

Apologies for the short notice, but we need a decision quickly.
>>>
>>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
>>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
>>> person who can't make that time is Michael in .nz. Sorry, Michael.
>>
>> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>>  * is similar to /lib/ld-x86-64.so.2
>>  * keeps the libraries and loader in the same directory
>>  * doesn't invent a new /libhf directory
>>  * is easier to implement in GLIBC
>>  * is architecture and ABI unique
>>  * requires less change for distros where the hard float libraries are
>> already in /lib
>
>  Sorry for more bikeshedding, but afaik rpm based distros are
> using the armv7hl identifier, so it could as well be
>
> /lib/ld-linux-armv7hl.so.3

This includes the ABI (h), adds the endianess (l), and implies a
architecture level (v7).  The name for the most common configurations
should be as short as possible so I'd rather drop the 'l' and add a
'b' or 'eb' if anyone wants a big endian distro in the future.  The
architecture level is a problem as the loader should also be valid on
ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
hard float binary that runs on everything, including a potential ARMv6
hard float RaspberryPi build.

>  Other variant could be
>
> /armv7hl-linux/lib/ld.so.3

This introduces both a new directory and a new style for naming :)

-- Michael

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Paulo César Pereira de Andrade]

Em 11 de abril de 2012 20:22, Michael Hope  escreveu:
> On 12 April 2012 10:38, Steve McIntyre  wrote:
>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>>
>>>And here's the details as promised.
>>>
>>>I've started a wiki page at
>>>
>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>
>>>with a strawman agenda for now, and a Doodle poll at
>>>
>>>http://www.doodle.com/93bitkqeb7auyxn7
>>>
>>>to see when the best time is for the call on Thursday/Friday. Please
>>>fill in the times that work for you ASAP and I'll announce the result
>>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>>distros and the upstream toolchain developers to be there, able to
>>>represent their groups and (importantly) able to make a decision here
>>>on what we should do.
>>>
>>>Apologies for the short notice, but we need a decision quickly.
>>
>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
>> person who can't make that time is Michael in .nz. Sorry, Michael.
>
> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>  * is similar to /lib/ld-x86-64.so.2
>  * keeps the libraries and loader in the same directory
>  * doesn't invent a new /libhf directory
>  * is easier to implement in GLIBC
>  * is architecture and ABI unique
>  * requires less change for distros where the hard float libraries are
> already in /lib

  Sorry for more bikeshedding, but afaik rpm based distros are
using the armv7hl identifier, so it could as well be

/lib/ld-linux-armv7hl.so.3

  Other variant could be

/armv7hl-linux/lib/ld.so.3

but that only if one wants to implement multiarch with sysroot
set to /armv7hl-linux, but that creates several other issues...

> I'm happy to do the GLIBC and GCC implementation.
>
> -- Michael
>
> ___
> cross-distro mailing list
> cross-dis...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/cross-distro

Paulo

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Wookey]

+++ Michael Hope [2012-04-12 12:16 +1200]:
> 2012/4/12 Paulo César Pereira de Andrade
> :

> >> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> >  Sorry for more bikeshedding, 
> > /lib/ld-linux-armv7hl.so.3
>  I'd rather drop the 'l'

We've already had the GNU triplet-name argument for this ABI. I don't
think having it again in order to use something slightly different for
the linker name is very helpful.

Unless of course we find that was another chimera and in fact that's
not really agreed either...

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Armhf dynamic linker path

[Mike Frysinger]

On Wednesday 11 April 2012 05:47:29 Steve McIntyre wrote:
> On Tue, Apr 10, 2012 at 11:01:47PM -0400, Mike Frysinger wrote:
> >On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote:
> >>   * /lib/ld-linux-$triplet.so.3
> >> - could work fine, so long as we can agree on triplets
> >
> >kind of a waste of space, and the definition of "triplet" is vague, and in
> >your example here, the word "linux" uselessly appears twice.
> 
> We *have* had agreement on the triplet here: arm-linux-gnueabihf.

it wasn't clear what triplet you were referring to.  Debian's multiarch has 
its own concept (according to its own wiki), and then there's the GNU triplet.
-mike


signature.asc
Description: This is a digitally signed message part.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Armhf dynamic linker path

[Mike Frysinger]

On Wednesday 11 April 2012 11:25:55 Paulo César Pereira de Andrade wrote:
>   Probably beating a dead cow, but, the major problem with sysroots
> would be the triplet name?
> 
>   E.g, in any architecture:
> 
> /arm-linux-gnueabi/sysroot-contents-here

it isn't really about having a sysroot the toolchain can find.  that already 
works today for any target or multilib or isa or soft/hard float or arch or 
.  the issue is having an ldso in its canonical path for runtime 
usage.  i don't think anyone wants hardcoded tuple dirs in the root.  some 
people can't even handle /bin or /sbin or /lib, so i'm afraid this proposal 
would cause them to implode ;).
-mike


signature.asc
Description: This is a digitally signed message part.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Paulo César Pereira de Andrade]

Em 11 de abril de 2012 21:16, Michael Hope  escreveu:
> 2012/4/12 Paulo César Pereira de Andrade
> :
>> Em 11 de abril de 2012 20:22, Michael Hope  
>> escreveu:
>>> On 12 April 2012 10:38, Steve McIntyre  wrote:
 On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>
>And here's the details as promised.
>
>I've started a wiki page at
>
>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>
>with a strawman agenda for now, and a Doodle poll at
>
>http://www.doodle.com/93bitkqeb7auyxn7
>
>to see when the best time is for the call on Thursday/Friday. Please
>fill in the times that work for you ASAP and I'll announce the result
>during Wednesday. Ideally we'd like stakeholders from all the relevant
>distros and the upstream toolchain developers to be there, able to
>represent their groups and (importantly) able to make a decision here
>on what we should do.
>
>Apologies for the short notice, but we need a decision quickly.

 And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
 person who can't make that time is Michael in .nz. Sorry, Michael.
>>>
>>> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>>>  * is similar to /lib/ld-x86-64.so.2
>>>  * keeps the libraries and loader in the same directory
>>>  * doesn't invent a new /libhf directory
>>>  * is easier to implement in GLIBC
>>>  * is architecture and ABI unique
>>>  * requires less change for distros where the hard float libraries are
>>> already in /lib
>>
>>  Sorry for more bikeshedding, but afaik rpm based distros are
>> using the armv7hl identifier, so it could as well be
>>
>> /lib/ld-linux-armv7hl.so.3
>
> This includes the ABI (h), adds the endianess (l), and implies a
> architecture level (v7).  The name for the most common configurations
> should be as short as possible so I'd rather drop the 'l' and add a
> 'b' or 'eb' if anyone wants a big endian distro in the future.  The
> architecture level is a problem as the loader should also be valid on
> ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
> hard float binary that runs on everything, including a potential ARMv6
> hard float RaspberryPi build.

  This means ld.so (and what else? a skype binary should not come fully
statically linked) should be built with -march=armv5te? That is, common
denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set?
  AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r
that has a div instruction in thumb mode).

>>  Other variant could be
>>
>> /armv7hl-linux/lib/ld.so.3
>
> This introduces both a new directory and a new style for naming :)

  Well, I said I was sorry for more bikeshedding :-)

> -- Michael

Paulo

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Brendan Conoboy]

On 04/11/2012 05:16 PM, Michael Hope wrote:
> 2012/4/12 Paulo César Pereira de Andrade
>> /lib/ld-linux-armv7hl.so.3
>
> This includes the ABI (h), adds the endianess (l), and implies a
> architecture level (v7).  The name for the most common configurations
> should be as short as possible so I'd rather drop the 'l' and add a
> 'b' or 'eb' if anyone wants a big endian distro in the future.  The
> architecture level is a problem as the loader should also be valid on
> ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
> hard float binary that runs on everything, including a potential ARMv6
> hard float RaspberryPi build.

In Fedora we specifically mean VFPv3-D16 when we're talking about hard 
float.  This is the lowest common denominator for us.  If you want to 
support armv5hl, armv6hl, and armv7hl as all being possible (whatever 
string you like to represent it) that's good to know because it's beyond 
what we're contemplating.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Michael Hope]

On 12 April 2012 12:38, Wookey  wrote:
> +++ Michael Hope [2012-04-12 12:16 +1200]:
>> 2012/4/12 Paulo César Pereira de Andrade
>> :
>
>> >> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>> >  Sorry for more bikeshedding,
>> > /lib/ld-linux-armv7hl.so.3
>>  I'd rather drop the 'l'
>
> We've already had the GNU triplet-name argument for this ABI. I don't
> think having it again in order to use something slightly different for
> the linker name is very helpful.
>
> Unless of course we find that was another chimera and in fact that's
> not really agreed either...

Sorry, I should have said that in my reply.  I agree, the GNU triplet
should be used.  I couldn't resist going into the past-covered reasons
why.

-- Michael

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Armhf dynamic linker path

[Mike Frysinger]

On Wednesday 11 April 2012 03:37:56 Konstantinos Margaritis wrote:
> On Tue, 10 Apr 2012 23:01:47 -0400 Mike Frysinger wrote:
> > one of the downsides of traveling down a path and upstreaming as an after
> > thought
> 
> You didn't really follow arm hardfloat progress in the past 2 years, did
> you (if you did you'd already be aware of attempts to get this thing
> upstreamed for more than a year).

i've only started following arm again as my last job (of 5+ years) was largely 
Blackfin related

> Honestly, I'm curious, are you speaking your personal opinion or on behalf
> of Gentoo? If the former then consider that we're trying to get consensus
> amongst distros not people, it's impossible to make everyone happy, but
> we'd be content to get distro people to agree on a standard.

considering i did the Gentoo/ARM port ~8 years ago and maintain the toolchain 
on Gentoo for all arches, i have a fairly big incentive to keep things clean.

> proposing it. So, I guess something like:
> 
> /lib/ld-arm-linux-gnueabhif.so.3
> 
> or using the ABI name:
> 
> /lib/ld-linux-aapcs-vfp.so.3
> 
> are the most likely candidates to be agreed by most distros, at least as I
> see it.

i can let the fine wording of the tuple in the filename be hammered out by 
others.  if we don't care about multilib, then /lib/ is fine, and as long is it 
isn't crowed by subdir-cruft (i.e. /lib//), then i'm happy.

side note: you really need to fix your mailer.  the lack of proper wrapping is 
obnoxious.
-mike


signature.asc
Description: This is a digitally signed message part.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Michael Hope]

2012/4/12 Paulo César Pereira de Andrade
:
> Em 11 de abril de 2012 21:16, Michael Hope  escreveu:
>> 2012/4/12 Paulo César Pereira de Andrade
>> :
>>> Em 11 de abril de 2012 20:22, Michael Hope  
>>> escreveu:
 On 12 April 2012 10:38, Steve McIntyre  wrote:
> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>
>>And here's the details as promised.
>>
>>I've started a wiki page at
>>
>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>>with a strawman agenda for now, and a Doodle poll at
>>
>>http://www.doodle.com/93bitkqeb7auyxn7
>>
>>to see when the best time is for the call on Thursday/Friday. Please
>>fill in the times that work for you ASAP and I'll announce the result
>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>distros and the upstream toolchain developers to be there, able to
>>represent their groups and (importantly) able to make a decision here
>>on what we should do.
>>
>>Apologies for the short notice, but we need a decision quickly.
>
> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
> person who can't make that time is Michael in .nz. Sorry, Michael.

 All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
  * is similar to /lib/ld-x86-64.so.2
  * keeps the libraries and loader in the same directory
  * doesn't invent a new /libhf directory
  * is easier to implement in GLIBC
  * is architecture and ABI unique
  * requires less change for distros where the hard float libraries are
 already in /lib
>>>
>>>  Sorry for more bikeshedding, but afaik rpm based distros are
>>> using the armv7hl identifier, so it could as well be
>>>
>>> /lib/ld-linux-armv7hl.so.3
>>
>> This includes the ABI (h), adds the endianess (l), and implies a
>> architecture level (v7).  The name for the most common configurations
>> should be as short as possible so I'd rather drop the 'l' and add a
>> 'b' or 'eb' if anyone wants a big endian distro in the future.  The
>> architecture level is a problem as the loader should also be valid on
>> ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
>> hard float binary that runs on everything, including a potential ARMv6
>> hard float RaspberryPi build.
>
>  This means ld.so (and what else? a skype binary should not come fully
> statically linked) should be built with -march=armv5te? That is, common
> denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set?
>  AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r
> that has a div instruction in thumb mode).

The architecture and feature set is a different topic and should be
discussed by the distros but I'd rather finish the loader path one
first.  Note that Fedora, Ubuntu, Debian, openSUSE, and Gentoo have
all taken the opportunity to go to ARMv7 at the same time as switching
to hard float.

-- Michael

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Paulo César Pereira de Andrade]

Em 11 de abril de 2012 22:39, Michael Hope  escreveu:
> 2012/4/12 Paulo César Pereira de Andrade
> :
>> Em 11 de abril de 2012 21:16, Michael Hope  
>> escreveu:
>>> 2012/4/12 Paulo César Pereira de Andrade
>>> :
 Em 11 de abril de 2012 20:22, Michael Hope  
 escreveu:
> On 12 April 2012 10:38, Steve McIntyre  wrote:
>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>>
>>>And here's the details as promised.
>>>
>>>I've started a wiki page at
>>>
>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>
>>>with a strawman agenda for now, and a Doodle poll at
>>>
>>>http://www.doodle.com/93bitkqeb7auyxn7
>>>
>>>to see when the best time is for the call on Thursday/Friday. Please
>>>fill in the times that work for you ASAP and I'll announce the result
>>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>>distros and the upstream toolchain developers to be there, able to
>>>represent their groups and (importantly) able to make a decision here
>>>on what we should do.
>>>
>>>Apologies for the short notice, but we need a decision quickly.
>>
>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
>> person who can't make that time is Michael in .nz. Sorry, Michael.
>
> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>  * is similar to /lib/ld-x86-64.so.2
>  * keeps the libraries and loader in the same directory
>  * doesn't invent a new /libhf directory
>  * is easier to implement in GLIBC
>  * is architecture and ABI unique
>  * requires less change for distros where the hard float libraries are
> already in /lib

  Sorry for more bikeshedding, but afaik rpm based distros are
 using the armv7hl identifier, so it could as well be

 /lib/ld-linux-armv7hl.so.3
>>>
>>> This includes the ABI (h), adds the endianess (l), and implies a
>>> architecture level (v7).  The name for the most common configurations
>>> should be as short as possible so I'd rather drop the 'l' and add a
>>> 'b' or 'eb' if anyone wants a big endian distro in the future.  The
>>> architecture level is a problem as the loader should also be valid on
>>> ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
>>> hard float binary that runs on everything, including a potential ARMv6
>>> hard float RaspberryPi build.
>>
>>  This means ld.so (and what else? a skype binary should not come fully
>> statically linked) should be built with -march=armv5te? That is, common
>> denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set?
>>  AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r
>> that has a div instruction in thumb mode).
>
> The architecture and feature set is a different topic and should be
> discussed by the distros but I'd rather finish the loader path one
> first.  Note that Fedora, Ubuntu, Debian, openSUSE, and Gentoo have
> all taken the opportunity to go to ARMv7 at the same time as switching
> to hard float.

  Ok. It obviously should be up to distros if they want the hardfp packages
to be able to run on armv5 with a vfp :-) And so is for skype if they want
it to run on such distro if it exists.  Simpler alternate name would be

/lib/ld-linux-armh.so.3

> -- Michael

Paulo

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ANNOUNCE] Linaro GCC 4.7 and 4.6 2012.04 released

[Michael Hope]

The Linaro Toolchain Working Group is pleased to announce the 2012.04
release of both Linaro GCC 4.7 and Linaro GCC 4.6.

Linaro GCC 4.7 2012.04 is the first release in the 4.7 series. Based
off the latest GCC 4.7.0+svn186061 release, it includes performance
improvements especially around 64 bit operations.

Interesting changes include:
 * Our first 4.7 based release
 * Updates to GCC 4.7.0+svn186061
 * Better use of 16 bit Thumb-2 instructions for smaller code size
 * Implements 64 bit ones complement in NEON
 * Adds support for the ARMv6 saturation instructions
 * Backports the NEON lexer improvements for faster compilation
 * Backports the 64 bit multiply, divide, and mod improvements

Fixes:
 * LP: #960283 slp pass assert when compiler configure with --enable-checking

Linaro GCC 4.6 2012.04 is the fourteenth release in the 4.6 series.
Based off the latest GCC 4.6.3+svn186060 release, this is the first
release after entering maintenance.

Interesting changes include:
 * Updates to 4.6.3+svn186060

Fixes:
 * LP: #960283 slp pass assert when compiler configure with --enable-checking

The source tarballs are available from:
 https://launchpad.net/gcc-linaro/+milestone/4.7-2012.04
 https://launchpad.net/gcc-linaro/+milestone/4.6-2012.04

Downloads are available from the Linaro GCC page on Launchpad:
 https://launchpad.net/gcc-linaro

More information on the features and issues are available from the
release page:
 https://launchpad.net/gcc-linaro/4.7/4.7-2012.04

Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Bugs: https://bugs.launchpad.net/gcc-linaro/

Questions? https://ask.linaro.org/

Interested in commercial support? Inquire at supp...@linaro.org

-- Michael

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Jon Masters]

On Apr 11, 2012, at 7:22 PM, Michael Hope wrote:

> My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> * is similar to /lib/ld-x86-64.so.2
> * keeps the libraries and loader in the same directory
> * doesn't invent a new /libhf directory
> * is easier to implement in GLIBC
> * is architecture and ABI unique
> * requires less change for distros where the hard float libraries are
> already in /lib
> 
> I'm happy to do the GLIBC and GCC implementation.

I'm happy with your proposal, as I am with any of the others that result
in a /lib path (our guys will accept that) that contains enough uniqueness
that there won't be a path clash later. Sure, Jakub will probably argue
that ".so.3" already implies "gnueabi" so we can drop that, and we can
screw around with this some more, but you are on the right track IMO.

Jon.


___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Phone call (was Re: Armhf dynamic linker path)

[Jakub Jelinek]

On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:

The directory should be /libhf/ or /libhfp/ for that for consistency
with all the other architectures.  Note e.g. x86_64 dynamic linker
is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
For distros that choose to multilib softfp vs. hardfp all the hardfp
libraries would go into the usual */lib{qual} paths (for qual hf resp.
hfp), for others /libhf can be a symlink to /lib or for those doing
multiarch stuff can be a symlink to the multiarch location of the thing.

I'm fine with arm and hf (resp. hfp) being mentioned in the name of
the dynamic linker, but IMNSHO having there gnu and eabi strings
is an overkill - why mention gnu there, when all the other
architectures which also have GNU libc dynamic linkers don't?  That
part is implicit.  And, EABI is implied by so.3, softfp dynamic linker
for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old
ABI is /lib/ld-linux.so.2.

Jakub

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain