Merge C++ conversion into trunk (0/6 - Overview)

Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

I will be sending 6 patches that implement all the changes we
have been making on the cxx-conversion branch.  As described in 
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
change the default bootstrap process so that stage 1 always
builds with a C++ compiler.

Other than the bootstrap change, the patches make no functional
changes to the compiler.  Everything should build as it does now
in trunk.

I have split the merge in 6 main patches.  I will send these
patches to the respective maintainers and gcc-patches.
Please remember that the patches conform to the new C++ coding
guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):

1- Configuration changes.
2- Re-write of VEC.
3- Re-write of gengtype to support C++ templates and
   user-provided marking functions.
4- New hash table class.
5- Re-write double_int.
6- Implement tree macros as inline functions so they can be
   called from gdb.

As discussed before, several of these patches do not fully change
the call sites to use the new APIs.  We will do this change once
the branch has been merged into trunk.  Otherwise, the branch
becomes a maintenance nightmare (despite not having changed many
caller sites we were already starting to run into maintenance
problems).

For those who would like to build the conversion, you can either
checkout the branch from SVN
(svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged
trunk I have in the git repo (branch dnovillo/cxx-conversion).

The bootstrap changes have already been tested on a wide range of
targets (http://gcc.gnu.org/wiki/CppBuildStatus).  Additionally,
I have tested the merged trunk on: x86_64-unknown-linux-gnu,
mips64el-unknown-linux-gnu, powerpc64-unknown-linux-gnu,
i686-pc-linux-gnu, and ia64-unknown-linux-gnu.


Thanks.  Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Marc Glisse]

On Sun, 12 Aug 2012, Diego Novillo wrote:

> For those who would like to build the conversion, you can either
> checkout the branch from SVN
> (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged
> trunk I have in the git repo (branch dnovillo/cxx-conversion).
>
> The bootstrap changes have already been tested on a wide range of
> targets (http://gcc.gnu.org/wiki/CppBuildStatus).

Hello,

as a matter of policy, is it required that non-gcc compilers can be used 
to initiate the bootstrap? In the table, clang seems to be the only other 
compiler that managed. IBM and Oracle both fail (the comment is not clear, 
but I think 12.3 also fails, just not exactly in the same way), and HP and 
Intel (to mention just a few) are not listed.

-- 
Marc Glisse

PS: I never know if it is better to trim Cc: lists in answers or let them 
grow...

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-12 16:57 , Marc Glisse wrote:

> other compiler that managed. IBM and Oracle both fail (the comment is
> not clear, but I think 12.3 also fails, just not exactly in the same
> way), and HP and Intel (to mention just a few) are not listed.

We should fix/workaround failing host C++ compilers similarly to how we 
deal with host C compilers.

If you have access to any of the compilers you mention, could you try 
building the branch?


Thanks.  Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[H.J. Lu]

On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo <dnovillo@google.com> wrote:
> I will be sending 6 patches that implement all the changes we
> have been making on the cxx-conversion branch.  As described in
> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
> change the default bootstrap process so that stage 1 always
> builds with a C++ compiler.
>
> Other than the bootstrap change, the patches make no functional
> changes to the compiler.  Everything should build as it does now
> in trunk.
>
> I have split the merge in 6 main patches.  I will send these
> patches to the respective maintainers and gcc-patches.
> Please remember that the patches conform to the new C++ coding
> guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):
>
> 1- Configuration changes.
> 2- Re-write of VEC.
> 3- Re-write of gengtype to support C++ templates and
>    user-provided marking functions.
> 4- New hash table class.
> 5- Re-write double_int.
> 6- Implement tree macros as inline functions so they can be
>    called from gdb.
>
> As discussed before, several of these patches do not fully change
> the call sites to use the new APIs.  We will do this change once
> the branch has been merged into trunk.  Otherwise, the branch
> becomes a maintenance nightmare (despite not having changed many
> caller sites we were already starting to run into maintenance
> problems).
>
> For those who would like to build the conversion, you can either
> checkout the branch from SVN
> (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged
> trunk I have in the git repo (branch dnovillo/cxx-conversion).
>

dnovillo/cxx-conversion git branch failed to bootstrap on
Fedora 17 x86-64 when configured with

--enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go

I got

/export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c: In function
\u2018tree_node* objc_build_constructor(tree,
vec_t<constructor_elt_d>*)\u2019:
/export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c:3212:44: error:
base operand of \u2018->\u2019 has non-pointer type
\u2018constructor_elt_d\u2019
   if (!VEC_index (constructor_elt, elts, 0)->index)


-- 
H.J.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[H.J. Lu]

On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo <dnovillo@google.com> wrote:
>> I will be sending 6 patches that implement all the changes we
>> have been making on the cxx-conversion branch.  As described in
>> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
>> change the default bootstrap process so that stage 1 always
>> builds with a C++ compiler.
>>
>> Other than the bootstrap change, the patches make no functional
>> changes to the compiler.  Everything should build as it does now
>> in trunk.
>>
>> I have split the merge in 6 main patches.  I will send these
>> patches to the respective maintainers and gcc-patches.
>> Please remember that the patches conform to the new C++ coding
>> guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):
>>
>> 1- Configuration changes.
>> 2- Re-write of VEC.
>> 3- Re-write of gengtype to support C++ templates and
>>    user-provided marking functions.
>> 4- New hash table class.
>> 5- Re-write double_int.
>> 6- Implement tree macros as inline functions so they can be
>>    called from gdb.
>>
>> As discussed before, several of these patches do not fully change
>> the call sites to use the new APIs.  We will do this change once
>> the branch has been merged into trunk.  Otherwise, the branch
>> becomes a maintenance nightmare (despite not having changed many
>> caller sites we were already starting to run into maintenance
>> problems).
>>
>> For those who would like to build the conversion, you can either
>> checkout the branch from SVN
>> (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged
>> trunk I have in the git repo (branch dnovillo/cxx-conversion).
>>
>
> dnovillo/cxx-conversion git branch failed to bootstrap on
> Fedora 17 x86-64 when configured with
>
> --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go
>
> I got
>
> /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c: In function
> \u2018tree_node* objc_build_constructor(tree,
> vec_t<constructor_elt_d>*)\u2019:
> /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c:3212:44: error:
> base operand of \u2018->\u2019 has non-pointer type
> \u2018constructor_elt_d\u2019
>    if (!VEC_index (constructor_elt, elts, 0)->index)
>

This patch fixes the error:

diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c
index 5c924bf..caa16c7 100644
--- a/gcc/objc/objc-act.c
+++ b/gcc/objc/objc-act.c
@@ -3209,7 +3209,7 @@ objc_build_constructor (tree type,
VEC(constructor_elt,gc) *elts)
 #ifdef OBJCPLUS
   /* Adjust for impedance mismatch.  We should figure out how to build
      CONSTRUCTORs that consistently please both the C and C++ gods.  */
-  if (!VEC_index (constructor_elt, elts, 0)->index)
+  if (!VEC_index (constructor_elt, elts, 0).index)
     TREE_TYPE (constructor) = init_list_type_node;
 #endif



-- 
H.J.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-12 18:38 , H.J. Lu wrote:
> On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo <dnovillo@google.com> wrote:
>>> I will be sending 6 patches that implement all the changes we
>>> have been making on the cxx-conversion branch.  As described in
>>> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
>>> change the default bootstrap process so that stage 1 always
>>> builds with a C++ compiler.
>>>
>>> Other than the bootstrap change, the patches make no functional
>>> changes to the compiler.  Everything should build as it does now
>>> in trunk.
>>>
>>> I have split the merge in 6 main patches.  I will send these
>>> patches to the respective maintainers and gcc-patches.
>>> Please remember that the patches conform to the new C++ coding
>>> guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):
>>>
>>> 1- Configuration changes.
>>> 2- Re-write of VEC.
>>> 3- Re-write of gengtype to support C++ templates and
>>>     user-provided marking functions.
>>> 4- New hash table class.
>>> 5- Re-write double_int.
>>> 6- Implement tree macros as inline functions so they can be
>>>     called from gdb.
>>>
>>> As discussed before, several of these patches do not fully change
>>> the call sites to use the new APIs.  We will do this change once
>>> the branch has been merged into trunk.  Otherwise, the branch
>>> becomes a maintenance nightmare (despite not having changed many
>>> caller sites we were already starting to run into maintenance
>>> problems).
>>>
>>> For those who would like to build the conversion, you can either
>>> checkout the branch from SVN
>>> (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged
>>> trunk I have in the git repo (branch dnovillo/cxx-conversion).
>>>
>>
>> dnovillo/cxx-conversion git branch failed to bootstrap on
>> Fedora 17 x86-64 when configured with
>>
>> --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go
>>
>> I got
>>
>> /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c: In function
>> \u2018tree_node* objc_build_constructor(tree,
>> vec_t<constructor_elt_d>*)\u2019:
>> /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c:3212:44: error:
>> base operand of \u2018->\u2019 has non-pointer type
>> \u2018constructor_elt_d\u2019
>>     if (!VEC_index (constructor_elt, elts, 0)->index)
>>
>
> This patch fixes the error:
>
> diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c
> index 5c924bf..caa16c7 100644
> --- a/gcc/objc/objc-act.c
> +++ b/gcc/objc/objc-act.c
> @@ -3209,7 +3209,7 @@ objc_build_constructor (tree type,
> VEC(constructor_elt,gc) *elts)
>   #ifdef OBJCPLUS
>     /* Adjust for impedance mismatch.  We should figure out how to build
>        CONSTRUCTORs that consistently please both the C and C++ gods.  */
> -  if (!VEC_index (constructor_elt, elts, 0)->index)
> +  if (!VEC_index (constructor_elt, elts, 0).index)
>       TREE_TYPE (constructor) = init_list_type_node;
>   #endif

Thanks.  Missed this because --enable-languages=all does not enable 
obj-c++.  Please commit to the branch.  I'll update the git image.


Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[H.J. Lu]

On Sun, Aug 12, 2012 at 5:27 PM, Diego Novillo <dnovillo@google.com> wrote:
> On 12-08-12 18:38 , H.J. Lu wrote:
>>
>> On Sun, Aug 12, 2012 at 3:33 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>
>>> On Sun, Aug 12, 2012 at 1:04 PM, Diego Novillo <dnovillo@google.com>
>>> wrote:
>>>>
>>>> I will be sending 6 patches that implement all the changes we
>>>> have been making on the cxx-conversion branch.  As described in
>>>> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
>>>> change the default bootstrap process so that stage 1 always
>>>> builds with a C++ compiler.
>>>>
>>>> Other than the bootstrap change, the patches make no functional
>>>> changes to the compiler.  Everything should build as it does now
>>>> in trunk.
>>>>
>>>> I have split the merge in 6 main patches.  I will send these
>>>> patches to the respective maintainers and gcc-patches.
>>>> Please remember that the patches conform to the new C++ coding
>>>> guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):
>>>>
>>>> 1- Configuration changes.
>>>> 2- Re-write of VEC.
>>>> 3- Re-write of gengtype to support C++ templates and
>>>>     user-provided marking functions.
>>>> 4- New hash table class.
>>>> 5- Re-write double_int.
>>>> 6- Implement tree macros as inline functions so they can be
>>>>     called from gdb.
>>>>
>>>> As discussed before, several of these patches do not fully change
>>>> the call sites to use the new APIs.  We will do this change once
>>>> the branch has been merged into trunk.  Otherwise, the branch
>>>> becomes a maintenance nightmare (despite not having changed many
>>>> caller sites we were already starting to run into maintenance
>>>> problems).
>>>>
>>>> For those who would like to build the conversion, you can either
>>>> checkout the branch from SVN
>>>> (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged
>>>> trunk I have in the git repo (branch dnovillo/cxx-conversion).
>>>>
>>>
>>> dnovillo/cxx-conversion git branch failed to bootstrap on
>>> Fedora 17 x86-64 when configured with
>>>
>>> --enable-languages=c,c++,fortran,java,lto,objc,obj-c++,go
>>>
>>> I got
>>>
>>> /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c: In function
>>> \u2018tree_node* objc_build_constructor(tree,
>>> vec_t<constructor_elt_d>*)\u2019:
>>> /export/gnu/import/git/gcc-x32/gcc/objc/objc-act.c:3212:44: error:
>>> base operand of \u2018->\u2019 has non-pointer type
>>> \u2018constructor_elt_d\u2019
>>>     if (!VEC_index (constructor_elt, elts, 0)->index)
>>>
>>
>> This patch fixes the error:
>>
>> diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c
>> index 5c924bf..caa16c7 100644
>> --- a/gcc/objc/objc-act.c
>> +++ b/gcc/objc/objc-act.c
>> @@ -3209,7 +3209,7 @@ objc_build_constructor (tree type,
>> VEC(constructor_elt,gc) *elts)
>>   #ifdef OBJCPLUS
>>     /* Adjust for impedance mismatch.  We should figure out how to build
>>        CONSTRUCTORs that consistently please both the C and C++ gods.  */
>> -  if (!VEC_index (constructor_elt, elts, 0)->index)
>> +  if (!VEC_index (constructor_elt, elts, 0).index)
>>       TREE_TYPE (constructor) = init_list_type_node;
>>   #endif
>
>
> Thanks.  Missed this because --enable-languages=all does not enable obj-c++.
> Please commit to the branch.  I'll update the git image.
>
>

I checked it into cxx-conversion branch.


-- 
H.J.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Richard Guenther]

On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo <dnovillo@google.com> wrote:
> I will be sending 6 patches that implement all the changes we
> have been making on the cxx-conversion branch.  As described in
> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
> change the default bootstrap process so that stage 1 always
> builds with a C++ compiler.
>
> Other than the bootstrap change, the patches make no functional
> changes to the compiler.  Everything should build as it does now
> in trunk.
>
> I have split the merge in 6 main patches.  I will send these
> patches to the respective maintainers and gcc-patches.
> Please remember that the patches conform to the new C++ coding
> guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):
>
> 1- Configuration changes.
> 2- Re-write of VEC.
> 3- Re-write of gengtype to support C++ templates and
>    user-provided marking functions.
> 4- New hash table class.
> 5- Re-write double_int.
> 6- Implement tree macros as inline functions so they can be
>    called from gdb.
>
> As discussed before, several of these patches do not fully change
> the call sites to use the new APIs.  We will do this change once
> the branch has been merged into trunk.  Otherwise, the branch
> becomes a maintenance nightmare (despite not having changed many
> caller sites we were already starting to run into maintenance
> problems).

As I understand only 1. to 3. were kind-of required for the merge, all
other changes are a bonus at this time and should be delayed IMHO
(thus not merged with this batch).

I also understand that you will, quickly after merging 1. to 3. convert
all VEC users and remove the old interface.  This should be done
before any of 4. - 6. is merged as generally we don't want the
"half-converted" to persist, nor have multiple such half-conversions
at the same time.

I also understand that the merge of 1. to 3. will be followed by the promised
gengtype improvements and re-organizations.

Thus, please to the first C++ things very well.

Thanks,
Richard.

> For those who would like to build the conversion, you can either
> checkout the branch from SVN
> (svn://gcc.gnu.org/gcc/branches/cxx-conversion) or get the merged
> trunk I have in the git repo (branch dnovillo/cxx-conversion).
>
> The bootstrap changes have already been tested on a wide range of
> targets (http://gcc.gnu.org/wiki/CppBuildStatus).  Additionally,
> I have tested the merged trunk on: x86_64-unknown-linux-gnu,
> mips64el-unknown-linux-gnu, powerpc64-unknown-linux-gnu,
> i686-pc-linux-gnu, and ia64-unknown-linux-gnu.
>
>
> Thanks.  Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-13 05:37 , Richard Guenther wrote:
> On Sun, Aug 12, 2012 at 10:04 PM, Diego Novillo <dnovillo@google.com> wrote:
>> I will be sending 6 patches that implement all the changes we
>> have been making on the cxx-conversion branch.  As described in
>> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
>> change the default bootstrap process so that stage 1 always
>> builds with a C++ compiler.
>>
>> Other than the bootstrap change, the patches make no functional
>> changes to the compiler.  Everything should build as it does now
>> in trunk.
>>
>> I have split the merge in 6 main patches.  I will send these
>> patches to the respective maintainers and gcc-patches.
>> Please remember that the patches conform to the new C++ coding
>> guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):
>>
>> 1- Configuration changes.
>> 2- Re-write of VEC.
>> 3- Re-write of gengtype to support C++ templates and
>>     user-provided marking functions.
>> 4- New hash table class.
>> 5- Re-write double_int.
>> 6- Implement tree macros as inline functions so they can be
>>     called from gdb.
>>
>> As discussed before, several of these patches do not fully change
>> the call sites to use the new APIs.  We will do this change once
>> the branch has been merged into trunk.  Otherwise, the branch
>> becomes a maintenance nightmare (despite not having changed many
>> caller sites we were already starting to run into maintenance
>> problems).
>
> As I understand only 1. to 3. were kind-of required for the merge, all
> other changes are a bonus at this time and should be delayed IMHO
> (thus not merged with this batch).

Both #4 and #5 have the same issues as #3 (VEC).  What remains to be 
done is update a whole swath of user code.  This is hard to maintain in 
the branch and needs to be done during stage 1.  The change in #6 is 
similarly ready, so delaying it makes no sense.

What I can do is merge #1-#3 as one rev and merge the others as 3 
separate revisions.

> I also understand that you will, quickly after merging 1. to 3. convert
> all VEC users and remove the old interface.  This should be done
> before any of 4. - 6. is merged as generally we don't want the
> "half-converted" to persist, nor have multiple such half-conversions
> at the same time.

Yes, there will be no half conversions.  We are committed to continue 
making changes in this area.


Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-12 16:04 , Diego Novillo wrote:
> I will be sending 6 patches that implement all the changes we
> have been making on the cxx-conversion branch.  As described in
> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
> change the default bootstrap process so that stage 1 always
> builds with a C++ compiler.
>
> Other than the bootstrap change, the patches make no functional
> changes to the compiler.  Everything should build as it does now
> in trunk.
>
> I have split the merge in 6 main patches.  I will send these
> patches to the respective maintainers and gcc-patches.
> Please remember that the patches conform to the new C++ coding
> guidelines (http://gcc.gnu.org/codingconventions.html#Cxx_Conventions):
>
> 1- Configuration changes.
> 2- Re-write of VEC.
> 3- Re-write of gengtype to support C++ templates and
>     user-provided marking functions.
> 4- New hash table class.
> 5- Re-write double_int.
> 6- Implement tree macros as inline functions so they can be
>     called from gdb.

Thanks for all the reviews.

Barring any last minute blockers, I would like to schedule the final 
merge sometime this week.  Ideally, trunk should be free of activity 
while I do the final test and commit.

This merge touches several files, so I'm thinking that the best time is 
going to be on Thu 16/Aug around 2:00 GMT.

Once the merge lands in trunk, Lawrence and I will be monitoring 
automatic builders for any problems that may show up.  In the next few 
days we will be doing follow-up patches for VEC, hash table and gengtype.


Thanks.  Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-14 09:48 , Diego Novillo wrote:

> This merge touches several files, so I'm thinking that the best time is
> going to be on Thu 16/Aug around 2:00 GMT.

So, the fixes I needed from Lawrence are already in so we can proceed 
with the merge.  I'll commit the merge tonight at ~2:00 GMT.

After the merge is in, I will send an announcement and request major 
branch merges to wait for another 24 hrs to allow testers the chance to 
pick up this merge.


Thanks.  Diego.

Re: Merge C++ conversion into trunk

[Iain Sandoe]

On 14 Aug 2012, at 19:59, Diego Novillo wrote:
> 
> After the merge is in, I will send an announcement and request major branch merges to wait for another 24 hrs to allow testers the chance to pick up this merge.

The following patch (mimicking what has been done elsewhere at r190402) restores bootstrap for powerpc-darwin.
OK for trunk?

Iain

gcc/

	* config/rs6000/rs6000.c (macho_branch_islands): Adjust for changes to
	vec.h.

Index: gcc/config/rs6000/rs6000.c
===================================================================
--- gcc/config/rs6000/rs6000.c	(revision 190417)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -24952,7 +24952,7 @@ macho_branch_islands (void)
 
   while (!VEC_empty (branch_island, branch_islands))
     {
-      branch_island *bi = VEC_last (branch_island, branch_islands);
+      branch_island *bi = &VEC_last (branch_island, branch_islands);
       const char *label = IDENTIFIER_POINTER (bi->label_name);
       const char *name = IDENTIFIER_POINTER (bi->function_name);
       char name_buf[512];

Re: Merge C++ conversion into trunk

[Diego Novillo]

On 12-08-16 12:50 , Iain Sandoe wrote:
>
> On 14 Aug 2012, at 19:59, Diego Novillo wrote:
>>
>> After the merge is in, I will send an announcement and request major branch merges to wait for another 24 hrs to allow testers the chance to pick up this merge.
>
> The following patch (mimicking what has been done elsewhere at r190402) restores bootstrap for powerpc-darwin.
> OK for trunk?
>
> Iain
>
> gcc/
>
> 	* config/rs6000/rs6000.c (macho_branch_islands): Adjust for changes to
> 	vec.h.

OK, thanks.


Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[H.J. Lu]

On Tue, Aug 14, 2012 at 11:59 AM, Diego Novillo <dnovillo@google.com> wrote:
> On 12-08-14 09:48 , Diego Novillo wrote:
>
>> This merge touches several files, so I'm thinking that the best time is
>> going to be on Thu 16/Aug around 2:00 GMT.
>
>
> So, the fixes I needed from Lawrence are already in so we can proceed with
> the merge.  I'll commit the merge tonight at ~2:00 GMT.
>
> After the merge is in, I will send an announcement and request major branch
> merges to wait for another 24 hrs to allow testers the chance to pick up
> this merge.
>

The C++ merge caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332

GCC memory usage is more than doubled from <= 3GB
to >= 10GB.  Is this a known issue?

-- 
H.J.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Lawrence Crowl]

On 8/20/12, H.J. Lu <hjl.tools@gmail.com> wrote:
> The C++ merge caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> GCC memory usage is more than doubled from <= 3GB to >= 10GB.
> Is this a known issue?

The two memory stat reports show no differences.  Are you sure you
didn't splice in the wrong report?

-- 
Lawrence Crowl

Re: Merge C++ conversion into trunk (0/6 - Overview)

[H.J. Lu]

On Mon, Aug 20, 2012 at 6:31 PM, Lawrence Crowl <crowl@google.com> wrote:
> On 8/20/12, H.J. Lu <hjl.tools@gmail.com> wrote:
>> The C++ merge caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>>
>> GCC memory usage is more than doubled from <= 3GB to >= 10GB.
>> Is this a known issue?
>
> The two memory stat reports show no differences.  Are you sure you
> didn't splice in the wrong report?
>

Those are outputs from -fmem-report.  I am not sure how useful
they are for this bug.

-- 
H.J.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Richard Guenther]

On Tue, Aug 21, 2012 at 3:31 AM, Lawrence Crowl <crowl@google.com> wrote:
> On 8/20/12, H.J. Lu <hjl.tools@gmail.com> wrote:
>> The C++ merge caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>>
>> GCC memory usage is more than doubled from <= 3GB to >= 10GB.
>> Is this a known issue?
>
> The two memory stat reports show no differences.  Are you sure you
> didn't splice in the wrong report?

Well, easy things such as a messed up hashtab conversion (no freeing)
or vec conversion (no freeing) can cause this, or even the gengtype change
causing GC issues  (which is why those should
have been different revisions).

Richard.

> --
> Lawrence Crowl

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Richard Guenther]

On Sun, 12 Aug 2012, Diego Novillo wrote:

> I will be sending 6 patches that implement all the changes we
> have been making on the cxx-conversion branch.  As described in 
> http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html, these patches
> change the default bootstrap process so that stage 1 always
> builds with a C++ compiler.
> 
> Other than the bootstrap change, the patches make no functional
> changes to the compiler.  Everything should build as it does now
> in trunk.

...

and debugging becomes a nightmare (hello gdb people!)

(gdb) call debug_tree (*expr_p)
 <integer_cst 0x7ffff695d7c0 type <integer_type 0x7ffff67fa5e8 int> 
constant 9>
(gdb) call debug_tree (0x7ffff67fa5e8)
Cannot resolve function debug_tree to any overloaded instance

filing bugs does not help (as usual).  
http://sourceware.org/bugzilla/show_bug.cgi?id=13356

It's a year old, to prep for this change.  Now we're here.  Debugging
sucks.

Great.
Richard.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-15 07:59 , Richard Guenther wrote:

> (gdb) call debug_tree (*expr_p)
>   <integer_cst 0x7ffff695d7c0 type <integer_type 0x7ffff67fa5e8 int>
> constant 9>
> (gdb) call debug_tree (0x7ffff67fa5e8)
> Cannot resolve function debug_tree to any overloaded instance

Yeah, in the absence of overloads this is annoying.  Happens with 0, too.


Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Richard Guenther]

