The previous patch fixed temporary lifetime for aggregate initialization of
classes; this one extends that fix to arrays. This specifically reverses my
r74790, the patch for PR12253, which was made wrong when these semantics
were specified in DR201.
Since the array cleanup region encloses the reg
Now that we're building cleanups for aggregate elements more often, it seems
worth optimizing by avoiding building one for the last element; once it is
initialized, the complete object is fully initialized, the element cleanups
end in favor of the complete object cleanup, and so a cleanup for the l
Now that PR94041 is fixed, I can return to addressing PR66139, missing
cleanups for partially constructed aggregate temporaries. My previous
approach of calling split_nonconstant_init in cp_gimplify_init_expr broke
because gimplification is too late to be introducing destructor calls. So
instead
When we're cleaning up an array, if one destructor throws, we should still
try to clean up the rest of the array. We can use TRY_CATCH_EXPR for this,
instead of a TARGET_EXPR like my other recent patches, because a destructor
call can't involve any temporaries that need to live longer.
I thought
My earlier attempt to fix this bug didn't handle the case where both the
return and the throwing cleanup are within a try-block that catches and
discards the exception. Fixed by adding the retval cleanup to any
try-blocks as well as the function body. PR102191 pointed out that we also
weren't han
Being in_function_try_handler isn't enough to satisfy the condition of
reaching the end of such a handler; in this case, we're reaching the end of
a handler within that handler, so we don't want the special semantics.
PR c++/61611
gcc/cp/ChangeLog:
* except.c (in_nested_catch): N
We have wrap_temporary_cleanups to handle the EH region nesting problems
between cleanups for complete variables and cleanups for temporaries used in
their construction, but we weren't calling it for temporaries extended from
binding to a reference.
We still don't want this for array cleanups (sin
We were always calling the complete destructor if the target constructor
throws, even if we were calling the base constructor.
PR c++/103711
gcc/cp/ChangeLog:
* init.c (perform_target_ctor): Select destructor by in_chrg.
gcc/testsuite/ChangeLog:
* g++.dg/eh/delegating1.
From: Andrew Pinski
Dwarf3/4/5 are really just extensions (well not fully) on
top of dwarf2 and the option --with-dwarf2 just changes the
default to emit dwarf 2, 3, 4, or 5 by default.
On the trunk, dwarf 5 is enabled by this configure option.
gcc/ChangeLog:
PR bootstrap/59447
Hi!
It was recently pointed out that we get anomalous behavior when using
__attribute__((target)) to select a CPU. As an example, when building for
-mcpu=power8 but using __attribute__((target("mcpu=power10")), it is legal
to call __builtin_vec_mod, but not vec_mod, even though these are
equivale
>Huh, loop_father should never be NULL. Maybe when fwprop is run after RTL loop
>opts you instead want to add a check for current_loops or alternelatively
>initialize loops in fwprop.
Oh, I didn't know that, i once saw there's ICE and thought it's related to
NULL loop. But I can't reproduce the
PR103936 demonstrates that some VEC_INIT_EXPR can still survive into
GENERIC; until that's fixed let's put back the handling in cp_gimplify_expr.
PR c++/103936
PR c++/65591
gcc/cp/ChangeLog:
* cp-gimplify.c (cp_gimplify_expr): Restore VEC_INIT_EXPR handling.
gcc/testsuit
101 - 112 of 112 matches
Mail list logo
