| Message ID | BANLkTinm91_Vt2V5P6VqB_AkwRrr4H0kuQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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 :-)
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
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 ...
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.
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.
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 >
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. */
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.