On Wed, 15 Aug 2012, Diego Novillo wrote:

> On 12-08-15 07:59 , Richard Guenther wrote:
> 
> > (gdb) call debug_tree (*expr_p)
> >   <integer_cst 0x7ffff695d7c0 type <integer_type 0x7ffff67fa5e8 int>
> > constant 9>
> > (gdb) call debug_tree (0x7ffff67fa5e8)
> > Cannot resolve function debug_tree to any overloaded instance
> 
> Yeah, in the absence of overloads this is annoying.  Happens with 0, too.

0 is fixed if you have recent enough gdb.

(gdb) call debug_tree (0)

as 0 is a null pointer constant.

Richard.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-15 08:18 , Richard Guenther wrote:

> 0 is fixed if you have recent enough gdb.
>
> (gdb) call debug_tree (0)
>
> as 0 is a null pointer constant.

Oh, cool.  Progress.

GDB folks, would it be hard to figure out that there is a single variant 
of the called function and trust the user that they are passing the 
right pointer value?


Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jan Kratochvil]

On Wed, 15 Aug 2012 14:23:37 +0200, Diego Novillo wrote:
> GDB folks, would it be hard to figure out that there is a single
> variant of the called function and trust the user that they are
> passing the right pointer value?

It is a needless violation of C++ resolving rules.  There are various easy way
how to get it working (in .gdbinit or cc1-gdb.gdb define GDB function, define
macro in GDB, use GDB python pretty printer instead (possibly even calling GCC
inferior function) etc.).

While I did not post such patch yet I would prefer to even forbid by default
expressions like
	(gdb) print *0x1234567
and enforce
	(gdb) print *(int *)0x1234567
instead as the former syntax confuses people (as commonly seen on IRC), the
same applies to calling functions without full debuginfo (they should require
an explicit cast in GDB) etc.


Regards,
Jan

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Michael Matz]

Hi,

On Wed, 15 Aug 2012, Jan Kratochvil wrote:

> It is a needless violation of C++ resolving rules.

It's not needless as the examples here show.  gdb is about helping people 
debug their stuff, not about language lawyering.

> There are various easy way how to get it working (in .gdbinit or 
> cc1-gdb.gdb define GDB function, define macro in GDB, use GDB python 
> pretty printer instead (possibly even calling GCC inferior function) 

We should define gdb macros for every not-overloaded function (which are 
_all_ GCC functions currently)?  Doesn't scale.


Ciao,
Michael.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jan Kratochvil]

Hi,

On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
> On Wed, 15 Aug 2012, Jan Kratochvil wrote:
> It's not needless as the examples here show.  gdb is about helping people 
> debug their stuff, not about language lawyering.

In such case there should be a GDB setting for it as at least from my opinion
it complicates the debugging.  Then there may be different opinions what
should be the default.


Thanks,
Jan

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jakub Jelinek]

On Wed, Aug 15, 2012 at 05:49:34PM +0200, Jan Kratochvil wrote:
> On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
> > On Wed, 15 Aug 2012, Jan Kratochvil wrote:
> > It's not needless as the examples here show.  gdb is about helping people 
> > debug their stuff, not about language lawyering.
> 
> In such case there should be a GDB setting for it as at least from my opinion
> it complicates the debugging.  Then there may be different opinions what
> should be the default.

That would be fine for gcc development purposes.  We could switch that mode
on at the end of gcc .gdbinit .

	Jakub

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 12-08-15 11:44 , Michael Matz wrote:
> Hi,
>
> On Wed, 15 Aug 2012, Jan Kratochvil wrote:
>
>> It is a needless violation of C++ resolving rules.
>
> It's not needless as the examples here show.  gdb is about helping people
> debug their stuff, not about language lawyering.

Agreed.  If I'm passing a numeric pointer constant, I'm already past the 
bleeding edge.  I don't want gdb to get in the way.  If the inferior 
call crashes, I get to keep both pieces.


Thanks.  Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Toon Moene]

On 08/15/2012 06:00 PM, Diego Novillo wrote:

 > On the switch to C++ as the build language for GCC ...

Here are my results:

