This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Chen Gang <gang dot chen dot 5i5j at gmail dot com>
- Cc: Mike Stump <mikestump at comcast dot net>, Jeff Law <law at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, rth at redhat dot com, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 18 Aug 2014 18:07:39 +0800
- Subject: Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
- Authentication-results: sourceware.org; auth=none
- References: <53D126DC dot 8030609 at gmail dot com> <53DAC502 dot 5040403 at redhat dot com> <53E6528C dot 8030309 at gmail dot com> <D49CD01C-B1C8-47DE-9A75-CA6E96965B4A at comcast dot net> <53E72A21 dot 2000904 at gmail dot com> <53F08862 dot 3050003 at gmail dot com> <CAHFci29u1qC6G_oELPhAm3mrEVRe_7zqwyZO8w6cW5JFnB2yxw at mail dot gmail dot com> <53F1D023 dot 3020008 at gmail dot com>
On Mon, Aug 18, 2014 at 6:06 PM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
> On 08/18/2014 03:05 PM, Bin.Cheng wrote:
>> On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
>>> On 08/10/2014 04:15 PM, Chen Gang wrote:
>>>> On 08/10/2014 04:03 PM, Mike Stump wrote:
>>>>> On Aug 9, 2014, at 9:55 AM, Chen Gang <gang.chen.5i5j@gmail.com> wrote:
>>>>>>> <save various .sum files>
>>>>>>
>>>>>> Excuse me, I can not find it with `find ./ | grep "\.sum$"`
>>>>>
>>>>> Then you didn't do a test suite run. make check will create .sum files. Try cd gcc && make check. Then in testsuite/gcc/gcc.sum there will be a file.
>>>>>
>>>
>>> After check again, I found, I did not install runtest (but it skipped,
>>> and let "make check" OK), after install from 'dejagnu', can have real
>>> effect. At present (just running "make check"), some results are:
>>>
>>> Running /upstream/toolchain/gcc/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
>>> FAIL: gcc.c-torture/compile/20001226-1.c -O0 (internal compiler error)
>>> FAIL: gcc.c-torture/compile/20001226-1.c -O0 (test for excess errors)
>>> FAIL: gcc.c-torture/compile/20001226-1.c -O3 -g (internal compiler error)
>>> FAIL: gcc.c-torture/compile/20001226-1.c -O3 -g (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-blockid.c -O0 (internal compiler error)
>>> FAIL: gcc.c-torture/compile/limits-blockid.c -O0 (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-caselabels.c -O1 (internal compiler error)
>>> FAIL: gcc.c-torture/compile/limits-caselabels.c -O1 (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-enumconst.c -O0 (internal compiler error)
>>> FAIL: gcc.c-torture/compile/limits-enumconst.c -O0 (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-enumconst.c -O1 (internal compiler error)
>>> FAIL: gcc.c-torture/compile/limits-enumconst.c -O1 (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-enumconst.c -O3 -g (internal compiler error)
>>> FAIL: gcc.c-torture/compile/limits-enumconst.c -O3 -g (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-enumconst.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)
>>> FAIL: gcc.c-torture/compile/limits-enumconst.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-externalid.c -O3 -g (internal compiler error)
>>> FAIL: gcc.c-torture/compile/limits-externalid.c -O3 -g (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-externalid.c -Os (internal compiler error)
>>> FAIL: gcc.c-torture/compile/limits-externalid.c -Os (test for excess errors)
>>> FAIL: gcc.c-torture/compile/limits-externdecl.c -O2 (test for excess errors)
>> Hi,
>> You can run below command for a single failed case, which makes it
>> easier to identify the problem.
>> $ make check-gcc RUNTESTFLAGS="compile.exp=20001226-1.c"
>> Then you could look into file gcc/testsuite/gcc/gcc.log for stack
>> back-trace of internal compiler error. Usually ICE is easy to
>> reslove, most likely your change overlooks some simple cases.
>>
>
> Thank you very much for your details explanation, if possible, I shall
> continue for them when I have time. At least I should know about whether
> they have negative effect with my related patch which I will send to.
>
> Under x86_64 linux, I guess, the reason of these failures are: during
> compiling, I stop and modify gcc source code, then continue to compile,
> so they may fail.
>
> Under x86_64 mac, I did not touch anything during compiling, and compile
> the 2 directories together:
>
> - one for original latest gcc source code (master for 20140816).
>
> - one for my modification based on the original latest gcc source code.
>
> - they passed building, but for make check, they reported same issues:
>
> ...
>
> FAIL: g++.dg/abi/covariant4.C -std=c++98 (internal compiler error)
> FAIL: g++.dg/abi/covariant4.C -std=c++98 (test for excess errors)
> FAIL: g++.dg/abi/covariant4.C -std=c++11 (internal compiler error)
> FAIL: g++.dg/abi/covariant4.C -std=c++11 (test for excess errors)
> FAIL: g++.dg/abi/covariant4.C -std=c++1y (internal compiler error)
> FAIL: g++.dg/abi/covariant4.C -std=c++1y (test for excess errors)
> FAIL: g++.dg/abi/dcast1.C -std=c++98 (internal compiler error)
> FAIL: g++.dg/abi/dcast1.C -std=c++98 (test for excess errors)
> FAIL: g++.dg/abi/dcast1.C -std=c++11 (internal compiler error)
> FAIL: g++.dg/abi/dcast1.C -std=c++11 (test for excess errors)
> FAIL: g++.dg/abi/dcast1.C -std=c++1y (internal compiler error)
> FAIL: g++.dg/abi/dcast1.C -std=c++1y (test for excess errors)
> FAIL: g++.dg/abi/thunk4.C -std=c++98 (internal compiler error)
> FAIL: g++.dg/abi/thunk4.C -std=c++98 (test for excess errors)
> FAIL: g++.dg/abi/thunk4.C -std=c++11 (internal compiler error)
> FAIL: g++.dg/abi/thunk4.C -std=c++11 (test for excess errors)
> FAIL: g++.dg/abi/thunk4.C -std=c++1y (internal compiler error)
> FAIL: g++.dg/abi/thunk4.C -std=c++1y (test for excess errors)
> FAIL: g++.dg/abi/thunk5.C -std=c++98 (internal compiler error)
> FAIL: g++.dg/abi/thunk5.C -std=c++98 (test for excess errors)
> FAIL: g++.dg/abi/thunk5.C -std=c++11 (internal compiler error)
> FAIL: g++.dg/abi/thunk5.C -std=c++11 (test for excess errors)
> FAIL: g++.dg/abi/thunk5.C -std=c++1y (internal compiler error)
> FAIL: g++.dg/abi/thunk5.C -std=c++1y (test for excess errors)
> FAIL: g++.dg/abi/vbase15.C -std=c++98 (internal compiler error)
> FAIL: g++.dg/abi/vbase15.C -std=c++98 (test for excess errors)
> FAIL: g++.dg/abi/vbase15.C -std=c++11 (internal compiler error)
> FAIL: g++.dg/abi/vbase15.C -std=c++11 (test for excess errors)
> FAIL: g++.dg/abi/vbase15.C -std=c++1y (internal compiler error)
> FAIL: g++.dg/abi/vbase15.C -std=c++1y (test for excess errors)
> FAIL: g++.dg/abi/vcall1.C -std=gnu++98 (internal compiler error)
> FAIL: g++.dg/abi/vcall1.C -std=gnu++98 (test for excess errors)
> FAIL: g++.dg/abi/vcall1.C -std=gnu++11 (internal compiler error)
> FAIL: g++.dg/abi/vcall1.C -std=gnu++11 (test for excess errors)
> FAIL: g++.dg/abi/vcall1.C -std=gnu++1y (internal compiler error)
> FAIL: g++.dg/abi/vcall1.C -std=gnu++1y (test for excess errors)
> FAIL: g++.dg/abi/vthunk1.C -std=c++98 (internal compiler error)
> FAIL: g++.dg/abi/vthunk1.C -std=c++98 (test for excess errors)
> FAIL: g++.dg/abi/vthunk1.C -std=c++11 (internal compiler error)
> FAIL: g++.dg/abi/vthunk1.C -std=c++11 (test for excess errors)
> FAIL: g++.dg/abi/vthunk1.C -std=c++1y (internal compiler error)
> FAIL: g++.dg/abi/vthunk1.C -std=c++1y (test for excess errors)
> FAIL: g++.dg/cpp0x/constexpr-virtual.C -std=c++11 (internal compiler error)
> FAIL: g++.dg/cpp0x/constexpr-virtual.C -std=c++11 (test for excess errors)
> FAIL: g++.dg/cpp0x/constexpr-virtual.C -std=c++1y (internal compiler error)
> FAIL: g++.dg/cpp0x/constexpr-virtual.C -std=c++1y (test for excess errors)
> ...
>
> For only sending my patch, may I bypass them, and then I shall try to
> analyze them one by one in another time, next?
I think it would be better to resolve test failures before sending
patch for review. For this specific case, I highly doubt all these
ICEs are caused by same reason, you can confirm this by running two
difference cases and check gcc.log file. If that's the case, you
could fix the problem then run the regression test again.
Thanks,
bin
>
>
> Welcome any ideas, suggestions or completions.
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed