Stepping down as x86 vector ISA maintainer
I would like to inform GCC community, that I decided to step down from maintaining x86 vector ISA part. x86 vector ISA has its own non-responsive maintainer, but I have filled the maintainers role nevertheless, until gcc-10 was released. Unfortunately, maintaining the whole x86 target has been too much of a burden to me, so I decided to wind down my involvment in x86 vector ISA part. I still plan to take part in reviewing the core of x86 target, including x87 and SSE math, but without stringop infrastructure and tuning, for whose Honza has much deeper understanding than me. Thanks for your understanding, Uros.
Re: Stepping down as x86 vector ISA maintainer
On Wed, 3 Jun 2020, Uros Bizjak wrote: > I would like to inform GCC community, that I decided to step down from > maintaining x86 vector ISA part. x86 vector ISA has its own > non-responsive maintainer, but I have filled the maintainers role > nevertheless, until gcc-10 was released. > > Unfortunately, maintaining the whole x86 target has been too much of a > burden to me, so I decided to wind down my involvment in x86 vector > ISA part. I still plan to take part in reviewing the core of x86 > target, including x87 and SSE math, but without stringop > infrastructure and tuning, for whose Honza has much deeper > understanding than me. Thanks for all your hard work! Richard. > Thanks for your understanding, > Uros.
Re: Stepping down as x86 vector ISA maintainer
On Wed, Jun 03, 2020 at 09:25:35AM +0200, Uros Bizjak via Gcc wrote: > I would like to inform GCC community, that I decided to step down from > maintaining x86 vector ISA part. x86 vector ISA has its own > non-responsive maintainer, but I have filled the maintainers role > nevertheless, until gcc-10 was released. Thank you for all your reviews, it has been greatly appreciated. Jakub
Re: [PATCH 0/5] some vxworks patches
Hi Rasmus, > On 26 May 2020, at 16:52, Rasmus Villemoes wrote: > > Hi Olivier et al > > I'm having quite a bit of trouble getting gcc 10 to build for our > vxworks 5 (5.5.1) target. The first thing I hit is > > #if !defined(_WRS_VXWORKS_MAJOR) > #error "VxWorks version macros needed but not defined" > #endif > > Our version.h doesn't define that macro (however, there's a > _WRS_VXWORKS_5_X defined in vxWorks.h). Amusingly, a few of the system > headers do mention _WRS_VXWORKS_MAJOR, e.g. > > getOptLib.h:#include "vxWorks.h" /* for _WRS_VXWORKS_MAJOR, if defined. */ > > and everywhere in the headers that use that macro, they are careful to > do "#if defined (_WRS_VXWORKS_MAJOR) && (_WRS_VXWORKS_MAJOR >= 6)". > > For now, I've just monkey-patched _vxworks-versions.h to get the build > past that - I suppose what I should do is to patch our version.h > system header instead to provide those two macros. > > But most of the gthread stuff simply doesn't build against our > headers. These five patches, and a bogus definition of WIND_USR > environment variable (-mrtp doesn't make sense for us, but > vx_crtbegin-rtp.o still gets built and that fails if WIND_USR doesn't > exist) get the build a little further - I then fail to build > libstdc++, but I'd like some feedback on whether vxworks 5 is even > supposed to be (still) supported before digging further. 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. Your message comes in timely - I was about to send a note mentioning this soon now, as we are starting a transition of all our production toolchains to gcc-10 and we are resuming posting updates upstream as stage1 has just reopened. The system environment on 5 and 6 is essentially frozen. Maintaining new versions of gcc operational on such legacy versions is increasingly difficult with every release as incompatibilities of various degrees of subtlety keep creeping in. Build failures are one thing and can often be addressed, but we have witnessed, for example, issues with newer dwarf constructs incorrectly processed by the system unwind lib or wrong code gen problems on arm for vx6 related to the use of a long deprecated ABI. 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. The series you sent seem to fit well and I'm getting to them more closely. Thanks Olivier > Rasmus Villemoes (5): > libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5 > gthr-vxworks.h: fix leftover _VXW_PRE_69 > gthr-vxworks.c: add include of taskLib.h > libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x > libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x > > libgcc/config/gthr-vxworks-cond.c | 4 > libgcc/config/gthr-vxworks-thread.c | 4 > libgcc/config/gthr-vxworks-tls.c| 5 + > libgcc/config/gthr-vxworks.c| 1 + > libgcc/config/gthr-vxworks.h| 10 +++--- > 5 files changed, 21 insertions(+), 3 deletions(-) > > -- > 2.23.0 >
Re: [PATCH 2/5] gthr-vxworks.h: fix leftover _VXW_PRE_69
> On 26 May 2020, at 16:52, Rasmus Villemoes wrote: > > _VXW_PRE_69 was introduced in 806dd0472f, then replaced by > _VXWORKS_PRE(6,9) in abb6c3eecf, but this one was missed. > > Fixes: abb6c3eecf (Introduce an internal API for VxWorks version checks) > --- > libgcc/config/gthr-vxworks.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h > index 8b55fc55407..e38174730bf 100644 > --- a/libgcc/config/gthr-vxworks.h > +++ b/libgcc/config/gthr-vxworks.h > @@ -286,7 +286,7 @@ typedef struct > typedef __gthread_tcb *__gthread_t; > > /* Typedefs specific to different vxworks versions. */ > -#if _VXW_PRE_69 > +#if _VXWORKS_PRE(6,9) > typedef int _Vx_usr_arg_t; > #define TASK_ID_NULL ((TASK_ID)NULL) > #define SEM_ID_NULL ((SEM_ID)NULL) Ok, thanks. Olivier
Re: Stepping down as x86 vector ISA maintainer
On Wed, Jun 3, 2020 at 12:25 AM Uros Bizjak wrote: > > I would like to inform GCC community, that I decided to step down from > maintaining x86 vector ISA part. x86 vector ISA has its own > non-responsive maintainer, but I have filled the maintainers role > nevertheless, until gcc-10 was released. > > Unfortunately, maintaining the whole x86 target has been too much of a > burden to me, so I decided to wind down my involvment in x86 vector > ISA part. I still plan to take part in reviewing the core of x86 > target, including x87 and SSE math, but without stringop > infrastructure and tuning, for whose Honza has much deeper > understanding than me. > > Thanks for your understanding, > Uros. Thanks for your hard works over the years. Wish you the best. -- H.J.
Support for named address spaces in C++
Hi all, I’ve added a named address space to our backend and I noticed that it is only support in C. Has anyone had experience porting this feature to C++? Is there any technical reason why it’s not supported? Thank you, Max
Re: Support for named address spaces in C++
On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc wrote: > > Hi all, > > I’ve added a named address space to our backend and I noticed that it is only > support in C. > Has anyone had experience porting this feature to C++? Is there any technical > reason why it’s not supported? The main issue is how it is interacts with templates and then mangling. There was a few other issues that have been posted about before every time it is raised. Thanks, Andrew > > Thank you, > Max
