On 12/20/2011 11:13 AM, Torvald Riegel wrote:
On Mon, 2011-12-19 at 15:17 -0800, Richard Henderson wrote:
On 12/19/2011 02:58 PM, Torvald Riegel wrote:
In the particular case (the validated loads technique used in
method-gl.cc, load(), store(), and validate()), we actually do not need
to have
On 01/03/2012 06:59 AM, Jakub Jelinek wrote:
PR bootstrap/51725
* cselib.c (add_mem_for_addr): Call canonical_cselib_val
on mem_elt first.
Ok.
r~
Hi!
The f1 function in the testcase fails newly starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=181332 because there
is no CLEANUP_POINT_EXPR around OMP_PARALLEL/OMP_TASK/OMP_FOR whose
IF/FINAL/NUM_THREADS/SCHEDULE clause expression might need some cleanups.
But as the testcase
Hi!
When gimple_ic is changing an indirect call into
if (cond)
direct_call ();
else
(*indirect_call) ()
and the indirect_call is not noreturn, but direct_call is
noreturn, we ICE during checking after profile, because the noreturn
call still has lhs set and edges that it shouldn't have.
The
Hi,
another old PR, about -Wredundant-decls (not in -Wall, nor in -Wextra,
thus safe bootstrap-wise).
The issue is that we are emitting a bogus warning for a declaration
followed by a specialization. The fix seems easy, just check !
DECL_TEMPLATE_SPECIALIZATION on newdecl; then however,
On 01/03/2012 09:10 AM, Jakub Jelinek wrote:
Attached are two different patches, the first one puts the
CLEANUP_POINT_EXPR around the whole OMP_PARALLEL etc. stmt, the second
one wraps the individual clause expressions into CLEANUP_POINT_EXPR.
Both patches have been bootstrapped/regtested on
On Mon, Jan 2, 2012 at 3:30 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Ayal Zaks ayal.z...@gmail.com writes:
+ for (i = 0; i ira_pressure_classes_num; i++)
+ {
+ enum reg_class pressure_class;
+
+ pressure_class = ira_pressure_classes[i];
+
+ if
OK.
Jason
All cross-builds are still done as C. In C++ you don't need
the missing struct qualifier or the typedef in typedef struct
gfc_expr ... gfc_expr; (the struct declaration suffices) as
there's no separate struct namespace IIUC.
Doesn't this show a bug in the compatibility warning system, or
is that
201 - 209 of 209 matches
Mail list logo