Re: PPC64 libmvec implementation of sincos

2019-09-30 Thread Szabolcs Nagy
On 27/09/2019 20:23, GT wrote: > I am attempting to create a vector version of sincos for PPC64. > The relevant discussion thread is on the GLIBC libc-alpha mailing list. > Navigate it beginning at > https://sourceware.org/ml/libc-alpha/2019-09/msg00334.html > > The intention is to reuse as much

make static method find_reloads_address_1(...) extern accessible

2019-09-30 Thread stefan
I've implemented LEGITIMIZE_RELOAD_ADDRESS and that implementation is calling find_reloads_address_1. My implementation adds double indirect addressing to the m68k target and since the use of an outer index register or offset depends on the use of an inner index register or offset, since only one

Eorror compiling GCC-4.8.0 for Solaris 2.9 and 2.10

2019-09-30 Thread Lincoln
Hi GNU.ORG, I am getting the error below when I try to compile gcc-4.8.0. Can someone assist me with a possible solution: "/tmp/gcc-4.8.0/libcpp/files.c", line 1268: Error: Cannot assign char* to int. "/tmp/gcc-4.8.0/libcpp/files.c", line 1371: Warning (Anachronism): Formal argument 2 of type

RFC: Enabling fixed point modes on x86

2019-09-30 Thread Martin Ling
Hi all, new to the list. Attached is a very short patch which enables the use of fixed point modes on x86 targets. I first created this a couple of years ago for gcc 7 and have just updated it for current git master. I have not sent this to the patches list as I do not expect it to be anywhere ne

Re: RFC: Enabling fixed point modes on x86

2019-09-30 Thread Joseph Myers
On Mon, 30 Sep 2019, Martin Ling wrote: > For starters, by doing this I have implicitly invented an ABI for fixed > point types on x86 (they get passed exactly like correspondingly-sized > integers, I suppose). This ABI would be unique to gcc. > > I have also implicitly set the numbers of integra

state of play/strategy for including Modula-2 into the trunk (licence queries)

2019-09-30 Thread Gaius Mulley
Hello, I thought I'd seek advice on how to get the Modula-2 front end into trunk and also give a state of play. State of play = Currently the gm2-trunk passes all but one regression test on amd64. Other architectures/platforms vary. In early September the whole number overflow de

ღ Why you respond so long in mine letter?

2019-09-30 Thread Colette
Hello,my love. I seen you in Facebook today and so I would like to see you. Ma name Grace I do some Account wit my nice pictures. I will waiting your arms. my second nickname : Phelps442. honey find me!!

Re: PPC64 libmvec implementation of sincos

2019-09-30 Thread GT
‐‐‐ Original Message ‐‐‐ On Monday, September 30, 2019 9:52 AM, Szabolcs Nagy wrote: > On 27/09/2019 20:23, GT wrote: > > > I am attempting to create a vector version of sincos for PPC64. > > The relevant discussion thread is on the GLIBC libc-alpha mailing list. > > Navigate it beginnin

Moving to C++11

2019-09-30 Thread Nicholas Krause
Greetings Jonathan and Jason, I was wondering what work is required to move to C++11. Seems your both interested in getting this done and so am I. Perhaps we start similar to Git with a wiki page about what features would be useful and then start migrating the makefiles to allow for this. So

Re: PPC64 libmvec implementation of sincos

2019-09-30 Thread Szabolcs Nagy
On 30/09/2019 18:30, GT wrote: > ‐‐‐ Original Message ‐‐‐ > On Monday, September 30, 2019 9:52 AM, Szabolcs Nagy > wrote: > >> On 27/09/2019 20:23, GT wrote: >> >>> I am attempting to create a vector version of sincos for PPC64. >>> The relevant discussion thread is on the GLIBC libc-alp

Re: PPC64 libmvec implementation of sincos

2019-09-30 Thread Richard Biener
On September 30, 2019 3:52:52 PM GMT+02:00, Szabolcs Nagy wrote: >On 27/09/2019 20:23, GT wrote: >> I am attempting to create a vector version of sincos for PPC64. >> The relevant discussion thread is on the GLIBC libc-alpha mailing >list. >> Navigate it beginning at >https://sourceware.org/ml/li

Re: git conversion of GCC wwwdocs repository

2019-09-30 Thread Joseph Myers
As far as I can tell from the discussion, people are happy with the version of the conversion using @gcc.gnu.org addresses. When shall we (do a final conversion if there are any commits postdating that one and) switch over to it as the live repository, set up hooks and update documentation of

Re: RFC: Followup to PR91593

2019-09-30 Thread Jerry DeLisle
Copying gcc list for additional thoughts on a possible bogus warning. On 9/29/19 9:02 AM, Jerry DeLisle wrote: Hi all, --- snip --- diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c index 4ef35561fdd..fc046efbe34 100644 --- a/libgfortran/io/write.c +++ b/libgfortran/io/write.c @@

Re: RFC: Followup to PR91593

2019-09-30 Thread Steve Kargl
On Mon, Sep 30, 2019 at 08:40:29PM -0700, Jerry DeLisle wrote: > Copying gcc list for additional thoughts on a possible bogus warning. > > On 9/29/19 9:02 AM, Jerry DeLisle wrote: > > Hi all, > > > --- snip --- > > > diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c > > index 4ef35561

Re: RFC: Followup to PR91593

2019-09-30 Thread Steve Kargl
On Mon, Sep 30, 2019 at 08:51:51PM -0700, Steve Kargl wrote: > > Can you just zero memory and remove the explicit setting > of the terminating '\0'? > > q = buffer; > memset(q, 0, len); > (may be dup) Upon further reading of the code, does buffer have 8*len+1 length? You would need to do