Re: Max Filippov appointed Xtensa maintainer
On Fri, Jun 5, 2020 at 5:50 PM David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Max Filippov as Xtensa maintainer. Thank you for your trust. > Please join me in congratulating Max on his new role. > Max, please update your listing in the MAINTAINERS file. Updated as follows: 2020-06-06 Max Filippov * MAINTAINERS: Add myself as xtensa port maintainer. --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5528aad5e232..d1343d33f1ab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -118,6 +118,7 @@ visium portEric Botcazou x86-64 portJan Hubicka xstormy16 portNick Clifton xtensa portSterling Augustine +xtensa portMax Filippov OS Port Maintainers(OS alphabetical order) @@ -383,7 +384,6 @@ Chris Fairles Alessandro Fanfarillo Changpeng Fang Li Feng -Max Filippov Thomas Fitzsimmons Alexander Fomin Brian Ford -- Thanks. -- Max
Re: gcc math functions for OpenMP vectoization
* Toon Moene: > On 6/5/20 6:10 PM, Tobias Burnus wrote: > >> On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote: > >>> It is glibc that provides them, not GCC. >>> See >>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD >>> >>> >> >> Minor addition: That header file is included in math.h, i.e. >> automatically available. >> For Fortran/gfortran there is math-vector-fortran.h (also provided by >> glibc) >> which has the same functions and a similar effect. > > I wonder if there are Linux distributions where this actually effected > already. > > I know for sure that it is not in Debian Testing (as of two weeks ago) > and Red Hat Fedora 30 (similarly). > > Do you know of any ? I think we backported the header file into Red Hat Enterprise Linux 8.2. So CentOS 8 should have it as well. The system compiler is too old to use it, but GCC Toolset 9 comes with a Fortran compiler that should pick it up (but I don't use Fortran myself).
Re: [PATCH 0/5] some vxworks patches
Hi Rasmus, > On 04 Jun 2020, at 15:31, Rasmus Villemoes wrote: > >> Unfortunately, no, not really: while we don't break it >> intentionally, it was transitioned to End Of Life a couple >> of years a ago and we don't test on such configurations >> any more. >> >> We are gradually going to a similar path for VxWorks 6, with 6.8 >> EOL since July 2019 and 6.9 turned Legacy early 2020 after ~9 years >> out. > > Hi Olivier, > > Thanks for the answer, though obviously not what I was hoping for. > Just for the record, who exactly are "we" above? AdaCore. >> We can take patches that are reported as helping such cases, >> as we have done in the past, as long as they are localized and look >> generally good. But as I mentioned, we are not in a position to >> really test vx5 configurations any more. > > I (and my customer) am willing to put in some effort to make (or keep) > gcc working for vxworks 5. Sounds good, thanks. Out of curiosity, what is your main motivation for keeping upgrading the compiler version on such an environment ? Do you have plans to move to a more recent version of VxWorks at some point ? > In case the ifdeffery in the existing > vxworks-related files becomes too unwieldy, would it be possible to > create a separate vxworks5 target, similar to the existing vxworksae > variant? A priori, I think we could do that as long as it's indeed similar to the existing vxworksae variant in terms of amount/kind of alternate sources and impact. I don't think we should go as far as entirely insulating the vx5 support. We had an issue of the exact same kind when we worked on the introduction of VxWorks7 support, and keeping things factorized helped a lot on a number of accounts. I understand the situation we're discussing is a bit different but most of the benefits remain valid I think. The changes you have so far look generally good (thanks again for proposing them!) and it seems worth pursuing a bit in this direction. I hope the changes we have in the pipe won't make it harder. The vast majority are testsuite updates and ports to other architectures. Otherwise, at a quick glance, a couple of fixincludes related bits which we might even need to revisit before upstreaming, and a minor libstdc++ configuration adjustment. They were issued with at least up to vx6 still in mind and I don't know of cases where we deliberately introduced something with the conscious knowledge that it would break older configurations. For sure, not in a fundamental impossible to recover fashion. Olivier
gcc-10-20200606 is now available
Snapshot gcc-10-20200606 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20200606/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 03da87235697eab344cde609d81d3f405f450c42 You'll find: gcc-10-20200606.tar.xz Complete GCC SHA256=e06067029f258fe83c243be9fc7b5a89e9c83dd7951aa842a6e95f525a4d9218 SHA1=8246cc394b7cf78558d266e83bc101d981d28ffe Diffs from 10-20200530 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
