testing policy for C/C++ front end changes

testing policy for C/C++ front end changes

[Sandra Loosemore]

Forgive me if this has been raised before -- I tried searching the 
archives but couldn't think of good keywords that would weed out 
unrelated posts....

I was checking the testing requirements for a C front end patch

https://gcc.gnu.org/contribute.html#testing

and noticed that the policy is to require a complete bootstrap for C 
changes, but not for C++.  Given that GCC's implementation language is 
now C++, isn't that backwards?  I'm not trying to weasel out of the 
extra work for my patch, just curious if the web site guidelines have 
gotten bit-rotten after the switch to C++, or if the SC did indeed 
consider the issue already and the published policy is accurate.

-Sandra

Re: testing policy for C/C++ front end changes

[Joern Rennecke]

On 9 November 2014 23:13, Sandra Loosemore <sandra@codesourcery.com> wrote:
> Forgive me if this has been raised before -- I tried searching the archives
> but couldn't think of good keywords that would weed out unrelated posts....
>
> I was checking the testing requirements for a C front end patch
>
> https://gcc.gnu.org/contribute.html#testing
>
> and noticed that the policy is to require a complete bootstrap for C
> changes, but not for C++.  Given that GCC's implementation language is now
> C++, isn't that backwards?

Indeed, seem like a valid point to bootstrap for C++ changes.
But bootstrap for C changes appears still valid, too; we still got C source in
various places, like libgcc, and generator programs.

Re: testing policy for C/C++ front end changes

[Jeff Law]

On 11/09/14 16:13, Sandra Loosemore wrote:
> https://gcc.gnu.org/contribute.html#testing
>
> and noticed that the policy is to require a complete bootstrap for C
> changes, but not for C++.  Given that GCC's implementation language is
> now C++, isn't that backwards?  I'm not trying to weasel out of the
> extra work for my patch, just curious if the web site guidelines have
> gotten bit-rotten after the switch to C++, or if the SC did indeed
> consider the issue already and the published policy is accurate.
They've bit-rotted a bit.  Interested in cons-ing up an update?

jeff

Re: testing policy for C/C++ front end changes

[Richard Biener]

On Mon, Nov 10, 2014 at 5:50 AM, Jeff Law <law@redhat.com> wrote:
> On 11/09/14 16:13, Sandra Loosemore wrote:
>>
>> https://gcc.gnu.org/contribute.html#testing
>>
>> and noticed that the policy is to require a complete bootstrap for C
>> changes, but not for C++.  Given that GCC's implementation language is
>> now C++, isn't that backwards?  I'm not trying to weasel out of the
>> extra work for my patch, just curious if the web site guidelines have
>> gotten bit-rotten after the switch to C++, or if the SC did indeed
>> consider the issue already and the published policy is accurate.
>
> They've bit-rotted a bit.  Interested in cons-ing up an update?

Bootstrap should now be required for both C and C++ FE changes
_and_ for libstdc++ changes as well given we start to pull in
libstdc++ headers during bootstrap.

Richard.

> jeff
>

Re: testing policy for C/C++ front end changes

[Sandra Loosemore]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On 11/10/2014 05:03 AM, Richard Biener wrote:
> On Mon, Nov 10, 2014 at 5:50 AM, Jeff Law <law@redhat.com> wrote:
>> On 11/09/14 16:13, Sandra Loosemore wrote:
>>>
>>> https://gcc.gnu.org/contribute.html#testing
>>>
>>> and noticed that the policy is to require a complete bootstrap for C
>>> changes, but not for C++.  Given that GCC's implementation language is
>>> now C++, isn't that backwards?  I'm not trying to weasel out of the
>>> extra work for my patch, just curious if the web site guidelines have
>>> gotten bit-rotten after the switch to C++, or if the SC did indeed
>>> consider the issue already and the published policy is accurate.
>>
>> They've bit-rotted a bit.  Interested in cons-ing up an update?
>
> Bootstrap should now be required for both C and C++ FE changes
> _and_ for libstdc++ changes as well given we start to pull in
> libstdc++ headers during bootstrap.

