Re: [PATCH] Prevent 'control reaches end of non-void function' warning for DO_WHILE
On 01/22/2012 03:38 AM, Tom de Vries wrote:
Sorry I didn't notice this patch until now; please CC me on C++ patches,
or at least mention C++ in the subject line.
+ tree expr = NULL;
+ append_to_statement_list (*block, expr);
+ *block = expr;
Rather than doing this dance here, I think it would be better to enhance
append_to_statement_list to handle the case of the list argument being a
non-list.
+ cp_walk_tree (incr, cp_genericize_r, data, NULL);
+ if (incr EXPR_P (incr))
+SET_EXPR_LOCATION (incr, start_locus);
It might be better to set the location on incr before genericizing, so
that the location can trickle down.
+ t = build1 (GOTO_EXPR, void_type_node, get_bc_label (bc_break));
+ SET_EXPR_LOCATION (t, start_locus);
Here you can use build1_loc instead of two separate statements.
- /* If we use a LOOP_EXPR here, we have to feed the whole thing
-back through the main gimplifier to lower it. Given that we
-have to gimplify the loop body NOW so that we can resolve
-break/continue stmts, seems easier to just expand to gotos. */
Since we're now lowering the loop at genericize time rather than
gimplify, what's the rationale for not using LOOP_EXPR/EXIT_EXPR? We
should still say something here. I suppose the rationale is that the C
front end currently goes straight to gotos.
if (cond != error_mark_node)
{
- gimplify_expr (cond, exit_seq, NULL, is_gimple_val, fb_rvalue);
- stmt = gimple_build_cond (NE_EXPR, cond,
- build_int_cst (TREE_TYPE (cond), 0),
- gimple_label_label (top),
- get_bc_label (bc_break));
- gimple_seq_add_stmt (exit_seq, stmt);
+ cond = build2 (NE_EXPR, boolean_type_node, cond,
+build_int_cst (TREE_TYPE (cond), 0));
I don't think we still need this extra comparison to 0, that seems like
a gimple-specific thing.
if (FOR_INIT_STMT (stmt))
+append_to_statement_list (FOR_INIT_STMT (stmt), expr);
+ genericize_cp_loop (loop, EXPR_LOCATION (stmt), FOR_COND (stmt),
+ FOR_BODY (stmt), FOR_EXPR (stmt), 1, walk_subtrees, data);
The call to genericize_cp_loop will clear *walk_subtrees, which means we
don't genericize the FOR_INIT_STMT.
+ tree jump = build_and_jump (label);
Again, let's use build1_loc.
+ *stmt_p = build_and_jump (label);
+ SET_EXPR_LOCATION (*stmt_p, location);
And here.
+ stmt = make_node (OMP_FOR);
Why make a new OMP_FOR rather than repurpose the one we already have?
We've already modified its operands.
Jason
Re: [google/gcc-4_6_2-mobile] PATCH: PR other/46770: Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
On Fri, Feb 17, 2012 at 05:20:02PM -0800, H.J. Lu wrote: This patch backports the fix from trunk: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 for google/gcc-4_6_2-mobile branch. This is needed to support C++ global constructors/destructiors on Android/x86. OK for google/gcc-4_6_2-mobile branch? Don't you want to backport also all the follow-ups on this? Jakub
[Patch, Fortran] PR52295 - allow for F2008 internal procs in generic interfaces
Build and regtested on x86-64-linux. OK for the (4.8?) trunk? Tobias intern-generic.diff Description: application/unknown
Re: [Patch, Fortran] PR52295 - allow for F2008 internal procs in generic interfaces
Dear Tobias, I saw Nasser's posting and the subsequent correspondence on clf. That's a pretty fast response! I think that this is OK for trunk, since it is only a change of standard for this error. Cheers Paul On Sat, Feb 18, 2012 at 12:58 PM, Tobias Burnus bur...@net-b.de wrote: Build and regtested on x86-64-linux. OK for the (4.8?) trunk? Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
[Patch, Fortran] PR 52270 - OOP - pointer check in vardef context, passing to intent-in ptr
The patch consists of two parts: * The pointer check in gfc_check_vardef_context didn't honour polymorphic variables * Passing a TYPE to a CLASS is not allowed if CLASS is a pointer or allocatable as the actual argument cannot change its effective type. However, if the dummy is an intent(in)-pointer, there is no risk of doing so. Thus, one can allow this. The latter is an interpretation request (F08/0073), which passed the J3 meeting. It is in line of the Fortran 2008 feature, where one can pass a TARGET variable (i.e. nonpointer) to an intent-in pointer dummy argument. Build and regtested on x86-64-linux OK for the (4.8) trunk? Tobias PS: Other pending patches, awaiting review: - http://gcc.gnu.org/ml/fortran/2012-02/msg00081.html (test suite failures) - http://gcc.gnu.org/ml/fortran/2012-02/msg00071.html (-Wrealloc-lhs) - http://gcc.gnu.org/ml/fortran/2012-02/msg00067.html (I/O vtable) Pending committal (optional dummy): - http://gcc.gnu.org/ml/fortran/2012-02/msg00062.html - http://gcc.gnu.org/ml/fortran/2012-02/msg00061.html ptr-intent-v2.diff Description: application/unknown
[patch, committed] invoke.texi: copy-edit docs for IRA options and parameters
I noted that the documentation for the IRA-related command-line options
and parameters needed fairly extensive copy-editing. In addition to
correcting some English grammar problems, I have reorganized some of the
discussion as well to make it easier to follow.
I've checked this in -- maybe it's not strictly obvious, but it's
intended to be a content-free change in terms of meaning, and it's at
least an incremental improvement in readability compared to what's there
now.
-Sandra
2012-02-18 Sandra Loosemore san...@codesourcery.com
gcc/
* doc/invoke.texi (-fira-* options): Copy-edit.
(ira-* parameters): Copy-edit.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 184367)
+++ gcc/doc/invoke.texi (working copy)
@@ -6759,56 +6759,65 @@ optimization.
Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
@item -fira-algorithm=@var{algorithm}
-Use specified coloring algorithm for the integrated register
-allocator. The @var{algorithm} argument should be @code{priority} or
-@code{CB}. The first algorithm specifies Chow's priority coloring,
-the second one specifies Chaitin-Briggs coloring. The second
-algorithm can be unimplemented for some architectures. If it is
-implemented, it is the default because Chaitin-Briggs coloring as a
-rule generates a better code.
+Use the specified coloring algorithm for the integrated register
+allocator. The @var{algorithm} argument can be @samp{priority}, which
+specifies Chow's priority coloring, or @samp{CB}, which specifies
+Chaitin-Briggs coloring. Chaitin-Briggs coloring is not implemented
+for all architectures, but for those targets that do support it, it is
+the default because it generates better code.
@item -fira-region=@var{region}
Use specified regions for the integrated register allocator. The
-@var{region} argument should be one of @code{all}, @code{mixed}, or
-@code{one}. The first value means using all loops as register
-allocation regions, the second value which is enabled by default when
-compiling with optimization for speed (@option{-O}, @option{-O2},
-@dots{}) means using all loops except for loops with small register
-pressure as the regions, and third one which is enabled by default for
-@option{-Os} or @option{-O0} means using all function as a single
-region. The first value can give best result for machines with small
-size and irregular register set, the third one results in faster and
-generates decent code and the smallest size code, and the second value
-usually give the best results in most cases and for most
-architectures.
+@var{region} argument should be one of the following:
+
+@table @samp
+
+@item all
+Use all loops as register allocation regions.
+This can give the best results for machines with a small and/or
+irregular register set.
+
+@item mixed
+Use all loops except for loops with small register pressure
+as the regions. This value usually gives
+the best results in most cases and for most architectures,
+and is enabled by default when compiling with optimization for speed
+(@option{-O}, @option{-O2}, @dots{}).
+
+@item one
+Use all functions as a single region.
+This typically results in the smallest code size, and is enabled by default for
+@option{-Os} or @option{-O0}.
+
+@end table
@item -fira-loop-pressure
@opindex fira-loop-pressure
-Use IRA to evaluate register pressure in loops for decision to move
-loop invariants. Usage of this option usually results in generation
-of faster and smaller code on machines with big register files (= 32
-registers) but it can slow compiler down.
+Use IRA to evaluate register pressure in loops for decisions to move
+loop invariants. This option usually results in generation
+of faster and smaller code on machines with large register files (= 32
+registers), but it can slow the compiler down.
This option is enabled at level @option{-O3} for some targets.
@item -fno-ira-share-save-slots
@opindex fno-ira-share-save-slots
-Switch off sharing stack slots used for saving call used hard
-registers living through a call. Each hard register will get a
-separate stack slot and as a result function stack frame will be
-bigger.
+Disable sharing of stack slots used for saving call-used hard
+registers living through a call. Each hard register gets a
+separate stack slot, and as a result function stack frames are
+larger.
@item -fno-ira-share-spill-slots
@opindex fno-ira-share-spill-slots
-Switch off sharing stack slots allocated for pseudo-registers. Each
-pseudo-register that did not get a hard register will get a separate
-stack slot and as a result function stack frame will be bigger.
+Disable sharing of stack slots allocated for pseudo-registers. Each
+pseudo-register that does not get a hard register gets a separate
+stack slot, and as a result function stack frames are larger.
@item -fira-verbose=@var{n}
@opindex fira-verbose
-Set up how
Re: [committed] invoke.texi: fix hyphenation of floating point and related terms
On Sun, 5 Feb 2012, Gerald Pfeifer wrote: * doc/invoke.texi: Correct hyphenation of floating point, double precision, and related terminology throughout the file. I believe we should document this then, as well, per the patch below? Any objections / thoughts? I know when ahead and committed this patch (in a minor variation to apply in a changed context). Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.65 diff -u -3 -p -r1.65 codingconventions.html --- codingconventions.html 15 Feb 2012 22:12:30 - 1.65 +++ codingconventions.html 19 Feb 2012 00:44:52 - @@ -364,6 +364,11 @@ and code. The following table lists som td/td /tr tr +tdfloating-point (adjective)/td +tdfloating point/td +td/td + /tr + tr tdfree software or just free/td tdOpen Source or OpenSource/td /tr
