It seems pretty straightforward to me that a function named copy_tree_r
should copy everything that isn't always shared (like decls). It
already copies SAVE_EXPR, after all; how is copying STATEMENT_LIST going
to cause trouble in a context where copying SAVE_EXPR isn't?
OK, this can make
On 05/04/2011 06:57 PM, Eric Botcazou wrote:
But you're unilaterally choosing one special handling (copying) among several
ones (copying, not copying, aborting) just because of one caller, for no good
reason IMO.
It seems pretty straightforward to me that a function named copy_tree_r
should
Well, let's look at the users of copy_tree_r.
cp/tree.c (bot_manip): The case I want to fix.
Then I'd put the fix there. The old behaviour of copy_tree_r is IMO the most
sensible one and its callers should cope, as almost all already do it seems.
--
Eric Botcazou
On 05/04/2011 04:12 AM, Eric Botcazou wrote:
Well, let's look at the users of copy_tree_r.
cp/tree.c (bot_manip): The case I want to fix.
Then I'd put the fix there. The old behaviour of copy_tree_r is IMO the most
sensible one and its callers should cope, as almost all already do it seems.
Well, I disagree. STATEMENT_LISTs are just another kind of thing you
encounter in an expression; if a caller wants special handling, they can
arrange for it.
But you're unilaterally choosing one special handling (copying) among several
ones (copying, not copying, aborting) just because of
How is it used in Ada?
The front-end doesn't use it directly, it's only used through the gimplifier
by the unsharing phase (unshare_body). We also have statement expressions.
--
Eric Botcazou
On 05/03/2011 03:00 AM, Eric Botcazou wrote:
How is it used in Ada?
The front-end doesn't use it directly, it's only used through the gimplifier
by the unsharing phase (unshare_body). We also have statement expressions.
In that case you wouldn't be affected by this patch; unshare_body uses
In that case you wouldn't be affected by this patch; unshare_body uses
mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.
Right, I added it precisely to support statement expressions in Ada (instead
of changing copy_tree_r) since we never want to copy them in the unsharing
On 05/03/2011 11:52 AM, Eric Botcazou wrote:
In that case you wouldn't be affected by this patch; unshare_body uses
mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.
Right, I added it precisely to support statement expressions in Ada (instead
of changing copy_tree_r) since
So, the problem in 48834 was that we had specified a particular target
for the vec initialization, but it was getting clobbered by ending up on
the rhs of an INIT_EXPR. So 48834.patch avoids that.
But Diego doesn't think there was any real reason to abort on trying to
copy a STATEMENT_LIST,
But Diego doesn't think there was any real reason to abort on trying to
copy a STATEMENT_LIST, so it seems to me that we could revert my earlier
patch for 40975 and just add support for copying STATEMENT_LIST. So
40975-2.patch adds that support.
FWIW this assertion caught an impressive
On 05/02/2011 06:23 PM, Eric Botcazou wrote:
I'm not sure you can copy statements if they have any side-effects; this looks
quite dangerous to me. Instead statement-expressions should be wrapped up in
a SAVE_EXPR/TARGET_EXPR to protect them and prevent copying.
It sounds like Ada and C++ are
12 matches
Mail list logo
