Patchwork : Restore bootstrap with --enable-build-with-cxx

login
register
mail settings
Submitter Uros Bizjak
Date May 17, 2011, 6:32 p.m.
Message ID <BANLkTinm91_Vt2V5P6VqB_AkwRrr4H0kuQ@mail.gmail.com>
Download mbox | patch
Permalink /patch/96006/
State New
Headers show

Comments

Uros Bizjak - May 17, 2011, 6:32 p.m.
Hello!

2011-05-17  Uros Bizjak  <ubizjak@gmail.com>

	* ipa-inline-analysis.c (inline_node_duplication_hook): Initialize
	info->entry with 0
	* tree-inline.c (maybe_inline_call_in_expr):  Initialize
	id.transform_lang_insert_block with NULL.

Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committed to mainline SVN as obvious.

Uros.
Toon Moene - May 17, 2011, 7:46 p.m.
On 05/17/2011 08:32 PM, Uros Bizjak wrote:

> Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
> Committed to mainline SVN as obvious.

Does that mean that I can now remove the --disable-werror from my daily 
C++ bootstrap run ?

It's great that some people understand the intricacies of the 
infight^H^H^H^H^H^H differences between the C and C++ type model.

OK: 1/2 :-)
Gabriel Dos Reis - May 18, 2011, 3:41 a.m.
On Tue, May 17, 2011 at 2:46 PM, Toon Moene <toon@moene.org> wrote:
> On 05/17/2011 08:32 PM, Uros Bizjak wrote:
>
>> Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
>> Committed to mainline SVN as obvious.
>
> Does that mean that I can now remove the --disable-werror from my daily C++
> bootstrap run ?
>
> It's great that some people understand the intricacies of the
> infight^H^H^H^H^H^H differences between the C and C++ type model.
>
> OK: 1/2 :-)

I suspect this infight would vanish if we just switched, as we discussed
in the past.

-- Gaby
Toon Moene - May 18, 2011, 8:17 p.m.
On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:

> On Tue, May 17, 2011 at 2:46 PM, Toon Moene<toon@moene.org>  wrote:

>> On 05/17/2011 08:32 PM, Uros Bizjak wrote:
>>
>>> Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
>>> Committed to mainline SVN as obvious.
>>
>> Does that mean that I can now remove the --disable-werror from my daily C++
>> bootstrap run ?

Well, that certainly worked, as exemplified by this:

http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01890.html

At least that would enable my daily run (between 18:10 and 20:10 UTC) to 
catch -Werror mistakes ...

>> It's great that some people understand the intricacies of the
>> infight^H^H^H^H^H^H differences between the C and C++ type model.
>>
>> OK: 1/2 :-)
>
> I suspect this infight would vanish if we just switched, as we discussed
> in the past.

Perhaps it would just help if we implemented the next step of the plan 
(http://gcc.gnu.org/wiki/gcc-in-cxx):

# "it would be a good thing to try forcing the C++ host compiler 
requirement for GCC 4.[7] with just building stage1 with C++ and 
stage2/3 with the stage1 C compiler. --disable-build-with-cxx would be a 
workaround for a missing C++ host compiler."

Of course, that still wouldn't make it possible to implement C++ 
solutions for C hacks because the "--disable-build-with-cxx" crowd would 
cry "foul" over this ...
Richard Guenther - May 18, 2011, 8:31 p.m.
On Wed, May 18, 2011 at 10:17 PM, Toon Moene <toon@moene.org> wrote:
> On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:
>
>> On Tue, May 17, 2011 at 2:46 PM, Toon Moene<toon@moene.org>  wrote:
>
>>> On 05/17/2011 08:32 PM, Uros Bizjak wrote:
>>>
>>>> Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
>>>> Committed to mainline SVN as obvious.
>>>
>>> Does that mean that I can now remove the --disable-werror from my daily
>>> C++
>>> bootstrap run ?
>
> Well, that certainly worked, as exemplified by this:
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01890.html
>
> At least that would enable my daily run (between 18:10 and 20:10 UTC) to
> catch -Werror mistakes ...
>
>>> It's great that some people understand the intricacies of the
>>> infight^H^H^H^H^H^H differences between the C and C++ type model.
>>>
>>> OK: 1/2 :-)
>>
>> I suspect this infight would vanish if we just switched, as we discussed
>> in the past.
>
> Perhaps it would just help if we implemented the next step of the plan
> (http://gcc.gnu.org/wiki/gcc-in-cxx):
>
> # "it would be a good thing to try forcing the C++ host compiler requirement
> for GCC 4.[7] with just building stage1 with C++ and stage2/3 with the
> stage1 C compiler. --disable-build-with-cxx would be a workaround for a
> missing C++ host compiler."

Or the other way around, build stage1 with the host C compiler, add
C++ to stage1-languages and build stage2/3 with the stageN C++ compiler.
That avoids the host C++ compiler requirement for now and excercises
the libstdc++ linking issues.

But yes, somebody has to go forward to implement either (or both) variants.

Not that I'm too excited to see GCC built with a C++ compiler (or even C++
features being used).

Richard.
Toon Moene - May 18, 2011, 8:44 p.m.
On 05/18/2011 10:31 PM, Richard Guenther wrote:

> Not that I'm too excited to see GCC built with a C++ compiler (or even C++
> features being used).

Hmmm, you think using "false" as a value for a pointer-returning 
function is just A-OK ?

Duh, I'm glad I'm using Fortran, where the programmer isn't even 
supposed to know what the value of .FALSE. is, because it is 
implementation dependent.
Richard Guenther - May 18, 2011, 8:47 p.m.
On Wed, May 18, 2011 at 10:44 PM, Toon Moene <toon@moene.org> wrote:
> On 05/18/2011 10:31 PM, Richard Guenther wrote:
>
>> Not that I'm too excited to see GCC built with a C++ compiler (or even C++
>> features being used).
>
> Hmmm, you think using "false" as a value for a pointer-returning function is
> just A-OK ?

No, it isn't ;)

Richard.

> Duh, I'm glad I'm using Fortran, where the programmer isn't even supposed to
> know what the value of .FALSE. is, because it is implementation dependent.
>
> --
> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
> Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
>

Patch

Index: ipa-inline-analysis.c
===================================================================
--- ipa-inline-analysis.c	(revision 173832)
+++ ipa-inline-analysis.c	(working copy)
@@ -702,7 +702,7 @@  inline_node_duplication_hook (struct cgr
       bool inlined_to_p = false;
       struct cgraph_edge *edge;
 
-      info->entry = false;
+      info->entry = 0;
       VEC_safe_grow_cleared (tree, heap, known_vals, count);
       for (i = 0; i < count; i++)
         {
Index: tree-inline.c
===================================================================
--- tree-inline.c	(revision 173832)
+++ tree-inline.c	(working copy)
@@ -5232,7 +5232,7 @@  maybe_inline_call_in_expr (tree exp)
       id.transform_call_graph_edges = CB_CGE_DUPLICATE;
       id.transform_new_cfg = false;
       id.transform_return_to_modify = true;
-      id.transform_lang_insert_block = false;
+      id.transform_lang_insert_block = NULL;
 
       /* Make sure not to unshare trees behind the front-end's back
 	 since front-end specific mechanisms may rely on sharing.  */