[PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

[PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

[Chen Gang]

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 <gang.chen.5i5j@gmail.com>
---
 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);
-- 
1.7.11.7

Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

[Joseph S. Myers]

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
joseph@codesourcery.com

Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

[Chen Gang]

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

[Joseph S. Myers]

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
joseph@codesourcery.com

Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

[Chen Gang]

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

[Jeff Law]

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

[Chen Gang]

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

[Jeff Law]

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 <gang.chen.5i5j@gmail.com>
> ---
>   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
<save various .sum files>
<apply patch>
make clean
make
make check
<compare .sum files>


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  <gang.chen.5i5j@gmail.com>

         * 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

[Chen Gang]

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 <gang.chen.5i5j@gmail.com>
>> ---
>>   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
> <save various .sum files>
> <apply patch>
> make clean
> make
> make check
> <compare .sum files>
> 

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  <gang.chen.5i5j@gmail.com>
> 
>         * 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

[Mike Stump]

On Jul 31, 2014, at 6:37 PM, Chen Gang <gang.chen.5i5j@gmail.com> 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

[Chen Gang]

On 08/01/2014 10:14 AM, Mike Stump wrote:
> On Jul 31, 2014, at 6:37 PM, Chen Gang <gang.chen.5i5j@gmail.com> 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

[Chen Gang]

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).

> <save various .sum files>

Excuse me, I can not find it with `find ./ | grep "\.sum$"`

[...]
> <compare .sum files>

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

[Chen Gang]

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).
> 
>> <save various .sum files>
> 
> Excuse me, I can not find it with `find ./ | grep "\.sum$"`
> 
> [...]
>> <compare .sum files>
> 
> 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

[Mike Stump]

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 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

[Chen Gang]

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.
> 

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

[Chen Gang]

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)
  ...

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

[Bin.Cheng]

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.

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

[Chen Gang]

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?


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

[Bin.Cheng]

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

Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

[Chen Gang]

On 8/18/14 18:07, Bin.Cheng wrote:
> 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.
> 

OK, thanks, what you said sounds reasonable to me, and I shall analyze
them firstly, before send patch. (and excuse me, the related patch has
to be delayed).

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

[Chen Gang]

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

[Mike Stump]

On Aug 20, 2014, at 7:26 AM, Chen Gang <gang.chen.5i5j@gmail.com> 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<n> 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

[Chen Gang]

On 08/21/2014 01:35 AM, Mike Stump wrote:
> On Aug 20, 2014, at 7:26 AM, Chen Gang <gang.chen.5i5j@gmail.com> 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<n> 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

[Mike Stump]

On Aug 20, 2014, at 11:29 AM, Chen Gang <gang.chen.5i5j@gmail.com> 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

[Chen Gang]

On 08/21/2014 03:23 AM, Mike Stump wrote:
> On Aug 20, 2014, at 11:29 AM, Chen Gang <gang.chen.5i5j@gmail.com> 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

[Mike Stump]

On Aug 18, 2014, at 3:06 AM, Chen Gang <gang.chen.5i5j@gmail.com> 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

[Chen Gang]

On 08/22/2014 12:18 AM, Mike Stump wrote:
> On Aug 18, 2014, at 3:06 AM, Chen Gang <gang.chen.5i5j@gmail.com> 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