On 15/07/15 04:17, Chris Johns wrote:
On 15/07/2015 8:15 am, Peter Dufault wrote:
On Jul 13, 2015, at 20:01 , Chris Johns <chr...@rtems.org> wrote:
On 14/07/2015 4:20 am, Joel Sherrill wrote:
On 7/13/2015 1:06 PM, Sebastian Huber wrote:
Yes, this option sounded like the right way to fix it, but...
https://gcc.gnu.org/ml/gcc-help/2015-03/msg00093.html
https://gcc.gnu.org/ml/gcc-help/2015-03/msg00094.html
Ouch! That is a big red flashing sign which says stay away!
And to Gedare's point of raising this as a PR, it is just
an optimization side-effect more than bug.
I wonder if this could impact any code in newlib? It should
have the same issue with the default calloc(). And maybe
some other routines like the string and mem* ones?
For the record can someone please explain why 'calloc' broke with gcc 5
on ARM in the first place ?
What is the code construct in that specific function [1] that is causing
the issue in the first place ? It seems a common type of idiom and I am
sure it must exist in user code.
I’m guessing the optimizer is recognizing that the code sequence used to
implement calloc() matches the definition for the built-in function calloc()
and so changes it to a call to calloc(). That won’t be an issue in (most) user
code.
Agreed, so why is this not a bug in gcc ? Sebastian, is this logged with
gcc ?
I didn't file a PR, only asked on the mailing list. My impression is
that this is not a bug, but a feature that must be disabled by C library
developers.
If the code being optimized is the function 'calloc', which it should
know, then maybe this is not such a good idea to call itself.
Yes, maybe this would complicate the compiler too much for a rare use
case, e.g. C library.
--
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