0:30 UTC - using C as the initial build language:

http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01329.html

and:

18:40 UTC - using C++ as the initial build language:

http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01408.html

both for x86_64-unknown-linux-gnu native (note: 
--with-build-config=bootstrap-lto).

As far as I can, little difference.

Congratulations, Diego and all the others who worked on this transition.

Kind regards,

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

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Tom Tromey]

>>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes:

Diego> GDB folks, would it be hard to figure out that there is a single
Diego> variant of the called function and trust the user that they are
Diego> passing the right pointer value?

I asked Keith to resurrect his patch for this.

Tom

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Gabriel Dos Reis]

On Wed, Aug 15, 2012 at 12:53 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Diego" == Diego Novillo <dnovillo@google.com> writes:
>
> Diego> GDB folks, would it be hard to figure out that there is a single
> Diego> variant of the called function and trust the user that they are
> Diego> passing the right pointer value?
>
> I asked Keith to resurrect his patch for this.

Since people are concerned about typing rules, would it
be an option for GDB to allow people to input pointer
literals with the "p" suffix (or "0p" prefix instead of "0x")?

-- Gaby

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Tom Tromey]

>>>>> "Gaby" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

Tom> I asked Keith to resurrect his patch for this.

Gaby> Since people are concerned about typing rules, would it
Gaby> be an option for GDB to allow people to input pointer
Gaby> literals with the "p" suffix (or "0p" prefix instead of "0x")?

I think on the whole I'd rather have one extension instead of two.

It seems to me that the above would still require extensions in the
overloading code, to deal with conversions from void*; or perhaps some
magic pointer type.

What I think Keith is going to do is take his patch, change it so that
int->pointer conversions (if the int != 0) are given a different badness
from other conversions (meaning that, in theory, this should only be
chosen as a last resort, and shouldn't interfere with ordinary uses),
and finally add a parameter so that the feature can be disabled.

I hope this will be acceptable all around.

Tom

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Gabriel Dos Reis]

On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Gaby" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> Tom> I asked Keith to resurrect his patch for this.
>
> Gaby> Since people are concerned about typing rules, would it
> Gaby> be an option for GDB to allow people to input pointer
> Gaby> literals with the "p" suffix (or "0p" prefix instead of "0x")?
>
> I think on the whole I'd rather have one extension instead of two.

That is a fair point :-)

>
> It seems to me that the above would still require extensions in the
> overloading code, to deal with conversions from void*; or perhaps some
> magic pointer type.
>
> What I think Keith is going to do is take his patch, change it so that
> int->pointer conversions (if the int != 0) are given a different badness
> from other conversions (meaning that, in theory, this should only be
> chosen as a last resort, and shouldn't interfere with ordinary uses),
> and finally add a parameter so that the feature can be disabled.
>
> I hope this will be acceptable all around.

OK, that sounds reasonable.

Thanks!

-- Gaby

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Keith Seitz]

