Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/22/2014 12:18 AM, Mike Stump wrote: > On Aug 18, 2014, at 3:06 AM, Chen Gang wrote: >> - 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: > > So, I see no evidence that you ran contrib/compare_tests yet. Did you? If > so, what was the output? > >> For only sending my patch, may I bypass them, > > So, the output of the make check is uninteresting, only the regressions > identified by compare_tests are interesting. If none, then you’re set wrt > the current patch. > OK, thanks. At present, under Fedora 20 x86_64, it passed normal testsuite: - "../gcc/configure && make && make check" succeed (echo $? == 0). - "contrib/compare_test dir_orig dir_new" succeed (echo $? == 0). - The related output of "contrib/compare_test" are: # Comparing directories ## Dir1=/upstream/build-gcc: 11 sum files ## Dir2=/upstream/build-gcc-new: 11 sum files # Comparing 11 common sum files ## /bin/sh ./compare_tests /tmp/gxx-sum1.7678 /tmp/gxx-sum2.7678 # No differences found in 11 common sum files >> and then I shall try to analyze them one by one in another time, next? > > You can, if you want. For example, there is a PR on the darwin issue that > has state in it. Roughly binds local is slightly wrong and need fixing. > OK, thank. I shall still try the Darwin, next, in another time, although it is not related with my new patches for sending. At last: Thank all of you very much for your much help, and I shall send related patch next. Thanks. -- Chen Gang Open share and attitude like air water and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Aug 18, 2014, at 3:06 AM, Chen Gang wrote: > - 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: So, I see no evidence that you ran contrib/compare_tests yet. Did you? If so, what was the output? > For only sending my patch, may I bypass them, So, the output of the make check is uninteresting, only the regressions identified by compare_tests are interesting. If none, then you’re set wrt the current patch. > and then I shall try to analyze them one by one in another time, next? You can, if you want. For example, there is a PR on the darwin issue that has state in it. Roughly binds local is slightly wrong and need fixing.
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/21/2014 03:23 AM, Mike Stump wrote: > On Aug 20, 2014, at 11:29 AM, Chen Gang wrote: >> >> It sounds useful to me. At present, my PC is 4 core, so I guess, -j2 > > No, -j4…. should be around twice as fast as -j2 on your machine (assuming > you aren’t memory starved (4GB or more)). > >> for 2 directories are enough. This time (without "--disable-multilibs), >> I still use 1x, for I am not sure that it must be success. > > Right, the -j won’t impact correctness, only speed of result. > At present, normal "../gcc/configure && make" is OK for both original directory and new directory. tonight, I shall run "make check" (I guess, it shall be OK, too), then try to send related patch tomorrow morning. Thanks. -- Chen Gang Open share and attitude like air water and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Aug 20, 2014, at 11:29 AM, Chen Gang wrote: > > It sounds useful to me. At present, my PC is 4 core, so I guess, -j2 No, -j4…. should be around twice as fast as -j2 on your machine (assuming you aren’t memory starved (4GB or more)). > for 2 directories are enough. This time (without "--disable-multilibs), > I still use 1x, for I am not sure that it must be success. Right, the -j won’t impact correctness, only speed of result.
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/21/2014 01:35 AM, Mike Stump wrote: > On Aug 20, 2014, at 7:26 AM, Chen Gang wrote: >> - for each test, always contents "unexpected errors" for gcc, g++ ... >> but "make check" skip them and continue, at last still "echo $?" = 0. > > I use make -k -j16. It is roughly 16x faster. I’d use -j where n is the > core count. I think -k is useful to ensure all the tests always run. If > make check returns 0, then the -k won’t make a difference. When non-zero, > then it might. > It sounds useful to me. At present, my PC is 4 core, so I guess, -j2 for 2 directories are enough. This time (without "--disable-multilibs), I still use 1x, for I am not sure that it must be success. Thanks. -- Chen Gang Open share and attitude like air water and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Aug 20, 2014, at 7:26 AM, Chen Gang wrote: > - for each test, always contents "unexpected errors" for gcc, g++ ... > but "make check" skip them and continue, at last still "echo $?" = 0. I use make -k -j16. It is roughly 16x faster. I’d use -j where n is the core count. I think -k is useful to ensure all the tests always run. If make check returns 0, then the -k won’t make a difference. When non-zero, then it might.
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/18/2014 06:17 PM, Chen Gang wrote:
> 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 get a new PC, I guess, I have passed "make check" with
"--disable-multilibs" (only spent less 10 hours!):
- "make check" finish return succeed: "echo $?" is 0. And generate 11
"*.sum" files.
- 10 of 11 are the same, the different one is about "gcc.sum", after
check the details contents, it is about my configuration issue, I am
trying run "cd gcc && make check" again, after re-configuration.
- for each test, always contents "unexpected errors" for gcc, g++ ...
but "make check" skip them and continue, at last still "echo $?" = 0.
If what I guess is incorrect, please let me know, thanks.
After finished install gcc*.i686, next, I shall try normal configuration
("enable-multilibs") for "make check". Welcome any ideas, suggestions,
or completions.
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 8/18/14 18:07, Bin.Cheng wrote: > On Mon, Aug 18, 2014 at 6:06 PM, Chen Gang wrote: >> On 08/18/2014 03:05 PM, Bin.Cheng wrote: >>> On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang 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 wrote: >>> >>> 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++
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Mon, Aug 18, 2014 at 6:06 PM, Chen Gang wrote: > On 08/18/2014 03:05 PM, Bin.Cheng wrote: >> On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang 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 wrote: >>> >> >> 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+
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/18/2014 03:05 PM, Bin.Cheng wrote: > On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang 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 wrote: >> > > 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
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Sun, Aug 17, 2014 at 6:48 PM, Chen Gang 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 wrote: > 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. Thanks, bin > ... > > Do these contents mean: I make any incorrect configuration, again? > > >> >> OK, thanks, I built it under individual directory "build-gcc", I guess >> your meaning is "cd ./build-gcc/gcc && make check". If what I guess is >> incorrect, please let me know, thanks. >> After comparing, should the related ".sum" files be the same (same means pass checking)? >>> >>> No, use contrib/compare_tests before_dir after_dir :-) If you _save_off >>> the .sum files, you can use the places where you same them off. If you use >>> two trees, you can just use them directly (no saving off). >>> >>> where the two are the build directories that you did a make check in. The >>> output will be in simple english and should be readily understandable. >>> > > After try, I found your information about 2 build directories are very > useful for me, which can same much time under smp machine. > > And sorry, I did not finish "make check" at the time point. I wasted my > time resources (of my free time) on constructing PC environments and my > x86_64 laptop environments. > > - x86_64 laptop under ubuntu: try to update 'libc6' package to install >'autogen'. At last, I succeed: overwrite libc6 package files under >individual living system, and then modify dpkg config file manually. > > - PC environments: I failed, the reason is my PC hardware is not stable >enough (low quality). After building several hours, the machine will >reboot automatically (tried several times, each needs several hours). > > And I shall try to finish as soon as possible (may tomorrow or the day > after tomorrow, under Mac book, and within a week under x86_64 laptop). > >> >> OK, Thanks, and I shall try to finish within next week (one building is >> still very long, although I have switched to mac book -- more higher >> performance machine). >> >> >> Thanks. >> > > Thanks. > -- > Chen Gang > > Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
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 wrote: >>> >>> 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) ... Do these contents mean: I make any incorrect configuration, again? > > OK, thanks, I built it under individual directory "build-gcc", I guess > your meaning is "cd ./build-gcc/gcc && make check". If what I guess is > incorrect, please let me know, thanks. > >>> After comparing, should the related ".sum" files be the same (same means >>> pass checking)? >> >> No, use contrib/compare_tests before_dir after_dir :-) If you _save_off >> the .sum files, you can use the places where you same them off. If you use >> two trees, you can just use them directly (no saving off). >> >> where the two are the build directories that you did a make check in. The >> output will be in simple english and should be readily understandable. >> After try, I found your information about 2 build directories are very useful for me, which can same much time under smp machine. And sorry, I did not finish "make check" at the time point. I wasted my time resources (of my free time) on constructing PC environments and my x86_64 laptop environments. - x86_64 laptop under ubuntu: try to update 'libc6' package to install 'autogen'. At last, I succeed: overwrite libc6 package files under individual living system, and then modify dpkg config file manually. - PC environments: I failed, the reason is my PC hardware is not stable enough (low quality). After building several hours, the machine will reboot automatically (tried several times, each needs several hours). And I shall try to finish as soon as possible (may tomorrow or the day after tomorrow, under Mac book, and within a week under x86_64 laptop). > > OK, Thanks, and I shall try to finish within next week (one building is > still very long, although I have switched to mac book -- more higher > performance machine). > > > Thanks. > Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/10/2014 04:03 PM, Mike Stump wrote: > On Aug 9, 2014, at 9:55 AM, Chen Gang wrote: >>> >> >> 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. > OK, thanks, I built it under individual directory "build-gcc", I guess your meaning is "cd ./build-gcc/gcc && make check". If what I guess is incorrect, please let me know, thanks. >> After comparing, should the related ".sum" files be the same (same means >> pass checking)? > > No, use contrib/compare_tests before_dir after_dir :-) If you _save_off the > .sum files, you can use the places where you same them off. If you use two > trees, you can just use them directly (no saving off). > > where the two are the build directories that you did a make check in. The > output will be in simple english and should be readily understandable. > OK, Thanks, and I shall try to finish within next week (one building is still very long, although I have switched to mac book -- more higher performance machine). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Aug 9, 2014, at 9:55 AM, Chen Gang wrote: >> > > 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 comparing, should the related ".sum" files be the same (same means > pass checking)? No, use contrib/compare_tests before_dir after_dir :-) If you _save_off the .sum files, you can use the places where you same them off. If you use two trees, you can just use them directly (no saving off). where the two are the build directories that you did a make check in. The output will be in simple english and should be readily understandable.
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 8/10/14 0:55, Chen Gang wrote: > On 8/1/14 6:36, Jeff Law wrote: >> >> make >> make check > > It is OK (I finish the 2 steps under Mac book). > >> > > Excuse me, I can not find it with `find ./ | grep "\.sum$"` > > [...] >> > > After comparing, should the related ".sum" files be the same (same means > pass checking)? > Oh! I guess "<...>" means optional steps, make && make check are enough for simple modification. And I shall send the trivial patch directly, if it really needs additional necessary steps, please reply that thread. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
Excuse me, when I try the testsuite for a new patch which I will send, I realize I should make sure some related information. So I consult for them, please help check, thanks. On 8/1/14 6:36, Jeff Law wrote: > > make > make check It is OK (I finish the 2 steps under Mac book). > Excuse me, I can not find it with `find ./ | grep "\.sum$"` [...] > After comparing, should the related ".sum" files be the same (same means pass checking)? Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 08/01/2014 10:14 AM, Mike Stump wrote: > On Jul 31, 2014, at 6:37 PM, Chen Gang wrote: >> Thank you very much for your work. Especially give a complete sample for >> the whole working flow, which I shall follow. >> >> For me, if no related documents for it, I recommend to put a complete >> sample (e.g. this one) to a related document which can be referenced by >> other newbies. > > https://gcc.gnu.org/contribute.html > Thank you for your information, I shall read it in details, next. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Jul 31, 2014, at 6:37 PM, Chen Gang wrote: > Thank you very much for your work. Especially give a complete sample for > the whole working flow, which I shall follow. > > For me, if no related documents for it, I recommend to put a complete > sample (e.g. this one) to a related document which can be referenced by > other newbies. https://gcc.gnu.org/contribute.html
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
Thank you very much for your work. Especially give a complete sample for
the whole working flow, which I shall follow.
For me, if no related documents for it, I recommend to put a complete
sample (e.g. this one) to a related document which can be referenced by
other newbies.
By the way, with your aid, my original plan "a patch per month" is
succeed, or it must be fail for 2014-07, thanks.
On 08/01/2014 06:36 AM, Jeff Law wrote:
> On 07/24/14 09:31, Chen Gang wrote:
>> strlen() will get string length excluding '\0', but strcpy() will append
>> '\0' in the end, so need XNEWVEC additional byte, or cause memory over
>> flow.
>>
>> Signed-off-by: Chen Gang
>> ---
>> gcc/gcc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/gcc.c b/gcc/gcc.c
>> index 6cd08ea..8ea46ec 100644
>> --- a/gcc/gcc.c
>> +++ b/gcc/gcc.c
>> @@ -4895,7 +4895,7 @@ do_spec_1 (const char *spec, int inswitch, const
>> char *soft_matched_part)
>> {
>> saved_suffix
>> = XNEWVEC (char, suffix_length
>> - + strlen (TARGET_OBJECT_SUFFIX));
>> + + strlen (TARGET_OBJECT_SUFFIX) + 1);
>> strncpy (saved_suffix, suffix, suffix_length);
>> strcpy (saved_suffix + suffix_length,
>> TARGET_OBJECT_SUFFIX);
> Thanks. I've installed this on the trunk after bootstrapping and
> regression testing on x86_64-unknown-linux-gnu
>
Thank you for your work.
> In the future, please do a bootstrap & regression test when submitting
> patches and indicate which platform you did the testing on.
>
> In essence the process looks like
>
> make
> make check
>
>
> make clean
> make
> make check
>
>
Thanks, I shall follow, next.
>
> It seems tedious for simple patches, but the requirements for
> bootstrapping and regression testing keep the tip of the trunk from
> getting broken too often (which is very costly for everyone when it
> occurs).
>
That sounds reasonable to me.
> You also need to provide a ChangeLog entry. The details of what belongs
> in a ChangeLog are on the web site. Here's an example for your patch:
>
> 2014-07-31 Chen Gang
>
> * gcc.c (do_spec_1): Allocate enough space for saved_suffix.
>
Thanks, I shall follow, next.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 07/24/14 09:31, Chen Gang wrote:
strlen() will get string length excluding '\0', but strcpy() will append
'\0' in the end, so need XNEWVEC additional byte, or cause memory over
flow.
Signed-off-by: Chen Gang
---
gcc/gcc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6cd08ea..8ea46ec 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -4895,7 +4895,7 @@ do_spec_1 (const char *spec, int inswitch, const char
*soft_matched_part)
{
saved_suffix
= XNEWVEC (char, suffix_length
-+ strlen (TARGET_OBJECT_SUFFIX));
++ strlen (TARGET_OBJECT_SUFFIX) + 1);
strncpy (saved_suffix, suffix, suffix_length);
strcpy (saved_suffix + suffix_length,
TARGET_OBJECT_SUFFIX);
Thanks. I've installed this on the trunk after bootstrapping and
regression testing on x86_64-unknown-linux-gnu
In the future, please do a bootstrap & regression test when submitting
patches and indicate which platform you did the testing on.
In essence the process looks like
make
make check
make clean
make
make check
It seems tedious for simple patches, but the requirements for
bootstrapping and regression testing keep the tip of the trunk from
getting broken too often (which is very costly for everyone when it occurs).
You also need to provide a ChangeLog entry. The details of what belongs
in a ChangeLog are on the web site. Here's an example for your patch:
2014-07-31 Chen Gang
* gcc.c (do_spec_1): Allocate enough space for saved_suffix.
Thanks,
Jeff
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 07/31/2014 11:09 AM, Jeff Law wrote: > On 07/30/14 16:29, Joseph S. Myers wrote: >> On Thu, 31 Jul 2014, Chen Gang wrote: >> >>> On 07/31/2014 06:12 AM, Joseph S. Myers wrote: On Thu, 24 Jul 2014, Chen Gang wrote: > strlen() will get string length excluding '\0', but strcpy() will > append > '\0' in the end, so need XNEWVEC additional byte, or cause memory over > flow. OK assuming it passed regression testing (with ChangeLog entry as usual, and you need to say what platform the patch was bootstrapped / regression tested on). >>> >>> Excuse me, I only find it by reading source code, not give a test (for >>> me, this kind of patch welcomes the related test, but not mandatory). >> >> I don't believe this particular patch needs a new regression test >> added to >> the testsuite. >> >> But you still need to meet all the usual patch requirements - run the GCC >> testsuite before and after the patch, and verify that it does not >> introduce any new failures, and say what platform you did that testing >> on. >> Even "obvious" patches can have non-obvious typos, hence the need to run >> the testsuite as a sanity check. > I was going to take care of this for Chen, but keep getting pulled into > other things. OK, thank all of you for spending your time resources on it. This kind of patch is non-urgent, so can only check it when related members have time, and I shall have a little patient (at least, can wait 2 weeks or more). Again next, I shall try to finish testsuite within this week end (2014-08-03). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 07/30/14 16:29, Joseph S. Myers wrote: On Thu, 31 Jul 2014, Chen Gang wrote: On 07/31/2014 06:12 AM, Joseph S. Myers wrote: On Thu, 24 Jul 2014, Chen Gang wrote: strlen() will get string length excluding '\0', but strcpy() will append '\0' in the end, so need XNEWVEC additional byte, or cause memory over flow. OK assuming it passed regression testing (with ChangeLog entry as usual, and you need to say what platform the patch was bootstrapped / regression tested on). Excuse me, I only find it by reading source code, not give a test (for me, this kind of patch welcomes the related test, but not mandatory). I don't believe this particular patch needs a new regression test added to the testsuite. But you still need to meet all the usual patch requirements - run the GCC testsuite before and after the patch, and verify that it does not introduce any new failures, and say what platform you did that testing on. Even "obvious" patches can have non-obvious typos, hence the need to run the testsuite as a sanity check. I was going to take care of this for Chen, but keep getting pulled into other things. Jeff
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 07/31/2014 06:29 AM, Joseph S. Myers wrote: > On Thu, 31 Jul 2014, Chen Gang wrote: > >> On 07/31/2014 06:12 AM, Joseph S. Myers wrote: >>> On Thu, 24 Jul 2014, Chen Gang wrote: >>> strlen() will get string length excluding '\0', but strcpy() will append '\0' in the end, so need XNEWVEC additional byte, or cause memory over flow. >>> >>> OK assuming it passed regression testing (with ChangeLog entry as usual, >>> and you need to say what platform the patch was bootstrapped / regression >>> tested on). >>> >> >> Excuse me, I only find it by reading source code, not give a test (for >> me, this kind of patch welcomes the related test, but not mandatory). > > I don't believe this particular patch needs a new regression test added to > the testsuite. > > But you still need to meet all the usual patch requirements - run the GCC > testsuite before and after the patch, and verify that it does not > introduce any new failures, and say what platform you did that testing on. > Even "obvious" patches can have non-obvious typos, hence the need to run > the testsuite as a sanity check. > > (For some sorts of patches it's different - e.g. for a patch to the > manual, "make info html pdf" is useful testing, but a testsuite run > isn't.) > Thank you for your valuable information. And I shall try. For me, this kind of tests are necessary for all kinds of patches (include this kind of patch). But excuse me, I am a newbie, I am not quit familiar with testsuite, so maybe I can not finish soon. But I should finish the related test with testsuite within this week end (within 2014-08-03). And still welcome any related ideas, suggestions, and completions. Thanks. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Thu, 31 Jul 2014, Chen Gang wrote: > On 07/31/2014 06:12 AM, Joseph S. Myers wrote: > > On Thu, 24 Jul 2014, Chen Gang wrote: > > > >> strlen() will get string length excluding '\0', but strcpy() will append > >> '\0' in the end, so need XNEWVEC additional byte, or cause memory over > >> flow. > > > > OK assuming it passed regression testing (with ChangeLog entry as usual, > > and you need to say what platform the patch was bootstrapped / regression > > tested on). > > > > Excuse me, I only find it by reading source code, not give a test (for > me, this kind of patch welcomes the related test, but not mandatory). I don't believe this particular patch needs a new regression test added to the testsuite. But you still need to meet all the usual patch requirements - run the GCC testsuite before and after the patch, and verify that it does not introduce any new failures, and say what platform you did that testing on. Even "obvious" patches can have non-obvious typos, hence the need to run the testsuite as a sanity check. (For some sorts of patches it's different - e.g. for a patch to the manual, "make info html pdf" is useful testing, but a testsuite run isn't.) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On 07/31/2014 06:12 AM, Joseph S. Myers wrote: > On Thu, 24 Jul 2014, Chen Gang wrote: > >> strlen() will get string length excluding '\0', but strcpy() will append >> '\0' in the end, so need XNEWVEC additional byte, or cause memory over >> flow. > > OK assuming it passed regression testing (with ChangeLog entry as usual, > and you need to say what platform the patch was bootstrapped / regression > tested on). > Excuse me, I only find it by reading source code, not give a test (for me, this kind of patch welcomes the related test, but not mandatory). But, if you still feel it is necessary to have a related test, I shall try. Thanks. -- Chen Gang Open share and attitude like air water and life which God blessed
Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using
On Thu, 24 Jul 2014, Chen Gang wrote: > strlen() will get string length excluding '\0', but strcpy() will append > '\0' in the end, so need XNEWVEC additional byte, or cause memory over > flow. OK assuming it passed regression testing (with ChangeLog entry as usual, and you need to say what platform the patch was bootstrapped / regression tested on). -- Joseph S. Myers jos...@codesourcery.com
