Hi GCC Team, Aarch64 Maintainers,
The rules in Vector Function Application Binary Interface Specification for
OpenMP
(https://sourceware.org/glibc/wiki/libmvec?action=AttachFile&do=view&target=VectorABI.txt)
is used in x86 for generating the simd clones of a function.
Is there a similar o
Hello Andrew,
> On Mar 13, 2017, at 19:01 , Andrew Jenner wrote:
>
> I volunteer to be the point of contact for the SPE port.
>
> Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE
> *not* being deprecated (we actively ship toolchain products with SPE
> multilibs, and
On 15/03/17 02:43, Martin Sebor wrote:
> On 03/12/2017 04:51 PM, Roland Illig wrote:
>> Hi,
>>
>> the gcc.pot file currently contains more than 12000 messages to be
>> translated, which is a very high number. Many of these messages are
>> diagnostics, and they can be categorized as follows:
>>
>> *
I want add new target arm-none-symbianelf. I have sh script what does magic.
You can download it here - https://github.com/fedor4ever/GCC-4-Symbian
Fiodar Stryzhniou
Hello.
We declare that one should use autoconf --version == 2.64. I have a package
that provides autoconf-2.64 binary
and I would like to ask whether our configure machinery can use the suffixed
autoconf binary?
Thanks,
Martin
On Mär 15 2017, Martin Liška wrote:
> We declare that one should use autoconf --version == 2.64. I have a package
> that provides autoconf-2.64 binary
> and I would like to ask whether our configure machinery can use the suffixed
> autoconf binary?
make AUTOCONF=autoconf-2.64
Andreas.
--
An
On 03/15/2017 02:23 PM, Andreas Schwab wrote:
On Mär 15 2017, Martin Liška wrote:
We declare that one should use autoconf --version == 2.64. I have a package
that provides autoconf-2.64 binary
and I would like to ask whether our configure machinery can use the suffixed
autoconf binary?
mak
Hi Guys,
There is a lot to tell you about this time. First up is glibc:
The GNU C Library version 2.25 is now available. In this version you
will find:
* Provisional support for ISO/IEC TR 24731-1:2010 which provides
replacement versions of many of the memory allocation functions
Hi all,
On Wed, Mar 15, 2017 at 11:01:31AM +0100, Olivier Hainque wrote:
> > On Mar 13, 2017, at 19:01 , Andrew Jenner wrote:
> > I volunteer to be the point of contact for the SPE port.
> >
> > Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE
> > *not* being deprecat
2016-12-05 16:31 GMT+01:00 Andrew Senkevich :
> 2016-11-16 8:02 GMT+03:00 Andrew Pinski :
>> On Tue, Nov 15, 2016 at 9:36 AM, Andrew Senkevich
>> wrote:
>>> Hi,
>>>
>>> new Intel instructions AVX512_4FMAPS and AVX512_4VNNIW introduce use
>>> of register groups.
>>>
>>> To support register groups f
Am 15.03.2017 um 03:43 schrieb Martin Sebor:
> Would using the existing internal_error{,no_backtrace}, and
> sorry work for this? (I.e., not translating those.) If my
> count is right there are nearly 500 calls to these three in
> GCC sources so I'm not sure that would put enough of a dent
> in th
> On Mar 15, 2017, at 15:26 , Segher Boessenkool
> wrote:
> I do not think VLE can get in, not in its current shape at least. VLE
> is very unlike PowerPC in many ways so it comes at a very big cost to
> the port (maintenance and otherwise -- maintenance is what I care about
> most).
>
> Sinc
On 03/15/2017 10:07 AM, Roland Illig wrote:
Am 15.03.2017 um 03:43 schrieb Martin Sebor:
Would using the existing internal_error{,no_backtrace}, and
sorry work for this? (I.e., not translating those.) If my
count is right there are nearly 500 calls to these three in
GCC sources so I'm not sure
On 03/15/2017 08:26 AM, Segher Boessenkool wrote:
Since SPE and VLE only share the part of the rs6000 port that doesn't
change at all (except for a bug fix once or twice a year), and everything
else needs special cases all over the place, it seems to me it would be
best for everyone if we split
On Wed, Mar 15, 2017 at 11:12:53AM -0600, Sandra Loosemore wrote:
> >Do you (AdaCore and Mentor) think splitting the port is a good idea?
>
> I can't speak on behalf of Mentor, and Andrew is the target expert here,
> but we currently do ship all of SPE, VLE, and AltiVec multilibs in the
> same p
On Wed, Mar 15, 2017 at 1:12 PM, Sandra Loosemore
wrote:
> On 03/15/2017 08:26 AM, Segher Boessenkool wrote:
>
>> Since SPE and VLE only share the part of the rs6000 port that doesn't
>> change at all (except for a bug fix once or twice a year), and everything
>> else needs special cases all over
On 15/03/2017 14:26, Segher Boessenkool wrote:
I do not think VLE can get in, not in its current shape at least.
That's unfortunate. Disregarding the SPE splitting plan for a moment,
what do you think would need to be done to get it into shape? I had
thought we were almost there with the patc
17 matches
Mail list logo
