On Thu, Jul 27, 2017 at 7:50 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> Hallo, > > the GCC 7.2 release will be probably in two weeks. I would like to use GCC > 7.2 and the Newlib snapshot 2017-07-20 for the RTEMS 4.12 release > candidate. I propose to do the 4.12 branch one week after the tool chain > update. > I don't mind bumping binutils and gcc. For now, that newlib snapshot is OK but I think we may want to bump to a newer one to catch the added POSIX methods from Aditya. What concerns me is: https://devel.rtems.org/milestone/4.12.0 which still shows 80 tickets and I still don't think there is one describing the x86 breakage on libbsd. I have no idea how many of those should be addressed. These should be evaluated rather than just kicked down the road. I did a build sweep with fresh tools yesterday. All BSPs built in my configuration and the warnings are in OK shape. I have filed some tickets about a few but most of these are very easy to fix for the right person. Here are some areas by person who could fix quickly. Out of 57 unique warnings: + 12 are in libdebugger(Chris) + 6-8 are in BSPs or termios that I think you need to look at. + 7 are in new mmap code (Gedare) It would be great if the core developers could take a look at the full report and see what can be eliminated ftp://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-4.12-master-20170726/ There are somie warnings for the static asserts. I suspect these are due to BSPs are low optimization levels. So I would like to make sure we: + know the state of all tickets and consciously make a decision on them. + address some of these warnings. That doesn't begin to address whether BSPs work or odd issues like do we switch to Couverture for qemu. I'm not trying to be an impediment. I just want a burn down list. --joel > > -- > 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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
