Re: Cortex-r52 FP double precision
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://developer.arm.com/products/processors/cortex-r/cortex-r52 Best regards, Thomas On 25/01/18 21:22, Alexander Fedotov wrote: Hi, As I understand from this https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master branch doesn't have support of double-precision FPv5 floating-point instructions for ARMv8-R (Cortex-r52). If yes, are there any chances to see them in GCC 8 ? Alex
Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode
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 building >> with latest gmp (6.1.2), mpfr (4.0.0) and mpc (1.1.) across all my systems. >> >> I observe isl was updated to 0.18 in the download_prerequisites script. Are >> the other's going to get updated before the 8.0.0 release? > > Now that mpc 1.1.0 was released we could update the versions if we get > sufficient > "positives" from people testing with newer releases. I've given it a try with that combo on sparc-sun-solaris2.10 (a primary target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed results: * The gmp reuse test enters an infinite loop on 32-bit sparc. * The mpfr trint test FAILs on sparcv9. The failure vanishes with --disable-thread-safe. * Many mpfr tests FAIL on amd64. Again, they vanish with --disable-thread-safe. I have not yet tried building gcc with those versions yet. Beside, IMO we need to make sure that trunk and all open branches can be built with that version set; having to maintain two different sets isn't an option. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Cortex-r52 FP double precision
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 + 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://developer.arm.com/products/processors/cortex-r/cortex-r52 > > Best regards, > > Thomas > > > On 25/01/18 21:22, Alexander Fedotov wrote: >> >> Hi, >> As I understand from this >> https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master >> branch doesn't have support of double-precision FPv5 floating-point >> instructions for ARMv8-R (Cortex-r52). >> If yes, are there any chances to see them in GCC 8 ? >> >> Alex >> > -- Best regards, AF
Re: Cortex-r52 FP double precision
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, 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 + 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://developer.arm.com/products/processors/cortex-r/cortex-r52 Best regards, Thomas On 25/01/18 21:22, Alexander Fedotov wrote: Hi, As I understand from this https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master branch doesn't have support of double-precision FPv5 floating-point instructions for ARMv8-R (Cortex-r52). If yes, are there any chances to see them in GCC 8 ? Alex
Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode
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 it a try with that combo on sparc-sun-solaris2.10 (a primary target) and i386-pc-solaris2.10 (32 and 64-bit each), with mixed results: * The gmp reuse test enters an infinite loop on 32-bit sparc. * The mpfr trint test FAILs on sparcv9. The failure vanishes with --disable-thread-safe. * Many mpfr tests FAIL on amd64. Again, they vanish with --disable-thread-safe. I have not yet tried building gcc with those versions yet. Beside, IMO we need to make sure that trunk and all open branches can be built with that version set; having to maintain two different sets isn't an option. Rainer
gcc generated memcpy calls symbol version
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 (or memmove, memset and memcmp), as documented here: https://gcc.gnu.org/onlinedocs/gcc/Standards.html When it does so, it doesn't respect the .symver directives, and uses the default version. Is there any way for me to force the version for these symbols aswell? I'm aware that I can disable the whole mechanism with -freestanding, but I don't want to cripple the optimiser. Regards, Tom Mason
Re: gcc generated memcpy calls symbol version
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 having is that gcc itself will sometimes > insert calls to memcpy (or memmove, memset and memcmp), as documented here: > https://gcc.gnu.org/onlinedocs/gcc/Standards.html > When it does so, it doesn't respect the .symver directives, and uses the > default version. > Is there any way for me to force the version for these symbols aswell? > I'm aware that I can disable the whole mechanism with -freestanding, but I > don't want to cripple the optimiser. I think this is related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 -- H.J.
Re: gcc generated memcpy calls symbol version
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 26, 2018 at 8:37 PM, H.J. Lu wrote: > 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 having is that gcc itself will sometimes > > insert calls to memcpy (or memmove, memset and memcmp), as documented > here: > > https://gcc.gnu.org/onlinedocs/gcc/Standards.html > > When it does so, it doesn't respect the .symver directives, and uses the > > default version. > > Is there any way for me to force the version for these symbols aswell? > > I'm aware that I can disable the whole mechanism with -freestanding, but > I > > don't want to cripple the optimiser. > > I think this is related to: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 > > -- > H.J. >
Re: gcc generated memcpy calls symbol version
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 need for PLT since hidden symbol is defined locally. But GCC ignores hidden visibility for libcalls, like memcpy. If GCC treats them like normal calls, your scheme and my testcase should work. > But anyway, doesn't matter terribly much if I understand :p > > On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu wrote: >> >> 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 having is that gcc itself will sometimes >> > insert calls to memcpy (or memmove, memset and memcmp), as documented >> > here: >> > https://gcc.gnu.org/onlinedocs/gcc/Standards.html >> > When it does so, it doesn't respect the .symver directives, and uses the >> > default version. >> > Is there any way for me to force the version for these symbols aswell? >> > I'm aware that I can disable the whole mechanism with -freestanding, but >> > I >> > don't want to cripple the optimiser. >> >> I think this is related to: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 >> >> -- >> H.J. > > -- H.J.
Re: Bugzilla timing out
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, and will keep monitoring. 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. Martin
Re: Bugzilla timing out
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 maintenance workload, >> e.g., a nightly cleanup pass that was quite likely excessive, and >> will keep monitoring. > > > 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. > Same here. When I opened a new bug today, it timed out. I had to look up the database to see if I opened it or not. -- H.J.
Re: Bugzilla timing out
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 be anti-spam processing. https://sourceware.org/grafana/index.html#/dashboard/file/default.json - FChE
Re: Bugzilla timing out
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 hours. Will look further into why, but quite a bit of it may > be anti-spam processing. 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. https://sourceware.org/ml/libc-alpha/2018-01/msg00901.html (the list archives uniquify based on message-id, but many separate copies have been delivered to libc-alpha so far each with its own ezmlm sequence number). -- Joseph S. Myers jos...@codesourcery.com
Re: Bugzilla timing out
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 of the timeouts / parallelism associated with spam filtering. - FChE
Re: Bugzilla timing out
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. [...] Thanks for the pointer. I tightened up some of the timeouts / parallelism associated with spam filtering. Thanks. It's a lot snappier now. Martin