Hmmmm.  How about the attached patch?  I also added a blurb about 
target-specific patches that I think reflects current practice.

-Sandra


[-- Attachment #2: wwwdocs.patch --]
[-- Type: text/x-patch, Size: 2447 bytes --]

? htdocs/contribute.html.~1.85.~
Index: htdocs/contribute.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.85
diff -u -p -r1.85 contribute.html
--- htdocs/contribute.html	27 Jun 2014 11:12:18 -0000	1.85
+++ htdocs/contribute.html	10 Nov 2014 15:19:37 -0000
@@ -100,9 +100,13 @@ list</a>.</p>
 <h3>Which tests to perform</h3>
 
 <p>If your change is to code that is not in a front end, or is to the
-C front end, you must perform a complete build of GCC and the runtime
+C or C++ front ends or <code>libgcc</code> or <code>libstdc++</code>
+libraries, you must perform a complete build of GCC and the runtime
 libraries included with it, on at least one target.  You must
-bootstrap all default languages, not just C, and run all testsuites.
+build all default languages, not just C, and run all testsuites.
+If your change is specific to a particular target back end, you need only
+build and test that target; otherwise a complete bootstrap on a 
+primary platform designated in the current release criteria is required.
 For a normal native configuration, running</p>
 <blockquote><pre>
 make bootstrap
@@ -111,19 +115,9 @@ make -k check
 <p>from the top level of the GCC tree (<strong>not</strong> the
 <code>gcc</code> subdirectory) will accomplish this.</p>
 
-<p>If your change is to the C++ front end, you should rebuild the compiler,
-<code>libstdc++</code>, <code>libjava</code> and run the C++ testsuite.
-If you already did a complete C,C++,Java bootstrap from your build
-directory before, you can use the following:</p>
-<blockquote><pre>
-make clean-target-libstdc++-v3                    # clean libstdc++ and ...
-test -d */libjava &amp;&amp; make -C */libjava clean-nat  # ... parts of libjava
-make all-target-libstdc++-v3 all-target-libjava   # rebuild compiler and libraries
-make -k check-c++                                 # run C++/libstdc++ testsuite
-</pre></blockquote>
-
 <p>If your change is to a front end other than the C or C++ front end,
-or a runtime library other than <code>libgcc</code>, you need to verify
+or a runtime library other than <code>libgcc</code> or
+<code>libstdc++</code>, you need to verify
 only that the runtime library for that language still builds and the
 tests for that language have not regressed.  (Most languages have
 tests stored both in the <code>gcc</code> subdirectory, and in the

Re: testing policy for C/C++ front end changes

[Richard Biener]

 On Mon, Nov 10, 2014 at 4:28 PM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
> On 11/10/2014 05:03 AM, Richard Biener wrote:
>>
>> On Mon, Nov 10, 2014 at 5:50 AM, Jeff Law <law@redhat.com> wrote:
>>>
>>> On 11/09/14 16:13, Sandra Loosemore wrote:
>>>>
>>>>
>>>> https://gcc.gnu.org/contribute.html#testing
>>>>
>>>> and noticed that the policy is to require a complete bootstrap for C
>>>> changes, but not for C++.  Given that GCC's implementation language is
>>>> now C++, isn't that backwards?  I'm not trying to weasel out of the
>>>> extra work for my patch, just curious if the web site guidelines have
>>>> gotten bit-rotten after the switch to C++, or if the SC did indeed
>>>> consider the issue already and the published policy is accurate.
>>>
>>>
>>> They've bit-rotted a bit.  Interested in cons-ing up an update?
>>
>>
>> Bootstrap should now be required for both C and C++ FE changes
>> _and_ for libstdc++ changes as well given we start to pull in
>> libstdc++ headers during bootstrap.
>
>
> Hmmmm.  How about the attached patch?  I also added a blurb about
> target-specific patches that I think reflects current practice.

I think you need to retain the fact that one needs to bootstrap, not just
build GCC.  Thus "If your change is to code that is not in a front
end, or is to the C or C++ front ends or <code>libgcc</code> or
<code>libstdc++</code>
libraries, you must perform a bootstrap of GCC with all languages enabled
by default, on at least one primary target,  and run all testsuites."

Ok with that change.

Thanks,
Richard.

> -Sandra
>

Re: testing policy for C/C++ front end changes

[Sandra Loosemore]

On 11/11/2014 02:05 AM, Richard Biener wrote:
>   On Mon, Nov 10, 2014 at 4:28 PM, Sandra Loosemore
> <sandra@codesourcery.com> wrote:
>> On 11/10/2014 05:03 AM, Richard Biener wrote:
>>>
>>> On Mon, Nov 10, 2014 at 5:50 AM, Jeff Law <law@redhat.com> wrote:
>>>>
>>>> On 11/09/14 16:13, Sandra Loosemore wrote:
>>>>>
>>>>>
>>>>> https://gcc.gnu.org/contribute.html#testing
>>>>>
>>>>> and noticed that the policy is to require a complete bootstrap for C
>>>>> changes, but not for C++.  Given that GCC's implementation language is
>>>>> now C++, isn't that backwards?  I'm not trying to weasel out of the
>>>>> extra work for my patch, just curious if the web site guidelines have
>>>>> gotten bit-rotten after the switch to C++, or if the SC did indeed
>>>>> consider the issue already and the published policy is accurate.
>>>>
>>>>
>>>> They've bit-rotted a bit.  Interested in cons-ing up an update?
>>>
>>>
>>> Bootstrap should now be required for both C and C++ FE changes
>>> _and_ for libstdc++ changes as well given we start to pull in
>>> libstdc++ headers during bootstrap.
>>
>>
>> Hmmmm.  How about the attached patch?  I also added a blurb about
>> target-specific patches that I think reflects current practice.
>
> I think you need to retain the fact that one needs to bootstrap, not just
> build GCC.  Thus "If your change is to code that is not in a front
> end, or is to the C or C++ front ends or <code>libgcc</code> or
> <code>libstdc++</code>
> libraries, you must perform a bootstrap of GCC with all languages enabled
> by default, on at least one primary target,  and run all testsuites."
>
> Ok with that change.

I think I'll have to leave the policy rewriting to somebody else, then, 
because I don't understand what to do about patches to a back end that 
cannot be bootstrapped (e.g., a bare-metal or embedded target where GCC 
is normally built as a cross, or where the patch submitter only has a 
simulator available for testing, etc).

-Sandra

Re: testing policy for C/C++ front end changes

[Fabien Chêne]

2014-11-11 10:05 GMT+01:00 Richard Biener <richard.guenther@gmail.com>:
[...]
> I think you need to retain the fact that one needs to bootstrap, not just
> build GCC.  Thus "If your change is to code that is not in a front
> end, or is to the C or C++ front ends or <code>libgcc</code> or
> <code>libstdc++</code>
> libraries, you must perform a bootstrap of GCC with all languages enabled
> by default, on at least one primary target,  and run all testsuites."
>
> Ok with that change.

Perhaps that would make sense to mention the existence of the compile
farm, and add link to it.
Otherwise, such requirements (which are obvious) could clearly
discourage contributors that do not have access to a powerful machine.

-- 
Fabien

Re: testing policy for C/C++ front end changes

[Markus Hitter]

Am 13.11.2014 um 14:08 schrieb Fabien Chêne:
> Perhaps that would make sense to mention the existence of the compile
> farm, and add link to it.

Good idea. Bonus points for adding a script which executes all the required steps.


Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/