This is the mail archive of the
mailing list for the GCC project.
Re: Problem with 447.dealII in spec2006 because of r240707
- From: C Bergström <cbergstrom at pathscale dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Marek Polacek <polacek at redhat dot com>, Andrew Pinski <pinskia at gmail dot com>, Bill Seurer <seurer at linux dot vnet dot ibm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 4 Oct 2016 23:45:59 +0800
- Subject: Re: Problem with 447.dealII in spec2006 because of r240707
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <CA+=Sn1mXuf5_cMftrkMNHe9facRngTPJNhMns1Mu47KXGgUbGw@mail.gmail.com> <20161004154112.GM3223@redhat.com> <firstname.lastname@example.org>
I'd +1 vote to send them a patch. I've had to do this for other
compilers. If you need a hand, I can give you some tips on how to do
that and also where to check if this has already been fixed.
On Tue, Oct 4, 2016 at 11:43 PM, Jeff Law <email@example.com> wrote:
> On 10/04/2016 09:41 AM, Marek Polacek wrote:
>> On Tue, Oct 04, 2016 at 08:38:00AM -0700, Andrew Pinski wrote:
>>> On Tue, Oct 4, 2016 at 8:33 AM, Bill Seurer <firstname.lastname@example.org>
>>>> parameter_handler.cc: In member function 'double
>>>> ParameterHandler::get_double(const string&) const':
>>>> parameter_handler.cc:777:28: error: ISO C++ forbids comparison between
>>>> pointer and integer [-fpermissive]
>>>> AssertThrow ((s.c_str()!='\0') || (*endptr == '\0'),
>>>> With the recent revision r240707 comparing a pointer with \0 became an
>>>> error. Unfortunately this is used in several spots in the test case
>>>> 447.dealII in spec2006 (one example above). There doesn't appear to be
>>>> way to disable this error check and we're not supposed to change the
>>>> test cases. Any ideas on how to work around this?
>>> Did you try -fpermissive ? Because that seems like it was listed ...
>> -fpermissive ought to help, but really best would be to use NULL instead
>> of '\0'...
> And report the issue to SPEC. They sometimes are willing to fix SPEC when
> the code is clearly wrong.