* [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
@ 2008-03-25 17:58 Doug Gregor
2008-03-26 6:46 ` Andrew Pinski
2008-03-26 20:44 ` Stan Shebs
0 siblings, 2 replies; 42+ messages in thread
From: Doug Gregor @ 2008-03-25 17:58 UTC (permalink / raw)
To: GCC Patches
[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]
My SFINAE patch to the C++ front end broke the Objective-C++ front
end. This patch fixes the problem, which involves some renaming of
routines in the C++ front end as well as minor fixes to the
Objective-C++ front end. Okay for mainline?
- Doug
2008-03-25 Douglas Gregor <doug.gregor@gmail.com>
* typeck.c (build_x_compound_expr): Use cp_build_compound_expr.
(build_compound_expr): New, for compatibility with C
build_compound_expr.
(cp_build_compound_expr): Renamed from build_compound_expr.
(build_c_cast): New, for compatibility with C build_c_cast.
(cp_build_c_cast): Renamed from build_c_cast.
* init.c (build_vec_delete_1): Fix calls to build_compound_expr.
* decl.c (cxx_maybe_build_cleanup): Ditto.
* cp-tree.h (build_compound_expr): Add C-compatibile prototype.
(cp_build_compound_expr): Renamed from build_compound_expr.
(build_c_cast): Add C-compatible prototype.
(cp_build_c_cast): Renamed from build_c_cast.
* typeck2.c (build_functional_cast): Use cp_build_c_cast.
* parser.c (cp_parser_cast_expression): Fix call to build_c_cast.
2008-03-25 Douglas Gregor <doug.gregor@gmail.com>
* objc-act.c (objc_build_component_ref): Fix call to
finish_class_member_access_expr.
(objc_generate_cxx_ctor_or_dtor): Fix call to
build_special_member_call.
[-- Attachment #2: sfinae-339-objc.patch --]
[-- Type: application/octet-stream, Size: 7113 bytes --]
Index: cp/typeck.c
===================================================================
--- cp/typeck.c (revision 133519)
+++ cp/typeck.c (working copy)
@@ -5037,7 +5037,7 @@ build_x_compound_expr (tree op1, tree op
result = build_new_op (COMPOUND_EXPR, LOOKUP_NORMAL, op1, op2, NULL_TREE,
/*overloaded_p=*/NULL, complain);
if (!result)
- result = build_compound_expr (op1, op2, complain);
+ result = cp_build_compound_expr (op1, op2, complain);
if (processing_template_decl && result != error_mark_node)
return build_min_non_dep (COMPOUND_EXPR, result, orig_op1, orig_op2);
@@ -5045,10 +5045,18 @@ build_x_compound_expr (tree op1, tree op
return result;
}
+/* Like cp_build_compound_expr, but for the c-common bits. */
+
+tree
+build_compound_expr (tree lhs, tree rhs)
+{
+ return cp_build_compound_expr (lhs, rhs, tf_warning_or_error);
+}
+
/* Build a compound expression. */
tree
-build_compound_expr (tree lhs, tree rhs, tsubst_flags_t complain)
+cp_build_compound_expr (tree lhs, tree rhs, tsubst_flags_t complain)
{
lhs = convert_to_void (lhs, "left-hand operand of comma", complain);
@@ -5775,11 +5783,19 @@ build_const_cast (tree type, tree expr,
/*valid_p=*/NULL);
}
+/* Like cp_build_c_cast, but for the c-common bits. */
+
+tree
+build_c_cast (tree type, tree expr)
+{
+ return cp_build_c_cast (type, expr, tf_warning_or_error);
+}
+
/* Build an expression representing an explicit C-style cast to type
TYPE of expression EXPR. */
tree
-build_c_cast (tree type, tree expr, tsubst_flags_t complain)
+cp_build_c_cast (tree type, tree expr, tsubst_flags_t complain)
{
tree value = expr;
tree result;
@@ -6466,7 +6482,7 @@ build_ptrmemfunc (tree type, tree pfn, i
/* Handle null pointer to member function conversions. */
if (integer_zerop (pfn))
{
- pfn = build_c_cast (type, integer_zero_node, tf_warning_or_error);
+ pfn = build_c_cast (type, integer_zero_node);
return build_ptrmemfunc1 (to_type,
integer_zero_node,
pfn);
Index: cp/init.c
===================================================================
--- cp/init.c (revision 133519)
+++ cp/init.c (working copy)
@@ -2528,15 +2528,13 @@ build_vec_delete_1 (tree base, tree maxi
body = build_compound_expr
(body, cp_build_modify_expr (tbase, NOP_EXPR,
build2 (POINTER_PLUS_EXPR, ptype, tbase, tmp),
- tf_warning_or_error),
- tf_warning_or_error);
+ tf_warning_or_error));
body = build_compound_expr
(body, build_delete (ptype, tbase, sfk_complete_destructor,
- LOOKUP_NORMAL|LOOKUP_DESTRUCTOR, 1),
- tf_warning_or_error);
+ LOOKUP_NORMAL|LOOKUP_DESTRUCTOR, 1));
loop = build1 (LOOP_EXPR, void_type_node, body);
- loop = build_compound_expr (tbase_init, loop, tf_warning_or_error);
+ loop = build_compound_expr (tbase_init, loop);
no_destructor:
/* If the delete flag is one, or anything else with the low bit set,
@@ -2582,7 +2580,7 @@ build_vec_delete_1 (tree base, tree maxi
else if (!body)
body = deallocate_expr;
else
- body = build_compound_expr (body, deallocate_expr, tf_warning_or_error);
+ body = build_compound_expr (body, deallocate_expr);
if (!body)
body = integer_zero_node;
Index: cp/decl.c
===================================================================
--- cp/decl.c (revision 133519)
+++ cp/decl.c (working copy)
@@ -12229,7 +12229,7 @@ cxx_maybe_build_cleanup (tree decl)
call = build_delete (TREE_TYPE (addr), addr,
sfk_complete_destructor, flags, 0);
if (cleanup)
- cleanup = build_compound_expr (cleanup, call, tf_warning_or_error);
+ cleanup = build_compound_expr (cleanup, call);
else
cleanup = call;
}
Index: cp/cp-tree.h
===================================================================
--- cp/cp-tree.h (revision 133519)
+++ cp/cp-tree.h (working copy)
@@ -4804,11 +4804,13 @@ extern tree build_x_conditional_expr (t
tsubst_flags_t);
extern tree build_x_compound_expr_from_list (tree, const char *);
extern tree build_x_compound_expr (tree, tree, tsubst_flags_t);
-extern tree build_compound_expr (tree, tree, tsubst_flags_t);
+extern tree build_compound_expr (tree, tree);
+extern tree cp_build_compound_expr (tree, tree, tsubst_flags_t);
extern tree build_static_cast (tree, tree, tsubst_flags_t);
extern tree build_reinterpret_cast (tree, tree, tsubst_flags_t);
extern tree build_const_cast (tree, tree, tsubst_flags_t);
-extern tree build_c_cast (tree, tree, tsubst_flags_t);
+extern tree build_c_cast (tree, tree);
+extern tree cp_build_c_cast (tree, tree, tsubst_flags_t);
extern tree build_x_modify_expr (tree, enum tree_code, tree,
tsubst_flags_t);
extern tree cp_build_modify_expr (tree, enum tree_code, tree,
Index: cp/typeck2.c
===================================================================
--- cp/typeck2.c (revision 133519)
+++ cp/typeck2.c (working copy)
@@ -1342,7 +1342,7 @@ build_functional_cast (tree exp, tree pa
/* This must build a C cast. */
parms = build_x_compound_expr_from_list (parms, "functional cast");
- return build_c_cast (type, parms, complain);
+ return cp_build_c_cast (type, parms, complain);
}
/* Prepare to evaluate as a call to a constructor. If this expression
@@ -1363,7 +1363,7 @@ build_functional_cast (tree exp, tree pa
conversion is equivalent (in definedness, and if defined in
meaning) to the corresponding cast expression. */
if (parms && TREE_CHAIN (parms) == NULL_TREE)
- return build_c_cast (type, TREE_VALUE (parms), complain);
+ return cp_build_c_cast (type, TREE_VALUE (parms), complain);
/* [expr.type.conv]
Index: cp/parser.c
===================================================================
--- cp/parser.c (revision 133519)
+++ cp/parser.c (working copy)
@@ -5880,7 +5880,7 @@ cp_parser_cast_expression (cp_parser *pa
return error_mark_node;
/* Perform the cast. */
- expr = build_c_cast (type, expr, tf_warning_or_error);
+ expr = build_c_cast (type, expr);
return expr;
}
}
Index: objc/objc-act.c
===================================================================
--- objc/objc-act.c (revision 133518)
+++ objc/objc-act.c (working copy)
@@ -1255,7 +1255,8 @@ objc_build_component_ref (tree datum, tr
front-end, but 'finish_class_member_access_expr' seems to be
a worthy substitute. */
#ifdef OBJCPLUS
- return finish_class_member_access_expr (datum, component, false);
+ return finish_class_member_access_expr (datum, component, false,
+ tf_warning_or_error);
#else
return build_component_ref (datum, component);
#endif
@@ -4493,7 +4494,7 @@ objc_generate_cxx_ctor_or_dtor (bool dto
(build_special_member_call
(build_ivar_reference (DECL_NAME (ivar)),
dtor ? complete_dtor_identifier : complete_ctor_identifier,
- NULL_TREE, type, LOOKUP_NORMAL));
+ NULL_TREE, type, LOOKUP_NORMAL, tf_warning_or_error));
}
}
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-25 17:58 [C++/Obj-C++ PATCH] Fix Objective-C++ breakage Doug Gregor
@ 2008-03-26 6:46 ` Andrew Pinski
2008-03-26 13:07 ` Richard Guenther
` (2 more replies)
2008-03-26 20:44 ` Stan Shebs
1 sibling, 3 replies; 42+ messages in thread
From: Andrew Pinski @ 2008-03-26 6:46 UTC (permalink / raw)
To: Doug Gregor; +Cc: GCC Patches
On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> My SFINAE patch to the C++ front end broke the Objective-C++ front
> end. This patch fixes the problem, which involves some renaming of
> routines in the C++ front end as well as minor fixes to the
> Objective-C++ front end. Okay for mainline?
This is the third bootstrap failure for Objective-C++ in less than two
weeks. I think it is either time to require Objective-C++ building or
decide we should remove it.
-- Pinski
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-26 6:46 ` Andrew Pinski
@ 2008-03-26 13:07 ` Richard Guenther
2008-03-26 13:17 ` NightStrike
2008-03-26 15:12 ` Tom Tromey
2008-03-26 20:59 ` Stan Shebs
2 siblings, 1 reply; 42+ messages in thread
From: Richard Guenther @ 2008-03-26 13:07 UTC (permalink / raw)
To: Andrew Pinski; +Cc: Doug Gregor, GCC Patches
On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> > My SFINAE patch to the C++ front end broke the Objective-C++ front
> > end. This patch fixes the problem, which involves some renaming of
> > routines in the C++ front end as well as minor fixes to the
> > Objective-C++ front end. Okay for mainline?
>
> This is the third bootstrap failure for Objective-C++ in less than two
> weeks. I think it is either time to require Objective-C++ building or
> decide we should remove it.
I agree. It is too tightly coupled to common C/C++ code to be not
enabled by default if it stays in. But you can add a +1 for the voting count
for removing the ObjC++ frontend.
Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-26 13:07 ` Richard Guenther
@ 2008-03-26 13:17 ` NightStrike
2008-03-26 13:41 ` Richard Guenther
0 siblings, 1 reply; 42+ messages in thread
From: NightStrike @ 2008-03-26 13:17 UTC (permalink / raw)
To: Richard Guenther; +Cc: Andrew Pinski, Doug Gregor, GCC Patches
On 3/26/08, Richard Guenther <richard.guenther@gmail.com> wrote:
> On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> > > My SFINAE patch to the C++ front end broke the Objective-C++ front
> > > end. This patch fixes the problem, which involves some renaming of
> > > routines in the C++ front end as well as minor fixes to the
> > > Objective-C++ front end. Okay for mainline?
> >
> > This is the third bootstrap failure for Objective-C++ in less than two
> > weeks. I think it is either time to require Objective-C++ building or
> > decide we should remove it.
>
> I agree. It is too tightly coupled to common C/C++ code to be not
> enabled by default if it stays in. But you can add a +1 for the voting count
> for removing the ObjC++ frontend.
Why do you want to remove the frontend?
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-26 13:17 ` NightStrike
@ 2008-03-26 13:41 ` Richard Guenther
2008-03-26 18:21 ` Doug Gregor
0 siblings, 1 reply; 42+ messages in thread
From: Richard Guenther @ 2008-03-26 13:41 UTC (permalink / raw)
To: NightStrike; +Cc: Andrew Pinski, Doug Gregor, GCC Patches
On Wed, Mar 26, 2008 at 2:10 PM, NightStrike <nightstrike@gmail.com> wrote:
>
> On 3/26/08, Richard Guenther <richard.guenther@gmail.com> wrote:
> > On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> > > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> > > > My SFINAE patch to the C++ front end broke the Objective-C++ front
> > > > end. This patch fixes the problem, which involves some renaming of
> > > > routines in the C++ front end as well as minor fixes to the
> > > > Objective-C++ front end. Okay for mainline?
> > >
> > > This is the third bootstrap failure for Objective-C++ in less than two
> > > weeks. I think it is either time to require Objective-C++ building or
> > > decide we should remove it.
> >
> > I agree. It is too tightly coupled to common C/C++ code to be not
> > enabled by default if it stays in. But you can add a +1 for the voting count
> > for removing the ObjC++ frontend.
>
> Why do you want to remove the frontend?
Because it is basically unmaintained.
Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-26 6:46 ` Andrew Pinski
2008-03-26 13:07 ` Richard Guenther
@ 2008-03-26 15:12 ` Tom Tromey
2008-03-26 20:59 ` Stan Shebs
2 siblings, 0 replies; 42+ messages in thread
From: Tom Tromey @ 2008-03-26 15:12 UTC (permalink / raw)
To: Andrew Pinski; +Cc: Doug Gregor, GCC Patches
>>>>> "Andrew" == Andrew Pinski <pinskia@gmail.com> writes:
Andrew> This is the third bootstrap failure for Objective-C++ in less
Andrew> than two weeks. I think it is either time to require
Andrew> Objective-C++ building or decide we should remove it.
FWIW, I agree.
Tom
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-26 13:41 ` Richard Guenther
@ 2008-03-26 18:21 ` Doug Gregor
2008-03-26 19:57 ` Kaveh R. GHAZI
0 siblings, 1 reply; 42+ messages in thread
From: Doug Gregor @ 2008-03-26 18:21 UTC (permalink / raw)
To: Richard Guenther; +Cc: NightStrike, Andrew Pinski, GCC Patches
On Wed, Mar 26, 2008 at 9:16 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
>
> On Wed, Mar 26, 2008 at 2:10 PM, NightStrike <nightstrike@gmail.com> wrote:
> >
> > On 3/26/08, Richard Guenther <richard.guenther@gmail.com> wrote:
> > > On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> > > > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> > > > > My SFINAE patch to the C++ front end broke the Objective-C++ front
> > > > > end. This patch fixes the problem, which involves some renaming of
> > > > > routines in the C++ front end as well as minor fixes to the
> > > > > Objective-C++ front end. Okay for mainline?
> > > >
> > > > This is the third bootstrap failure for Objective-C++ in less than two
> > > > weeks. I think it is either time to require Objective-C++ building or
> > > > decide we should remove it.
> > >
> > > I agree. It is too tightly coupled to common C/C++ code to be not
> > > enabled by default if it stays in. But you can add a +1 for the voting count
> > > for removing the ObjC++ frontend.
> >
> > Why do you want to remove the frontend?
>
> Because it is basically unmaintained.
Which means I don't even know whether I can commit this patch to *fix*
the front end or not. I'll give it 24 more hours, and commit if I
don't hear any screams.
- Doug
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-26 18:21 ` Doug Gregor
@ 2008-03-26 19:57 ` Kaveh R. GHAZI
0 siblings, 0 replies; 42+ messages in thread
From: Kaveh R. GHAZI @ 2008-03-26 19:57 UTC (permalink / raw)
To: Doug Gregor, stanshebs
Cc: Richard Guenther, NightStrike, Andrew Pinski, GCC Patches
On Wed, 26 Mar 2008, Doug Gregor wrote:
> On Wed, Mar 26, 2008 at 9:16 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
> >
> > On Wed, Mar 26, 2008 at 2:10 PM, NightStrike <nightstrike@gmail.com> wrote:
> > >
> > > On 3/26/08, Richard Guenther <richard.guenther@gmail.com> wrote:
> > > > On Wed, Mar 26, 2008 at 4:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> > > > > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> > > > > > My SFINAE patch to the C++ front end broke the Objective-C++ front
> > > > > > end. This patch fixes the problem, which involves some renaming of
> > > > > > routines in the C++ front end as well as minor fixes to the
> > > > > > Objective-C++ front end. Okay for mainline?
> > > > >
> > > > > This is the third bootstrap failure for Objective-C++ in less than two
> > > > > weeks. I think it is either time to require Objective-C++ building or
> > > > > decide we should remove it.
> > > >
> > > > I agree. It is too tightly coupled to common C/C++ code to be not
> > > > enabled by default if it stays in. But you can add a +1 for the voting count
> > > > for removing the ObjC++ frontend.
> > >
> > > Why do you want to remove the frontend?
> >
> > Because it is basically unmaintained.
>
> Which means I don't even know whether I can commit this patch to *fix*
> the front end or not. I'll give it 24 more hours, and commit if I
> don't hear any screams.
> - Doug
Actually we do have a maintainer, Stan would you please take a look?
Thanks,
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-25 17:58 [C++/Obj-C++ PATCH] Fix Objective-C++ breakage Doug Gregor
2008-03-26 6:46 ` Andrew Pinski
@ 2008-03-26 20:44 ` Stan Shebs
1 sibling, 0 replies; 42+ messages in thread
From: Stan Shebs @ 2008-03-26 20:44 UTC (permalink / raw)
To: Doug Gregor; +Cc: GCC Patches
Doug Gregor wrote:
> My SFINAE patch to the C++ front end broke the Objective-C++ front
> end. This patch fixes the problem, which involves some renaming of
> routines in the C++ front end as well as minor fixes to the
> Objective-C++ front end. Okay for mainline?
>
Yes, this looks fine. Sorry to take a day to get to it - hadn't sunk in
that it was breaking builds. :-)
Stan
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-26 6:46 ` Andrew Pinski
2008-03-26 13:07 ` Richard Guenther
2008-03-26 15:12 ` Tom Tromey
@ 2008-03-26 20:59 ` Stan Shebs
2008-03-27 7:49 ` Kaveh R. GHAZI
2 siblings, 1 reply; 42+ messages in thread
From: Stan Shebs @ 2008-03-26 20:59 UTC (permalink / raw)
To: Andrew Pinski; +Cc: Doug Gregor, GCC Patches
Andrew Pinski wrote:
> On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
>
>> My SFINAE patch to the C++ front end broke the Objective-C++ front
>> end. This patch fixes the problem, which involves some renaming of
>> routines in the C++ front end as well as minor fixes to the
>> Objective-C++ front end. Okay for mainline?
>>
>
> This is the third bootstrap failure for Objective-C++ in less than two
> weeks. I think it is either time to require Objective-C++ building or
> decide we should remove it.
>
So I must be missing something, because I've bootstrapped it several
times in the past couple weeks, and didn't see any breakage. Do I need
to be monitoring a particular list, or on irc, or bootstrapping every
day, or what?
Stan
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-26 20:59 ` Stan Shebs
@ 2008-03-27 7:49 ` Kaveh R. GHAZI
0 siblings, 0 replies; 42+ messages in thread
From: Kaveh R. GHAZI @ 2008-03-27 7:49 UTC (permalink / raw)
To: Stan Shebs; +Cc: Andrew Pinski, Doug Gregor, GCC Patches
On Wed, 26 Mar 2008, Stan Shebs wrote:
> Andrew Pinski wrote:
> > On Tue, Mar 25, 2008 at 10:03 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
> >
> >> My SFINAE patch to the C++ front end broke the Objective-C++ front
> >> end. This patch fixes the problem, which involves some renaming of
> >> routines in the C++ front end as well as minor fixes to the
> >> Objective-C++ front end. Okay for mainline?
> >>
> >
> > This is the third bootstrap failure for Objective-C++ in less than two
> > weeks. I think it is either time to require Objective-C++ building or
> > decide we should remove it.
> >
> So I must be missing something, because I've bootstrapped it several
> times in the past couple weeks, and didn't see any breakage. Do I need
> to be monitoring a particular list, or on irc, or bootstrapping every
> day, or what?
> Stan
IMHO, you shouldn't have to notice and/or clean up other people's breakage
after the fact. Since objc++ has you as a maintainer, IMHO we should turn
it on by default. Then instead of fixing breakage, you could work through
some of the objc++ bugzilla entries. :-)
http://tinyurl.com/36m46m
Here's one showing objc++, objc and libobjc:
http://tinyurl.com/3aanju
I think showing progress on this front would help establish that objc++ is
actively maintained and strengthen the argument to put it in the default
bootstrap list. Stan, are you able to contribute on this front?
Thanks,
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 14:12 ` Jakub Jelinek
@ 2008-03-28 21:28 ` Ralf Wildenhues
0 siblings, 0 replies; 42+ messages in thread
From: Ralf Wildenhues @ 2008-03-28 21:28 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Richard Guenther, Paolo Bonzini, Kaveh R. GHAZI, Mark Mitchell,
Joseph S. Myers, Steven Bosscher, GCC Patches, stanshebs,
pinskia
* Jakub Jelinek wrote on Fri, Mar 28, 2008 at 02:21:05PM CET:
> Not sure if libtool can be easily convinced to avoid building everything
> twice though.
Either pass -static/-shared in {,AM_,target_}GCJFLAGS or pass
--tag=disable-static/ --tag=disable-shared before the --tag=GCJ argument
(Automake 1.10 has {,AM_,target_}LIBTOOLFLAGS for this, with 1.9.6
something like
LIBTOOL = @LIBTOOL@ --tag=disable-static
should work. If you can decide globally per configure, then passing
--disable-static/--disable-shared to that is preferable, though.
Cheers,
Ralf
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 12:41 ` Richard Guenther
2008-03-28 12:45 ` Paolo Bonzini
@ 2008-03-28 14:12 ` Jakub Jelinek
2008-03-28 21:28 ` Ralf Wildenhues
1 sibling, 1 reply; 42+ messages in thread
From: Jakub Jelinek @ 2008-03-28 14:12 UTC (permalink / raw)
To: Richard Guenther
Cc: Paolo Bonzini, Kaveh R. GHAZI, Mark Mitchell, Joseph S. Myers,
Steven Bosscher, GCC Patches, stanshebs, pinskia
On Fri, Mar 28, 2008 at 11:58:03AM +0100, Richard Guenther wrote:
> If we can improve on the bootlenecks (dejagnu anyone? splitting
> insn-* and gen*, or building the generator files optimized during
> stage1?) it would maybe scale even better, which even I would
> appreciate.
Low-hanging fruit e.g. could be a configure switch to disable building
libgcj.a/libgcj-tools.a when libgcj.so/libgcj-tools.so is built.
As statically linking -lgcj/-lgcj-tools has very significant limitations
and issues, libgcj.a/libgcj-tools.a really should be used just
on targets which don't support shared libraries.
Not sure if libtool can be easily convinced to avoid building everything
twice though. But could very well save 30% or 40% of libjava build time.
Jakub
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 12:45 ` Paolo Bonzini
2008-03-28 13:30 ` Richard Guenther
@ 2008-03-28 13:45 ` H.J. Lu
1 sibling, 0 replies; 42+ messages in thread
From: H.J. Lu @ 2008-03-28 13:45 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Richard Guenther, Kaveh R. GHAZI, Mark Mitchell, Joseph S. Myers,
Steven Bosscher, GCC Patches, stanshebs, pinskia
On Fri, Mar 28, 2008 at 4:05 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
> > If we can improve on the bootlenecks (dejagnu anyone? splitting
> > insn-* and gen*, or building the generator files optimized during
> > stage1?)
>
> A while ago people were speaking of building stage1 optimized... can you
> test with STAGE1_CFLAGS="-O2 -g"?
>
I think it is a bad idea. It will make all stages of gcc very hard to debug.
H.J.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 13:30 ` Richard Guenther
2008-03-28 13:36 ` Andrew Pinski
@ 2008-03-28 13:44 ` Paolo Bonzini
1 sibling, 0 replies; 42+ messages in thread
From: Paolo Bonzini @ 2008-03-28 13:44 UTC (permalink / raw)
To: Richard Guenther
Cc: Kaveh R. GHAZI, Mark Mitchell, Joseph S. Myers, Steven Bosscher,
GCC Patches, stanshebs, pinskia
Richard Guenther wrote:
> On Fri, Mar 28, 2008 at 12:05 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>> > If we can improve on the bootlenecks (dejagnu anyone? splitting
>> > insn-* and gen*, or building the generator files optimized during
>> > stage1?)
>>
>> A while ago people were speaking of building stage1 optimized... can you
>> test with STAGE1_CFLAGS="-O2 -g"?
>
> 10473.53user 849.12system 34:57.32elapsed 539%CPU
>
> so not too much effect on the elapsed time (3 minutes).
IMO not worth the difference since, at least for development,
unoptimized stage1 means you don't have to recompile anything to debug
testsuite failures (just make stage1-start).
Paolo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 13:30 ` Richard Guenther
@ 2008-03-28 13:36 ` Andrew Pinski
2008-03-28 13:44 ` Paolo Bonzini
1 sibling, 0 replies; 42+ messages in thread
From: Andrew Pinski @ 2008-03-28 13:36 UTC (permalink / raw)
To: Richard Guenther
Cc: Paolo Bonzini, Kaveh R. GHAZI, Mark Mitchell, Joseph S. Myers,
Steven Bosscher, GCC Patches, stanshebs
Sent from my iPhone
On Mar 28, 2008, at 6:07, "Richard Guenther"
<richard.guenther@gmail.com> wrote:
> On Fri, Mar 28, 2008 at 12:05 PM, Paolo Bonzini <bonzini@gnu.org>
> wrote:
>>
>>> If we can improve on the bootlenecks (dejagnu anyone? splitting
>>> insn-* and gen*, or building the generator files optimized during
>>> stage1?)
>>
>> A while ago people were speaking of building stage1 optimized...
>> can you
>> test with STAGE1_CFLAGS="-O2 -g"?
>
> 10473.53user 849.12system 34:57.32elapsed 539%CPU
>
> so not too much effect on the elapsed time (3 minutes).
On the Cell the effect should be more for optimized stage1 because of
it handles loads after stores ( no load bypass).
-- Pinski
>
>
> Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 12:45 ` Paolo Bonzini
@ 2008-03-28 13:30 ` Richard Guenther
2008-03-28 13:36 ` Andrew Pinski
2008-03-28 13:44 ` Paolo Bonzini
2008-03-28 13:45 ` H.J. Lu
1 sibling, 2 replies; 42+ messages in thread
From: Richard Guenther @ 2008-03-28 13:30 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Kaveh R. GHAZI, Mark Mitchell, Joseph S. Myers, Steven Bosscher,
GCC Patches, stanshebs, pinskia
On Fri, Mar 28, 2008 at 12:05 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
> > If we can improve on the bootlenecks (dejagnu anyone? splitting
> > insn-* and gen*, or building the generator files optimized during
> > stage1?)
>
> A while ago people were speaking of building stage1 optimized... can you
> test with STAGE1_CFLAGS="-O2 -g"?
10473.53user 849.12system 34:57.32elapsed 539%CPU
so not too much effect on the elapsed time (3 minutes).
Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
@ 2008-03-28 13:08 FX Coudert
0 siblings, 0 replies; 42+ messages in thread
From: FX Coudert @ 2008-03-28 13:08 UTC (permalink / raw)
To: gcc patches
Hi,
I'm adding a little comment here:
> Inlining changes: Ada, C and C++ show more issues than Fortran.
More inlining opportunities are expected in Fortran when the multiple-
decls-per-function issue is fixed (I'm working on it for 4.4). I
don't know if it will make us on par with other languages.
Another comment: my feeling is that the Fortran front-end and
testsuite have exposed quite a few tree-optimization regressions
during 4.2 and 4.3 development. I'm wondering what are the times of
the different testsuites (C, C++, Fortran, Java); from my feeling (as
front-end maintainer, I don't often test C, rarely C++, and almost
never Java), C++ and Java are the major resource eaters.
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 12:41 ` Richard Guenther
@ 2008-03-28 12:45 ` Paolo Bonzini
2008-03-28 13:30 ` Richard Guenther
2008-03-28 13:45 ` H.J. Lu
2008-03-28 14:12 ` Jakub Jelinek
1 sibling, 2 replies; 42+ messages in thread
From: Paolo Bonzini @ 2008-03-28 12:45 UTC (permalink / raw)
To: Richard Guenther
Cc: Kaveh R. GHAZI, Mark Mitchell, Joseph S. Myers, Steven Bosscher,
GCC Patches, stanshebs, pinskia
> If we can improve on the bootlenecks (dejagnu anyone? splitting
> insn-* and gen*, or building the generator files optimized during
> stage1?)
A while ago people were speaking of building stage1 optimized... can you
test with STAGE1_CFLAGS="-O2 -g"?
Paolo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 8:04 ` Paolo Bonzini
@ 2008-03-28 12:41 ` Richard Guenther
2008-03-28 12:45 ` Paolo Bonzini
2008-03-28 14:12 ` Jakub Jelinek
0 siblings, 2 replies; 42+ messages in thread
From: Richard Guenther @ 2008-03-28 12:41 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Kaveh R. GHAZI, Mark Mitchell, Joseph S. Myers, Steven Bosscher,
GCC Patches, stanshebs, pinskia
On Fri, Mar 28, 2008 at 7:04 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
>
> > The baseline bootstrap --enable-languages=all and "make check" took
> > 3:40:59. The patched bootstrap enabling objc++ by default took 3:41:41,
> > so that's only *42 seconds* longer, or 0.3% more.
>
> When I'll remove target libiberty, I hope to save more than that.
> Throwing another piece of data in the thread. :-)
:)
So I thought I make some measurements myself. For "bad" patches
I do all-languages and multilib bootstrap and tests on x86_64-linux.
Bootstrap takes
11566.82user 835.02system 37:41.31elapsed 548%CPU
and multilib testing (RUNTESTFLAGS="--target_board=unix/\{,-m32\}")
10793.09user 3616.46system 59:11.61elapsed 405%CPU
on a moderately old 8 core machine (with enough memory to allow
-j10 bootstrap and -j8 test). As you can see we can not even fully
utilize all the CPUs (the big generator files are likely a problem and
bad parallelism in the libjava build is another), testing time is also
hugely dominated by all the forks() (see that system time number!).
Still this means my regular bootstrap and testing time is around
one hour (minus ada and minus the -m32 testing), which IMHO is
very reasonable. If you double that it would be the time it takes
on a single-CPU quad-core machine which I expect a free-time
volunteer GCC developer to have access to ;)
If we can improve on the bootlenecks (dejagnu anyone? splitting
insn-* and gen*, or building the generator files optimized during
stage1?) it would maybe scale even better, which even I would
appreciate.
Thanks,
Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 4:12 ` Kaveh R. GHAZI
@ 2008-03-28 8:04 ` Kaveh R. GHAZI
2008-03-28 8:04 ` Paolo Bonzini
0 siblings, 1 reply; 42+ messages in thread
From: Kaveh R. GHAZI @ 2008-03-28 8:04 UTC (permalink / raw)
To: Richard Guenther
Cc: Mark Mitchell, Joseph S. Myers, Steven Bosscher, GCC Patches,
bonzini, stanshebs, pinskia
On Thu, 27 Mar 2008, Kaveh R. GHAZI wrote:
> I'll do a bootstrap --enable-langauges=all and run the testsuite with and
> without the patch below to see what the actual timing difference is.
I got the results. Tests were on on an 8-way x86_64-unknown-linux-gnu
box. I ran the tests at the same time to minimize load related factors,
and the make's were all serial. No special RUNTESTFLAGS, so no extra
passes in the testsuite. Just one regular run through was done.
Since mainline cannot bootstrap objc++ because of the recent breakage, I
did the experiment on the 4.3 branch using --enable-checking=yes to
simulate what developers will see on mainline.
The baseline bootstrap --enable-languages=all and "make check" took
3:40:59. The patched bootstrap enabling objc++ by default took 3:41:41,
so that's only *42 seconds* longer, or 0.3% more.
So once objc++ is back to bootstrap-land, may I install my patch to
activate it by default on mainline?
Thanks,
--Kaveh
PS: For comparison I added in Ada and it took 4:14:58 which is almost 34
minutes longer than the baseline, or 15.4% more. I don't have an opinion
about whether it should be on by default or not. Just throwing the
statistic out there.
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 8:04 ` Kaveh R. GHAZI
@ 2008-03-28 8:04 ` Paolo Bonzini
2008-03-28 12:41 ` Richard Guenther
0 siblings, 1 reply; 42+ messages in thread
From: Paolo Bonzini @ 2008-03-28 8:04 UTC (permalink / raw)
To: Kaveh R. GHAZI
Cc: Richard Guenther, Mark Mitchell, Joseph S. Myers,
Steven Bosscher, GCC Patches, stanshebs, pinskia
> The baseline bootstrap --enable-languages=all and "make check" took
> 3:40:59. The patched bootstrap enabling objc++ by default took 3:41:41,
> so that's only *42 seconds* longer, or 0.3% more.
When I'll remove target libiberty, I hope to save more than that.
Throwing another piece of data in the thread. :-)
Paolo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 22:57 ` Richard Guenther
@ 2008-03-28 4:12 ` Kaveh R. GHAZI
2008-03-28 8:04 ` Kaveh R. GHAZI
0 siblings, 1 reply; 42+ messages in thread
From: Kaveh R. GHAZI @ 2008-03-28 4:12 UTC (permalink / raw)
To: Richard Guenther
Cc: Mark Mitchell, Joseph S. Myers, Steven Bosscher, GCC Patches,
bonzini, stanshebs, pinskia
On Thu, 27 Mar 2008, Richard Guenther wrote:
> On Thu, Mar 27, 2008 at 11:34 PM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> > On Thu, 27 Mar 2008, Mark Mitchell wrote:
> >
> > > I think that having all GCC developers build/test all languages all the
> > > time is overkill. I'm all for testing, and I certainly think that
> > > people should make an effort to test languages that it seems like their
> > > paches might be likely to impact (e.g., major C++ changes are likely to
> > > affect Objectie-C++), but adding hours to everyones build/test cycles
> > > seems like a bad tradeoff. Instead, people who break Ada,
> > > Objective-C++, etc., should be responsible to requests to fix the
> > > breakage, and willing to revert their patches if no fix is immediately
> > > found.
> >
> >
> > I think a middle ground could be that we enable building objc++ by
> > default, but not run its testsuite unless it is specifically enabled.
> >
> > This would catch the type of bootstrap errors we've seen several times
> > recently without causing significant extra time in the overall build time.
> > I think there's like three extra .o files necessary to link cc1objcplus,
> > the remainder are reused modules from the C and C++ frontends. It
> > certainly wouldn't be "adding hours" to everyone's test cycle. And
> > there's no objc++ specific target library AFAICT, so it's really cheap to
> > activate.
> >
> > Does this sound like a balanced and fair compromise?
>
> Even the 130 tests of the objc++ testsuite won't hurt anyone. Building
> and testing libjava is what is most of the pain ;)
> Richard.
I guess you're right :-) we might as well throw in the few tests that it
has. After all, there are thousands of tests in the other directories.
I double running the obj-c++ tests will make a dent.
I'll do a bootstrap --enable-langauges=all and run the testsuite with and
without the patch below to see what the actual timing difference is.
Assuming it's "really small" I hope no one objects to this patch?
--Kaveh
2008-03-28 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* config-lang.in (build_by_default): Build obj-c++ by default.
diff -rup orig/egcc-SVN20080327/gcc/objcp/config-lang.in egcc-SVN20080327/gcc/objcp/config-lang.in
--- orig/egcc-SVN20080327/gcc/objcp/config-lang.in 2008-03-14 00:34:31.000000000 +0100
+++ egcc-SVN20080327/gcc/objcp/config-lang.in 2008-03-28 00:58:54.000000000 +0100
@@ -28,9 +28,6 @@ language="obj-c++"
compilers="cc1objplus\$(exeext)"
-# Per GCC Steering Committee.
-build_by_default="no"
-
# By building the Objective-C and C++ front-ends, we will get
# the object files we need, along with the libraries (libstdc++,
# libobjc).
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 2:41 ` Mark Mitchell
@ 2008-03-28 3:17 ` Andrew Pinski
0 siblings, 0 replies; 42+ messages in thread
From: Andrew Pinski @ 2008-03-28 3:17 UTC (permalink / raw)
To: Mark Mitchell
Cc: Richard Guenther, Kaveh R. GHAZI, Joseph S. Myers,
Steven Bosscher, GCC Patches, bonzini, stanshebs
On Thu, Mar 27, 2008 at 4:35 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> This is useful data. It would seem to suggest that C/C++ testing would
> have caught most of your problems, with the exception of the
> complex-number testing, where you found Fortran testing to be most
> effective.
For me, yes but this was just from memory and is not exactly the full
truth. As I was touching in most cases the front-ends, I needed to
test them anyways so just testing C/C++ was not the correct thing to
do really. Also sometimes you never know which front-end's testsuite
will produce a problem with the patch you are working on; you can
estimate but this is never a good idea. Also why are we complaining
about testing times?
I rather we have more testing than less when it comes to testing the
compiler. Everytime I see a bug, I always try to add a testcase. But
sometimes bugs show up only because the IR that is produced by one
specific front-end. How do you know if you change that code, it will
not break the corner case you just found? I am against not requiring
testing of the Fortran or Ada or Objective-C or Java front-ends for
middle end or target changes. They found useful bugs and in some
cases you can add a C testcase for the same issue (I have tried doing
that in some cases). Yes running only the C testsuite simplifies
testing but that should only be done during the development of the
patch and you should do a full bootstrap and test before submitting.
I usually start a full bootstrap/test before I go bed or leave for the
day so I have the results in the morning. Most of the time I don't
find issues but when I do, I go back and look at them and look at why
the C testsuite was not testing it. I think this comes down to how
people develop, and we should not force a development mechanism on
them except when they are ready to submit the patch and only then we
can say how did you test it.
I have a feeling that this thread has gone way off topic and should
start a new one about testing before submitting.
-- Pinski
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-28 0:41 ` Andrew Pinski
@ 2008-03-28 2:41 ` Mark Mitchell
2008-03-28 3:17 ` Andrew Pinski
0 siblings, 1 reply; 42+ messages in thread
From: Mark Mitchell @ 2008-03-28 2:41 UTC (permalink / raw)
To: Andrew Pinski
Cc: Richard Guenther, Kaveh R. GHAZI, Joseph S. Myers,
Steven Bosscher, GCC Patches, bonzini, stanshebs
Andrew Pinski wrote:
> On Thu, Mar 27, 2008 at 3:56 PM, Mark Mitchell <mark@codesourcery.com> wrote:
>> These aren't rhetorical questions; I have no idea. I'm interested in
>> what actual experience is like here. My guess would be that changes to
>> the build machinery are quite likely to break various languages, but
>> that changes to (say) the register allocator are unlikely to work
>> reliably in C/C++, but not in Fortran/Java. And, that, in fact, Ada is
>> the language other than C/C++ most likely to show up problems.
>
> Examples of where I have had issues:
This is useful data. It would seem to suggest that C/C++ testing would
have caught most of your problems, with the exception of the
complex-number testing, where you found Fortran testing to be most
effective.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 23:30 ` Mark Mitchell
2008-03-28 0:41 ` Andrew Pinski
@ 2008-03-28 2:12 ` Richard Guenther
1 sibling, 0 replies; 42+ messages in thread
From: Richard Guenther @ 2008-03-28 2:12 UTC (permalink / raw)
To: Mark Mitchell
Cc: Kaveh R. GHAZI, Joseph S. Myers, Steven Bosscher, GCC Patches,
bonzini, stanshebs, pinskia
On Thu, Mar 27, 2008 at 11:56 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Richard Guenther wrote:
>
> > Obj-C++ is certainly not a problem. Java and Fortran are already part of all
> > build/test cycles, libjava being a huge memory eater.
>
> Is that a good thing? I've done little middle-end work, so I don't have
> much experience with this. How often does a change to the optimizers
> pass all of the C/C++ testsuites, but fail in the Java or Fortran
> testsuites?
>
> These aren't rhetorical questions; I have no idea. I'm interested in
> what actual experience is like here. My guess would be that changes to
> the build machinery are quite likely to break various languages, but
> that changes to (say) the register allocator are unlikely to work
> reliably in C/C++, but not in Fortran/Java. And, that, in fact, Ada is
> the language other than C/C++ most likely to show up problems.
Sadly it happens often enough that only libjava or java testing is affected
by a patch. Likewise Fortran is often special in the kinds of IL produced.
Ada testing doesn't show failures most of the time, but it excercises parts
of the middle-end no other frontend does.
So they are all useful in that coverage of the C and C++ testsuite isn't
good enough to catch even obvious problems sometimes.
Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 23:30 ` Mark Mitchell
@ 2008-03-28 0:41 ` Andrew Pinski
2008-03-28 2:41 ` Mark Mitchell
2008-03-28 2:12 ` Richard Guenther
1 sibling, 1 reply; 42+ messages in thread
From: Andrew Pinski @ 2008-03-28 0:41 UTC (permalink / raw)
To: Mark Mitchell
Cc: Richard Guenther, Kaveh R. GHAZI, Joseph S. Myers,
Steven Bosscher, GCC Patches, bonzini, stanshebs
On Thu, Mar 27, 2008 at 3:56 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> These aren't rhetorical questions; I have no idea. I'm interested in
> what actual experience is like here. My guess would be that changes to
> the build machinery are quite likely to break various languages, but
> that changes to (say) the register allocator are unlikely to work
> reliably in C/C++, but not in Fortran/Java. And, that, in fact, Ada is
> the language other than C/C++ most likely to show up problems.
Examples of where I have had issues:
Changing complex types, Fortran, Ada, and C++ show up more issues than
C testing, more in Fortran than anywhere else really.
Inlining changes: Ada, C and C++ show more issues than Fortran.
For Pointer Plus, C++ was the hardest one to convert, it was full of
pointer arithmetic all the place.
For PHI_NODE memory reduction, C++ and Fortran showed the issue which
did not show up in C.
Vector changes, not tested that well at all even with the auto
vectorizer testsuite (tested locally on most of the internal sources
here at Sony).
Thanks,
Andrew Pinski
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 23:10 ` Richard Guenther
2008-03-27 23:17 ` Richard Guenther
2008-03-27 23:26 ` Andrew Pinski
@ 2008-03-27 23:30 ` Mark Mitchell
2008-03-28 0:41 ` Andrew Pinski
2008-03-28 2:12 ` Richard Guenther
2 siblings, 2 replies; 42+ messages in thread
From: Mark Mitchell @ 2008-03-27 23:30 UTC (permalink / raw)
To: Richard Guenther
Cc: Kaveh R. GHAZI, Joseph S. Myers, Steven Bosscher, GCC Patches,
bonzini, stanshebs, pinskia
Richard Guenther wrote:
> Obj-C++ is certainly not a problem. Java and Fortran are already part of all
> build/test cycles, libjava being a huge memory eater.
Is that a good thing? I've done little middle-end work, so I don't have
much experience with this. How often does a change to the optimizers
pass all of the C/C++ testsuites, but fail in the Java or Fortran
testsuites?
These aren't rhetorical questions; I have no idea. I'm interested in
what actual experience is like here. My guess would be that changes to
the build machinery are quite likely to break various languages, but
that changes to (say) the register allocator are unlikely to work
reliably in C/C++, but not in Fortran/Java. And, that, in fact, Ada is
the language other than C/C++ most likely to show up problems.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 23:10 ` Richard Guenther
2008-03-27 23:17 ` Richard Guenther
@ 2008-03-27 23:26 ` Andrew Pinski
2008-03-27 23:30 ` Mark Mitchell
2 siblings, 0 replies; 42+ messages in thread
From: Andrew Pinski @ 2008-03-27 23:26 UTC (permalink / raw)
To: Richard Guenther
Cc: Mark Mitchell, Kaveh R. GHAZI, Joseph S. Myers, Steven Bosscher,
GCC Patches, bonzini, stanshebs
On Thu, Mar 27, 2008 at 3:49 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> Obj-C++ is certainly not a problem. Java and Fortran are already part of all
> build/test cycles, libjava being a huge memory eater.
libstdc++ testing is also a huge memory eater. I ran into swapping
while it is running all the time.
-- Pinski
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 23:10 ` Richard Guenther
@ 2008-03-27 23:17 ` Richard Guenther
2008-03-27 23:26 ` Andrew Pinski
2008-03-27 23:30 ` Mark Mitchell
2 siblings, 0 replies; 42+ messages in thread
From: Richard Guenther @ 2008-03-27 23:17 UTC (permalink / raw)
To: Mark Mitchell
Cc: Kaveh R. GHAZI, Joseph S. Myers, Steven Bosscher, GCC Patches,
bonzini, stanshebs, pinskia
On Thu, Mar 27, 2008 at 11:42 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Kaveh R. GHAZI wrote:
>
> > I think a middle ground could be that we enable building objc++ by
> > default, but not run its testsuite unless it is specifically enabled.
>
> I'm mildly opposed, but not so much so that I would make much of an
> argument for it.
>
>
> > It certainly wouldn't be "adding hours" to everyone's test cycle.
>
> I agree. That comment was meant to refer to the possibility of adding
> all of Ada, Java, Fortran, etc. to all build/test cycles. I see
> Objective-C++ as a pretty minor issue; neither the costs nor benefits
> are terribly great. Some of the other languages are more widely used,
> but also more expensive to build/test.
Obj-C++ is certainly not a problem. Java and Fortran are already part of all
build/test cycles, libjava being a huge memory eater. Ada isn't too bad and
I tend to include it for middle-end patches (after all I can remember "ada",
but most of the time misspell obj-c++(?) as objcp or objc++(?)).
Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 22:58 ` Mark Mitchell
@ 2008-03-27 23:10 ` Richard Guenther
2008-03-27 23:17 ` Richard Guenther
` (2 more replies)
0 siblings, 3 replies; 42+ messages in thread
From: Richard Guenther @ 2008-03-27 23:10 UTC (permalink / raw)
To: Mark Mitchell
Cc: Kaveh R. GHAZI, Joseph S. Myers, Steven Bosscher, GCC Patches,
bonzini, stanshebs, pinskia
On Thu, Mar 27, 2008 at 11:42 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Kaveh R. GHAZI wrote:
>
> > I think a middle ground could be that we enable building objc++ by
> > default, but not run its testsuite unless it is specifically enabled.
>
> I'm mildly opposed, but not so much so that I would make much of an
> argument for it.
>
>
> > It certainly wouldn't be "adding hours" to everyone's test cycle.
>
> I agree. That comment was meant to refer to the possibility of adding
> all of Ada, Java, Fortran, etc. to all build/test cycles. I see
> Objective-C++ as a pretty minor issue; neither the costs nor benefits
> are terribly great. Some of the other languages are more widely used,
> but also more expensive to build/test.
Obj-C++ is certainly not a problem. Java and Fortran are already part of all
build/test cycles, libjava being a huge memory eater. Ada isn't too bad and
I tend to include it for middle-end patches (after all I can remember "ada",
but most of the time misspell obj-c++(?) as objcp or objc++(?)).
Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 22:55 ` Kaveh R. GHAZI
2008-03-27 22:56 ` Andrew Pinski
2008-03-27 22:57 ` Richard Guenther
@ 2008-03-27 22:58 ` Mark Mitchell
2008-03-27 23:10 ` Richard Guenther
2 siblings, 1 reply; 42+ messages in thread
From: Mark Mitchell @ 2008-03-27 22:58 UTC (permalink / raw)
To: Kaveh R. GHAZI
Cc: Joseph S. Myers, Steven Bosscher, GCC Patches, bonzini,
stanshebs, pinskia
Kaveh R. GHAZI wrote:
> I think a middle ground could be that we enable building objc++ by
> default, but not run its testsuite unless it is specifically enabled.
I'm mildly opposed, but not so much so that I would make much of an
argument for it.
> It certainly wouldn't be "adding hours" to everyone's test cycle.
I agree. That comment was meant to refer to the possibility of adding
all of Ada, Java, Fortran, etc. to all build/test cycles. I see
Objective-C++ as a pretty minor issue; neither the costs nor benefits
are terribly great. Some of the other languages are more widely used,
but also more expensive to build/test.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 22:55 ` Kaveh R. GHAZI
2008-03-27 22:56 ` Andrew Pinski
@ 2008-03-27 22:57 ` Richard Guenther
2008-03-28 4:12 ` Kaveh R. GHAZI
2008-03-27 22:58 ` Mark Mitchell
2 siblings, 1 reply; 42+ messages in thread
From: Richard Guenther @ 2008-03-27 22:57 UTC (permalink / raw)
To: Kaveh R. GHAZI
Cc: Mark Mitchell, Joseph S. Myers, Steven Bosscher, GCC Patches,
bonzini, stanshebs, pinskia
On Thu, Mar 27, 2008 at 11:34 PM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> On Thu, 27 Mar 2008, Mark Mitchell wrote:
>
> > I think that having all GCC developers build/test all languages all the
> > time is overkill. I'm all for testing, and I certainly think that
> > people should make an effort to test languages that it seems like their
> > paches might be likely to impact (e.g., major C++ changes are likely to
> > affect Objectie-C++), but adding hours to everyones build/test cycles
> > seems like a bad tradeoff. Instead, people who break Ada,
> > Objective-C++, etc., should be responsible to requests to fix the
> > breakage, and willing to revert their patches if no fix is immediately
> > found.
>
>
> I think a middle ground could be that we enable building objc++ by
> default, but not run its testsuite unless it is specifically enabled.
>
> This would catch the type of bootstrap errors we've seen several times
> recently without causing significant extra time in the overall build time.
> I think there's like three extra .o files necessary to link cc1objcplus,
> the remainder are reused modules from the C and C++ frontends. It
> certainly wouldn't be "adding hours" to everyone's test cycle. And
> there's no objc++ specific target library AFAICT, so it's really cheap to
> activate.
>
> Does this sound like a balanced and fair compromise?
Even the 130 tests of the objc++ testsuite won't hurt anyone. Building
and testing libjava is what is most of the pain ;)
Richard.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 22:55 ` Kaveh R. GHAZI
@ 2008-03-27 22:56 ` Andrew Pinski
2008-03-27 22:57 ` Richard Guenther
2008-03-27 22:58 ` Mark Mitchell
2 siblings, 0 replies; 42+ messages in thread
From: Andrew Pinski @ 2008-03-27 22:56 UTC (permalink / raw)
To: Kaveh R. GHAZI
Cc: Mark Mitchell, Joseph S. Myers, Steven Bosscher, GCC Patches,
bonzini, stanshebs
On Thu, Mar 27, 2008 at 3:34 PM, Kaveh R. GHAZI
<ghazi@caip.rutgers.edu> wrote:
> I think a middle ground could be that we enable building objc++ by
> default, but not run its testsuite unless it is specifically enabled.
The testsuite for Objective-C++ is so small, it is not even a blimp in
my testing time. So I don't think this is a good middle ground.
-- Pinski
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 18:13 ` Mark Mitchell
@ 2008-03-27 22:55 ` Kaveh R. GHAZI
2008-03-27 22:56 ` Andrew Pinski
` (2 more replies)
0 siblings, 3 replies; 42+ messages in thread
From: Kaveh R. GHAZI @ 2008-03-27 22:55 UTC (permalink / raw)
To: Mark Mitchell
Cc: Joseph S. Myers, Steven Bosscher, GCC Patches, bonzini,
stanshebs, pinskia
On Thu, 27 Mar 2008, Mark Mitchell wrote:
> I think that having all GCC developers build/test all languages all the
> time is overkill. I'm all for testing, and I certainly think that
> people should make an effort to test languages that it seems like their
> paches might be likely to impact (e.g., major C++ changes are likely to
> affect Objectie-C++), but adding hours to everyones build/test cycles
> seems like a bad tradeoff. Instead, people who break Ada,
> Objective-C++, etc., should be responsible to requests to fix the
> breakage, and willing to revert their patches if no fix is immediately
> found.
I think a middle ground could be that we enable building objc++ by
default, but not run its testsuite unless it is specifically enabled.
This would catch the type of bootstrap errors we've seen several times
recently without causing significant extra time in the overall build time.
I think there's like three extra .o files necessary to link cc1objcplus,
the remainder are reused modules from the C and C++ frontends. It
certainly wouldn't be "adding hours" to everyone's test cycle. And
there's no objc++ specific target library AFAICT, so it's really cheap to
activate.
Does this sound like a balanced and fair compromise?
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 16:19 ` Joseph S. Myers
2008-03-27 18:13 ` Mark Mitchell
@ 2008-03-27 19:21 ` Paolo Bonzini
1 sibling, 0 replies; 42+ messages in thread
From: Paolo Bonzini @ 2008-03-27 19:21 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Steven Bosscher, GCC Patches
> It was disabled when tree-ssa was merged, because it wasn't ready for
> tree-ssa at that time. I'm not aware of any policy decision to disable
> it, just what should have been temporary disabling until a problem was
> fixed; I think we should enable it by default again, while still allowing
> people not to test patches with Ada since they may not have bootstrap Ada
> compilers.
Not to mention, that the old issue that required you to "make
gnatlib_and_tools" before "make install" (otherwise you'd screw up an
existing GNAT install) is gone.
Paolo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 16:19 ` Joseph S. Myers
@ 2008-03-27 18:13 ` Mark Mitchell
2008-03-27 22:55 ` Kaveh R. GHAZI
2008-03-27 19:21 ` Paolo Bonzini
1 sibling, 1 reply; 42+ messages in thread
From: Mark Mitchell @ 2008-03-27 18:13 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Steven Bosscher, GCC Patches
Joseph S. Myers wrote:
> It was disabled when tree-ssa was merged, because it wasn't ready for
> tree-ssa at that time. I'm not aware of any policy decision to disable
> it, just what should have been temporary disabling until a problem was
> fixed; I think we should enable it by default again, while still allowing
> people not to test patches with Ada since they may not have bootstrap Ada
> compilers.
I think that having all GCC developers build/test all languages all the
time is overkill. I'm all for testing, and I certainly think that
people should make an effort to test languages that it seems like their
paches might be likely to impact (e.g., major C++ changes are likely to
affect Objectie-C++), but adding hours to everyones build/test cycles
seems like a bad tradeoff. Instead, people who break Ada,
Objective-C++, etc., should be responsible to requests to fix the
breakage, and willing to revert their patches if no fix is immediately
found.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 10:12 Steven Bosscher
2008-03-27 10:22 ` Paolo Bonzini
@ 2008-03-27 16:19 ` Joseph S. Myers
2008-03-27 18:13 ` Mark Mitchell
2008-03-27 19:21 ` Paolo Bonzini
1 sibling, 2 replies; 42+ messages in thread
From: Joseph S. Myers @ 2008-03-27 16:19 UTC (permalink / raw)
To: Steven Bosscher; +Cc: GCC Patches
On Thu, 27 Mar 2008, Steven Bosscher wrote:
> Is "actively maintained" an argument to enable a language by default?
> Ada is actively maintained, and the Ada language probably has far more
> users than ObjC++ does. But GNAT is not enabled by default. It is good
It was disabled when tree-ssa was merged, because it wasn't ready for
tree-ssa at that time. I'm not aware of any policy decision to disable
it, just what should have been temporary disabling until a problem was
fixed; I think we should enable it by default again, while still allowing
people not to test patches with Ada since they may not have bootstrap Ada
compilers.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 10:22 ` Paolo Bonzini
@ 2008-03-27 10:23 ` Paolo Bonzini
0 siblings, 0 replies; 42+ messages in thread
From: Paolo Bonzini @ 2008-03-27 10:23 UTC (permalink / raw)
To: gcc-patches
Cc: Kaveh R. GHAZI, Stan Shebs, Andrew Pinski, Doug Gregor, GCC Patches
> The SC tried to avoid exactly the situation GCC is in now
> (http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html): "Furthermore,
> nobody will be required to test Objective-C++ as part of the check-in
> cycle, and people who cause defects in Objective-C++ will not
> necessarily be required to fix them, although good manners dictates
> that people will help clean up their own mess where practical."
As I interpret it, if the patches are very invasive (such as the once
that changed tree nodes internal to the parsers, to be separate C
structs) no one should be forced to rework Objective-C++. But in most
cases, spending half an hour on a fix is just "good manners".
Paolo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
2008-03-27 10:12 Steven Bosscher
@ 2008-03-27 10:22 ` Paolo Bonzini
2008-03-27 10:23 ` Paolo Bonzini
2008-03-27 16:19 ` Joseph S. Myers
1 sibling, 1 reply; 42+ messages in thread
From: Paolo Bonzini @ 2008-03-27 10:22 UTC (permalink / raw)
To: Steven Bosscher
Cc: Kaveh R. GHAZI, Stan Shebs, Andrew Pinski, Doug Gregor, GCC Patches
> The SC tried to avoid exactly the situation GCC is in now
> (http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html): "Furthermore,
> nobody will be required to test Objective-C++ as part of the check-in
> cycle, and people who cause defects in Objective-C++ will not
> necessarily be required to fix them, although good manners dictates
> that people will help clean up their own mess where practical."
As I interpret it, if the patches are very invasive (such as the once
that changed tree nodes internal to the parsers, to be separate C
structs) no one should be forced to rework Objective-C++. But in most
cases, spending half an hour on a fix is just "good manners".
Paolo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
@ 2008-03-27 10:12 Steven Bosscher
2008-03-27 10:22 ` Paolo Bonzini
2008-03-27 16:19 ` Joseph S. Myers
0 siblings, 2 replies; 42+ messages in thread
From: Steven Bosscher @ 2008-03-27 10:12 UTC (permalink / raw)
To: Kaveh R. GHAZI; +Cc: Stan Shebs, Andrew Pinski, Doug Gregor, GCC Patches
xf. http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01640.html
On Wed, 26 Mar 2008, Kaveh R. GHAZI wrote:
> I think showing progress on this front would help establish that objc++ is
> actively maintained and strengthen the argument to put it in the default
> bootstrap list. Stan, are you able to contribute on this front?
Is "actively maintained" an argument to enable a language by default?
Ada is actively maintained, and the Ada language probably has far more
users than ObjC++ does. But GNAT is not enabled by default. It is good
that Stan has stood up to maintain it, but the real maintenance hassle
is not on Stan but on everyone who wants to change the C, ObjC, or C++
front ends. If I look at the ObjC++ front end, I see a
dump-and-disappear action by the front end contributors, burdening the
community with the maintenance for it.
So who is going to benefit from enabling ObjC++ by default? Certainly
not any of the groups and individuals who actively contribute to GCC
development. Maybe the odd-one-out Apple user who builds GCC from
source, but that wouldn't justify enabling the front end for everyone
by default, IMHO.
The SC tried to avoid exactly the situation GCC is in now
(http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html): "Furthermore,
nobody will be required to test Objective-C++ as part of the check-in
cycle, and people who cause defects in Objective-C++ will not
necessarily be required to fix them, although good manners dictates
that people will help clean up their own mess where practical."
Gr.
Steven
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [C++/Obj-C++ PATCH] Fix Objective-C++ breakage
@ 2008-03-26 20:58 Dominique Dhumieres
0 siblings, 0 replies; 42+ messages in thread
From: Dominique Dhumieres @ 2008-03-26 20:58 UTC (permalink / raw)
To: gcc-patches
I have opened pr35704 this morning, though my summary was not explicit
enough. The patch fixed the bootstrap issue for me.
Dominique
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2008-03-28 19:52 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-25 17:58 [C++/Obj-C++ PATCH] Fix Objective-C++ breakage Doug Gregor
2008-03-26 6:46 ` Andrew Pinski
2008-03-26 13:07 ` Richard Guenther
2008-03-26 13:17 ` NightStrike
2008-03-26 13:41 ` Richard Guenther
2008-03-26 18:21 ` Doug Gregor
2008-03-26 19:57 ` Kaveh R. GHAZI
2008-03-26 15:12 ` Tom Tromey
2008-03-26 20:59 ` Stan Shebs
2008-03-27 7:49 ` Kaveh R. GHAZI
2008-03-26 20:44 ` Stan Shebs
2008-03-26 20:58 Dominique Dhumieres
2008-03-27 10:12 Steven Bosscher
2008-03-27 10:22 ` Paolo Bonzini
2008-03-27 10:23 ` Paolo Bonzini
2008-03-27 16:19 ` Joseph S. Myers
2008-03-27 18:13 ` Mark Mitchell
2008-03-27 22:55 ` Kaveh R. GHAZI
2008-03-27 22:56 ` Andrew Pinski
2008-03-27 22:57 ` Richard Guenther
2008-03-28 4:12 ` Kaveh R. GHAZI
2008-03-28 8:04 ` Kaveh R. GHAZI
2008-03-28 8:04 ` Paolo Bonzini
2008-03-28 12:41 ` Richard Guenther
2008-03-28 12:45 ` Paolo Bonzini
2008-03-28 13:30 ` Richard Guenther
2008-03-28 13:36 ` Andrew Pinski
2008-03-28 13:44 ` Paolo Bonzini
2008-03-28 13:45 ` H.J. Lu
2008-03-28 14:12 ` Jakub Jelinek
2008-03-28 21:28 ` Ralf Wildenhues
2008-03-27 22:58 ` Mark Mitchell
2008-03-27 23:10 ` Richard Guenther
2008-03-27 23:17 ` Richard Guenther
2008-03-27 23:26 ` Andrew Pinski
2008-03-27 23:30 ` Mark Mitchell
2008-03-28 0:41 ` Andrew Pinski
2008-03-28 2:41 ` Mark Mitchell
2008-03-28 3:17 ` Andrew Pinski
2008-03-28 2:12 ` Richard Guenther
2008-03-27 19:21 ` Paolo Bonzini
2008-03-28 13:08 FX Coudert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).