This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Fix gcc.dg/20050922-*.c
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Mike Stump <mikestump at comcast dot net>
- 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 15:25:16 -0400 (EDT)
- 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> <DB201187-0B79-43DC-A00A-7A587F9295F1 at comcast dot net>
On Fri, 25 Oct 2013, Mike Stump wrote:
> On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> > On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
> >> 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,
But only as allowed by the standard.
No gratuitous leaking of identifiers allowed.
> 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.
Yeah, but in this case it was. None of the standard contents in
stdlib.h need uint32_t, at face value. A look in the C99
standard make me say
<http://sourceware.org/ml/newlib/2013/msg00803.html>.
brgds, H-P