* [PATCH PING] c++-specific bits of tree-slimming patches @ 2011-03-24 13:15 Nathan Froyd 2011-04-05 12:10 ` Nathan Froyd 2011-04-08 17:50 ` Jason Merrill 0 siblings, 2 replies; 17+ messages in thread From: Nathan Froyd @ 2011-03-24 13:15 UTC (permalink / raw) To: gcc-patches; +Cc: jason The C++-specific bits of these patches: [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html [PATCH 07/18] generalize build_case_label to the rest of the compiler http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html [PATCH 08/18] convert cp *FOR_STMTs to use private scope fields http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00553.html [PATCH 09/18] convert cp IF_STMTs to use private scope fields http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00562.html [PATCH 10/18] convert cp SWITCH_STMTs to use private scope fields http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00552.html [PATCH 11/18] mark EXPR_PACK_EXPANSION as typed only http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00563.html [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00566.html are still pending review. -Nathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-03-24 13:15 [PATCH PING] c++-specific bits of tree-slimming patches Nathan Froyd @ 2011-04-05 12:10 ` Nathan Froyd 2011-04-08 17:50 ` Jason Merrill 1 sibling, 0 replies; 17+ messages in thread From: Nathan Froyd @ 2011-04-05 12:10 UTC (permalink / raw) To: gcc-patches; +Cc: jason On Thu, Mar 24, 2011 at 06:15:18AM -0700, Nathan Froyd wrote: > The C++-specific bits of these patches: > > [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html > > [PATCH 07/18] generalize build_case_label to the rest of the compiler > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html > > [PATCH 08/18] convert cp *FOR_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00553.html > > [PATCH 09/18] convert cp IF_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00562.html > > [PATCH 10/18] convert cp SWITCH_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00552.html > > [PATCH 11/18] mark EXPR_PACK_EXPANSION as typed only > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00563.html > > [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00566.html > > are still pending review. Ping^2. Alternatively, could we have a GWP or similar rule on Tom's suggestion: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00620.html that patches propagating middle-end changes to front-ends are obvious/preapproved, perhaps after a 24-48 hour waiting period for comments? That would cover 02 and 07 above (possibly 17 as well); 02 is blocking some of the already-approved middle-end changes later in the series. I think Tom's suggestion makes a lot of sense, but I'm not exactly a disinterested observer... :) -Nathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-03-24 13:15 [PATCH PING] c++-specific bits of tree-slimming patches Nathan Froyd 2011-04-05 12:10 ` Nathan Froyd @ 2011-04-08 17:50 ` Jason Merrill 2011-04-14 11:30 ` Nathan Froyd 2011-04-22 2:49 ` Nathan Froyd 1 sibling, 2 replies; 17+ messages in thread From: Jason Merrill @ 2011-04-08 17:50 UTC (permalink / raw) To: Nathan Froyd; +Cc: gcc-patches On 03/24/2011 09:15 AM, Nathan Froyd wrote: > The C++-specific bits of these patches: > > [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html OK. > [PATCH 07/18] generalize build_case_label to the rest of the compiler > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html > + tree t = make_node (CASE_LABEL_EXPR); > + > + TREE_TYPE (t) = void_type_node; > + SET_EXPR_LOCATION (t, input_location); As jsm and richi said, using input_location like this is a regression. Can we use DECL_SOURCE_LOCATION (label_decl) instead? > [PATCH 08/18] convert cp *FOR_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00553.html > [PATCH 09/18] convert cp IF_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00562.html > [PATCH 10/18] convert cp SWITCH_STMTs to use private scope fields > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00552.html OK. > [PATCH 11/18] mark EXPR_PACK_EXPANSION as typed only > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00563.html It looks like you need to add EXPR_PACK_EXPANSION cases to value_dependent_expression_p and cp_tree_equal. Maybe split out the code from write_expression that overrides TREE_OPERAND_LENGTH in some cases and use that new function instead of TREE_OPERAND_LENGTH in these places. > [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00566.html OK. > Alternatively, could we have a GWP or similar rule on Tom's suggestion: > > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00620.html > > that patches propagating middle-end changes to front-ends are > obvious/preapproved, perhaps after a 24-48 hour waiting period for > comments? That would cover 02 and 07 above (possibly 17 as well); 02 is > blocking some of the already-approved middle-end changes later in the > series. That makes sense to me, but I'd give it a week. Jason ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-08 17:50 ` Jason Merrill @ 2011-04-14 11:30 ` Nathan Froyd 2011-04-14 11:32 ` Richard Guenther 2011-04-21 16:33 ` Joseph S. Myers 2011-04-22 2:49 ` Nathan Froyd 1 sibling, 2 replies; 17+ messages in thread From: Nathan Froyd @ 2011-04-14 11:30 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches, joseph, rguenther On Fri, Apr 08, 2011 at 01:50:24PM -0400, Jason Merrill wrote: > On 03/24/2011 09:15 AM, Nathan Froyd wrote: >> + tree t = make_node (CASE_LABEL_EXPR); >> + >> + TREE_TYPE (t) = void_type_node; >> + SET_EXPR_LOCATION (t, input_location); > > As jsm and richi said, using input_location like this is a regression. > Can we use DECL_SOURCE_LOCATION (label_decl) instead? Sure. Joseph, Richi, are you happy with that change? It would fix the C/C++ regression, as c_add_case_label does: /* Create the LABEL_DECL itself. */ label = create_artificial_label (loc); ... /* Add a CASE_LABEL to the statement-tree. */ case_label = add_stmt (build_case_label (loc, low_value, high_value, label)); so the DECL_SOURCE_LOCATION would be the same as the location_t we were passing in anyway. For the other languages, I think it would be neutral or an improvement (they all use input_location or UNKNOWN_LOCATION for the CASE_LABEL anyway). >> [PATCH 11/18] mark EXPR_PACK_EXPANSION as typed only >> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00563.html > > It looks like you need to add EXPR_PACK_EXPANSION cases to > value_dependent_expression_p and cp_tree_equal. Maybe split out the > code from write_expression that overrides TREE_OPERAND_LENGTH in some > cases and use that new function instead of TREE_OPERAND_LENGTH in these > places. Thanks for catching this, will do. -Nathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-14 11:30 ` Nathan Froyd @ 2011-04-14 11:32 ` Richard Guenther 2011-04-21 16:33 ` Joseph S. Myers 1 sibling, 0 replies; 17+ messages in thread From: Richard Guenther @ 2011-04-14 11:32 UTC (permalink / raw) To: Nathan Froyd; +Cc: Jason Merrill, gcc-patches, joseph On Thu, 14 Apr 2011, Nathan Froyd wrote: > On Fri, Apr 08, 2011 at 01:50:24PM -0400, Jason Merrill wrote: > > On 03/24/2011 09:15 AM, Nathan Froyd wrote: > >> + tree t = make_node (CASE_LABEL_EXPR); > >> + > >> + TREE_TYPE (t) = void_type_node; > >> + SET_EXPR_LOCATION (t, input_location); > > > > As jsm and richi said, using input_location like this is a regression. > > Can we use DECL_SOURCE_LOCATION (label_decl) instead? > > Sure. Joseph, Richi, are you happy with that change? It would fix the > C/C++ regression, as c_add_case_label does: > > /* Create the LABEL_DECL itself. */ > label = create_artificial_label (loc); > ... > /* Add a CASE_LABEL to the statement-tree. */ > case_label = add_stmt (build_case_label (loc, low_value, high_value, label)); > > so the DECL_SOURCE_LOCATION would be the same as the location_t we were > passing in anyway. For the other languages, I think it would be neutral > or an improvement (they all use input_location or UNKNOWN_LOCATION for > the CASE_LABEL anyway). Yes, using DECL_SOURCE_LOCATION (label_decl) sounds like the correct thing. Richard. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-14 11:30 ` Nathan Froyd 2011-04-14 11:32 ` Richard Guenther @ 2011-04-21 16:33 ` Joseph S. Myers 1 sibling, 0 replies; 17+ messages in thread From: Joseph S. Myers @ 2011-04-21 16:33 UTC (permalink / raw) To: Nathan Froyd; +Cc: Jason Merrill, gcc-patches, rguenther On Thu, 14 Apr 2011, Nathan Froyd wrote: > On Fri, Apr 08, 2011 at 01:50:24PM -0400, Jason Merrill wrote: > > On 03/24/2011 09:15 AM, Nathan Froyd wrote: > >> + tree t = make_node (CASE_LABEL_EXPR); > >> + > >> + TREE_TYPE (t) = void_type_node; > >> + SET_EXPR_LOCATION (t, input_location); > > > > As jsm and richi said, using input_location like this is a regression. > > Can we use DECL_SOURCE_LOCATION (label_decl) instead? > > Sure. Joseph, Richi, are you happy with that change? It would fix the > C/C++ regression, as c_add_case_label does: > > /* Create the LABEL_DECL itself. */ > label = create_artificial_label (loc); > ... > /* Add a CASE_LABEL to the statement-tree. */ > case_label = add_stmt (build_case_label (loc, low_value, high_value, label)); > > so the DECL_SOURCE_LOCATION would be the same as the location_t we were > passing in anyway. For the other languages, I think it would be neutral > or an improvement (they all use input_location or UNKNOWN_LOCATION for > the CASE_LABEL anyway). Seems fine with me. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-08 17:50 ` Jason Merrill 2011-04-14 11:30 ` Nathan Froyd @ 2011-04-22 2:49 ` Nathan Froyd 2011-04-22 3:59 ` Jason Merrill 1 sibling, 1 reply; 17+ messages in thread From: Nathan Froyd @ 2011-04-22 2:49 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches On Fri, Apr 08, 2011 at 01:50:24PM -0400, Jason Merrill wrote: > On 03/24/2011 09:15 AM, Nathan Froyd wrote: >> + tree t = make_node (CASE_LABEL_EXPR); >> + >> + TREE_TYPE (t) = void_type_node; >> + SET_EXPR_LOCATION (t, input_location); > > As jsm and richi said, using input_location like this is a regression. > Can we use DECL_SOURCE_LOCATION (label_decl) instead? I went off and tried that; some callers provide a NULL label_decl. What's the right thing to do in that case--use UNKNOWN_LOCATION or input_location? I'm leaning towards the former. -Nathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 2:49 ` Nathan Froyd @ 2011-04-22 3:59 ` Jason Merrill 2011-04-22 4:22 ` Nathan Froyd 0 siblings, 1 reply; 17+ messages in thread From: Jason Merrill @ 2011-04-22 3:59 UTC (permalink / raw) To: Nathan Froyd; +Cc: gcc-patches On 04/21/2011 08:50 PM, Nathan Froyd wrote: > On Fri, Apr 08, 2011 at 01:50:24PM -0400, Jason Merrill wrote: >> As jsm and richi said, using input_location like this is a regression. >> Can we use DECL_SOURCE_LOCATION (label_decl) instead? > > I went off and tried that; some callers provide a NULL label_decl. Hunh. How does that work? They fill in CASE_LABEL later? Can that be changed? Jason ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 3:59 ` Jason Merrill @ 2011-04-22 4:22 ` Nathan Froyd 2011-04-22 8:57 ` Jason Merrill 0 siblings, 1 reply; 17+ messages in thread From: Nathan Froyd @ 2011-04-22 4:22 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches On Thu, Apr 21, 2011 at 10:49:05PM -0400, Jason Merrill wrote: > On 04/21/2011 08:50 PM, Nathan Froyd wrote: >> On Fri, Apr 08, 2011 at 01:50:24PM -0400, Jason Merrill wrote: >>> As jsm and richi said, using input_location like this is a regression. >>> Can we use DECL_SOURCE_LOCATION (label_decl) instead? >> >> I went off and tried that; some callers provide a NULL label_decl. > > Hunh. How does that work? They fill in CASE_LABEL later? Can that be > changed? Yeah, tree-eh.c:lower_try_finally_switch. I don't know how easy it is to fix; it certainly looks non-trivial. -Nathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 4:22 ` Nathan Froyd @ 2011-04-22 8:57 ` Jason Merrill 2011-04-22 9:12 ` Mike Stump 2011-04-25 23:06 ` Nathan Froyd 0 siblings, 2 replies; 17+ messages in thread From: Jason Merrill @ 2011-04-22 8:57 UTC (permalink / raw) To: Nathan Froyd; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 538 bytes --] On 04/21/2011 10:55 PM, Nathan Froyd wrote: > On Thu, Apr 21, 2011 at 10:49:05PM -0400, Jason Merrill wrote: >> Hunh. How does that work? They fill in CASE_LABEL later? Can that be >> changed? > > Yeah, tree-eh.c:lower_try_finally_switch. I don't know how easy it is > to fix; it certainly looks non-trivial. Well, I tried adjusting it and regression testing seems fine so far. I can't think what the comment would be talking about with pointers not providing a stable order; I don't see anything that would rely on that. Jason [-- Attachment #2: case-lab.patch --] [-- Type: text/plain, Size: 1607 bytes --] commit 50cd5e483b89a3be6fd9e432edf1ece31f6756bd Author: Jason Merrill <jason@redhat.com> Date: Fri Apr 22 00:47:36 2011 -0400 bar diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c index 60e2236..feee182 100644 --- a/gcc/tree-eh.c +++ b/gcc/tree-eh.c @@ -1419,11 +1419,9 @@ lower_try_finally_switch (struct leh_state *state, struct leh_tf_state *tf) void **slot; case_lab = build3 (CASE_LABEL_EXPR, void_type_node, build_int_cst (NULL, switch_id), - NULL, NULL); + NULL, create_artificial_label (tf_loc)); /* We store the cont_stmt in the pointer map, so that we can recover - it in the loop below. We don't create the new label while - walking the goto_queue because pointers don't offer a stable - order. */ + it in the loop below. */ if (!cont_map) cont_map = pointer_map_create (); slot = pointer_map_insert (cont_map, case_lab); @@ -1443,13 +1441,10 @@ lower_try_finally_switch (struct leh_state *state, struct leh_tf_state *tf) gcc_assert (cont_map); slot = pointer_map_contains (cont_map, last_case); - /* As the comment above suggests, CASE_LABEL (last_case) was just a - placeholder, it does not store an actual label, yet. */ gcc_assert (slot); cont_stmt = *(gimple *) slot; - label = create_artificial_label (tf_loc); - CASE_LABEL (last_case) = label; + label = CASE_LABEL (last_case); x = gimple_build_label (label); gimple_seq_add_stmt (&switch_body, x); ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 8:57 ` Jason Merrill @ 2011-04-22 9:12 ` Mike Stump 2011-04-22 12:36 ` Richard Guenther 2011-04-22 16:59 ` Jason Merrill 2011-04-25 23:06 ` Nathan Froyd 1 sibling, 2 replies; 17+ messages in thread From: Mike Stump @ 2011-04-22 9:12 UTC (permalink / raw) To: Jason Merrill; +Cc: Nathan Froyd, gcc-patches On Apr 21, 2011, at 9:59 PM, Jason Merrill wrote: > On 04/21/2011 10:55 PM, Nathan Froyd wrote: >> On Thu, Apr 21, 2011 at 10:49:05PM -0400, Jason Merrill wrote: >>> Hunh. How does that work? They fill in CASE_LABEL later? Can that be >>> changed? >> >> Yeah, tree-eh.c:lower_try_finally_switch. I don't know how easy it is >> to fix; it certainly looks non-trivial. > > Well, I tried adjusting it and regression testing seems fine so far. Unsurprising... It will never fail during testsuite run, and won't always fail during a bootstrap. > I can't think what the comment would be talking about with pointers not providing a stable order; I don't see anything that would rely on that. http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html has the details of why the code was put in. Essentially, the Ada boostrap on x86 linux. What's worse is, at the time, it would only occasionally fail, so, a bootstrap that works won't prove anything. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 9:12 ` Mike Stump @ 2011-04-22 12:36 ` Richard Guenther 2011-04-22 14:45 ` Nathan Froyd 2011-04-22 16:59 ` Jason Merrill 1 sibling, 1 reply; 17+ messages in thread From: Richard Guenther @ 2011-04-22 12:36 UTC (permalink / raw) To: Mike Stump; +Cc: Jason Merrill, Nathan Froyd, gcc-patches On Fri, Apr 22, 2011 at 8:13 AM, Mike Stump <mikestump@comcast.net> wrote: > On Apr 21, 2011, at 9:59 PM, Jason Merrill wrote: >> On 04/21/2011 10:55 PM, Nathan Froyd wrote: >>> On Thu, Apr 21, 2011 at 10:49:05PM -0400, Jason Merrill wrote: >>>> Hunh. How does that work? They fill in CASE_LABEL later? Can that be >>>> changed? >>> >>> Yeah, tree-eh.c:lower_try_finally_switch. I don't know how easy it is >>> to fix; it certainly looks non-trivial. >> >> Well, I tried adjusting it and regression testing seems fine so far. > > Unsurprising... It will never fail during testsuite run, and won't always fail during a bootstrap. > >> I can't think what the comment would be talking about with pointers not providing a stable order; I don't see anything that would rely on that. > > http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html > > has the details of why the code was put in. Essentially, the Ada boostrap on x86 linux. What's worse is, at the time, it would only occasionally fail, so, a bootstrap that works won't prove anything. Well, unless we are not walking a pointer-based hashtable I don't see how this matters here. To Nathan: yes, UNKNOWN_LOCATION would be correct. Whoever then sets the label should adjust it accordingly. Richard. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 12:36 ` Richard Guenther @ 2011-04-22 14:45 ` Nathan Froyd 0 siblings, 0 replies; 17+ messages in thread From: Nathan Froyd @ 2011-04-22 14:45 UTC (permalink / raw) To: Richard Guenther; +Cc: Mike Stump, Jason Merrill, gcc-patches On Fri, Apr 22, 2011 at 11:12:01AM +0200, Richard Guenther wrote: > On Fri, Apr 22, 2011 at 8:13 AM, Mike Stump <mikestump@comcast.net> wrote: > > Unsurprising... Â It will never fail during testsuite run, and won't > > always fail during a bootstrap. > > > >> I can't think what the comment would be talking about with pointers > >> not providing a stable order; I don't see anything that would rely > >> on that. > > > > Â http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html > > > > has the details of why the code was put in. Â Essentially, the Ada > > boostrap on x86 linux. Â What's worse is, at the time, it would only > > occasionally fail, so, a bootstrap that works won't prove anything. > > Well, unless we are not walking a pointer-based hashtable I don't see > how this matters here. I can't see the pointer traversal, either--unless there's some subtlety in how things are added to the goto_queue. I'm going to leave the code alone for the moment. > To Nathan: yes, UNKNOWN_LOCATION would be correct. Whoever then sets > the label should adjust it accordingly. Will commit with that change in build_case_label, then. I will leave the location-setting to a separate commit, if any. -Nathan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 9:12 ` Mike Stump 2011-04-22 12:36 ` Richard Guenther @ 2011-04-22 16:59 ` Jason Merrill 2011-04-22 17:35 ` Mike Stump 2011-04-29 8:38 ` Alexandre Oliva 1 sibling, 2 replies; 17+ messages in thread From: Jason Merrill @ 2011-04-22 16:59 UTC (permalink / raw) To: Mike Stump; +Cc: Nathan Froyd, gcc-patches, Alexandre Oliva On 04/22/2011 02:13 AM, Mike Stump wrote: > http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html > > has the details of why the code was put in. Right. At the time, we were sorting the goto queue based on pointer values, which caused the problem. We no longer do that, so we shouldn't need this workaround (deferring creation of case label labels) anymore. What do you think, Alex? Jason ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 16:59 ` Jason Merrill @ 2011-04-22 17:35 ` Mike Stump 2011-04-29 8:38 ` Alexandre Oliva 1 sibling, 0 replies; 17+ messages in thread From: Mike Stump @ 2011-04-22 17:35 UTC (permalink / raw) To: Jason Merrill; +Cc: Nathan Froyd, gcc-patches, Alexandre Oliva On Apr 22, 2011, at 8:55 AM, Jason Merrill wrote: > On 04/22/2011 02:13 AM, Mike Stump wrote: >> http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html >> >> has the details of why the code was put in. > > Right. At the time, we were sorting the goto queue based on pointer values, which caused the problem. We no longer do that, Excellent. That was the only concern I knew of. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 16:59 ` Jason Merrill 2011-04-22 17:35 ` Mike Stump @ 2011-04-29 8:38 ` Alexandre Oliva 1 sibling, 0 replies; 17+ messages in thread From: Alexandre Oliva @ 2011-04-29 8:38 UTC (permalink / raw) To: Jason Merrill; +Cc: Mike Stump, Nathan Froyd, gcc-patches On Apr 22, 2011, Jason Merrill <jason@redhat.com> wrote: > On 04/22/2011 02:13 AM, Mike Stump wrote: >> http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html >> >> has the details of why the code was put in. > Right. At the time, we were sorting the goto queue based on pointer > values, which caused the problem. We no longer do that, so we > shouldn't need this workaround (deferring creation of case label > labels) anymore. > What do you think, Alex? Yeah, this change looks safe now. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH PING] c++-specific bits of tree-slimming patches 2011-04-22 8:57 ` Jason Merrill 2011-04-22 9:12 ` Mike Stump @ 2011-04-25 23:06 ` Nathan Froyd 1 sibling, 0 replies; 17+ messages in thread From: Nathan Froyd @ 2011-04-25 23:06 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches On Fri, Apr 22, 2011 at 12:59:21AM -0400, Jason Merrill wrote: > On 04/21/2011 10:55 PM, Nathan Froyd wrote: >> On Thu, Apr 21, 2011 at 10:49:05PM -0400, Jason Merrill wrote: >>> Hunh. How does that work? They fill in CASE_LABEL later? Can that be >>> changed? >> >> Yeah, tree-eh.c:lower_try_finally_switch. I don't know how easy it is >> to fix; it certainly looks non-trivial. > > Well, I tried adjusting it and regression testing seems fine so far. I > can't think what the comment would be talking about with pointers not > providing a stable order; I don't see anything that would rely on > that. Based on discussion downthread, I plan to commit something like your patch (I think `label' is unused after this, so requires trivial changes) on your behalf tomorrow, unless you beat me to it or unless somebody yells. I'd rather have this not mixed up with the rest of the build_case_label changes. -Nathan ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-04-29 7:53 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-03-24 13:15 [PATCH PING] c++-specific bits of tree-slimming patches Nathan Froyd 2011-04-05 12:10 ` Nathan Froyd 2011-04-08 17:50 ` Jason Merrill 2011-04-14 11:30 ` Nathan Froyd 2011-04-14 11:32 ` Richard Guenther 2011-04-21 16:33 ` Joseph S. Myers 2011-04-22 2:49 ` Nathan Froyd 2011-04-22 3:59 ` Jason Merrill 2011-04-22 4:22 ` Nathan Froyd 2011-04-22 8:57 ` Jason Merrill 2011-04-22 9:12 ` Mike Stump 2011-04-22 12:36 ` Richard Guenther 2011-04-22 14:45 ` Nathan Froyd 2011-04-22 16:59 ` Jason Merrill 2011-04-22 17:35 ` Mike Stump 2011-04-29 8:38 ` Alexandre Oliva 2011-04-25 23:06 ` Nathan Froyd
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).