Re: Cortex-r52 FP double precision

2018-01-26 Thread Thomas Preudhomme
Hi Alexander, As mentioned in [1], Arm Cortex-R52 can have either single precision or double precision + Neon. This is reflected in GCC 8 by -mcpu=cortex-r52 defaulting to the latter (double precision + Neon) and -mcpu=cortex-r52+nofp.dp giving you the former (single precision). [1] https://

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

2018-01-26 Thread Rainer Orth
Hi Richard, > On Tue, Jan 16, 2018 at 8:20 PM, Andrew Roberts > wrote: >> Boot strap on Darwin x86_64 with llvm now seems broken as of last 8.0.0 >> snapshot, it still is working fine with 7.2.0. >> I've added bug: 83903 >> >> x86_64, armv6, armv7, aarch64 all seem fine on linux. I've been build

Re: Cortex-r52 FP double precision

2018-01-26 Thread Alexander Fedotov
Thank you Thomas So in order to set dp+Neon for armv8-r I should to use switch "neon-fp-armv8". Not an fpv5-d16. Right ? On Fri, Jan 26, 2018 at 12:52 PM, Thomas Preudhomme wrote: > Hi Alexander, > > As mentioned in [1], Arm Cortex-R52 can have either single precision or > double precision + Neo

Re: Cortex-r52 FP double precision

2018-01-26 Thread Thomas Preudhomme
That or just use -mfpu=auto (as in -mcpu=cortex-r52 -mfpu=auto -mfloat-abi=(softfp|hard)). Best regards, Thomas On 26/01/18 16:44, Alexander Fedotov wrote: Thank you Thomas So in order to set dp+Neon for armv8-r I should to use switch "neon-fp-armv8". Not an fpv5-d16. Right ? On Fri, Jan 26

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

2018-01-26 Thread Andrew Roberts
It might be worth checking what MPFR is linking with in the test suite. I seemed to see it linking with the system libs when built in tree, rather than the in tree ones. This seems a regression in the MPFR test suite compared with 3.1.6 Andrew On 26/01/18 14:22, Rainer Orth wrote: I've given

gcc generated memcpy calls symbol version

2018-01-26 Thread Tom Mason
Hi, I've got a project here: https://github.com/wheybags/glibc_version_header which uses .symver directives to link to a specified version of glibc, so long as it's older than the version on your system. This works, but a problem I'm having is that gcc itself will sometimes insert calls to memcpy (

Re: gcc generated memcpy calls symbol version

2018-01-26 Thread H.J. Lu
On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason wrote: > Hi, > I've got a project here: https://github.com/wheybags/glibc_version_header > which uses .symver directives to link to a specified version of glibc, so > long as it's older than the version on your system. > This works, but a problem I'm hav

Re: gcc generated memcpy calls symbol version

2018-01-26 Thread Tom Mason
I'm not entirely sure I understand that issue. From what I understand, calls to a function in a shared library should always use the PLT? Also, I don't understand the purpose of applying hidden visibility to an extern symbol, But anyway, doesn't matter terribly much if I understand :p On Fri, Jan

Re: gcc generated memcpy calls symbol version

2018-01-26 Thread H.J. Lu
On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason wrote: > I'm not entirely sure I understand that issue. From what I understand, calls > to a function in a shared library should always use the PLT? > Also, I don't understand the purpose of applying hidden visibility to an > extern symbol, There is no n

Re: Bugzilla timing out

2018-01-26 Thread Martin Sebor
On 01/22/2018 11:08 AM, Frank Ch. Eigler wrote: Hi - Problems are still occurring for me; Bugzilla gives me 504 Gateway Time-outs when I try to access it tonight... OK, we reworked some of the database routine maintenance workload, e.g., a nightly cleanup pass that was quite likely excessive,

Re: Bugzilla timing out

2018-01-26 Thread H.J. Lu
On Fri, Jan 26, 2018 at 1:52 PM, Martin Sebor wrote: > On 01/22/2018 11:08 AM, Frank Ch. Eigler wrote: >> >> Hi - >> >>> Problems are still occurring for me; Bugzilla gives me 504 Gateway >>> Time-outs when I try to access it tonight... >> >> >> OK, we reworked some of the database routine mainten

Re: Bugzilla timing out

2018-01-26 Thread Frank Ch. Eigler
Hi - > Thanks for looking into it. I'm still (or again) seeing very > poor responsiveness. Right now, bringing up an existing bug > takes an entire minute. There has been quite a burst in activity on sourceware.org over the last few hours. Will look further into why, but quite a bit of it may

Re: Bugzilla timing out

2018-01-26 Thread Joseph Myers
On Fri, 26 Jan 2018, Frank Ch. Eigler wrote: > Hi - > > > Thanks for looking into it. I'm still (or again) seeing very > > poor responsiveness. Right now, bringing up an existing bug > > takes an entire minute. > > There has been quite a burst in activity on sourceware.org over the > last few

Re: Bugzilla timing out

2018-01-26 Thread Frank Ch. Eigler
Hi - > Many copies of a 5 MB message have apparently been timing out in > sourceware's spam processing, resulting in sourceware repeatedly accepting > the message while the sender's mail server also times out (sooner) and > keeps resending it. [...] Thanks for the pointer. I tightened up some

Re: Bugzilla timing out

2018-01-26 Thread Martin Sebor
On 01/26/2018 04:08 PM, Frank Ch. Eigler wrote: Hi - Many copies of a 5 MB message have apparently been timing out in sourceware's spam processing, resulting in sourceware repeatedly accepting the message while the sender's mail server also times out (sooner) and keeps resending it. [...] Tha