This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Fix gcc.dg/20050922-*.c
- From: Mike Stump <mikestump at comcast dot net>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: Vidya Praveen <vidyapraveen at arm dot com>, gcc-patches at gcc dot gnu dot org, rearnsha at arm dot com, marcus dot shawcroft at arm dot com, janisjo at codesourcery dot com
- Date: Fri, 25 Oct 2013 09:14:55 -0700
- Subject: Re: [Patch] Fix gcc.dg/20050922-*.c
- Authentication-results: sourceware.org; auth=none
- References: <20131021102832 dot GB3343 at e103625-lin dot cambridge dot arm dot com> <5754744A-BD8A-4231-B481-B2AA44D9A48A at comcast dot net> <alpine dot BSF dot 2 dot 02 dot 1310241754300 dot 21715 at arjuna dot pair dot com> <alpine dot BSF dot 2 dot 02 dot 1310242231010 dot 42187 at arjuna dot pair dot com>
On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson <email@example.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 <firstname.lastname@example.org> 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)
>>> it fail? If none, then no, a back port isn't necessary. If
>>> 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.