On Fri, Sep 18, 2015 at 5:10 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > Hello Daniel, > > there was a discussion about this on this mailing list. I think the result > was that GCC is working as intended: > > https://lists.rtems.org/pipermail/devel/2015-July/011879.html
Yes. Semantic is changed but after the discussion we concluded that it is fine; there is however a corner case where the optimization worsens performance, but I concede it's uncommon. Nevertheless the motivation was the recursive calloc() issue; someone recommended -fno-builtin-malloc but I will continue the discussion to see what's the best solution is. We are considering these alternatives: 1) -fno-builtin-malloc: currently works, but I don't like it, because I don't want to disable the gcc's builtin malloc everywhere just because this very case 2) -fno-builtin-calloc: currently doesn't work (and it should); despite I think that the fact that it should work whereas it doesn't is a bug, I don't have a strong position about this, so I want to continue the discussion. 3) flag the function with an optimization() attribute. The attribute is reportedly broken, so this (calloc) fix involves fixing the optimization-related attribute machinery which grows the scope far beyond the original issue. Additionally, I don't like to disable _all_ the optimizations in calloc() just because this one. 4) add a flag to enable/disable the calloc=malloc+memset optimization. Easy to implement, but impacts in all the code just because this function. 5) disable the optimization if the caller function is calloc() itself. This is also somewhat easy to implement, but maybe fragile if calloc calls another function that does the malloc+memset. I'm sympathetic towards 2 and 5. I will get consensus with other gcc maintainers and see what comes out and will let you know. Daniel. > > On 17/09/15 21:39, Daniel Gutson wrote: >> >> Hi, >> >> we are working towards compiling RTEMS for gcc 5.2 (since we are >> working in a fork of the latter). >> >> We found a bug that Sebastian previously found, which I reported here: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618 >> Not only it causes calloc() to call itself (recursively), but the >> (arguably) optimization severely breaks the semantic as shown in the >> bug report. >> >> Andres will fix it and will let you know about the progress. >> >> Thanks, >> >> Daniel. >> > > -- > 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. > -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel