Re: [Patch] Fix gcc.dg/20050922-*.c

2013-11-18 Thread Mike Stump 
On Nov 18, 2013, at 3:09 AM, Vidya Praveen  wrote:
>> Ok, let it bake on trunk and then you can back port it if no one screams.
> 
> I think it has baked long enough. Could this be approved for 4.7 and 4.8 now?

Oh, that was pre-approval to back port, conditional on no fallout and no 
screams…  If there is no compelling reason to not back port it, then Ok.

Re: Re: [Patch] Fix gcc.dg/20050922-*.c

2013-11-18 Thread Vidya Praveen 

Mike,

On 25/10/13 00:37, Mike Stump wrote:

On Oct 24, 2013, at 2:26 AM, Vidya Praveen  wrote:

On Mon, Oct 21, 2013 at 06:40:28PM +0100, Mike Stump wrote:

On Oct 21, 2013, at 3:28 AM, Vidya Praveen  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?


It fails on arm-none-eabi.


Ok, let it bake on trunk and then you can back port it if no one screams.



I think it has baked long enough. Could this be approved for 4.7 and 4.8 now?

VP.

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-25 Thread Hans-Peter Nilsson 
On Fri, 25 Oct 2013, Mike Stump wrote:
> On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson  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  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
.

brgds, H-P

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-25 Thread Mike Stump 
On Oct 24, 2013, at 7:33 PM, Hans-Peter Nilsson  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  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  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.

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-24 Thread Hans-Peter Nilsson 
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  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  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.

brgds, H-P

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-24 Thread Mike Stump 
On Oct 24, 2013, at 2:26 AM, Vidya Praveen  wrote:
> On Mon, Oct 21, 2013 at 06:40:28PM +0100, Mike Stump wrote:
>> On Oct 21, 2013, at 3:28 AM, Vidya Praveen  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?
> 
> It fails on arm-none-eabi. 

Ok, let it bake on trunk and then you can back port it if no one screams.

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-24 Thread Hans-Peter Nilsson 


On Mon, 21 Oct 2013, Mike Stump wrote:

> On Oct 21, 2013, at 3:28 AM, Vidya Praveen  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.

brgds, H-P

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-24 Thread Vidya Praveen 
On Mon, Oct 21, 2013 at 05:47:44PM +0100, Jeff Law wrote:
> On 10/21/13 04:28, Vidya Praveen wrote:
> > Hello,
> >
> > 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. Testcase writing 
> > guidelines
> > discourages such inclusion as well.
> >
> > This patch replaces these #includes with manual declarations.
> >
> > Tested for aarch64-none-elf, arm-none-eabi and x86_64-linux-gnu
> >
> > OK for trunk, 4.7, 4.8?
> >
> > VP.
> >
> > ---
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2013-10-21  Vidya Praveen  
> >
> > * gcc.dg/20050922-1.c: Remove stdlib.h and declare abort().
> > * gcc.dg/20050922-1.c: Remove stdlib.h and declare abort() and exit().
> OK & installed on trunk.
> 
> Release managers would need to make a decision about whether or not to 
> include this for the 4.7/4.8 branches.
> 

Thanks Jeff!

VP.

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-24 Thread Vidya Praveen 
On Mon, Oct 21, 2013 at 06:40:28PM +0100, Mike Stump wrote:
> On Oct 21, 2013, at 3:28 AM, Vidya Praveen  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?
>

It fails on arm-none-eabi. 

VP.

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-21 Thread Mike Stump 
On Oct 21, 2013, at 3:28 AM, Vidya Praveen  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…

Re: [Patch] Fix gcc.dg/20050922-*.c

2013-10-21 Thread Jeff Law 

On 10/21/13 04:28, Vidya Praveen wrote:

Hello,

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. Testcase writing guidelines
discourages such inclusion as well.

This patch replaces these #includes with manual declarations.

Tested for aarch64-none-elf, arm-none-eabi and x86_64-linux-gnu

OK for trunk, 4.7, 4.8?

VP.

---

gcc/testsuite/ChangeLog:

2013-10-21  Vidya Praveen  

* gcc.dg/20050922-1.c: Remove stdlib.h and declare abort().
* gcc.dg/20050922-1.c: Remove stdlib.h and declare abort() and exit().

OK & installed on trunk.

Release managers would need to make a decision about whether or not to 
include this for the 4.7/4.8 branches.


Thanks,
Jeff