On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
> On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "Gaby" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>>
>> Tom> I asked Keith to resurrect his patch for this.
[snip]
>> I hope this will be acceptable all around.
>
> OK, that sounds reasonable.

I have committed a patch which should allow you to do this and closed 
c++/13356. If there are any further problems/issues, please let me know.

We've re-purposed an old, unused option, "check type". This option does 
absolutely nothing in older versions of gdb, so setting it 
unconditionally is safe for all recent versions of gdb: "set check type 
off".

Keith

Re: Merge C++ conversion into trunk (0/6 - Overview)

[H.J. Lu]

On Fri, Aug 17, 2012 at 10:45 AM, Keith Seitz <keiths@redhat.com> wrote:
> On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote:
>>
>> On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>>>
>>>>>>>> "Gaby" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>>>
>>>
>>> Tom> I asked Keith to resurrect his patch for this.
>
> [snip]
>
>>> I hope this will be acceptable all around.
>>
>>
>> OK, that sounds reasonable.
>
>
> I have committed a patch which should allow you to do this and closed
> c++/13356. If there are any further problems/issues, please let me know.
>
> We've re-purposed an old, unused option, "check type". This option does
> absolutely nothing in older versions of gdb, so setting it unconditionally
> is safe for all recent versions of gdb: "set check type off".
>

Shouldn't it be added to GCC .gdbinit?

-- 
H.J.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Mike Stump]

On Aug 15, 2012, at 4:59 AM, Richard Guenther wrote:
> and debugging becomes a nightmare (hello gdb people!)

> (gdb) call debug_tree (0x7ffff67fa5e8)
> Cannot resolve function debug_tree to any overloaded instance

Inquiring minds want to know if:

macro define debug_tree(A) ((tree)A)

makes the above work if you put it into gdbinit.in?  If yes, then, I think for now we should add such lines for every non-overloaded function, I too like using hex constants from dumps.  Oh, or, maybe we just add a debug_tree(long) overload just to satisfy gdb.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Mike Stump]

On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote:
> Other than the bootstrap change, the patches make no functional
> changes to the compiler.  Everything should build as it does now
> in trunk.

In my gcc/Makefile, I see:

CFLAGS = -g
CXXFLAGS = -g -O2

This makes builds in the gcc directory default to -O2, before they were -O0.  -O0 aides in debugging for people that develop the compiler.  Do you see this?

I think:

# Remove the -O2: for historical reasons, unless bootstrapping we prefer         
# optimizations to be activated explicitly by the toplevel.                      
case "$CC" in
  */prev-gcc/xgcc*) ;;
  *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
esac
AC_SUBST(CFLAGS)

in configure.ac does this.  I think if CXXFLAGS is also so done, we'd gain parity.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Paolo Bonzini]

Il 23/08/2012 22:54, Mike Stump ha scritto:
> 
> # Remove the -O2: for historical reasons, unless bootstrapping we prefer         
> # optimizations to be activated explicitly by the toplevel.                      
> case "$CC" in
>   */prev-gcc/xgcc*) ;;
>   *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
> esac
> AC_SUBST(CFLAGS)
> 
> in configure.ac does this.  I think if CXXFLAGS is also so done, we'd gain parity.

Agreed, patch is preapproved.  This is not really done to aid debugging
though, it is to avoid optimization bugs when compiling stage1.

Paolo

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Mike Stump]

On Aug 24, 2012, at 12:24 AM, Paolo Bonzini wrote:
> Agreed, patch is preapproved.  This is not really done to aid debugging
> though, it is to avoid optimization bugs when compiling stage1.

Ah, but building a non-bootstrap compiler from the top-level builds -O2 and when built from the gcc subtree, builds -O0.  Ever wonder why?  It isn't to avoid code-gen errors in CC.  it is to make the developers life easier.  I know, so much of gcc's history is lost to time and at times, not handed down to the new kids.  The bad bits, just fade away.  The useful things, for example, this, will live on, as some of use still know about and use the feature.  When it breaks, we complain.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 2012-08-23 16:54 , Mike Stump wrote:
> On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote:
>> Other than the bootstrap change, the patches make no functional
>> changes to the compiler.  Everything should build as it does now in
>> trunk.
>
> In my gcc/Makefile, I see:
>
> CFLAGS = -g CXXFLAGS = -g -O2

Odd.  I see:

CFLAGS = -g
CXXFLAGS = -g

in stage1-gcc/

In gcc/ I see both set to -g -O2, of course.  I would've noticed -g -O2 
in the stage1 build because I am constantly debugging that binary.


Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jakub Jelinek]

On Fri, Aug 24, 2012 at 08:30:36AM -0400, Diego Novillo wrote:
> On 2012-08-23 16:54 , Mike Stump wrote:
> >On Aug 12, 2012, at 1:04 PM, Diego Novillo wrote:
> >>Other than the bootstrap change, the patches make no functional
> >>changes to the compiler.  Everything should build as it does now in
> >>trunk.
> >
> >In my gcc/Makefile, I see:
> >
> >CFLAGS = -g CXXFLAGS = -g -O2
> 
> Odd.  I see:
> 
> CFLAGS = -g
> CXXFLAGS = -g
> 
> in stage1-gcc/
> 
> In gcc/ I see both set to -g -O2, of course.  I would've noticed -g
> -O2 in the stage1 build because I am constantly debugging that
> binary.

You haven't built your compiler with --disable-bootstrap, so you aren't
seeing what Mike is complaining about.

	Jakub

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Diego Novillo]

On 2012-08-24 08:35 , Jakub Jelinek wrote:

> You haven't built your compiler with --disable-bootstrap, so you aren't
> seeing what Mike is complaining about.

Ah, Mike failed to mention that detail.

Mike, it is unlikely that I will be able to work on a fix before I 
leave.  It does not look like a difficult fix in any case.  Would you 
mind preparing a patch?  If not, I'll get to it after I return.


Thanks.  Diego.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Mike Stump]

On Aug 24, 2012, at 5:35 AM, Jakub Jelinek wrote:
> You haven't built your compiler with --disable-bootstrap, so you aren't
> seeing what Mike is complaining about.

Actually, I'm not using disable....  Just a normal cross compile.

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jakub Jelinek]

On Thu, Aug 23, 2012 at 01:54:38PM -0700, Mike Stump wrote:
> I think:
> 
> # Remove the -O2: for historical reasons, unless bootstrapping we prefer         
> # optimizations to be activated explicitly by the toplevel.                      
> case "$CC" in
>   */prev-gcc/xgcc*) ;;
>   *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
> esac
> AC_SUBST(CFLAGS)
> 
> in configure.ac does this.  I think if CXXFLAGS is also so done, we'd gain parity.

Can we get this change in?  The current state is terribly annoying.

	Jakub

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Paolo Bonzini]

Il 13/09/2012 10:46, Jakub Jelinek ha scritto:
>> > # Remove the -O2: for historical reasons, unless bootstrapping we prefer         
>> > # optimizations to be activated explicitly by the toplevel.                      
>> > case "$CC" in
>> >   */prev-gcc/xgcc*) ;;
>> >   *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
>> > esac
>> > AC_SUBST(CFLAGS)
>> > 
>> > in configure.ac does this.  I think if CXXFLAGS is also so done, we'd gain parity.
> Can we get this change in?  The current state is terribly annoying.

Yes, please go ahead.

Paolo

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Jakub Jelinek]

On Thu, Sep 13, 2012 at 10:53:23AM +0200, Paolo Bonzini wrote:
> Il 13/09/2012 10:46, Jakub Jelinek ha scritto:
> >> > # Remove the -O2: for historical reasons, unless bootstrapping we prefer         
> >> > # optimizations to be activated explicitly by the toplevel.                      
> >> > case "$CC" in
> >> >   */prev-gcc/xgcc*) ;;
> >> >   *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
> >> > esac
> >> > AC_SUBST(CFLAGS)
> >> > 
> >> > in configure.ac does this.  I think if CXXFLAGS is also so done, we'd gain parity.
> > Can we get this change in?  The current state is terribly annoying.
> 
> Yes, please go ahead.

Here it is, bootstrapped/regtested on x86_64-linux and i686-linux,
additionally tested on --disable-bootstrap tree, both by make cc1 inside of
gcc subdir (no -O2) and make all-gcc above it (with -O2).

Ok for trunk?

2012-09-13  Jakub Jelinek  <jakub@redhat.com>

	* configure.ac (CXXFLAGS): Remove -O2 when not bootstrapping.
	* configure: Regenerated.

--- gcc/configure.ac.jj	2012-09-13 07:54:41.000000000 +0200
+++ gcc/configure.ac	2012-09-13 14:19:54.016741197 +0200
@@ -296,9 +296,11 @@ AC_SUBST(OUTPUT_OPTION)
 # optimizations to be activated explicitly by the toplevel.
 case "$CC" in
   */prev-gcc/xgcc*) ;;
