Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 15/8/19 4:10 pm, Sebastian Huber wrote: > - Am 15. Aug 2019 um 0:43 schrieb Chris Johns chr...@rtems.org: > >> On 14/8/19 5:38 pm, Sebastian Huber wrote: >>> On 14/08/2019 09:25, Sebastian Huber wrote: On 14/08/2019 09:09, Chris Johns wrote: > On 14/8/19 4:52 pm, Sebastian Huber wrote: >> On 14/08/2019 08:52, Chris Johns wrote: > [...] >> 4. Update the ARM BSPs to use the new machine options. > Is there something that documents the changes we need to make? No, you have to compare the multilib configurations in GCC 7 and 9. >> >> I was after something that says change `xxx` to `yyy`. I am happy to do the >> change, I do not have the time to figure which options are which. > > I can do that. I don't know the mapping off hand. I have to look at the new > multilib options. > Thank you, I would feel more comfortable following your lead. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
- Am 15. Aug 2019 um 0:43 schrieb Chris Johns chr...@rtems.org: > On 14/8/19 5:38 pm, Sebastian Huber wrote: >> On 14/08/2019 09:25, Sebastian Huber wrote: >>> >>> On 14/08/2019 09:09, Chris Johns wrote: On 14/8/19 4:52 pm, Sebastian Huber wrote: > On 14/08/2019 08:52, Chris Johns wrote: [...] > 4. Update the ARM BSPs to use the new machine options. Is there something that documents the changes we need to make? >>> >>> No, you have to compare the multilib configurations in GCC 7 and 9. > > I was after something that says change `xxx` to `yyy`. I am happy to do the > change, I do not have the time to figure which options are which. I can do that. I don't know the mapping off hand. I have to look at the new multilib options. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/8/19 5:38 pm, Sebastian Huber wrote: > On 14/08/2019 09:25, Sebastian Huber wrote: >> >> On 14/08/2019 09:09, Chris Johns wrote: >>> On 14/8/19 4:52 pm, Sebastian Huber wrote: On 14/08/2019 08:52, Chris Johns wrote: On ARM a breaking change in compiler options is necessary. >>> What options are these? >> ARM changed the FPU options in GCC 8 and later. >> >>> Also this seems back to front to me. Should all hosts be on 9.2.0 and >>> those >>> that >>> cannot have specific versions? >> Only PowerPC should stay at GCC 7 until the next RTEMS release from my >> point of >> view. Everything else can move on. > Awesome. To make sure I understand the steps ... > > 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc > 2. Set the default to gcc-9.2.0 > 3. Move all other archs to the defaults > > ? Yes, and: 4. Update the ARM BSPs to use the new machine options. >>> Is there something that documents the changes we need to make? >> >> No, you have to compare the multilib configurations in GCC 7 and 9. I was after something that says change `xxx` to `yyy`. I am happy to do the change, I do not have the time to figure which options are which. > Are you looking for information for users of ARM BSPs which have to update > their > hard-coded compiler options? No, we have to provide this information > somewhere. No, users who hard code options into their applications will have to update. We do not have a way to convey this detail at this point in time, may be a section in the user manual. My long term wish is to provide a stable interface to RTEMS that provides these flags. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/08/2019 09:25, Sebastian Huber wrote: On 14/08/2019 09:09, Chris Johns wrote: On 14/8/19 4:52 pm, Sebastian Huber wrote: On 14/08/2019 08:52, Chris Johns wrote: On ARM a breaking change in compiler options is necessary. What options are these? ARM changed the FPU options in GCC 8 and later. Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? Only PowerPC should stay at GCC 7 until the next RTEMS release from my point of view. Everything else can move on. Awesome. To make sure I understand the steps ... 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc 2. Set the default to gcc-9.2.0 3. Move all other archs to the defaults ? Yes, and: 4. Update the ARM BSPs to use the new machine options. Is there something that documents the changes we need to make? No, you have to compare the multilib configurations in GCC 7 and 9. Are you looking for information for users of ARM BSPs which have to update their hard-coded compiler options? No, we have to provide this information somewhere. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/08/2019 09:09, Chris Johns wrote: On 14/8/19 4:52 pm, Sebastian Huber wrote: On 14/08/2019 08:52, Chris Johns wrote: On ARM a breaking change in compiler options is necessary. What options are these? ARM changed the FPU options in GCC 8 and later. Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? Only PowerPC should stay at GCC 7 until the next RTEMS release from my point of view. Everything else can move on. Awesome. To make sure I understand the steps ... 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc 2. Set the default to gcc-9.2.0 3. Move all other archs to the defaults ? Yes, and: 4. Update the ARM BSPs to use the new machine options. Is there something that documents the changes we need to make? No, you have to compare the multilib configurations in GCC 7 and 9. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/8/19 4:52 pm, Sebastian Huber wrote: > On 14/08/2019 08:52, Chris Johns wrote: > On ARM a breaking change in compiler options is necessary. What options are these? >>> ARM changed the FPU options in GCC 8 and later. >>> Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? >>> Only PowerPC should stay at GCC 7 until the next RTEMS release from my >>> point of >>> view. Everything else can move on. >> Awesome. To make sure I understand the steps ... >> >> 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc >> 2. Set the default to gcc-9.2.0 >> 3. Move all other archs to the defaults >> >> ? > > Yes, and: > > 4. Update the ARM BSPs to use the new machine options. Is there something that documents the changes we need to make? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/08/2019 08:52, Chris Johns wrote: On ARM a breaking change in compiler options is necessary. What options are these? ARM changed the FPU options in GCC 8 and later. Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? Only PowerPC should stay at GCC 7 until the next RTEMS release from my point of view. Everything else can move on. Awesome. To make sure I understand the steps ... 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc 2. Set the default to gcc-9.2.0 3. Move all other archs to the defaults ? Yes, and: 4. Update the ARM BSPs to use the new machine options. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/8/19 3:02 pm, Sebastian Huber wrote: > On 14/08/2019 01:52, Chris Johns wrote: >> On 13/8/19 3:02 pm, Sebastian Huber wrote: >> >>> the patch just changed GCC 9.1 to 9.2 on all targets which use GCC 9, these >>> are >>> or1k, riscv, and x86_64. >> >> The change as broken MacOS due to this bug ... >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 >> >> I posted build results showing the error is still present. I had a patch in >> the >> previous version and it should apply. > > Now I am a bit confused. This patch > > https://git.rtems.org/rtems-source-builder/commit/?id=5a0dba77b13eec49f86ce3812fb74f65dfa1e98d > > > changes the GCC version from 9.1.0 to 9.2.0 on or1k, riscv, and x86_64. I > didn't > change the patches: > > https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-gcc-9.1.0-newlib-6661a67.cfg?id=5a0dba77b13eec49f86ce3812fb74f65dfa1e98d OK and thanks. I will have a look next week to see what is happening. > The GCC bug doesn't seem to be a GCC 9.1.0 to 9.2.0 regression. In your build > log only riscv failed, or1k and x86_64 passed. Is this a sporadic problem? Yes. No one has chased the issue down and the reason it happens so solutions and fixes currently are and nothing more than speculation. It may not fail and it does not fail for some. On a faster Mac then my mini it is easier to have happen. >>> Since there will be probably no RTEMS 5 in the near future, maybe we should >>> move >>> to GCC 9.2 in general. >> >> This is a catch-22, I hope to start on the release process soon but things >> like >> this add to the complexity and add to the time it takes. >> >>> If we do this on PowerPC, then the SPE is no longer supported. >> >> Joel has stated many times in talks I have seen that we follow the >> architectures >> GCC supports and if one is removed we remove support. >> >> Does this mean 5.1 is the last version of RTEMS to support SPE? > > This was my plan. OK. >> Should the specific BSPs be moved to tier 4 and marked for removal? > > The SPE support should bit rot for a while. The chips are still in production > and used with RTEMS, e.g. by EPICS users. When we release we need to make sure these users know this is the case. I am not sure how we should do that. >>> On ARM a breaking change in compiler options is necessary. >> >> What options are these? > > ARM changed the FPU options in GCC 8 and later. > >> >> Also this seems back to front to me. Should all hosts be on 9.2.0 and those >> that >> cannot have specific versions? > > Only PowerPC should stay at GCC 7 until the next RTEMS release from my point > of > view. Everything else can move on. Awesome. To make sure I understand the steps ... 1. Move gcc-fb371a33fa6 to 5/rtems-powerpc 2. Set the default to gcc-9.2.0 3. Move all other archs to the defaults ? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 14/08/2019 01:52, Chris Johns wrote: On 13/8/19 3:02 pm, Sebastian Huber wrote: the patch just changed GCC 9.1 to 9.2 on all targets which use GCC 9, these are or1k, riscv, and x86_64. The change as broken MacOS due to this bug ... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 I posted build results showing the error is still present. I had a patch in the previous version and it should apply. Now I am a bit confused. This patch https://git.rtems.org/rtems-source-builder/commit/?id=5a0dba77b13eec49f86ce3812fb74f65dfa1e98d changes the GCC version from 9.1.0 to 9.2.0 on or1k, riscv, and x86_64. I didn't change the patches: https://git.rtems.org/rtems-source-builder/tree/rtems/config/tools/rtems-gcc-9.1.0-newlib-6661a67.cfg?id=5a0dba77b13eec49f86ce3812fb74f65dfa1e98d The GCC bug doesn't seem to be a GCC 9.1.0 to 9.2.0 regression. In your build log only riscv failed, or1k and x86_64 passed. Is this a sporadic problem? Since there will be probably no RTEMS 5 in the near future, maybe we should move to GCC 9.2 in general. This is a catch-22, I hope to start on the release process soon but things like this add to the complexity and add to the time it takes. If we do this on PowerPC, then the SPE is no longer supported. Joel has stated many times in talks I have seen that we follow the architectures GCC supports and if one is removed we remove support. Does this mean 5.1 is the last version of RTEMS to support SPE? This was my plan. Should the specific BSPs be moved to tier 4 and marked for removal? The SPE support should bit rot for a while. The chips are still in production and used with RTEMS, e.g. by EPICS users. On ARM a breaking change in compiler options is necessary. What options are these? ARM changed the FPU options in GCC 8 and later. Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? Only PowerPC should stay at GCC 7 until the next RTEMS release from my point of view. Everything else can move on. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
On 13/8/19 3:02 pm, Sebastian Huber wrote: > the patch just changed GCC 9.1 to 9.2 on all targets which use GCC 9, these > are > or1k, riscv, and x86_64. The change as broken MacOS due to this bug ... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 I posted build results showing the error is still present. I had a patch in the previous version and it should apply. > Since there will be probably no RTEMS 5 in the near future, maybe we should > move > to GCC 9.2 in general. This is a catch-22, I hope to start on the release process soon but things like this add to the complexity and add to the time it takes. > If we do this on PowerPC, then the SPE is no longer supported. Joel has stated many times in talks I have seen that we follow the architectures GCC supports and if one is removed we remove support. Does this mean 5.1 is the last version of RTEMS to support SPE? Should the specific BSPs be moved to tier 4 and marked for removal? > On ARM a breaking change in compiler options is necessary. What options are these? Also this seems back to front to me. Should all hosts be on 9.2.0 and those that cannot have specific versions? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS 5 gcc-fb371a33fa6 vs gcc-9.2.0
Hello Chris, the patch just changed GCC 9.1 to 9.2 on all targets which use GCC 9, these are or1k, riscv, and x86_64. Since there will be probably no RTEMS 5 in the near future, maybe we should move to GCC 9.2 in general. If we do this on PowerPC, then the SPE is no longer supported. On ARM a breaking change in compiler options is necessary. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
