broken gcc 5.2

Daniel Gutson daniel.gutson at tallertechnologies.com
Fri Sep 18 12:45:24 UTC 2015


On Fri, Sep 18, 2015 at 5:10 AM, Sebastian Huber
<sebastian.huber at 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.huber at 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



More information about the devel mailing list