[PATCH] Fix PR 35061 (#pragma pop_macro causes ICE if no macro value on stack)
Ian Lance Taylor
iant@google.com
Thu Feb 14 21:33:00 GMT 2008
"Danny Smith" <dansmister@gmail.com> writes:
> On 13 Feb 2008 08:07:05 -0800, Ian Lance Taylor <iant@google.com> wrote:
> >
> > Jakub Jelinek <jakub@redhat.com> writes:
> >
> > > On Tue, Feb 05, 2008 at 06:22:57AM -0700, Tom Tromey wrote:
> > > > >>>>> "Danny" == Danny Smith <dansmister@gmail.com> writes:
> > > >
> > > > Danny> his fixes the ICE reported in PR 35061 (#pragma pop_macro causes ICE
> > > > Danny> if no macro value on stack), which is caused by failing to check that
> > > > Danny> the pushed_macro_table has been allocated.
> > > >
> > > > Danny> Is this OK for 4.4 once 4.3.0 branches?
> > > > Danny> Tested on i686-pc-mingw32
> > > >
> > > > It looks good to me, though I don't think I can approve it.
> > > > Please include the test case as well.
> > > >
> > > > Did you find this ICE on real code? If so then it seems a bit weird
> > > > to me to ship a compiler with a new feature that has a known ICE,
> > > > especially when the fix is so small and obvious.
> > >
> > > Yeah, if this is approved, it should be applied to 4.3 as well as 4.4.
> >
> > I agree.
> >
> > I will approve this patch. Please include the test case as well.
> >
> Just to be sure. Does this approval override the regression-only
> restriction? Or should I mark the bug as a regression (since gcc.4.2
> just warned about an unknown pragma rather than ICEing)?
It doesn't really matter how you mark the PR. This is a bug in a new
feature, so I think the fix should go in. There is no reason to
release a new feature with a bug just because of a rule about
regressions.
A release manager can overrule me, of course.
Ian
More information about the Gcc-patches
mailing list