Re: [PR48866] three alternative fixes
On Jun 2, 2011, Alexandre Oliva aol...@redhat.com wrote:
On May 30, 2011, Alexandre Oliva aol...@redhat.com wrote:
On May 30, 2011, Alexandre Oliva aol...@redhat.com wrote:
I have 3 different, mutually exclusive patches that fix PR 48866. The
problem is exponential time while dealing with an expression that
resulted from a long chain of replaceable insns with memory accesses
moved past the debug insns referring to their results.
1. emit debug temps for replaceable DEFs that end up being referenced in
debug insns. We already have some code to try to deal with this, but it
emits the huge expressions we'd rather avoid, and it may create
unnecessary duplication. This new approach emits a placeholder instead
of skipping replaceable DEFs altogether, and then, if the DEF is
referenced in a debug insn (perhaps during the late debug re-expasion of
some other placeholder), it is expanded. Placeholders that end up not
being referenced are then throw away.
This is my favorite option, for it's safest: it doesn't change
executable code at all (or should I say it *shouldn't* change it, for I
haven't verified that it doesn't), retaining any register pressure
benefits from TER.
This revised and retested version records expansions in an array indexed
on SSA version rather than a pointer_map, as suggested by Matz.
Updated to deal with debug source bind stmts, added an assertion in
var-tracking to make sure we don't get unexpected kinds of decls in
VAR_LOCATION insns. Regstrapped on x86_64-linux-gnu and i686-linux-gnu.
Ok to install?
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/48866
* cfgexpand.c (DEBUG_INSN_TOEXPAND): New.
(def_expansions): New.
(def_expansions_init): New.
(def_expansions_remove_placeholder, def_expansions_fini): New.
(def_get_expansion_ptr): New.
(expand_debug_expr): Create debug temps as needed.
(expand_debug_insn): New, split out of...
(expand_debug_locations): ... this.
(gen_emit_debug_insn): New, split out of...
(expand_gimple_basic_block): ... this. Simplify expansion of
debug stmts. Emit placeholders for replaceable DEFs, rather
than debug temps at last non-debug uses.
(gimple_expand_cfg): Initialize and finalize expansions cache.
* var-tracking.c (use_type): Check for acceptable var decls in
var_locations.
Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c.orig 2012-04-08 01:43:59.334000124 -0300
+++ gcc/cfgexpand.c 2012-04-08 01:50:46.851123535 -0300
@@ -2611,6 +2611,70 @@ expand_debug_parm_decl (tree decl)
return NULL_RTX;
}
+/* Mark debug insns that are placeholders for replaceable SSA_NAMEs
+ that have not been expanded yet. */
+#define DEBUG_INSN_TOEXPAND(RTX) \
+ (RTL_FLAG_CHECK1(DEBUG_INSN_TOEXPAND, (RTX), DEBUG_INSN)-used)
+
+/* Map replaceable SSA_NAMEs versions to their RTL expansions. */
+static rtx *def_expansions;
+
+/* Initialize the def_expansions data structure. This is to be called
+ before expansion of a function starts. */
+
+static void
+def_expansions_init (void)
+{
+ gcc_checking_assert (!def_expansions);
+ def_expansions = XCNEWVEC (rtx, num_ssa_names);
+}
+
+/* Remove the DEBUG_INSN INSN if it still binds an SSA_NAME. */
+
+static bool
+def_expansions_remove_placeholder (rtx insn)
+{
+ gcc_checking_assert (insn);
+
+ if (TREE_CODE (INSN_VAR_LOCATION_DECL (insn)) == SSA_NAME)
+{
+ gcc_assert (!DEBUG_INSN_TOEXPAND (insn));
+ remove_insn (insn);
+}
+
+ return true;
+}
+
+/* Finalize the def_expansions data structure. This is to be called
+ at the end of the expansion of a function. */
+
+static void
+def_expansions_fini (void)
+{
+ int i = num_ssa_names;
+
+ gcc_checking_assert (def_expansions);
+ while (i--)
+if (def_expansions[i])
+ def_expansions_remove_placeholder (def_expansions[i]);
+ XDELETEVEC (def_expansions);
+ def_expansions = NULL;
+}
+
+/* Return a pointer to the rtx expanded from EXP. EXP must be a
+ replaceable SSA_NAME. */
+
+static rtx *
+def_get_expansion_ptr (tree exp)
+{
+ gcc_checking_assert (def_expansions);
+ gcc_checking_assert (TREE_CODE (exp) == SSA_NAME);
+ gcc_checking_assert (bitmap_bit_p (SA.values, SSA_NAME_VERSION (exp)));
+ return def_expansions[SSA_NAME_VERSION (exp)];
+}
+
+static void expand_debug_insn (rtx insn);
+
/* Return an RTX equivalent to the value of the tree expression EXP. */
static rtx
@@ -3421,7 +3485,30 @@ expand_debug_expr (tree exp)
gimple g = get_gimple_for_ssa_name (exp);
if (g)
{
- op0 = expand_debug_expr (gimple_assign_rhs_to_tree (g));
+ rtx insn = *def_get_expansion_ptr (exp);
+ tree vexpr;
+
+ /* If this still has the original SSA_NAME, emit a debug
+ temp and compute the RTX value. */
+ if (TREE_CODE (INSN_VAR_LOCATION_DECL (insn)) == SSA_NAME)
+ {
+ tree var = SSA_NAME_VAR (INSN_VAR_LOCATION_DECL (insn));
+
+ vexpr = make_node (DEBUG_EXPR_DECL);
+ DECL_ARTIFICIAL
Re: fix left-over debug insns in DCE
On Jun 6, 2011, Alexandre Oliva aol...@redhat.com wrote:
On Jun 6, 2011, Eric Botcazou ebotca...@adacore.com wrote:
It might be too late for DF to do anything sensible to preserve the
debug info rather than just throw it away, as your partial approval
suggests.
OK, let me think about this a little more.
Ping?
Here are the remaining bits.
Some more context here: this enables DCE to turn removed insns into
debug temps when they're useful for debug info. It further improves
debug info quality when installed along with the patch I just posted for
PR 48866. Without it, a number of chains of debug temps that lead to a
real insn that gets deleted end up useless.
Regstrapped on x86_64-linux-gnu and i686-pc-linux-gnu. Ok to install?
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/48866
* df.h (enum debug_temp_where): New.
(dead_debug_init, dead_debug_finish) Declare.
(dead_debug_add, dead_debug_insert_temp): Declare.
(struct dead_debug_use, struct dead_debug): Moved from...
* df-problems.c: ... here.
(df_set_unused_notes_for_mw): Bind debug uses of unused regno
to a debug temp.
(df_create_unused_note): Likewise.
(df_set_dead_notes_for_mw): Move comment where it belongs.
(dead_debug_init): Export.
(dead_debug_reset_uses): New, factored out of...
(dead_debug_finish): ...this. Export.
(dead_debug_reset): Remove.
(dead_debug_add): Export.
(dead_debug_insert_before): Rename to...
(dead_debug_insert_temp): ... this. Add where argument. Export.
Locate stored value for BEFORE_WITH_VALUE. Avoid repeat inserts.
Return insertion count.
(df_note_bb_compute): Adjust.
* dce.c (word_dce_process_block): Adjust dead debug uses.
(dce_process_block): Likewise.
Index: gcc/df.h
===
--- gcc/df.h.orig 2012-03-01 04:26:27.926134403 -0300
+++ gcc/df.h 2012-03-26 11:19:12.300584463 -0300
@@ -1101,4 +1101,35 @@ extern void union_defs (df_ref, struct w
unsigned int *used, struct web_entry *,
bool (*fun) (struct web_entry *, struct web_entry *));
+/* Debug uses of dead regs. */
+
+/* Node of a linked list of uses of dead REGs in debug insns. */
+struct dead_debug_use
+{
+ df_ref use;
+ struct dead_debug_use *next;
+};
+
+/* Linked list of the above, with a bitmap of the REGs in the
+ list. */
+struct dead_debug
+{
+ struct dead_debug_use *head;
+ bitmap used;
+ bitmap to_rescan;
+};
+
+enum debug_temp_where
+ {
+DEBUG_TEMP_BEFORE_WITH_REG = -1,
+DEBUG_TEMP_BEFORE_WITH_VALUE = 0,
+DEBUG_TEMP_AFTER_WITH_REG = 1
+ };
+
+void dead_debug_init (struct dead_debug *, bitmap);
+void dead_debug_finish (struct dead_debug *, bitmap);
+void dead_debug_add (struct dead_debug *, df_ref, unsigned int);
+int dead_debug_insert_temp (struct dead_debug *, unsigned int, rtx,
+ enum debug_temp_where);
+
#endif /* GCC_DF_H */
Index: gcc/df-problems.c
===
--- gcc/df-problems.c.orig 2012-01-30 16:47:05.0 -0200
+++ gcc/df-problems.c 2012-03-26 11:49:17.848542873 -0300
@@ -2886,25 +2886,6 @@ df_whole_mw_reg_unused_p (struct df_mw_h
}
-/* Node of a linked list of uses of dead REGs in debug insns. */
-struct dead_debug_use
-{
- df_ref use;
- struct dead_debug_use *next;
-};
-
-/* Linked list of the above, with a bitmap of the REGs in the
- list. */
-struct dead_debug
-{
- struct dead_debug_use *head;
- bitmap used;
- bitmap to_rescan;
-};
-
-static void dead_debug_reset (struct dead_debug *, unsigned int);
-
-
/* Set the REG_UNUSED notes for the multiword hardreg defs in INSN
based on the bits in LIVE. Do not generate notes for registers in
artificial uses. DO_NOT_GEN is updated so that REG_DEAD notes are
@@ -2930,7 +2911,7 @@ df_set_unused_notes_for_mw (rtx insn, st
{
unsigned int regno = mws-start_regno;
df_set_note (REG_UNUSED, insn, mws-mw_reg);
- dead_debug_reset (debug, regno);
+ dead_debug_insert_temp (debug, regno, insn, DEBUG_TEMP_AFTER_WITH_REG);
#ifdef REG_DEAD_DEBUGGING
df_print_note (adding 1: , insn, REG_NOTES (insn));
@@ -2945,7 +2926,7 @@ df_set_unused_notes_for_mw (rtx insn, st
!bitmap_bit_p (artificial_uses, r))
{
df_set_note (REG_UNUSED, insn, regno_reg_rtx[r]);
- dead_debug_reset (debug, r);
+ dead_debug_insert_temp (debug, r, insn, DEBUG_TEMP_AFTER_WITH_REG);
#ifdef REG_DEAD_DEBUGGING
df_print_note (adding 2: , insn, REG_NOTES (insn));
#endif
@@ -3013,12 +2994,12 @@ df_set_dead_notes_for_mw (rtx insn, stru
if (df_whole_mw_reg_dead_p (mws, live, artificial_uses, do_not_gen))
{
- /* Add a dead note for the entire multi word register. */
if (is_debug)
{
*added_notes_p = true;
return;
}
+ /* Add a dead note for the entire multi word register. */
df_set_note (REG_DEAD, insn, mws-mw_reg);
#ifdef REG_DEAD_DEBUGGING
df_print_note (adding 1: , insn, REG_NOTES (insn));
[PR 50826] [DF] no debug temps for artificial uses
This patch is a small improvement to DF, for an issue I noticed while
investigating PR 50826. We take note of, and may emit debug temps for,
REGs for which we won't emit REG_DEAD/REG_UNUSED notes. This is a
waste, removed with this patch.
Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install?
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR debug/50826
* df-problems.c (df_note_bb_compute): Do not take note of
debug uses for whose REGs we won't emit DEAD or UNUSED notes.
Index: gcc/df-problems.c
===
--- gcc/df-problems.c.orig 2012-04-08 01:50:45.379141149 -0300
+++ gcc/df-problems.c 2012-04-08 02:05:13.406574358 -0300
@@ -3528,7 +3528,12 @@ df_note_bb_compute (unsigned int bb_inde
{
if (debug_insn 0)
{
- dead_debug_add (debug, use, uregno);
+ /* We won't add REG_UNUSED or REG_DEAD notes for
+ these, so we don't have to mess with them in
+ debug insns either. */
+ if (!bitmap_bit_p (artificial_uses, uregno)
+ (!df_ignore_stack_reg (uregno)))
+ dead_debug_add (debug, use, uregno);
continue;
}
break;
--
Alexandre Oliva, freedom fighterhttp://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
Re: [PATCH] Fix ICE in expand_cse_reciprocals (PR tree-optimization/42078)
On Jun 3, 2011, Alexandre Oliva aol...@redhat.com wrote:
According to http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01082.html
on Nov 20, 2009, Alexandre Oliva aol...@redhat.com wrote:
On Nov 19, 2009, Richard Guenther richard.guent...@gmail.com wrote:
In fact this exchanging of the LHS (or rather invalidating of the
SSA name value) should be a helper function that knows
the implementation details and avoids going through releasing
and allocating the name.
Okie dokie, here's a sequence of patches that implements helper
functions for this sort of stuff.
The first patch introduces machinery to propagate “dying” DEFs into
debug stmts, while replacing them with other SSA_NAMEs.
This is already in.
The second extends it so as to enable the old LHS to be redefined
e.g. in terms of the new LHS. IIRC this may be useful in some other
transformations that, in the process of introducing VTA, I changed from
modifying stmts in place to inserting new stmts and removing others. I
haven't looked for them yet.
The third uses this new feature for the case at hand, while avoiding
computing the reciprocal expression if we know it won't be used.
Updated versions of these follow. Regstrapped on x86_64-linux-gnu and
i686-linux-gnu. Ok to install?
I was asked to submit these again in stage1, so... Ping?
(updated and re-tested)
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
PR tree-optimization/42078
* gimple.h (gimple_replace_lhs_wants_value): New.
(gimple_replace_lhs): Add value.
* gimple.c (gimple_replace_lhs): Likewise. Pass it on.
* tree-flow.h (insert_debug_temp_for_var_def): Add value.
* tree-ssa.c (insert_debug_temp_for_var_def): Likewise. Use it.
(insert_debug_temps_for_defs): Pass NULL value.
* tree-ssanames.c (release_ssa_name): Likewise.
* tree-ssa-math-opts.c (execute_cse_reciprocals): Likewise.
* gcc/tree-ssa-reassoc.c (repropagate_negates): Likewise.
Index: gcc/gimple.h
===
--- gcc/gimple.h.orig 2012-04-07 20:24:41.796529955 -0300
+++ gcc/gimple.h 2012-04-08 02:06:44.417457641 -0300
@@ -943,7 +943,7 @@ void gimple_assign_set_rhs_with_ops_1 (g
tree, tree, tree);
tree gimple_get_lhs (const_gimple);
void gimple_set_lhs (gimple, tree);
-void gimple_replace_lhs (gimple, tree);
+void gimple_replace_lhs (gimple, tree, tree);
gimple gimple_copy (gimple);
void gimple_set_modified (gimple, bool);
void gimple_cond_get_ops_from_tree (tree, enum tree_code *, tree *, tree *);
@@ -2521,6 +2521,14 @@ gimple_has_lhs (gimple stmt)
gimple_call_lhs (stmt) != NULL_TREE));
}
+/* Return true if it might be useful to pass a VALUE to
+ gimple_replace_lhs (). */
+static inline bool
+gimple_replace_lhs_wants_value (void)
+{
+ return MAY_HAVE_DEBUG_STMTS;
+}
+
/* Return the code of the predicate computed by conditional statement GS. */
Index: gcc/gimple.c
===
--- gcc/gimple.c.orig 2012-04-07 20:24:41.796529955 -0300
+++ gcc/gimple.c 2012-04-08 02:06:44.606455321 -0300
@@ -2239,10 +2239,10 @@ gimple_set_lhs (gimple stmt, tree lhs)
expression with a different value.
This will update any annotations (say debug bind stmts) referring
- to the original LHS, so that they use the RHS instead. This is
- done even if NLHS and LHS are the same, for it is understood that
- the RHS will be modified afterwards, and NLHS will not be assigned
- an equivalent value.
+ to the original LHS, so that they use VALUE or the RHS instead.
+ This is done even if NLHS and LHS are the same, for it is
+ understood that the RHS will be modified afterwards, and NLHS will
+ not be assigned an equivalent value.
Adjusting any non-annotation uses of the LHS, if needed, is a
responsibility of the caller.
@@ -2254,15 +2254,20 @@ gimple_set_lhs (gimple stmt, tree lhs)
copying and removing. */
void
-gimple_replace_lhs (gimple stmt, tree nlhs)
+gimple_replace_lhs (gimple stmt, tree nlhs, tree value)
{
+ /* If the conditions in which this function uses VALUE change,
+ adjust gimple_replace_lhs_wants_value(). */
+ gcc_assert (gimple_replace_lhs_wants_value ()
+ == MAY_HAVE_DEBUG_STMTS);
+
if (MAY_HAVE_DEBUG_STMTS)
{
tree lhs = gimple_get_lhs (stmt);
gcc_assert (SSA_NAME_DEF_STMT (lhs) == stmt);
- insert_debug_temp_for_var_def (NULL, lhs);
+ insert_debug_temp_for_var_def (NULL, lhs, value);
}
gimple_set_lhs (stmt, nlhs);
Index: gcc/tree-flow.h
===
--- gcc/tree-flow.h.orig 2012-04-07 20:24:45.350481393 -0300
+++ gcc/tree-flow.h 2012-04-08 02:06:44.658454684 -0300
@@ -563,7 +563,7 @@ typedef bool (*walk_use_def_chains_fn) (
extern void walk_use_def_chains (tree, walk_use_def_chains_fn, void *, bool);
void insert_debug_temps_for_defs (gimple_stmt_iterator *);
-void
Re: fix incorrect debug temp added by df-problems
On Oct 27, 2011, Alexandre Oliva aol...@redhat.com wrote:
pr43165.c -Os -g exercises a bug in df-problems WRT the introduction of
debug temps. After pro_and_epilogue, the function was optimized to this:
push bp
mov bp,sp
# debug insn referencing bp
pop bp
I don't know why we bother to preserve and set up bp, it's not used in
nondebug insns (and even with -g0 we still emit it). GCC 4.5 did
better, but that's a different issue I haven't addressed.
The problem I address here is that the debug insn references bp, but
df-problems sees bp is dead at the debug insn during backward scanning,
and decides we have to emit a debug temp before its last use.
However, there isn't a last use: the set is dead, but it isn't regarded
as such because bp is in artificial_uses at the end of the block. For
this reason, df_create_unused_note refrains from emitting the note and
resetting the debug uses.
However, the decision to emit a debug temp before the last bp use
remains in effect, so when the backward scanning reaches the push bp, it
emits a debug temp bound to the *previous* value of bp, and replaces
the debug use of bp with that. Oops.
This patch arranges for us to not decide a debug use is dead if we won't
emit a REG_DEAD or REG_UNUSED note for it, because it is
artificially-used or an ignored stack reg. An alternative would be to
remove any pending dead_debug entry from the list when we encounter a
set, but this is cheaper and it *should* be equivalent.
With this patch, the debug insn remains using bp, and no debug temp is
introduced.
Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install?
Apologies, I've just re-posted this patch claiming it had to do with
pr50826. Maybe it does (I'm no longer sure I actually ran into the same
problem there), but this was the thread in which I first posted it, so
I'll follow up here.
Regstrapped and retested. Ok?
This fixes a bug in pr43165.c with -Os -g.
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
* df-problems.c (df_note_bb_compute): Do not take note of
debug uses for whose REGs we won't emit DEAD or UNUSED notes.
Index: gcc/df-problems.c
===
--- gcc/df-problems.c.orig 2012-04-08 01:50:45.379141149 -0300
+++ gcc/df-problems.c 2012-04-08 02:05:13.406574358 -0300
@@ -3528,7 +3528,12 @@ df_note_bb_compute (unsigned int bb_inde
{
if (debug_insn 0)
{
- dead_debug_add (debug, use, uregno);
+ /* We won't add REG_UNUSED or REG_DEAD notes for
+ these, so we don't have to mess with them in
+ debug insns either. */
+ if (!bitmap_bit_p (artificial_uses, uregno)
+ (!df_ignore_stack_reg (uregno)))
+ dead_debug_add (debug, use, uregno);
continue;
}
break;
--
Alexandre Oliva, freedom fighterhttp://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
Re: don't force debug insns after their PREV_INSNs
On Jun 3, 2011, Bernd Schmidt ber...@codesourcery.com wrote:
On 06/03/2011 04:47 PM, Alexandre Oliva wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=677681 can be
“fixed” by disabling the artificial dependency of a debug insn on its
previous insn.
Debug insns will often depend on their prevs anyway, in a use/def
relationship, but if the def was (re)moved or the use was reset, this
artificial dep helped keep the debug insn “in place”.
Being a very imperfect heuristic, it's not clear that it helps more than
it harms. Thoughts? Regstrapped on x86_64-linux-gnu and
i686-linux-gnu.
Can you explain a little more clearly what the problem is? The RH
bugzilla isn't really clear.
The problem here is that a nondebug insn may be moved ahead of a useful
debug insn and clobber one of its inputs, rendering it useless, when
there's no good reason for the debug insn to be kept in place, other
than an accidental dependency on the previous insn when it happens to be
unrelated with the debug insn.
Removing the extraneous dependency, that was thought to be a way to
reduce movement of debug insns, improves on this problem. It's not
clear that this artificial dependency really does any good, since odds
are that that previous insn may be pulled ahead anyway, in which case so
will debug insn (unless that would fail other of its deps, of course)
Retested. Ok?
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
* sched-deps.c (sched_analyze_insn): Don't force debug insns
to follow their original predecessors.
Index: gcc/sched-deps.c
===
--- gcc/sched-deps.c.orig 2012-02-25 09:45:31.749795611 -0200
+++ gcc/sched-deps.c 2012-04-08 02:10:39.710573253 -0300
@@ -2988,18 +2988,6 @@ sched_analyze_insn (struct deps_desc *de
reg_last-uses = alloc_INSN_LIST (insn, reg_last-uses);
}
CLEAR_REG_SET (reg_pending_uses);
-
- /* Quite often, a debug insn will refer to stuff in the
- previous instruction, but the reason we want this
- dependency here is to make sure the scheduler doesn't
- gratuitously move a debug insn ahead. This could dirty
- DF flags and cause additional analysis that wouldn't have
- occurred in compilation without debug insns, and such
- additional analysis can modify the generated code. */
- prev = PREV_INSN (insn);
-
- if (prev NONDEBUG_INSN_P (prev))
- add_dependence (insn, prev, REG_DEP_ANTI);
}
else
{
--
Alexandre Oliva, freedom fighterhttp://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
Re: debug insns in SMS
On May 4, 2011, Revital1 Eres e...@il.ibm.com wrote:
Hello Alexandre
I think this will restore proper functioning to SMS in the presence of
debug insns. A while ago, we'd never generate deps of non-debug insns
on debug insns. I introduced them to enable sched to adjust (reset)
debug insns when non-debug insns were moved before them. I believe it
is safe to leave them out of the SCCs. Even though this will end up
causing some loss of debug info, that's probably unavoidable, and the
end result after this change is pobably the best we can hope for. Your
thoughts?
Thanks for the patch!
I actually discussed this issue with Ayal yesterday.
Ayal also suggested to reconsider the edges that are created in
the DDG between real instructions and debug_insns. Currently, we create
bidirectional anti deps edges between them. This leads to the problem you
were trying to solve in the current patch (described below) where these
extra edges influence the construction of the strongly connected component
and the code generated with and w\o -g. Your patch seems to solve this
problem.
However I can not approve it as I'm not the maintainer (Ayal is).
Ping?
(Retested on x86_64-linux-gnu and i686-pc-linux-gnu)
for gcc/ChangeLog
from Alexandre Oliva aol...@redhat.com
* ddg.c (build_intra_loop_deps): Discard deps of nondebug on debug.
Index: gcc/ddg.c
===
--- gcc/ddg.c.orig 2012-01-04 21:06:38.0 -0200
+++ gcc/ddg.c 2012-04-08 02:10:44.711511989 -0300
@@ -532,7 +532,12 @@ build_intra_loop_deps (ddg_ptr g)
FOR_EACH_DEP (dest_node-insn, SD_LIST_BACK, sd_it, dep)
{
- ddg_node_ptr src_node = get_node_of_insn (g, DEP_PRO (dep));
+ ddg_node_ptr src_node;
+
+ if (DEBUG_INSN_P (DEP_PRO (dep)) !DEBUG_INSN_P (dest_node-insn))
+ continue;
+
+ src_node = get_node_of_insn (g, DEP_PRO (dep));
if (!src_node)
continue;
--
Alexandre Oliva, freedom fighterhttp://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
[SPARC] Adjust testsuite parameterization
This both eliminates bogus failures in the testsuite on SPARC64/Linux when you
configure --with-cpu=v8 and enables more tests on SPARC/Solaris (which is by
default configured --with-cpu=v9).
Tested on SPARC64/Linux and SPARC/Solaris, applied on mainline and 4.7 branch.
2012-04-09 Eric Botcazou ebotca...@adacore.com
* lib/target-supports.exp (check_effective_target_sparc_v9): New.
(check_effective_target_sync_long_long): Add SPARC case.
(check_effective_target_sync_long_long_runtime): Likewise.
(check_effective_target_sync_int_long): Adjust SPARC case.
(check_effective_target_sync_char_short): Likewise.
--
Eric Botcazou
Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 186176)
+++ lib/target-supports.exp (working copy)
@@ -2551,7 +2551,22 @@ proc check_effective_target_ultrasparc_v
} -mcpu=niagara3]
}
-# Return 1 if this is a Sparc target with VIS enabled.
+# Return 1 if this is a SPARC-V9 target.
+
+proc check_effective_target_sparc_v9 { } {
+if { [istarget sparc*-*-*] } {
+ return [check_no_compiler_messages sparc_v9 object {
+ int main (void) {
+ asm volatile (return %i7+8);
+ return 0;
+ }
+ }]
+} else {
+ return 0
+}
+}
+
+# Return 1 if this is a SPARC target with VIS enabled.
proc check_effective_target_sparc_vis { } {
if { [istarget sparc*-*-*] } {
@@ -3730,7 +3745,8 @@ proc check_effective_target_sync_long_lo
if { [istarget x86_64-*-*]
|| [istarget i?86-*-*])
|| [istarget arm*-*-*]
- || [istarget alpha*-*-*] } {
+ || [istarget alpha*-*-*]
+ || ([istarget sparc*-*-*] [check_effective_target_lp64]) } {
return 1
} else {
return 0
@@ -3775,6 +3791,10 @@ proc check_effective_target_sync_long_lo
} ]
} elseif { [istarget alpha*-*-*] } {
return 1
+} elseif { ([istarget sparc*-*-*]
+ [check_effective_target_lp64]
+ [check_effective_target_ultrasparc_hw]) } {
+ return 1
} else {
return 0
}
@@ -3800,8 +3820,7 @@ proc check_effective_target_sync_int_lon
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
- || [istarget sparc64-*-*]
- || [istarget sparcv9-*-*]
+ || ([istarget sparc*-*-*] [check_effective_target_sparc_v9])
|| [check_effective_target_mips_llsc] } {
set et_sync_int_long_saved 1
}
@@ -3830,8 +3849,7 @@ proc check_effective_target_sync_char_sh
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
- || [istarget sparc64-*-*]
- || [istarget sparcv9-*-*]
+ || ([istarget sparc*-*-*] [check_effective_target_sparc_v9])
|| [check_effective_target_mips_llsc] } {
set et_sync_char_short_saved 1
}
[patch] Emit variable as size attribute in debug info
Hi,
in Ada record (structure) types can have a variable size and, in this case, the
debug info contains -1 as size attribute for the type. While the long term
plan is to support general expressions as size attribute, a small step forward
is to accept simple variables, which is an important subcase for GNAT.
Tested on x86_64-suse-linux, OK for the mainline?
2012-04-09 Eric Botcazou ebotca...@adacore.com
* dwarf2out.c (add_byte_size_attribute) RECORD_TYPE: Handle variable
reference as size attribute.
--
Eric Botcazou
Index: dwarf2out.c
===
--- dwarf2out.c (revision 186176)
+++ dwarf2out.c (working copy)
@@ -15729,6 +15729,7 @@ add_subscript_info (dw_die_ref type_die,
static void
add_byte_size_attribute (dw_die_ref die, tree tree_node)
{
+ dw_die_ref decl_die;
unsigned size;
switch (TREE_CODE (tree_node))
@@ -15740,6 +15741,12 @@ add_byte_size_attribute (dw_die_ref die,
case RECORD_TYPE:
case UNION_TYPE:
case QUAL_UNION_TYPE:
+ if (TREE_CODE (TYPE_SIZE_UNIT (tree_node)) == VAR_DECL
+ (decl_die = lookup_decl_die (TYPE_SIZE_UNIT (tree_node
+ {
+ add_AT_die_ref (die, DW_AT_byte_size, decl_die);
+ return;
+ }
size = int_size_in_bytes (tree_node);
break;
case FIELD_DECL:
[RFC] Unconditionally clean up CFG before emitting prologue
Hi,
with the numerous checks generated in Ada, the gimplification process can
generated dead branches that aren't easily eliminated at -O0 and can impair
the debugging experience. We have found that unconditionally cleaning up the
CFG before emitting the prologue/epilogue can help in some cases. This is the
same idiom already used in rest_of_handle_jump2 for example.
Tested on x86_64-suse-linux. Comments?
2012-04-09 Eric Botcazou ebotca...@adacore.com
* function.c (rest_of_handle_thread_prologue_and_epilogue): Clean up
the CFG before generating prologue/epilogue even when not optimizing.
--
Eric Botcazou
Index: function.c
===
--- function.c (revision 186176)
+++ function.c (working copy)
@@ -6877,8 +6877,7 @@ struct rtl_opt_pass pass_leaf_regs =
static unsigned int
rest_of_handle_thread_prologue_and_epilogue (void)
{
- if (optimize)
-cleanup_cfg (CLEANUP_EXPENSIVE);
+ cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0);
/* On some machines, the prologue and epilogue code, or parts thereof,
can be represented as RTL. Doing so lets us schedule insns between
[PATCH, i386]: Fix PR 52883, ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
Hello!
As pointed out by Eric, there is this little detail in the
documentation w.r.t sign and zero-extending conversions:
For all conversion operations, X must not be `VOIDmode' because the
mode in which to do the conversion would not be known. The conversion
must either be done at compile-time or X must be placed into a register.
Taking this into account, the fix is straightforward. We have to
prevent VOIDmode immediates from entering ZERO_EXTEND RTX.
2012-04-09 Uros Bizjak ubiz...@gmail.com
PR target/52883
* config/i386/predicates.md (x86_64_zext_general_operand): Prevent
VOIDmode immediate operands.
* config/i386/constraints.md (Wz): New constraint.
* config/i386/i386.md (*zero_extendsidi2_rex64): Use Wz instead of Z.
testsuite/ChangeLog:
2012-04-09 Uros Bizjak ubiz...@gmail.com
PR target/52883
* gcc.target/i386/pr52883.c: New testcase.
Patch was tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 186236)
+++ config/i386/i386.md (working copy)
@@ -3393,10 +3393,10 @@
(define_insn *zero_extendsidi2_rex64
[(set (match_operand:DI 0 nonimmediate_operand
- =r ,o,?*Ym,?*y,?*Yi,!*x)
+ =r ,o,?*Ym,?*y,?*Yi,!*x)
(zero_extend:DI
(match_operand:SI 1 x86_64_zext_general_operand
- rmZ,0,r ,m ,r ,m*x)))]
+ rmWz,0,r ,m ,r ,m*x)))]
TARGET_64BIT
@
mov{l}\t{%1, %k0|%k0, %1}
Index: config/i386/constraints.md
===
--- config/i386/constraints.md (revision 186236)
+++ config/i386/constraints.md (working copy)
@@ -18,7 +18,7 @@
;; http://www.gnu.org/licenses/.
;;; Unused letters:
-;;; B H T W
+;;; B H T
;;; h k v
;; Integer register constraints.
@@ -199,6 +199,16 @@
instructions).
(match_operand 0 x86_64_immediate_operand))
+;; We use W prefix to denote any number of
+;; constant-or-symbol-reference constraints
+
+(define_constraint Wz
+ 32-bit unsigned integer constant, or a symbolic reference known
+ to fit that range (for zero-extending conversion operations that
+ require non-VOIDmode immediate operands).
+ (and (match_operand 0 x86_64_zext_immediate_operand)
+ (match_test GET_MODE (op) != VOIDmode)))
+
(define_constraint Z
32-bit unsigned integer constant, or a symbolic reference known
to fit that range (for immediate operands in zero-extending x86-64
Index: config/i386/predicates.md
===
--- config/i386/predicates.md (revision 186236)
+++ config/i386/predicates.md (working copy)
@@ -341,11 +341,13 @@
(match_operand 0 general_operand)))
;; Return true if OP is general operand representable on x86_64
-;; as zero extended constant.
+;; as zero extended constant. This predicate is used in zero-extending
+;; conversion operations that require non-VOIDmode immediate operands.
(define_predicate x86_64_zext_general_operand
(if_then_else (match_test TARGET_64BIT)
(ior (match_operand 0 nonimmediate_operand)
-(match_operand 0 x86_64_zext_immediate_operand))
+(and (match_operand 0 x86_64_zext_immediate_operand)
+ (match_test GET_MODE (op) != VOIDmode)))
(match_operand 0 general_operand)))
;; Return true if OP is general operand representable on x86_64
Index: testsuite/gcc.target/i386/pr52883.c
===
--- testsuite/gcc.target/i386/pr52883.c (revision 0)
+++ testsuite/gcc.target/i386/pr52883.c (revision 0)
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options -O } */
+
+int a, b, d, e, f, i, j, k, l, m;
+unsigned c;
+int g[] = { }, h[0];
+
+int
+fn1 () {
+ return 0;
+}
+
+void
+fn2 () {
+ c = 0;
+ e = 0;
+ for (;; e = 0)
+if (f j) {
+ k = fn1 ();
+ l = (d || k) * b;
+ m = l * a;
+ h[0] = m = i;
+} else
+ i = g[c];
+}
[C/ObjC/C++/ObjC++] cleanup diagnostics initialization
This patch cleans up the diagnostic initialization of the C-family FEs. It keeps the default of no line-wrapping. It moves together all initializations and deletes code that has no effect. Bootstrapped and regression tested on x86-unknown-linux-gnu with enable-languages=all,ada,obj-c++. OK? 2012-04-09 Manuel López-Ibáñez m...@gcc.gnu.org * doc/invoke.texi (fmessage-length): New. * pretty-print.h (getenv_columns): New. * c-objc-common.c (c_objc_common_init): Do not do diagnostics initialization here. c-family/ * c-opts.c (c_common_initialize_diagnostics): Rename as c_common_diagnostics_defaults. Set defaults here. * c-common.h (c_common_initialize_diagnostics): Likewise. cp/ * cp-objcp-common.c (cxx_initialize_diagnostics): Move from here to ... * error.c: ... here. (init_error): Delete. * cp-tree.h (init_error): Delete. * lex.c (cxx_init): Do not call init_error. * cxx-pretty-print.c (pp_cxx_pretty_printer_init): Do not set default message length here. diagnostic-init.diff Description: Binary data
Re: [PATCH] Fix PR52614
On Fri, Apr 6, 2012 at 12:15 AM, Ian Lance Taylor i...@google.com wrote: Richard Guenther richard.guent...@gmail.com writes: On Thu, Apr 5, 2012 at 6:22 AM, Mike Stump mikest...@comcast.net wrote: On Apr 4, 2012, at 7:56 PM, William J. Schmidt wrote: There seems to be tacit agreement that the vector tests should use -fno-common on all targets to avoid the recent spate of failures (see discussion in 52571 and 52603). OK for trunk? Ok. Any other solution I think will be real work and we shouldn't loose the testing between now and then by not having the test cases working. Ian, you are the source of all of these problems. While I did not notice any degradations in SPEC (on x86) with handling commons correctly now, the fact that our testsuite needs -fno-common to make things vectorizable shows that users might be impacted negatively by this, which is only a real problem in corner cases. Why can the link editor not promote the definitions alignment when merging with a common with bigger alignment? The defined symbol will be embedded in a data section along with other defined data symbols, at some offset O from the start of the section. The data section will have a required alignment A. It is entirely possible that there is no way to honor A and also ensure that A+O is aligned as requested by the common symbol. This whole issue only applies to vectorization involving global symbols defined with no initializer in C, when vectorization requires an alignment greater than that implied by the type of the symbol. It does not affect function arguments or local variables. It does not affect C++. Is vectorization of uninitialized global symbols really a common case? Another approach we could use is to say that when the vectorizer wants to increase the alignment of a common symbol, it would force the symbol to be defined rather than common. That would be safe, as it would lead to a multiple-definition error at link time in cases where it would be unsafe. I would be fine with making the compiler work that way for C, although of course there would have to be an option to disable it. That would work fine at least with LTO - though I'm not sure the linker-plugin gives enough feedback that a common is not overridden by an external definition. Maybe it would be a good idea to promote all commons to definitions with LTO (where possible, of course). I don't know enough about Fortran to know whether the same issues arise there. Perhaps in Fortran a common symbol is always a common symbol and can never be a defined symbol. If that is the case then for Fortran I think it would be safe to change the alignment of the common symbol. Of course we would need to have some way to indicate that in the middle-end--DECL_ALWAYS_COMMON or something. I don't know either. OTOH commons are records, so the vectorizer cannot change alignment of a common sub-variable - so in this case it would be better if the frontend would align the common to BIGGEST_ALIGNMENT or so. Richard. Ian
Re: [C/ObjC/C++/ObjC++] cleanup diagnostics initialization
On Mon, Apr 9, 2012 at 5:12 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: This patch cleans up the diagnostic initialization of the C-family FEs. It keeps the default of no line-wrapping. It moves together all initializations and deletes code that has no effect. Bootstrapped and regression tested on x86-unknown-linux-gnu with enable-languages=all,ada,obj-c++. OK? 2012-04-09 Manuel López-Ibáñez m...@gcc.gnu.org * doc/invoke.texi (fmessage-length): New. This ChangeLog description should be Update; not New. * pretty-print.h (getenv_columns): New. * c-objc-common.c (c_objc_common_init): Do not do diagnostics initialization here. c-family/ * c-opts.c (c_common_initialize_diagnostics): Rename as c_common_diagnostics_defaults. Set defaults here. * c-common.h (c_common_initialize_diagnostics): Likewise. Make the comment less personal; we don't who I is in I'm putting them here in three months (nor should we have to know.) I suggest to just remove that comment. cp/ * cp-objcp-common.c (cxx_initialize_diagnostics): Move from here to ... * error.c: ... here. Replace the free with XDELETE, to match usage elsewhere. (init_error): Delete. This deletion moves the initialization of cxx_pp to cxx_initialize_diagnostics. That is the wrong place. As the comment says, cxx_pp is not for diagnostics, so it should be initialized separately -- if possible as early as possible. * cp-tree.h (init_error): Delete. * lex.c (cxx_init): Do not call init_error. this should still call a routine that initializes cxx_pp. * cxx-pretty-print.c (pp_cxx_pretty_printer_init): Do not set default message length here.
Re: [C11-atomic] [patch] gimple atomic statements
On Fri, Apr 6, 2012 at 10:13 AM, Richard Sandiford rdsandif...@googlemail.com wrote: Richard Guenther richard.guent...@gmail.com writes: They can affect shared memory in some ways like a call, but don't have many of the other attributes of call. They are really more like an assignment or other operation with arbitrary shared memory side effects. I do hope to be able to teach the optimizers the directionality of the memory model restrictions. ie, ACQUIRE is only a barrier to hoisting shared memory code... stores can be moved downward past this mode. RELEASE is only a barrier to sinking code. RELAXED is no barrier at all to code motion. In fact, a relaxed store is barely different than a real store... but there is a slight difference so we can't make it a normal store :-P. By teaching the other parts of the compiler about a GIMPLE_ ATOMIC, we could hopefully lessen their impact eventually. Ok. I suppose having a GIMPLE_ATOMIC is fine then. Just for my own education really, but: does this mean that there'd be unnecessary pessimisation in representing the thing as a call? No, there are not. They are more pessimized than GIMPLE_ASSIGNs (unless you handle them specially in a few places). But the same is true for GIMPLE_ATOMIC. The question is one of convenience as far as I understand. In general I would like to avoid new GIMPLE codes, especially random ones. You can do everything with builtins or internal functions just fine. The interleaved load/store internal fns are really assignments too, so if calls aren't right for that kind of operation, maybe we need to replace the internal fns with something else. Or at least come up with some new call properties. What missed optimizations do you see? Which is a roundabout way of wondering what the main difficulties would be in attaching things like directionality to a call. Directionality? Not arguing for anything here, just an onlooker wanting to understand. :-) (BTW, it sounds like restricting memory accesses to GIMPLE_ASSIGN might cause trouble for the interleave load/store stuff too.) Well. In the end my plan was to have a GIMPLE_LOAD and GIMPLE_STORE stmt, where the load would load to an SSA name and the store would store from a constant or an SSA name. Advantages would be simplified data-flow analysis and things like aggregate copy propagation and value-numbering for free. It would also be easier to attach special data / properties to the now single load / store sites (where in calls you can have an arbitrary number of loads at least). Whatever special property the interleaved load/store has would be stored there, too. The idea was to be able to fold most of the implicit information about loads/stores that are in the MEM_REF /COMPONENT_REF / ARRAY_REF trees into proper gimple level information, like having an array of index, stride tuples for (multidimensional) array accesses. Think of it like a place where we can properly embed the MEM_ATTRs we have on the RTL side for example. That's much easier if there were loads/stores only in very defined places. Richard.
Re: [PR51570] minimize ENTRY_VALUEs in debug location lists
On Mon, Apr 09, 2012 at 02:50:02AM -0300, Alexandre Oliva wrote: for gcc/ChangeLog from Alexandre Oliva aol...@redhat.com PR debug/51570 * var-tracking.c (expand_depth): New type. (onepart_aux, expand_loc_callback_data): Change depth type to it. (loc_exp_dep_alloc): Adjust initializer. (update_depth): Use new type. Add entryvals. (vt_expand_var_loc_chain): Take note of expansions with ENTRY_VALUEs, but don't accept them right away. Run an optional second pass accepting the minimum ENTRY_VALUE count found in the first pass. (vt_expand_loc_callback, INIT_ELCD): Adjust. Ok for trunk, thanks. Jakub
Re: Mirror gcc/contrib - src/contrib? [was Re: [patch, gcc RFA] dg-extract-results.sh: Handle KFAILs.]
Doug == Doug Evans d...@google.com writes: Doug On Thu, Mar 15, 2012 at 11:54 AM, Mike Stump mikest...@comcast.net wroteDoug btw, is there any interest in mirroring gcc/contrib - src/contrib? Doug [instead of gdb having its own copy in gdb/testsuite, it *could* use Doug the one in, e.g., src/contrib. I don't have a strong opinion. I'm Doug just looking for others opinions, as the topic came up in another Doug context.] I wouldn't mind if anything else there was useful for gdb. Tom
Re: Mirror gcc/contrib - src/contrib? [was Re: [patch, gcc RFA] dg-extract-results.sh: Handle KFAILs.]
On Mon, Apr 9, 2012 at 7:43 AM, Tom Tromey tro...@redhat.com wrote: Doug == Doug Evans d...@google.com writes: Doug On Thu, Mar 15, 2012 at 11:54 AM, Mike Stump mikest...@comcast.net wroteDoug btw, is there any interest in mirroring gcc/contrib - src/contrib? Doug [instead of gdb having its own copy in gdb/testsuite, it *could* use Doug the one in, e.g., src/contrib. I don't have a strong opinion. I'm Doug just looking for others opinions, as the topic came up in another Doug context.] I wouldn't mind if anything else there was useful for gdb. There's testsuite-management/validate_failures.py which is useful here. Whether it's useful to the FSF or Redhat trees, I don't know. I can't put in the time to do all the administrivia to make this happen (and keep it working, e.g., impose something like making sure people follow the same rules as libiberty so the trees stay in sync), so I don't want to send people down this path unless there's sufficient support, and someone else to do the work.
Re: Mirror gcc/contrib - src/contrib? [was Re: [patch, gcc RFA] dg-extract-results.sh: Handle KFAILs.]
On Fri, 6 Apr 2012, Doug Evans wrote: btw, is there any interest in mirroring gcc/contrib - src/contrib? [instead of gdb having its own copy in gdb/testsuite, it *could* use the one in, e.g., src/contrib. I don't have a strong opinion. I'm just looking for others opinions, as the topic came up in another context.] Looking at gcc/contrib, there is a lot of stuff there which does not seem applicable to other projects. Not sure I'd just mirror all that... Gerald
Re: [RFC] Unconditionally clean up CFG before emitting prologue
Isn't the gimple cfg-cleanup we run post optimization (right before expansion) not enough? Or the cfg-cleanup we perform right after expansion now? At least if the branches are really caused by the gimplification process I would expect things to be cleaned up at this point, no? At least the patch has a non-null (albeit minor) effect, which pertains mainly to jump threading (typical diff attached, Ada code at -O0 on x86-64). -- Eric Botcazou @@ -648,7 +648,6 @@ jmp .L70 .L206: nop -.L71: leaq -768(%rbp), %rax addq $448, %rax movq %rax, %rdi @@ -1107,7 +1106,6 @@ .LEHE34: cmpl $1, %ebx jne .L197 -.L93: movq 16(%rbp), %rax movzbl 186(%rax), %eax testb %al, %al @@ -1398,7 +1396,6 @@ call prime__worlds_secondary_greeks__compute_secondary_greeks__B68b___finalizer.3706 cmpl $1, %ebx jne .L198 -.L112: cmpb $0, -3925(%rbp) je .L113 movq 16(%rbp), %rax @@ -1672,14 +1669,14 @@ .L204: movq -4000(%rbp), %rax movq -4008(%rbp), %rdx - jmp .L151 + jmp .L156 .L186: movq %rax, %rcx movq %rdx, %rax cmpq $6, %rax je .L154 movq %rcx, %rax - jmp .L151 + jmp .L156 .L154: movq %rcx, -96(%rbp) movq -96(%rbp), %rax @@ -1712,7 +1709,6 @@ je .L67 jmp .L204 .L185: -.L151: jmp .L156 .L191: movq %rax, -4024(%rbp) @@ -1773,9 +1769,8 @@ .L197: movq -4016(%rbp), %rax movq -4032(%rbp), %rdx - jmp .L166 + jmp .L156 .L192: -.L166: jmp .L156 .L193: movq %rax, -4048(%rbp) @@ -1838,9 +1833,8 @@ jmp .L70 .L117: movq %r15, %rax - jmp .L173 + jmp .L174 .L196: -.L173: jmp .L174 .L175: .L174: @@ -2510,7 +2504,6 @@ jmp .L253 .L286: nop -.L254: movq 24(%rbp), %rax movzbl 101(%rax), %eax testb %al, %al @@ -2578,12 +2571,12 @@ .L285: movq %r14, %rax movq %r15, %rdx - jmp .L264 + jmp .L269 .L278: movq %rdx, %rcx cmpq $2, %rcx je .L267 - jmp .L264 + jmp .L269 .L267: movq %rax, -56(%rbp) movq -56(%rbp), %rax @@ -2617,7 +2610,6 @@ je .L250 jmp .L285 .L277: -.L264: jmp .L269 .L283: movq %rax, %rbx
[Patch, Fortran, F03] PR52909: Procedure pointers not private to modules
Hi all, here is a simple patch for a problem recently reported by Andrew Benson: Procedure pointers inside a module don't receive the proper name mangling, which can lead to name collisions (as the test case demonstrates). The patch fixes this and regtests cleanly on x86_64-unknown-linux-gnu. I am aware that it will break the ABI, but only for programs involving procedure pointers (which still is a 'relatively' new feature, supported since gfortran 4.4). So, ok for trunk? Btw, speaking of ABI breaking: What are the chances of the array descriptor update and ABI cleanup happening for the 4.8 release? I know such an ABI breaking has been planned for some time, but I haven't followed the gfortran mailing list in detail during the last weeks and months, so I'm not sure what the current status is. Cheers, Janus 2012-04-09 Janus Weil ja...@gcc.gnu.org PR fortran/52909 * trans-decl.c (get_proc_pointer_decl): Apply name mangling. 2012-04-09 Janus Weil ja...@gcc.gnu.org PR fortran/52909 * gfortran.dg/proc_ptr_37.f90: New test case. pr52909.diff Description: Binary data proc_ptr_37.f90 Description: Binary data
Re: Support for Runtime CPU type detection via builtins (issue5754058)
On Sun, Apr 8, 2012 at 6:17 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
On Thu, 29 Mar 2012, Sriraman Tallam wrote:
Hi,
I have made a new patch to only have two builtins :
* __builtin_cpu_is (CPUNAME)
* __builtin_cpu_supports (FEATURE)
apart from the cpu init builtin, __builtin_cpu_init.
I don't see any .texi file as part of this change. Shouldn't this
be documented (and also added to the release notes gcc-4.8/changes.html)?
I modified extend.texi for documenting the builtins. I guess you
missed it. I am reattaching the patch just in case.
List of CPU names :
* amd
* intel
Are company names really suitable here? Intel is also still producing
ia64 aka Itanium, and in the future AMD might do some ARM-based designs.
AMD64 and Intel64 might work.
This is basically the vendor info from CPUID. I dont mind changing it
but I do not understand why Intel or AMD is unsuitable.
Gerald
* config/i386/i386.c (build_processor_features_struct): New function.
(build_processor_model_struct): New function.
(make_var_decl): New function.
(get_field_from_struct): New function.
(fold_builtin_target): New function.
(ix86_fold_builtin): New function.
(ix86_expand_builtin): Expand new builtins by folding them.
(make_cpu_type_builtin): New functions.
(ix86_init_platform_type_builtins): Make the new builtins.
(ix86_init_builtins): Make new builtins to detect CPU type.
(TARGET_FOLD_BUILTIN): New macro.
(IX86_BUILTIN_CPU_INIT): New enum value.
(IX86_BUILTIN_CPU_IS): New enum value.
(IX86_BUILTIN_CPU_SUPPORTS): New enum value.
* config/i386/i386-builtin-types.def: New function type.
* testsuite/gcc.target/builtin_target.c: New testcase.
* doc/extend.texi: Document builtins.
* libgcc/config/i386/i386-cpuinfo.c: New file.
* libgcc/config/i386/t-cpuinfo: New file.
* libgcc/config.host: Include t-cpuinfo.
* libgcc/config/i386/libgcc-glibc.ver: Version symbols __cpu_model
and __cpu_features.
Index: libgcc/config.host
===
--- libgcc/config.host (revision 185898)
+++ libgcc/config.host (working copy)
@@ -1130,7 +1130,7 @@ i[34567]86-*-linux* | x86_64-*-linux* | \
i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
i[34567]86-*-knetbsd*-gnu | \
i[34567]86-*-gnu*)
- tmake_file=${tmake_file} t-tls i386/t-linux
+ tmake_file=${tmake_file} t-tls i386/t-linux i386/t-cpuinfo
if test $libgcc_cv_cfi = yes; then
tmake_file=${tmake_file} t-stack i386/t-stack-i386
fi
Index: libgcc/config/i386/t-cpuinfo
===
--- libgcc/config/i386/t-cpuinfo(revision 0)
+++ libgcc/config/i386/t-cpuinfo(revision 0)
@@ -0,0 +1 @@
+LIB2ADD += $(srcdir)/config/i386/i386-cpuinfo.c
Index: libgcc/config/i386/i386-cpuinfo.c
===
--- libgcc/config/i386/i386-cpuinfo.c (revision 0)
+++ libgcc/config/i386/i386-cpuinfo.c (revision 0)
@@ -0,0 +1,298 @@
+/* Get CPU type and Features for x86 processors.
+ Copyright (C) 2012 Free Software Foundation, Inc.
+ Contributed by Sriraman Tallam (tmsri...@google.com)
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+http://www.gnu.org/licenses/. */
+
+#include cpuid.h
+#include tsystem.h
+
+int __cpu_indicator_init (void) __attribute__ ((constructor (101)));
+
+enum vendor_signatures
+{
+ SIG_INTEL = 0x756e6547 /* Genu */,
+ SIG_AMD =0x68747541 /* Auth */
+};
+
+/* ISA Features supported. */
+
+struct __processor_features
+{
+ unsigned int __cpu_cmov : 1;
+ unsigned int __cpu_mmx : 1;
+ unsigned int __cpu_popcnt : 1;
+ unsigned int __cpu_sse : 1;
+ unsigned int __cpu_sse2 : 1;
+ unsigned int __cpu_sse3 : 1;
+ unsigned int __cpu_ssse3 : 1;
+ unsigned int __cpu_sse4_1 : 1;
+ unsigned int __cpu_sse4_2 : 1;
+} __cpu_features;
+
+/* Processor Vendor and Models. */
+
+enum processor_vendor
+{
+ VENDOR_INTEL = 1,
+ VENDOR_AMD,
+ VENDOR_MAX
+};
+
+enum processor_types
+{
+ INTEL_ATOM = 1,
+ INTEL_CORE2,
+ INTEL_COREI7,
+ AMDFAM10H,
+ AMDFAM15H,
+ CPU_TYPE_MAX
+};
+
+enum processor_subtypes
+{
+ INTEL_COREI7_NEHALEM,
+ INTEL_COREI7_WESTMERE,
+ INTEL_COREI7_SANDYBRIDGE,
+ AMDFAM10H_BARCELONA,
+ AMDFAM10H_SHANGHAI,
+
Re: [C/ObjC/C++/ObjC++] cleanup diagnostics initialization
On Mon, Apr 9, 2012 at 6:19 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: On 9 April 2012 12:43, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Mon, Apr 9, 2012 at 5:12 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: * c-common.h (c_common_initialize_diagnostics): Likewise. Make the comment less personal; we don't who I is in I'm putting them here in three months (nor should we have to know.) I suggest to just remove that comment. That comment has been there for ages, I just moved it around. But I am happy to remove it. yes, thanks. This deletion moves the initialization of cxx_pp to cxx_initialize_diagnostics. That is the wrong place. As the comment says, cxx_pp is not for diagnostics, so it should be initialized separately -- if possible as early as possible. * cp-tree.h (init_error): Delete. * lex.c (cxx_init): Do not call init_error. this should still call a routine that initializes cxx_pp. Where? Maybe in a dedicated function called construct_cxx_pp(), called from cxx_init? cxx_initialize_diagnostics is run earlier than cxx_init, so it is now initialized earlier than before. Moreover, by putting both together, it is clear to anyone that there are two pretty-printers, and the comment clarifies what the second is for. I understand that init_error means initialize_error routines, and indeed it contained code initializing diagnostics. since it has nothing to do with diagnostics, it is better not to place its initialization there. Otherwise, in 3 months somewhere will come and complain that the diagnostics and pretty printers are hard to debug etc ;-) However, if the above does not convince you. What about renaming init_error to cxx_pp_init, and move the cxx_pp initialization there so it is clear that this function is ONLY to initialize cxx_pp and not for anything else? that or the suggestion above. Is the patch OK with the above changes? I appreciate your impatience but I would like to look at the revised version first.
Re: [wwwdocs] Minor tweak to release branch status descriptions
On Mon, Apr 9, 2012 at 3:47 PM, Gerald Pfeifer ger...@pfeifer.com wrote: Release managers, On Sun, 11 Sep 2011, Gerald Pfeifer wrote: I'd like to make the change below which helps with lower resolution systems (or non-maximized web browsers) or larger font sizes. Practically I think everyone would understand the new version is the same as the old, and the official status links usually are more explicit, but still -- any objections from the RMs? what is your take on this? Updated patch below. Works for me. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.848 diff -u -3 -p -r1.848 index.html --- index.html 22 Mar 2012 09:58:00 - 1.848 +++ index.html 9 Apr 2012 13:46:56 - @@ -140,7 +140,7 @@ Any additions? Don't be shy, send them !--GCC 4.7 status below-- a href=http://gcc.gnu.org/ml/gcc/2012-03/msg00345.html;2012-03-14/a !--GCC 4.7 status above-- - (regression fixes and docs only). + (regression fixes and docs). br / span class=regress a @@ -159,7 +159,7 @@ Any additions? Don't be shy, send them !--GCC 4.6 status below-- a href=http://gcc.gnu.org/ml/gcc/2012-03/msg6.html;2012-03-01/a !--GCC 4.6 status above-- - (regression fixes and docs only). + (regression fixes and docs). br / span class=regress a @@ -179,7 +179,7 @@ Any additions? Don't be shy, send them !--GCC 4.5 status below-- a href=http://gcc.gnu.org/ml/gcc/2011-04/msg00412.html;2011-04-29/a !--GCC 4.5 status above-- - (regression fixes and docs only). + (regression fixes and docs). span class=regress br / a
Fix partitioning of aliases
Hi,
this patch fixes several different ICEs related to handling aliases in WHOPR
partitioning. It took me over week debug this, but when variable alias
is added to a boundary and its destination is not added, we get queue of
unforutnate events where the destinatoin gets analyzed and added at ltrans time
resulting in interesting miscompilation seen at Mozilla with some vtables.
The problem is that constructor won't get streamed when the declaration is
not in varpool at partitioning time and thus once the variable is re-added
it has zero constructor.
Of course the problem manifests itself in various weird ways depending
on ordering of linker command maing it very difficult to reduce anything.
While working on this I also noticed that PR 52634 is about related problem
where aliases are incorectly partitioned into multiple partitions.
The patch also fixes the varpool ICEs mentioned in the other two PRs.
I failed to produce testcase version of PR52722 testcase, since it does not
link now either, but it won't ICE.
I will commit the patch and wait for some time, but I would like to backport
it to 4.7, since it solves quite nasty misoptimization problem.
At mainline after this patch i would like to follow with series of cleanups
and API changes I have in queue for symtab work.
Honza
PR lto/52722
PR lto/51765
PR lto/52634
* lto-cgraph.c (compute_ltrans_boundary): When alias is in the boundary,
add its target too.
* lto.c (add_references_to_partition): Add also aliased nodes.
(add_cgraph_node_to_partition,
add_varpool_node_to_partition): Work on nodes, not functions/variables;
when adding alias, add also the aliased object.
* gcc.dg/lto/pr52634_1.c: New testcase.
* gcc.dg/lto/pr52634_0.c: New testcase.
Index: lto-cgraph.c
===
*** lto-cgraph.c(revision 185767)
--- lto-cgraph.c(working copy)
*** compute_ltrans_boundary (struct lto_out_
*** 799,804
--- 799,806
lto_set_varpool_encoder_encode_initializer (varpool_encoder, vnode);
add_references (encoder, varpool_encoder, vnode-ref_list);
}
+ else if (vnode-alias || vnode-alias_of)
+ add_references (encoder, varpool_encoder, vnode-ref_list);
}
/* Go over all the nodes again to include callees that are not in
Index: lto/lto.c
===
*** lto/lto.c (revision 185767)
--- lto/lto.c (working copy)
*** free_ltrans_partitions (void)
*** 1444,1450
VEC_free (ltrans_partition, heap, ltrans_partitions);
}
! /* See all references that go to comdat objects and bring them into partition
too. */
static void
add_references_to_partition (ltrans_partition part, struct ipa_ref_list *refs)
{
--- 1444,1451
VEC_free (ltrans_partition, heap, ltrans_partitions);
}
! /* See all references that go to comdat objects and bring them into partition
too.
!Also see all aliases of the newly added entry and bring them, too. */
static void
add_references_to_partition (ltrans_partition part, struct ipa_ref_list *refs)
{
*** add_references_to_partition (ltrans_part
*** 1453,1467
for (i = 0; ipa_ref_list_reference_iterate (refs, i, ref); i++)
{
if (ref-refered_type == IPA_REF_CGRAPH
! DECL_COMDAT (cgraph_function_node (ipa_ref_node (ref), NULL)-decl)
!cgraph_node_in_set_p (ipa_ref_node (ref), part-cgraph_set))
add_cgraph_node_to_partition (part, ipa_ref_node (ref));
else
if (ref-refered_type == IPA_REF_VARPOOL
!DECL_COMDAT (ipa_ref_varpool_node (ref)-decl)
!!varpool_node_in_set_p (ipa_ref_varpool_node (ref),
part-varpool_set))
add_varpool_node_to_partition (part, ipa_ref_varpool_node (ref));
}
}
/* Worker for add_cgraph_node_to_partition. */
--- 1454,1498
for (i = 0; ipa_ref_list_reference_iterate (refs, i, ref); i++)
{
if (ref-refered_type == IPA_REF_CGRAPH
! (DECL_COMDAT (cgraph_function_node (ipa_ref_node (ref),
! NULL)-decl)
! || (ref-use == IPA_REF_ALIAS
! lookup_attribute
! (weakref, DECL_ATTRIBUTES (ipa_ref_node (ref)-decl
!cgraph_node_in_set_p (ipa_ref_node (ref), part-cgraph_set))
add_cgraph_node_to_partition (part, ipa_ref_node (ref));
else
if (ref-refered_type == IPA_REF_VARPOOL
!(DECL_COMDAT (ipa_ref_varpool_node (ref)-decl)
! || (ref-use == IPA_REF_ALIAS
!lookup_attribute
!(weakref,
! DECL_ATTRIBUTES (ipa_ref_varpool_node (ref)-decl
!!varpool_node_in_set_p (ipa_ref_varpool_node (ref),
! part-varpool_set))
Re: [v3] fix libstdc++/52476
Attached patch applied to 4_7-branch.
2012-04-09 François Dumont fdum...@gcc.gnu.org
PR libstdc++/52476
* include/bits/hashtable.h (_Hashtable::_M_rehash_aux): Add.
(_Hashtable::_M_rehash): Use the latter.
* testsuite/23_containers/unordered_multimap/insert/52476.cc: New.
* testsuite/23_containers/unordered_multiset/insert/52476.cc: New.
Tested under linux x86_64.
I don't think I have the necessary rights to close the PR on bugzilla, I
haven't been able to do so.
François
On 04/02/2012 12:12 AM, Paolo Carlini wrote:
Hi,
Attached patch applied.
2012-03-16 François Dumont fdum...@gcc.gnu.org
PR libstdc++/52476
* include/bits/hashtable.h (_Hashtable::_M_rehash_aux): Add.
(_Hashtable::_M_rehash): Use the latter.
* testsuite/23_containers/unordered_multimap/insert/52476.cc:
New.
* testsuite/23_containers/unordered_multiset/insert/52476.cc:
New.
Francois, at your ease, I think it's time to apply the fix to
4_7-branch too and resolve the PR. By the way, Daniel confirmed in
private email that mainline works just fine now.
Thanks,
Paolo.
Index: include/bits/hashtable.h
===
--- include/bits/hashtable.h (revision 186244)
+++ include/bits/hashtable.h (working copy)
@@ -596,6 +596,12 @@
// reserve, if present, comes from _Rehash_base.
private:
+ // Helper rehash method used when keys are unique.
+ void _M_rehash_aux(size_type __n, std::true_type);
+
+ // Helper rehash method used when keys can be non-unique.
+ void _M_rehash_aux(size_type __n, std::false_type);
+
// Unconditionally change size of bucket array to n, restore hash policy
// state to __state on exception.
void _M_rehash(size_type __n, const _RehashPolicyState __state);
@@ -1592,41 +1598,145 @@
{
__try
{
- _Bucket* __new_buckets = _M_allocate_buckets(__n);
- _Node* __p = _M_begin();
- _M_before_begin._M_nxt = nullptr;
- std::size_t __cur_bbegin_bkt;
- while (__p)
+ _M_rehash_aux(__n, integral_constantbool, __uk());
+ }
+ __catch(...)
+ {
+ // A failure here means that buckets allocation failed. We only
+ // have to restore hash policy previous state.
+ _M_rehash_policy._M_reset(__state);
+ __throw_exception_again;
+ }
+}
+
+ // Rehash when there is no equivalent elements.
+ templatetypename _Key, typename _Value,
+ typename _Allocator, typename _ExtractKey, typename _Equal,
+ typename _H1, typename _H2, typename _Hash, typename _RehashPolicy,
+ bool __chc, bool __cit, bool __uk
+void
+_Hashtable_Key, _Value, _Allocator, _ExtractKey, _Equal,
+ _H1, _H2, _Hash, _RehashPolicy, __chc, __cit, __uk::
+_M_rehash_aux(size_type __n, std::true_type)
+{
+ _Bucket* __new_buckets = _M_allocate_buckets(__n);
+ _Node* __p = _M_begin();
+ _M_before_begin._M_nxt = nullptr;
+ std::size_t __bbegin_bkt;
+ while (__p)
+ {
+ _Node* __next = __p-_M_next();
+ std::size_t __bkt = _HCBase::_M_bucket_index(__p, __n);
+ if (!__new_buckets[__bkt])
{
- _Node* __next = __p-_M_next();
- std::size_t __new_index = _HCBase::_M_bucket_index(__p, __n);
- if (!__new_buckets[__new_index])
+ __p-_M_nxt = _M_before_begin._M_nxt;
+ _M_before_begin._M_nxt = __p;
+ __new_buckets[__bkt] = _M_before_begin;
+ if (__p-_M_nxt)
+ __new_buckets[__bbegin_bkt] = __p;
+ __bbegin_bkt = __bkt;
+ }
+ else
+ {
+ __p-_M_nxt = __new_buckets[__bkt]-_M_nxt;
+ __new_buckets[__bkt]-_M_nxt = __p;
+ }
+ __p = __next;
+ }
+ _M_deallocate_buckets(_M_buckets, _M_bucket_count);
+ _M_bucket_count = __n;
+ _M_buckets = __new_buckets;
+}
+
+ // Rehash when there can be equivalent elements, preserve their relative
+ // order.
+ templatetypename _Key, typename _Value,
+ typename _Allocator, typename _ExtractKey, typename _Equal,
+ typename _H1, typename _H2, typename _Hash, typename _RehashPolicy,
+ bool __chc, bool __cit, bool __uk
+void
+_Hashtable_Key, _Value, _Allocator, _ExtractKey, _Equal,
+ _H1, _H2, _Hash, _RehashPolicy, __chc, __cit, __uk::
+_M_rehash_aux(size_type __n, std::false_type)
+{
+ _Bucket* __new_buckets = _M_allocate_buckets(__n);
+
+ _Node* __p = _M_begin();
+ _M_before_begin._M_nxt = nullptr;
+ std::size_t __bbegin_bkt;
+ std::size_t __prev_bkt;
+ _Node* __prev_p = nullptr;
+ bool __check_bucket = false;
+
+ while (__p)
+ {
+ bool __check_now = true;
+ _Node* __next = __p-_M_next();
+ std::size_t __bkt = _HCBase::_M_bucket_index(__p, __n);
+
+ if (!__new_buckets[__bkt])
+ {
+ __p-_M_nxt = _M_before_begin._M_nxt;
+ _M_before_begin._M_nxt = __p;
+ __new_buckets[__bkt] = _M_before_begin;
+ if (__p-_M_nxt)
+ __new_buckets[__bbegin_bkt] = __p;
+ __bbegin_bkt = __bkt;
+
Re: [PATCH] Caret diagnostics
Attached a new version of the patch: * It uses the default cutoff as max_width, whatever it is (as controlled by -fmessage-length). * It uses the pretty-printer. The text cannot (should not) wrap because we still print only max_width chars at most. * It removes unnecessary prune patterns. Bootstrapped and regression tested with languages=all,ada,obj-c++. Cheers, Manuel. 2012-04-09 Manuel López-Ibáñez m...@gcc.gnu.org PR 24985 libstdc++-v3/ * testsuite/lib/prune.exp: Handle caret. libmudflap/ * testsuite/lib/libmudflap.exp: Handle caret. gcc/ * diagnostic.h (show_caret): Declare. (diagnostic_show_locus): Declare. * diagnostic.c (diagnostic_initialize): Initialize to false. (diagnostic_show_locus): New. (diagnostic_report_diagnostic): Call it. * input.c (read_line): New. (location_get_source_line): New. * input.h (location_get_source_line): Declare. * toplev.c (general_init): Initialize show_caret from options. * dwarf2out.c (gen_producer_string): Handle fdiagnostics-show-caret. * opts.c (common_handle_option): Likewise. * pretty-print.h (pp_get_prefix): New. (pp_base_get_prefix): New. * common.opt (fdiagnostics-show-caret): New option. * doc/invoke.texi (fdiagnostics-show-caret): Document it. testsuite/ * lib/prune.exp: Add -fno-diagnostics-show-caret. caret-diagnostics-20120409.diff Description: Binary data
Re: [PATCH, RFC] Extend __attribute__((format)) with user-specified conversion sequences
Hi, thanks for the reply.
On 4/8/12 6:25 AM, Joseph S. Myers wrote:
Character pairs like this don't seem very extensible, in that you are
providing meanings for any even-length string, rather than (for example)
only a limited subset of strings leaving room for meanings to be assigned
later to other strings.
Future extensions could use identifiers rather than strings, or other
syntax, but understood.
They also have the obvious problem of not covering application-specific
types as arguments, only types that have corresponding standard formats.
Agreed.
In principle we want extensibility of format checking, and want it to be
as flexible as the built-in checking is regarding the peculiarities of
different formats - but we also don't want to export implementation
details of format checking to users' source code, and the two points seem
rather to contradict each others. So my recent inclination has been that
we should make it possible for plugins to add new format checking types
(but the details of the relevant interfaces would be unstable, so such
plugins might need to change for each GCC version). That means a function
for a plugin to register a new format type - and probably a callback
called when that format type is used for a function declaration that can
look for a typedef name in the same way that the existing GCC-internal
formats are handled.
The plugin architecture would work great for format strings that are
very different from printf/scanf, but seems heavyweight for format
strings that are close to printf/scanf.
Would a better syntax for printf/scanf + extensions format strings be
worth accepting independent of plugins?
For instance:
__attribute__(printf, 1, 1, '' ('%'), ';' ('0'))
== treat '' like '%' and ';' like '0'
__attribute__(printf, 1, 1, '' (), 'F' (expr *))
== '' takes 0 arguments, 'F' takes an expr * argument in the list
Best,
Eddie
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote: On 4 April 2012 18:54, Jakub Jelinek ja...@redhat.com wrote: If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think. The problem here that everyone !Debian isn't taking into account is that multilib paths don't solve our use-case. Multilib paths only solve the case of multiple ABIs on the same base processor family. As soon as you combine x86, arm, power, etc, you end up with overlaps (or, the potential for overlaps; the fact that various arches accidentally have different majors keeps those overlaps to a minimum right now, but that's not by design). Honestly, this is something we should have solved two decades ago, but the very idea that someone would want to do what Debian is now doing didn't occur to any of us. That's cool. We didn't think of it back then. That's no excuse to continue with the status quo just because it's the status quo. To be perfectly clear here, we don't care where the linker goes (really, we don't), we just want it to be both arch and ABI unique. If that means taking a crc32 of a rot-13 of the compiler flags used to define the ABI, and then stuffing the linker in /lib/gobbledygook/ld-linux.so, so be it. If this means setting up a (very) lightweight process with the LSB, where everytime a new distro proposes a shiny new arch/ABI, they submit it, and the LSB assigns them an ABI serial, and we all then agree to toss the linker in /lib/abi-2345/ld-linux, that works too. Don't care. Really don't care. This isn't about trying to force people to switch from multilib to multi- arch, where the former is clearly working fine for them. It's not. This is purely about people bikeshedding about paths they consider un-pretty, while (I hope not maliciously or knowingly?) causing potential overlap and breakage for those of us for whom this actually matters and isn't purely a color selection exercise. In the short term, due to sheer luck, /libhf/ld-linux.so.3 would work for us, purely because that doesn't overlap with any other linkers that Debian currently ships. The fact that the multilib path happens to work doesn't make it correct for our use-case, and certainly doesn't make it correct ongoing. Ultimately, however, I want this solved. We thought we had this solved at Plumbers last fall. To hear now that we didn't involve everyone is disheartening, given that we (we being Debian and Ubuntu) were well outnumbered in that room by people from RedHat, Fedora, ChromeOS, and Gentoo. We all agreed on something back then, and now that I'm three weeks away from shipping an armhf distro, it's all exploded yet again into Bikeshed Part III: The Revenge of Purple Paint. I really want to ship a compiler than stuffs the correct and agreed upon linker in headers. I don't want to see third parties build binaries on Ubuntu that don't run on Fedora. No one wants to see that, I think. Obviously, conversely (though this is much less hassle), I need to be able to ship a linker symlink that matches expectations, so that binaries built on Fedora will run on Ubuntu. Again, I'm sure we all want that. So, pretty please, can we (A) address the concerns here without people putting up the Unique paths are Debian trying to force multi-arch on us straw man, and (B) agree to *something*, before I ship something that conforms to a standard agreed upon more than half a year ago that is now a cause for contention? Pretty please? With sugar on top? Kthx. (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp). Yip. I assume something like /lib64 to stay consistent with other architectures. aarch64 is hard float only. I expect that most distros will probably ship their aarch64 libraries in /lib64 (Debian and Ubuntu won't, but that's fine) to keep consistent with their other 64-bit ports, but where you put libraries is entirely unrelated to where the linker lives. You could have all your libraries in /root/.trash/ and if the linker lives in a canonical location and can resolve that, that's fine. I will still (obviously, I think, from my comments above) argue that the linker should live in a guaranteed unique location. Overlap with other arches in /lib64 is certainly far more likely than overlap in /libhf. ... Adam Conrad
Re: [v3] fix libstdc++/52476
On 9 April 2012 20:25, François Dumont wrote: I don't think I have the necessary rights to close the PR on bugzilla, I haven't been able to do so. You should be able to using your @gcc.gnu.org account. What if you assign it to yourself first?
Re: Propagate profile counts after switch case expansion (issue5896043)
On Sun, Mar 25, 2012 at 9:40 PM, Easwaran Raman era...@google.com wrote: On Sun, Mar 25, 2012 at 12:22 PM, Jan Hubicka hubi...@ucw.cz wrote: This patch propagates execution count of thee case labels of a switch-case statement after its expansion. Bootstraps and all tests pass. OK for trunk? Hi, while this is resonable thing to do, I belive it would make most sense to make switch lowering at gimple level: i.e. reorganize the existing code to produce gimple statement and change expansion code to produce tablejump from every gimple switch statement that was left in the code. This would be both cleaner and would allow gimple optimizers to improve the generated code. Incrementally it would also allow us to improve switch exansion that is quite baroque and not realy producing very good code in some common cases. If you would be interested working on this (i.e. reorganizing the expansion code to produce gimple), I would be very happy. If not, I can review the profile updating part for mainline, since in any case this is desriable thing to do. I am planning to explore improvements to switch expansion (peeling some cases and using jump tables for the rest, for example) and I think the reorganization you suggest is the right way to do such improvements. But until I can spend time on it and get it done, I would like this patch to get reviewed and checked in. Thanks, Easwaran Ping.
[patch] Add generic __builtin_bswap16 support
Hi,
this adds generic support for __builtin_bswap16 (only PowerPC has it for now).
It is mapped to the bswap optab in HImode, whose implementation is as follows:
- if a bswaphi2 pattern is present (PowerPC), it is directly used; or else
- if a rotlhi2/rotrhi2 pattern is present (x86), it is directly used, or else
- if ashlxx2 lshrxx2 are present (SPARC), they are used to open-code the
operation, or else,
- if a bswapsi2 pattern is present, it is used (with a final shift), otherwise
- the bswapsi2 libcall is used (with a final shift).
Since it is expected that most architectures will fall into one of the first 3
cases, no __bswaphi2 symbol is added to libgcc. And pass_optimize_bswap isn't
modified to recognize the builtin either, as this seems overkill to me.
Tested on x86, x86-64 and PowerPC Linux, OK for the mainline?
2012-04-09 Eric Botcazou ebotca...@adacore.com
PR target/52624
* doc/extend.texi (Other Builtins): Document __builtin_bswap16.
(PowerPC AltiVec/VSX Built-in Functions): Remove it.
* builtin-types.def (BT_UINT16): New primitive type.
(BT_FN_UINT16_UINT16): New function type.
* builtins.def (BUILT_IN_BSWAP16): New.
* builtins.c (expand_builtin_bswap): Add TARGET_MODE argument.
(expand_builtin) BUILT_IN_BSWAP16: New case. Pass TARGET_MODE to
expand_builtin_bswap.
* optabs.c (expand_unop): Deal with bswap in HImode specially. Add
missing bits for bswap to libcall code.
* tree.c (build_common_tree_nodes): Build uint16_type_node.
* tree.h (enum tree_index): Add TI_UINT16_TYPE.
(uint16_type_node): New define.
* config/rs6000/rs6000-builtin.def (RS6000_BUILTIN_BSWAP_HI): Delete.
* config/rs6000/rs6000.c (rs6000_expand_builtin): Remove handling of
above builtin.
(rs6000_init_builtins): Likewise.
* config/rs6000/rs6000.md (bswaphi2): Add TARGET_POWERPC predicate.
2012-04-09 Eric Botcazou ebotca...@adacore.com
c-family/
* c-common.h (uint16_type_node): Rename into...
(c_uint16_type_node): ...this.
* c-common.c (c_common_nodes_and_builtins): Adjust for above renaming.
* c-cppbuiltin.c (builtin_define_stdint_macros): Likewise.
2012-04-09 Eric Botcazou ebotca...@adacore.com
testsuite/
* gcc.dg/builtin-bswap-1.c: Test __builtin_bswap16 __builtin_bswap64.
* gcc.dg/builtin-bswap-4.c: Test __builtin_bswap16.
* gcc.dg/builtin-bswap-5.c: Likewise.
* gcc.target/i386/builtin-bswap-4.c: New test.
--
Eric Botcazou
Index: doc/extend.texi
===
--- doc/extend.texi (revision 186176)
+++ doc/extend.texi (working copy)
@@ -8535,12 +8535,17 @@ Similar to @code{__builtin_powi}, except
are @code{long double}.
@end deftypefn
-@deftypefn {Built-in Function} int32_t __builtin_bswap32 (int32_t x)
+@deftypefn {Built-in Function} int16_t __builtin_bswap16 (int16_t x)
Returns @var{x} with the order of the bytes reversed; for example,
-@code{0xaabbccdd} becomes @code{0xddccbbaa}. Byte here always means
+@code{0xaabb} becomes @code{0xbbaa}. Byte here always means
exactly 8 bits.
@end deftypefn
+@deftypefn {Built-in Function} int32_t __builtin_bswap32 (int32_t x)
+Similar to @code{__builtin_bswap16}, except the argument and return types
+are 32-bit.
+@end deftypefn
+
@deftypefn {Built-in Function} int64_t __builtin_bswap64 (int64_t x)
Similar to @code{__builtin_bswap32}, except the argument and return types
are 64-bit.
@@ -13426,7 +13431,6 @@ float __builtin_rsqrtf (float);
double __builtin_recipdiv (double, double);
double __builtin_rsqrt (double);
long __builtin_bpermd (long, long);
-int __builtin_bswap16 (int);
@end smallexample
The @code{vec_rsqrt}, @code{__builtin_rsqrt}, and
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 186176)
+++ c-family/c-common.c (working copy)
@@ -4991,7 +4991,7 @@ c_common_nodes_and_builtins (void)
uint8_type_node =
TREE_TYPE (identifier_global_value (c_get_ident (UINT8_TYPE)));
if (UINT16_TYPE)
-uint16_type_node =
+c_uint16_type_node =
TREE_TYPE (identifier_global_value (c_get_ident (UINT16_TYPE)));
if (UINT32_TYPE)
c_uint32_type_node =
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 186176)
+++ c-family/c-common.h (working copy)
@@ -390,7 +390,7 @@ extern const unsigned int num_c_common_r
#define int32_type_node c_global_trees[CTI_INT32_TYPE]
#define int64_type_node c_global_trees[CTI_INT64_TYPE]
#define uint8_type_node c_global_trees[CTI_UINT8_TYPE]
-#define uint16_type_node c_global_trees[CTI_UINT16_TYPE]
+#define c_uint16_type_node c_global_trees[CTI_UINT16_TYPE]
#define c_uint32_type_node c_global_trees[CTI_UINT32_TYPE]
#define c_uint64_type_node
Re: [SH] Fold big/little endian word code with MSW and LSW
Oleg Endo oleg.e...@t-online.de wrote:
On a second thought, it might be better to simplify those cases in
the .md file, where low/high subregs are used by using 'gen_highpart'
and 'gen_lowpart' for example, instead of checking the endianness over
and over again.
I'm trying out a couple of things...
... like the attached patch.
Tested against rev. 186216 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}
and no new failures.
I've left the DFmode related patterns alone, because when
'gen_highpart' / 'gen_lowpart' is used to access DFmode subregs the
functions fill fail because 'sh_cannot_change_mode_class' rejects the
mode changes DFmode - SFmode for some reason...
OK like that?
OK.
Regards,
kaz
Re: [PATCH] Caret diagnostics
On 04/09/2012 04:01 PM, Manuel López-Ibáñez wrote: * It uses the default cutoff as max_width, whatever it is (as controlled by -fmessage-length). * It uses the pretty-printer. The text cannot (should not) wrap because we still print only max_width chars at most. Hmm, I think if pp_line_cutoff is 0 and we're on a terminal, we still want to use COLUMNS to limit how much of the source we print. Jason
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Monday 09 April 2012 16:48:06 Adam Conrad wrote: On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote: On 4 April 2012 18:54, Jakub Jelinek wrote: If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think. The problem here that everyone !Debian isn't taking into account is that multilib paths don't solve our use-case. Multilib paths only solve the case of multiple ABIs on the same base processor family. As soon as you combine x86, arm, power, etc, you end up with overlaps and the problem there is that you're assuming anyone !Debian sees this as a problem. so, once again, do not use the armhf standardization work to backdoor multiarch. if you want to talk about multiarch, then start a new thread to do that. Ultimately, however, I want this solved. We thought we had this solved at Plumbers last fall. To hear now that we didn't involve everyone is disheartening, given that we (we being Debian and Ubuntu) were well outnumbered in that room by people from RedHat, Fedora, ChromeOS, and Gentoo. tbh, i thought the ldso discussion was more we've been talking about this for a long time, so let's just go with XXX and then people moved on to the next topic (which was defining exactly what hard float abi meant wrt compiler flags). further, it seemed like we had distro representation there, but not mainline gcc people. So, pretty please, can we (A) address the concerns here without people putting up the Unique paths are Debian trying to force multi-arch on us straw man, and (B) agree to *something*, before I ship something that conforms to a standard agreed upon more than half a year ago that is now a cause for contention? Pretty please? With sugar on top? Kthx. again, saying /lib/tuple/ldso isn't multiarch is bunk. but it sounds like you're fine with /libhf/, so there isn't anything left to thrash about there. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Mon, Apr 09, 2012 at 07:14:45PM -0400, Mike Frysinger wrote: again, saying /lib/tuple/ldso isn't multiarch is bunk. but it sounds like you're fine with /libhf/, so there isn't anything left to thrash about there. I appreciate your careful reading of my email and the issues I outlined, and I look forward to your new urbandictionary definition of the common colloquialism fine with. A path for one file isn't multi-arch. A unique path for linkers does help facilitate multi-arch, but we're not forcing you to put libraries some place you don't want to, implement new ideas you don't want to, or any other such bunk, as you so obviously impartially put it. I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you. This isn't about pushing multi-arch on others. This isn't about pushing multi-arch on others. Also, this. Isn't. About. Pushing. Multi-arch. On. Others. I don't know how much more clear I can make that. If the QT guys filed a bug/feature request on libstdc++ asking to change something that didn't break C++ standards, but facilitated some fancy thing they were working on, my response wouldn't be dude, I use GTK, what do I care about your weird needs, screw you and your QT agenda, it would be to ask them why they need the thing they need, evaluate how, if in any way, that would impact other users, and work with them. Using unique linker paths (for new architectures) hurts exactly zero users, and this discussion has taken up FAR MORE developer time than implementation ever would have. Arguing against unique linker paths for the reason that we've never done that before is not helpful, and it's blatantly ignoring technical arguments and hiding them behind some bizarre inter-distro conspiracy theory. Maybe the conspiracy theory is fun for you. I don't know. It's not for me. We were told by GCC upstream that we needed distro consensus. We got that over half a year ago. Now I'm told by distros that the patch not being upstream is why they are backing out of said consensus. Fun. Adam Conrad
Re: [PATCH] Fix PR52571
On Mar 14, 2012, at 5:59 AM, Richard Guenther wrote: This fixes PR52571, we should not align DECL_COMMON variables as they might be pre-empted by a definition with lower alignment. I added this to the PR: Ah, I had another thought. COMDAT and LINKONCE things I don't think can be realigned for all the same reasons that one cannot align COMMON. I've not thought about this long and hard, so, could be wrong, so, would be good to have a C++ or a vectorizer person review the idea. The idea is, if you compile one translation unit with a vectorizor on, and another with it off, we wind up with two instantiations, each with different alignment, and the one picked at the end need not be either of them, but rather an explicit instantiation. This seems identical to what happens to common to me.
[SH] PR 50751 - add HImode displacement addressing support
Hello,
The attached patch adds HImode addressing support.
Tested against rev. 186243 with
sudo make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}
and no new failures.
Test cases will follow soon.
Cheers,
Oleg
ChangeLog:
PR target/50751
* config/sh/sh-protos.h (sh_legitimate_index_p): Add
new arguments consider_sh2a and allow_zero.
* config/sh/sh.c (sh_legitimate_index_p): Likewise.
(disp_addr_displacement): New function.
(sh_address_cost): Use disp_addr_displacement function instead
of DISP_ADDR_OFFSET.
(sh_legitimate_address_p): Adapt to changed
sh_legitimate_index_p declaration.
(sh_find_mov_disp_adjust): Remove HImode check.
(sh_secondary_reload): Add HImode case. Use
satisfies_constraint_Sdd, disp_addr_displacement and
max_mov_insn_displacement.
(max_mov_insn_displacement): Remove HImode check.
* config/sh/sh.h (CONST_OK_FOR_K04, CONST_OK_FOR_K12,
DISP_ADDR_P, DISP_ADDR_OFFSET): Remove.
* config/sh/constraints.md (K05, K13): New constraints.
(K12): Correct comment.
(Sdd): Do not use DISP_ADDR_P macro.
(Snd): Use satisfies_constraint_Sdd.
(Sbw): Likewise.
* config/sh/sh.md (extendhisi2): Remove constraints from
expander.
(*extendhisi2_compact, movhi_i): Remove.
(*extendhisi2_compact_reg, *extendhisi2_compact_mem_disp,
*extendhisi2_compact_mem_disp, *extendhisi2_compact_snd,
*movhi_reg_reg, *movhi_store_mem_disp05,
*movhi_store_mem_disp13, *movhi_load_mem_disp,
*movhi_load_mem_disp, *movhi): New insns.
(*extendqisi2_compact_mem_disp, *extendqisi2_compact_mem_disp,
*movqi_store_mem_disp04, *movqi_store_mem_disp12,
*movqi_load_mem_disp, *movqi_load_mem_disp): Use
sh_legitimate_index_p instead of CONST_OK_FOR_Kxx.
Add new peepholes for HImode displacement addressing.
Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md (revision 186233)
+++ gcc/config/sh/predicates.md (working copy)
@@ -404,7 +404,7 @@
if (GET_CODE (x) == PLUS
REG_P (XEXP (x, 0))
CONST_INT_P (XEXP (x, 1)))
- return sh_legitimate_index_p (mode, XEXP (x, 1));
+ return sh_legitimate_index_p (mode, XEXP (x, 1), TARGET_SH2A, false);
}
if (TARGET_SHMEDIA
@@ -466,7 +466,7 @@
if (GET_CODE (x) == PLUS
REG_P (XEXP (x, 0))
CONST_INT_P (XEXP (x, 1)))
- return sh_legitimate_index_p (mode, XEXP (x, 1));
+ return sh_legitimate_index_p (mode, XEXP (x, 1), TARGET_SH2A, false);
}
return general_operand (op, mode);
Index: gcc/config/sh/sh-protos.h
===
--- gcc/config/sh/sh-protos.h (revision 186233)
+++ gcc/config/sh/sh-protos.h (working copy)
@@ -56,7 +56,7 @@
extern bool fp_zero_operand (rtx);
extern bool fp_one_operand (rtx);
extern rtx get_fpscr_rtx (void);
-extern bool sh_legitimate_index_p (enum machine_mode, rtx);
+extern bool sh_legitimate_index_p (enum machine_mode, rtx, bool, bool);
extern bool sh_legitimize_reload_address (rtx *, enum machine_mode, int, int);
extern rtx legitimize_pic_address (rtx, enum machine_mode, rtx);
extern bool nonpic_symbol_mentioned_p (rtx);
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 186233)
+++ gcc/config/sh/sh.c (working copy)
@@ -304,6 +304,7 @@
static int mov_insn_size (enum machine_mode, bool);
static int max_mov_insn_displacement (enum machine_mode, bool);
static int mov_insn_alignment_mask (enum machine_mode, bool);
+static HOST_WIDE_INT disp_addr_displacement (rtx);
static void sh_init_sync_libfuncs (void) ATTRIBUTE_UNUSED;
@@ -3160,11 +3161,6 @@
scale the max. displacement value accordingly. */
const int disp_scale = consider_sh2a ? (4095 / 15) : 1;
- /* FIXME: HImode with displacement addressing is not supported yet.
- Make it purposefully fail for now. */
- if (mode == HImode)
-return 0;
-
/* SH2A supports FPU move insns with 12 bit displacements.
Other variants to do not support any kind of displacements for
FPU move insns. */
@@ -3194,15 +3190,24 @@
return mov_insn_sz 0 ? (mov_insn_sz - 1) : 0;
}
+/* Return the displacement value of a displacement address. */
+
+static inline HOST_WIDE_INT
+disp_addr_displacement (rtx x)
+{
+ gcc_assert (satisfies_constraint_Sdd (x));
+ return INTVAL (XEXP (XEXP (x, 0), 1));
+}
+
/* Compute the cost of an address. */
static int
sh_address_cost (rtx x, bool speed ATTRIBUTE_UNUSED)
{
/* 'reg + disp' addressing. */
- if (DISP_ADDR_P (x))
+ if (satisfies_constraint_Sdd (x))
{
- const HOST_WIDE_INT offset =
[PATCH] Fix PR middle-end/52894
The current 4.5, 4.6 and 4.7 branches are now seriously broken for all
PA target due to the fix applied for PR middle-end/52640, an optimization
fix. This is because the PA backend defers output of function descriptors
and externals (hpux) using TARGET_ASM_FILE_END. As a result, assemble_external
can be called after after varasm.c processes it's list of pending externals
and the vector used for this list deleted.
The attached change fixes this problem. The change has been tested
on hppa-unknown-linux-gnu and hppa2.0w-hp-hpux11.11 with no observed
regressions. I believe it to be the simplest way to fix these release
branches although it may not be optimal (externals are doublely delayed
on PA hpux).
Ok for the 4.5, 4.6 and 4.7 branches? The fix for PR middle-end/52640
was not applied to the trunk.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2012-04-09 John David Anglin dave.ang...@nrc-cnrc.gc.ca
PR middle-end/52894
* varasm.c (process_pending_assemble_externals): Set
pending_assemble_externals_processed true.
(assemble_external): Call assemble_external_real if the pending
assemble externals have been processed.
Index: varasm.c
===
--- varasm.c(revision 186213)
+++ varasm.c(working copy)
@@ -2108,6 +2108,11 @@
the entire pending_assemble_externals list. See assemble_external(). */
static struct pointer_set_t *pending_assemble_externals_set;
+/* Some targets delay some output to final using TARGET_ASM_FILE_END.
+ As a result, assemble_external can be called after the list of externals
+ is processed and the pointer set destroyed. */
+static bool pending_assemble_externals_processed;
+
#ifdef ASM_OUTPUT_EXTERNAL
/* True if DECL is a function decl for which no out-of-line copy exists.
It is assumed that DECL's assembler name has been set. */
@@ -2160,6 +2165,7 @@
assemble_external_real (TREE_VALUE (list));
pending_assemble_externals = 0;
+ pending_assemble_externals_processed = true;
pointer_set_destroy (pending_assemble_externals_set);
#endif
}
@@ -2201,6 +2207,12 @@
weak_decls = tree_cons (NULL, decl, weak_decls);
#ifdef ASM_OUTPUT_EXTERNAL
+ if (pending_assemble_externals_processed)
+{
+ assemble_external_real (decl);
+ return;
+}
+
if (! pointer_set_insert (pending_assemble_externals_set, decl))
pending_assemble_externals = tree_cons (NULL, decl,
pending_assemble_externals);
PATCH: PR other/52777: [4.8 Regression] ./options.h:3546:0: error: MASK_SIO redefined [-Werror]
Hi, I checked in this patch, which has been approved in PR. H.J. --- Index: config/pa/pa.opt === --- config/pa/pa.opt(revision 186256) +++ config/pa/pa.opt(working copy) @@ -138,9 +138,3 @@ Generate PA1.1 code mspace-regs Target RejectNegative Report InverseMask(NO_SPACE_REGS) Do not disable space regs - -Mask(SIO) -;; Generate cpp defines for server I/O. - -Mask(GNU_LD) -;; Assume GNU linker by default Index: ChangeLog === --- ChangeLog (revision 186256) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2012-04-09 H.J. Lu hongjiu...@intel.com + + PR other/52777 + * config/pa/pa.opt: Remove SIO and GNU_LD. + 2012-04-09 Jan Hubicka j...@suse.cz PR lto/52722
execute permissions in ada
I'd like to remove execute permissions for: gcc/ada/*.adb Ok?
remove execute permissions from gcc/testsuite
Remove execute permissions from gcc/testsuite: * gcc.dg/dll-8.c: Remove execute permissions. * g++.dg/ext/dllexport5.C: Likewise.
Re: execute permissions in ada
On Apr 9, 2012, at 23:03, Mike Stump wrote: I'd like to remove execute permissions for: gcc/ada/*.adb Ok? Sure. What about *.ads? -Geert
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Monday 09 April 2012 19:31:40 Adam Conrad wrote: I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you. and as already stated, the proposed paths here, free of multiarch subpaths, satisfy the requirements that you've put forth -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Thursday 05 April 2012 12:25:09 Konstantinos Margaritis wrote: On Thu, 5 Apr 2012 11:55:14 -0400 Mike Frysinger wrote: note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or /libhf/ld-linux.so.[34]. /lib/triplet/ldso is really the only one i don't think doesn't belong. and I'm just saying that I dislike /libhf, I also think that just raising the version is a wrong solution. i can see why bumping ver # is undesirable, but i don't think it's that big of a deal. the ldso is a bit of a magic beast, so i don't think applying the same SONAME versioning rules is terribly important. especially since ARM has already moved from ld-linux.so.2 for OABI to ld-linux.so.3 for EABI. you could even argue that enshrining hardfloat is actually an ABI version bump, so ld-linux.so.4 is appropriate. and really, once you bump the SONAME, injecting substrings like hf are no different. don't really know what you're talking about here. other distros have no problem with handling multilib. multilib for softfloat/hardfloat on arm? I don't think so, even for other arches -it was already demonstrated that you cannot e.g. have powerpc e500v2 and e600 installed concurrently, i'm not familiar with ppc's embedded variants, so i can't speak to these examples and anyway that's not the topic of the discussion here. Apart from multiarch there is no other solution to do that *for* arm, at least at the moment, because the two ABIs use exactly the same paths on a non-multiarch system. i'm not sure why you think that. if people actually want to do multilib with these, then there's nothing stopping people from doing that, once the ldso's are in a unique path. And I get back to the proposed solution /libhf -which is the multilib path you're referring to- and I'm saying that the topic here is for the linker path alone. In the hypothetical scenario that everyone agreed on /libhf for the linker path, but not for libraries -which would stay in /lib- , then we'd have a /libhf top directory with just one file, the linker. Or a symlink from /lib to /libhf or /lib/triplet to /libhf in Debian's case, but that defeats the purposes of having a new /libhf directory, doesn't it? what Debian chooses to do with multiarch is up to Debian ... i don't think it should have any bearing here. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On 04/09/2012 05:14 PM, Mike Frysinger wrote: tbh, i thought the ldso discussion was more we've been talking about this for a long time, so let's just go with XXX and then people moved on to the next topic (which was defining exactly what hard float abi meant wrt compiler flags). further, it seemed like we had distro representation there, but not mainline gcc people. Actually Mike, there was at least one mainline GCC person there. Me. Of course I was thrown into a discussion I knew nothing about, but the goal of having a standardized path to discover ld.so which worked across distros seems like goodness to me. Honestly, I don't see what all the resistance is about. Jeff
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tuesday 10 April 2012 00:16:34 Jeff Law wrote: On 04/09/2012 05:14 PM, Mike Frysinger wrote: tbh, i thought the ldso discussion was more we've been talking about this for a long time, so let's just go with XXX and then people moved on to the next topic (which was defining exactly what hard float abi meant wrt compiler flags). further, it seemed like we had distro representation there, but not mainline gcc people. Actually Mike, there was at least one mainline GCC person there. Me. my mistake. i don't think we've met before, and that was a fairly busy time for me, so i probably missed things. we should get a beer ;). Of course I was thrown into a discussion I knew nothing about admittedly, that was the first time i've been in a linaro-related meeting before, and i hadn't been following linaro at all before (as the job i left before wasn't working on arm at all) goal of having a standardized path to discover ld.so which worked across distros seems like goodness to me. Honestly, I don't see what all the resistance is about. i think we have suggestions that would work for everyone ... but maybe this thread has gotten too big so we need to regroup with a summary -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote: On Monday 09 April 2012 19:31:40 Adam Conrad wrote: I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you. and as already stated, the proposed paths here, free of multiarch subpaths, satisfy the requirements that you've put forth Like I said, then, you didn't actually read or understand why proposing multilib paths doesn't work. You realize conceptually, I hope, that there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once you cross the base CPU architecture boundary, right? Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for us right now, due to sheer luck, and you're running with that as saying that we clearly have no problem here worth solving. When the next architecture clashes with linkers on another (hint: it almost certainly will), do we get to argue about this all over again in six months, instead of codifying a new and saner practice now? ... Adam Conrad
die CRs
* g++.dg/cpp0x/udlit-raw-op.C: Don't use CRLF endings.
* gcc.dg/tree-ssa/vrp59.c: Likewise.
* gcc.dg/tree-ssa/vrp60.c: Likewise.
Index: gcc.dg/tree-ssa/vrp60.c
===
--- gcc.dg/tree-ssa/vrp60.c (revision 186258)
+++ gcc.dg/tree-ssa/vrp60.c (revision 186260)
@@ -1,31 +1,31 @@
-/* { dg-do compile } */
-/* { dg-options -O2 -fno-tree-ccp -fno-tree-dominator-opts -fdump-tree-vrp1
} */
-
-int foo (int x, int b)
-{
- int cst;
- if (b)
-cst = -__INT_MAX__ - 1;
- else
-cst = -__INT_MAX__;
- x = x | cst;
- if (x = 0)
-return 12345;
- return x;
-}
-
-int bar (int x, int b)
-{
- int cst;
- if (b)
-cst = __INT_MAX__;
- else
-cst = __INT_MAX__ - 1;
- x = x cst;
- if (x 0)
-return 12345;
- return x;
-}
-
-/* { dg-final { scan-tree-dump-not 12345 vrp1 } } */
-/* { dg-final { cleanup-tree-dump vrp1 } } */
+/* { dg-do compile } */
+/* { dg-options -O2 -fno-tree-ccp -fno-tree-dominator-opts -fdump-tree-vrp1
} */
+
+int foo (int x, int b)
+{
+ int cst;
+ if (b)
+cst = -__INT_MAX__ - 1;
+ else
+cst = -__INT_MAX__;
+ x = x | cst;
+ if (x = 0)
+return 12345;
+ return x;
+}
+
+int bar (int x, int b)
+{
+ int cst;
+ if (b)
+cst = __INT_MAX__;
+ else
+cst = __INT_MAX__ - 1;
+ x = x cst;
+ if (x 0)
+return 12345;
+ return x;
+}
+
+/* { dg-final { scan-tree-dump-not 12345 vrp1 } } */
+/* { dg-final { cleanup-tree-dump vrp1 } } */
Index: gcc.dg/tree-ssa/vrp59.c
===
--- gcc.dg/tree-ssa/vrp59.c (revision 186258)
+++ gcc.dg/tree-ssa/vrp59.c (revision 186260)
@@ -1,35 +1,35 @@
-/* { dg-do compile } */
-/* { dg-options -O2 -fno-tree-ccp -fdump-tree-vrp1 } */
-
-int f(int x)
-{
- if (x = 0 x = 3)
-{
- x = x ^ 3;
- x = x 3;
-}
- return x;
-}
-
-int g(int x)
-{
- if (x = 0 x = 3)
-{
- x = x ^ 2;
- x = x 3;
-}
- return x;
-}
-
-int h(int x)
-{
- if (x = 0 x = 3)
-{
- x = x ^ 1;
- x = x 3;
-}
- return x;
-}
-
-/* { dg-final { scan-tree-dump-not 3; vrp1 } } */
-/* { dg-final { cleanup-tree-dump vrp1 } } */
+/* { dg-do compile } */
+/* { dg-options -O2 -fno-tree-ccp -fdump-tree-vrp1 } */
+
+int f(int x)
+{
+ if (x = 0 x = 3)
+{
+ x = x ^ 3;
+ x = x 3;
+}
+ return x;
+}
+
+int g(int x)
+{
+ if (x = 0 x = 3)
+{
+ x = x ^ 2;
+ x = x 3;
+}
+ return x;
+}
+
+int h(int x)
+{
+ if (x = 0 x = 3)
+{
+ x = x ^ 1;
+ x = x 3;
+}
+ return x;
+}
+
+/* { dg-final { scan-tree-dump-not 3; vrp1 } } */
+/* { dg-final { cleanup-tree-dump vrp1 } } */
Index: ChangeLog
===
--- ChangeLog (revision 186258)
+++ ChangeLog (revision 186260)
@@ -1,5 +1,9 @@
2012-04-09 Mike Stump mikest...@comcast.net
+ * g++.dg/cpp0x/udlit-raw-op.C: Don't use CRLF endings.
+ * gcc.dg/tree-ssa/vrp59.c: Likewise.
+ * gcc.dg/tree-ssa/vrp60.c: Likewise.
+
* gcc.dg/dll-8.c: Remove execute permissions.
* g++.dg/ext/dllexport5.C: Likewise.
Index: g++.dg/cpp0x/udlit-raw-op.C
===
--- g++.dg/cpp0x/udlit-raw-op.C (revision 186258)
+++ g++.dg/cpp0x/udlit-raw-op.C (revision 186260)
@@ -1,21 +1,21 @@
-// { dg-do run }
-// { dg-options -std=c++0x }
-
-#include cassert
-#include cstring
-
-int
-operator _raw_umber(const char * str)
-{
- return strlen(str);
-}
-
-int
-main()
-{
- int i =
0123012301230123012301230123012301230123012301230123012301230123_raw_umber;
- assert( i == 64 );
-
- int j =
90123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789_raw_umber;
- assert( j == 101 );
-}
+// { dg-do run }
+// { dg-options -std=c++0x }
+
+#include cassert
+#include cstring
+
+int
+operator _raw_umber(const char * str)
+{
+ return strlen(str);
+}
+
+int
+main()
+{
+ int i =
0123012301230123012301230123012301230123012301230123012301230123_raw_umber;
+ assert( i == 64 );
+
+ int j =
90123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789_raw_umber;
+ assert( j == 101 );
+}
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
Em 9 de abril de 2012 17:48, Adam Conrad adcon...@debian.org escreveu: On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote: On 4 April 2012 18:54, Jakub Jelinek ja...@redhat.com wrote: If the agreement is that arm 32-bit softfp really needs to be installable alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says, e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp, /libhf/ld-linux.so.3 and */libhf dirs for hardfp and /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit arm-linux-gnueabi gcc configured for softfp/hardfp multilib with MULTILIB_OSDIRNAMES, etc., have it configured in glibc OK. This gives a different path for the hard float loader and lets the Debian guys add on top of that. I'll ping them and see what they think. The problem here that everyone !Debian isn't taking into account is that multilib paths don't solve our use-case. Multilib paths only solve the case of multiple ABIs on the same base processor family. As soon as you combine x86, arm, power, etc, you end up with overlaps (or, the potential for overlaps; the fact that various arches accidentally have different majors keeps those overlaps to a minimum right now, but that's not by design). Honestly, this is something we should have solved two decades ago, but the very idea that someone would want to do what Debian is now doing didn't occur to any of us. That's cool. We didn't think of it back then. That's no excuse to continue with the status quo just because it's the status quo. To be perfectly clear here, we don't care where the linker goes (really, we don't), we just want it to be both arch and ABI unique. If that means taking a crc32 of a rot-13 of the compiler flags used to define the ABI, and then stuffing the linker in /lib/gobbledygook/ld-linux.so, so be it. If this means setting up a (very) lightweight process with the LSB, where everytime a new distro proposes a shiny new arch/ABI, they submit it, and the LSB assigns them an ABI serial, and we all then agree to toss the linker in /lib/abi-2345/ld-linux, that works too. Don't care. Really don't care. This isn't about trying to force people to switch from multilib to multi- arch, where the former is clearly working fine for them. It's not. This is purely about people bikeshedding about paths they consider un-pretty, while (I hope not maliciously or knowingly?) causing potential overlap and breakage for those of us for whom this actually matters and isn't purely a color selection exercise. In the short term, due to sheer luck, /libhf/ld-linux.so.3 would work for us, purely because that doesn't overlap with any other linkers that Debian currently ships. The fact that the multilib path happens to work doesn't make it correct for our use-case, and certainly doesn't make it correct ongoing. Ultimately, however, I want this solved. We thought we had this solved at Plumbers last fall. To hear now that we didn't involve everyone is disheartening, given that we (we being Debian and Ubuntu) were well outnumbered in that room by people from RedHat, Fedora, ChromeOS, and Gentoo. We all agreed on something back then, and now that I'm three weeks away from shipping an armhf distro, it's all exploded yet again into Bikeshed Part III: The Revenge of Purple Paint. I really want to ship a compiler than stuffs the correct and agreed upon linker in headers. I don't want to see third parties build binaries on Ubuntu that don't run on Fedora. No one wants to see that, I think. Obviously, conversely (though this is much less hassle), I need to be able to ship a linker symlink that matches expectations, so that binaries built on Fedora will run on Ubuntu. Again, I'm sure we all want that. So, pretty please, can we (A) address the concerns here without people putting up the Unique paths are Debian trying to force multi-arch on us straw man, and (B) agree to *something*, before I ship something that conforms to a standard agreed upon more than half a year ago that is now a cause for contention? Pretty please? With sugar on top? Kthx. (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp). Yip. I assume something like /lib64 to stay consistent with other architectures. aarch64 is hard float only. I expect that most distros will probably ship their aarch64 libraries in /lib64 (Debian and Ubuntu won't, but that's fine) to keep consistent with their other 64-bit ports, but where you put libraries is entirely unrelated to where the linker lives. You could have all your libraries in /root/.trash/ and if the linker lives in a canonical location and can resolve that, that's fine. I will still (obviously, I think, from my comments above) argue that the linker should live in a guaranteed unique
Ada testcase CR line endings
So, I'd like to change all the ada testcases to use normal unix line endings. testsuite/gnat.dg/taft_type2_pkg.ads is an example if one such file, any objections?
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tue, Apr 10, 2012 at 05:17:36AM +, Adam Conrad wrote: On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote: On Monday 09 April 2012 19:31:40 Adam Conrad wrote: I realize that most people can't see past their own use case to understand why a unique location for linkers is helpful, useful, and important for some other people's use cases, but you either didn't read or chose to ignore why using multilib paths just plain doesn't scale past a single base architecture, and why that's a problem for people who aren't you. and as already stated, the proposed paths here, free of multiarch subpaths, satisfy the requirements that you've put forth Like I said, then, you didn't actually read or understand why proposing multilib paths doesn't work. You realize conceptually, I hope, that there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once you cross the base CPU architecture boundary, right? But you are incorrectly assuming that anyone outside Debian actually sees that as a problem. When we've designed multilib for Linux (following Irix layout, which for some weird reason Debian was the only one which ignored it), it hasn't been a goal and I don't see why it should be a goal now. For crossing base CPU architecture boundaries we have for many years --sysroot, you can't run natively the binaries/libraries anyway, while for ABIs that you can run natively it is very common to run binaries for the different native ABIs concurrently. We really want consistency about the dynamic linker names etc. across different targets and sneaking silently multiarch paths on one architecture would make it inconsistent with all the others. So, please just use /libhf/ld-linux.so.3. will), do we get to argue about this all over again in six months, instead of codifying a new and saner practice now? Not everybody agrees it is a saner practice. Jakub
Re: execute permissions in ada
On Apr 9, 2012, at 8:39 PM, Geert Bosch wrote: On Apr 9, 2012, at 23:03, Mike Stump wrote: I'd like to remove execute permissions for: gcc/ada/*.adb Ok? Sure. What about *.ads? I assume that was a friendly, please feel free to fix *.ads as well. Fixed: * a-assert.ads: Remove execute permission. * a-chacon.ads: Likewise. * a-coteio.ads: Likewise. * a-envvar.ads: Likewise. * a-exetim-mingw.ads: Likewise. * a-fzteio.ads: Likewise. * a-izteio.ads: Likewise. * a-lcteio.ads: Likewise. * a-llctio.ads: Likewise. * a-scteio.ads: Likewise. * a-suenco.ads: Likewise. * a-suenst.ads: Likewise. * a-suewst.ads: Likewise. * a-suezst.ads: Likewise. * a-tirsfi.ads: Likewise. * a-wichha.ads: Likewise. * a-zchara.ads: Likewise. * a-zchhan.ads: Likewise. * a-zchuni.ads: Likewise. * a-zrstfi.ads: Likewise. * aspects.ads: Likewise. * g-byorma.ads: Likewise. * g-decstr.ads: Likewise. * g-encstr.ads: Likewise. * g-spchge.ads: Likewise. * g-u3spch.ads: Likewise. * g-wispch.ads: Likewise. * g-zspche.ads: Likewise. * namet-sp.ads: Likewise. * s-os_lib.ads: Likewise. * s-regexp.ads: Likewise. * s-regpat.ads: Likewise. * s-string.ads: Likewise. * s-tasloc.ads: Likewise. * s-utf_32.ads: Likewise. * sem_aux.ads: Likewise. * a-assert.adb: Likewise. * a-chacon.adb: Likewise. * a-envvar.adb: Likewise. * a-exetim-mingw.adb: Likewise. * a-suenco.adb: Likewise. * a-suenst.adb: Likewise. * a-suewst.adb: Likewise. * a-suezst.adb: Likewise. * a-tirsfi.adb: Likewise. * a-wichha.adb: Likewise. * a-zchhan.adb: Likewise. * a-zchuni.adb: Likewise. * a-zrstfi.adb: Likewise. * aspects.adb: Likewise. * g-byorma.adb: Likewise. * g-decstr.adb: Likewise. * g-encstr.adb: Likewise. * g-spchge.adb: Likewise. * g-u3spch.adb: Likewise. * g-wispch.adb: Likewise. * g-zspche.adb: Likewise. * namet-sp.adb: Likewise. * s-except.adb: Likewise. * s-inmaop-vxworks.adb: Likewise. * s-os_lib.adb: Likewise. * s-regexp.adb: Likewise. * s-regpat.adb: Likewise. * s-string.adb: Likewise. * s-tasloc.adb: Likewise. * s-utf_32.adb: Likewise. * s-wchcon.adb: Likewise. * sem_aux.adb: Likewise. Property changes on: a-zchuni.adb ___ Deleted: svn:executable - * Property changes on: a-zchuni.ads ___ Deleted: svn:executable - * Property changes on: s-tasloc.adb ___ Deleted: svn:executable - * Property changes on: s-tasloc.ads ___ Deleted: svn:executable - * Property changes on: s-string.adb ___ Deleted: svn:executable - * Property changes on: a-envvar.adb ___ Deleted: svn:executable - * Property changes on: s-string.ads ___ Deleted: svn:executable - * Property changes on: a-envvar.ads ___ Deleted: svn:executable - * Property changes on: sem_aux.adb ___ Deleted: svn:executable - * Property changes on: g-wispch.adb ___ Deleted: svn:executable - * Property changes on: sem_aux.ads ___ Deleted: svn:executable - * Property changes on: g-wispch.ads ___ Deleted: svn:executable - * Property changes on: a-tirsfi.adb ___ Deleted: svn:executable - * Property changes on: a-tirsfi.ads ___ Deleted: svn:executable - * Property changes on: g-encstr.adb ___ Deleted: svn:executable - * Property changes on: g-encstr.ads ___ Deleted: svn:executable - * Property changes on: s-regpat.adb ___ Deleted: svn:executable - * Property changes on: s-regpat.ads