-  *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
+  *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" `
+     CXXFLAGS=`echo $CXXFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
 esac
 AC_SUBST(CFLAGS)
+AC_SUBST(CXXFLAGS)
 
 # Determine PICFLAG for target gnatlib.
 GCC_PICFLAG_FOR_TARGET
--- gcc/configure.jj	2012-09-13 07:54:39.000000000 +0200
+++ gcc/configure	2012-09-13 14:34:40.429269215 +0200
@@ -4863,10 +4863,12 @@ fi
 # optimizations to be activated explicitly by the toplevel.
 case "$CC" in
   */prev-gcc/xgcc*) ;;
-  *) CFLAGS=`echo $CFLAGS | sed "s/-O[s0-9]* *//" ` ;;
+  *) CFLAGS=`echo $CFLAGS | sed "s/-O[s0-9]* *//" `
+     CXXFLAGS=`echo $CXXFLAGS | sed "s/-O[s0-9]* *//" ` ;;
 esac
 
 
+
 # Determine PICFLAG for target gnatlib.
 
 
@@ -17782,7 +17784,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17785 "configure"
+#line 17787 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17888,7 +17890,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17891 "configure"
+#line 17893 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H


	Jakub

Re: Merge C++ conversion into trunk (0/6 - Overview)

[Paolo Bonzini]

Il 13/09/2012 17:57, Jakub Jelinek ha scritto:
>>> > > Can we get this change in?  The current state is terribly annoying.
>> > 
>> > Yes, please go ahead.
> Here it is, bootstrapped/regtested on x86_64-linux and i686-linux,
> additionally tested on --disable-bootstrap tree, both by make cc1 inside of
> gcc subdir (no -O2) and make all-gcc above it (with -O2).

Ok.

Paolo

[PATCH] Fix up CFLAGS/CXXFLAGS gcc/configure adjustment (PR other/54692)

[Jakub Jelinek]

Hi!

On Thu, Sep 13, 2012 at 06:24:14PM +0200, Paolo Bonzini wrote:
> Il 13/09/2012 17:57, Jakub Jelinek ha scritto:
> >>> > > Can we get this change in?  The current state is terribly annoying.
> >> > 
> >> > Yes, please go ahead.
> > Here it is, bootstrapped/regtested on x86_64-linux and i686-linux,
> > additionally tested on --disable-bootstrap tree, both by make cc1 inside of
> > gcc subdir (no -O2) and make all-gcc above it (with -O2).
> 
> Ok.

Seems the sed command was using " *" at the end, so it happily changed
e.g. "-Og " into just "g " instead of either keeping "-Og " in, or
removing it altogether.  This patches fixes it, now
-Ofast, -Og, -Os, -O, -O[0-9]* are removed when followed by whitespace
and not otherwise.  Bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

2012-09-25  Jakub Jelinek  <jakub@redhat.com>

	PR other/54692
	* configure.ac (CFLAGS, CXXFLAGS): Remove -Ofast or -Og
	properly.
	* configure: Regenerated.

--- gcc/configure.ac.jj	2012-09-13 18:29:46.000000000 +0200
+++ gcc/configure.ac	2012-09-24 21:47:41.606278259 +0200
@@ -296,8 +296,8 @@ AC_SUBST(OUTPUT_OPTION)
 # optimizations to be activated explicitly by the toplevel.
 case "$CC" in
   */prev-gcc/xgcc*) ;;
-  *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" `
-     CXXFLAGS=`echo $CXXFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
+  *) CFLAGS=`echo "$CFLAGS " | sed -e "s/-Ofast[[ 	]]//" -e "s/-O[[gs]][[ 	]]//" -e "s/-O[[0-9]]*[[ 	]]//" `
+     CXXFLAGS=`echo "$CXXFLAGS " | sed -e "s/-Ofast[[ 	]]//" -e "s/-O[[gs]][[ 	]]//" -e "s/-O[[0-9]]*[[ 	]]//" ` ;;
 esac
 AC_SUBST(CFLAGS)
 AC_SUBST(CXXFLAGS)
--- gcc/configure.jj	2012-09-17 11:13:13.119075354 +0200
+++ gcc/configure	2012-09-24 21:49:02.900837573 +0200
@@ -4863,8 +4863,8 @@ fi
 # optimizations to be activated explicitly by the toplevel.
 case "$CC" in
   */prev-gcc/xgcc*) ;;
-  *) CFLAGS=`echo $CFLAGS | sed "s/-O[s0-9]* *//" `
-     CXXFLAGS=`echo $CXXFLAGS | sed "s/-O[s0-9]* *//" ` ;;
+  *) CFLAGS=`echo "$CFLAGS " | sed -e "s/-Ofast[ 	]//" -e "s/-O[gs][ 	]//" -e "s/-O[0-9]*[ 	]//" `
+     CXXFLAGS=`echo "$CXXFLAGS " | sed -e "s/-Ofast[ 	]//" -e "s/-O[gs][ 	]//" -e "s/-O[0-9]*[ 	]//" ` ;;
 esac
 
 


	Jakub

Re: [PATCH] Fix up CFLAGS/CXXFLAGS gcc/configure adjustment (PR other/54692)

[Richard Guenther]

On Tue, Sep 25, 2012 at 1:19 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> On Thu, Sep 13, 2012 at 06:24:14PM +0200, Paolo Bonzini wrote:
>> Il 13/09/2012 17:57, Jakub Jelinek ha scritto:
>> >>> > > Can we get this change in?  The current state is terribly annoying.
>> >> >
>> >> > Yes, please go ahead.
>> > Here it is, bootstrapped/regtested on x86_64-linux and i686-linux,
>> > additionally tested on --disable-bootstrap tree, both by make cc1 inside of
>> > gcc subdir (no -O2) and make all-gcc above it (with -O2).
>>
>> Ok.
>
> Seems the sed command was using " *" at the end, so it happily changed
> e.g. "-Og " into just "g " instead of either keeping "-Og " in, or
> removing it altogether.  This patches fixes it, now
> -Ofast, -Og, -Os, -O, -O[0-9]* are removed when followed by whitespace
> and not otherwise.  Bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?

Looks good to me.

Thanks,
Richard.

> 2012-09-25  Jakub Jelinek  <jakub@redhat.com>
>
>         PR other/54692
>         * configure.ac (CFLAGS, CXXFLAGS): Remove -Ofast or -Og
>         properly.
>         * configure: Regenerated.
>
> --- gcc/configure.ac.jj 2012-09-13 18:29:46.000000000 +0200
> +++ gcc/configure.ac    2012-09-24 21:47:41.606278259 +0200
> @@ -296,8 +296,8 @@ AC_SUBST(OUTPUT_OPTION)
>  # optimizations to be activated explicitly by the toplevel.
>  case "$CC" in
>    */prev-gcc/xgcc*) ;;
> -  *) CFLAGS=`echo $CFLAGS | sed "s/-O[[s0-9]]* *//" `
> -     CXXFLAGS=`echo $CXXFLAGS | sed "s/-O[[s0-9]]* *//" ` ;;
> +  *) CFLAGS=`echo "$CFLAGS " | sed -e "s/-Ofast[[      ]]//" -e "s/-O[[gs]][[  ]]//" -e "s/-O[[0-9]]*[[        ]]//" `
> +     CXXFLAGS=`echo "$CXXFLAGS " | sed -e "s/-Ofast[[  ]]//" -e "s/-O[[gs]][[  ]]//" -e "s/-O[[0-9]]*[[        ]]//" ` ;;
>  esac
>  AC_SUBST(CFLAGS)
>  AC_SUBST(CXXFLAGS)
> --- gcc/configure.jj    2012-09-17 11:13:13.119075354 +0200
> +++ gcc/configure       2012-09-24 21:49:02.900837573 +0200
> @@ -4863,8 +4863,8 @@ fi
>  # optimizations to be activated explicitly by the toplevel.
>  case "$CC" in
>    */prev-gcc/xgcc*) ;;
> -  *) CFLAGS=`echo $CFLAGS | sed "s/-O[s0-9]* *//" `
> -     CXXFLAGS=`echo $CXXFLAGS | sed "s/-O[s0-9]* *//" ` ;;
> +  *) CFLAGS=`echo "$CFLAGS " | sed -e "s/-Ofast[       ]//" -e "s/-O[gs][      ]//" -e "s/-O[0-9]*[    ]//" `
> +     CXXFLAGS=`echo "$CXXFLAGS " | sed -e "s/-Ofast[   ]//" -e "s/-O[gs][      ]//" -e "s/-O[0-9]*[    ]//" ` ;;
>  esac
>
>
>
>
>         Jakub

Re: [PATCH] Fix up CFLAGS/CXXFLAGS gcc/configure adjustment (PR other/54692)

[Paolo Bonzini]

Il 25/09/2012 13:19, Jakub Jelinek ha scritto:
> Hi!
> 
> On Thu, Sep 13, 2012 at 06:24:14PM +0200, Paolo Bonzini wrote:
>> Il 13/09/2012 17:57, Jakub Jelinek ha scritto:
>>>>>>> Can we get this change in?  The current state is terribly annoying.
>>>>>
>>>>> Yes, please go ahead.
>>> Here it is, bootstrapped/regtested on x86_64-linux and i686-linux,
>>> additionally tested on --disable-bootstrap tree, both by make cc1 inside of
>>> gcc subdir (no -O2) and make all-gcc above it (with -O2).
>>
>> Ok.
> 
> Seems the sed command was using " *" at the end, so it happily changed
> e.g. "-Og " into just "g " instead of either keeping "-Og " in, or
> removing it altogether.  This patches fixes it, now
> -Ofast, -Og, -Os, -O, -O[0-9]* are removed when followed by whitespace
> and not otherwise.  Bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?

Yes, thanks.  Would it make sense to leave -Og in?

Paolo

Re: [PATCH] Fix up CFLAGS/CXXFLAGS gcc/configure adjustment (PR other/54692)

[Jakub Jelinek]

On Tue, Sep 25, 2012 at 05:59:28PM +0200, Paolo Bonzini wrote:
> Il 25/09/2012 13:19, Jakub Jelinek ha scritto:
> Yes, thanks.  Would it make sense to leave -Og in?

Maybe once it matures more.  E.g. the scheduler isn't currently
tweaked for -Og (should either not schedule at all, or only
within group of insns with the same location (source loc + block),
possibly allowing no location/block insns to be moved around at will).

	Jakub