On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson <h...@bitrange.com> wrote: > On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote: >> On Mon, 21 Oct 2013, Mike Stump wrote: >> >>> On Oct 21, 2013, at 3:28 AM, Vidya Praveen <vidyaprav...@arm.com> wrote: >>>> Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This >>>> can >>>> be a issue especially since they define uint32_t. >>> >>>> OK for 4.7, 4.8? >>> >>> For release branches, you'd need to transition from the >>> theoretical to the practical. On which systems (software) >>> does >>> it fail? If none, then no, a back port isn't necessary. If >>> it >>> fails on a system (or software) on which real users use, then >>> I'll approve it once you name the system (software) and let it >>> bake on trunk for a week and see if anyone objects? >> >> I too would like to include this change on those branches, as >> recent generic newlib changes has caused these tests to break >> (regress) for my autotester for cris-elf testing those branches. > > Uhm, I'm on the fence, half-way wanting to retract my > suggestion. This seems a recent bug in newlib, in which e.g. > #include <stdlib.h> causes uint32_t to be defined, bleeding from > newlib-internal include of stdint.h. On the other hand, testing > that bleed isn't the purpose of these tests.
Ah, that's what I was interested in, recent change in newlib; that makes it even more reasonable to me. Standard headers are supposed to include all headers they need, and if they need uint32_t (or any of the types the header that defines that type has in it) in an interface in any header that that header needs… then it isn't a gratuitous stupidity.
