Re: [patch][cris] Clean up some cris-aout remnants
On Tue, 5 Jun 2012, Steven Bosscher wrote: > This patch just cleans up some remaining code for removed cris-aout > subtarget by folding away code that was conditional on TARGET_ELF. > > Tested with a x86_64-linux X cris-elf cross-compiler. OK for trunk? Woohoo, that's a lot of left-over cruft! @@ -891,31 +881,17 @@ enum cris_pic_symbol_type align_ = 2; \ /* FIXME: Do we need this? */ \ else if (align_ < 1) \ - align_ = 1; \ + align_ = 1; \ You ran the test-suite with no regressions? Ok then but without the cris.h spurious wrong white-space change above (already a TAB). (Changing that else into a gcc_unreachable would be an experiment for another day.) brgds, H-P PS. please use the email address in MAINTAINERS, the gcc.gnu.org addresses are for bugzilla.
Re: [RFC, ivopts] fix bugs in ivopts address cost computation
On Tue, 5 Jun 2012, Sandra Loosemore wrote: > (1) While the address cost computation is assuming in some situations > that pre/post increment/decrement addressing will be used if > supported by the target, it isn't actually using the target's address > cost for such forms -- instead, just the cost of the form that would > be used if autoinc weren't available/applicable. There are lots of bugzilla entries complaining about bad autoinc/dec generation. Maybe your patch solves some of them? > (2) The computation to determine which multiplier values are supported > by target addressing modes is constructing an address rtx of the form > (reg * ratio) to do the tests. This isn't a valid address RTX on > Hexagon, although both (reg + reg * ratio) and (sym + reg * ratio) > are. Yeah, I've spotted this one and (7), funny in a bad way. It's not a sane addressing mode except as a corner-case of (reg*ratio + constant) (e.g. constant=sym). A value in a register, and just multiply that by a constant to use as an address? When would that be useful? Should a target include the corner-case as a special-case addressing-mode just to appease ivopts? Made me think less of ivopts. Dunno if I entered a PR, mea culpa ...doesn't seem so. > I bootstrapped and regression-tested the patch on x86_64. I haven't > tried to benchmark the performance effect of the patch on anything > other than Hexagon; there I found that, once ivopts actually started > paying attention to the target address costs function, it needed to be > re-tuned. So, it wouldn't surprise me if other back ends could > benefit from some tweaking as well, depending on the extent to which > they're affected by the bugs I listed above. Right, but the lesson learned is to just ignore effects on other targets... In all fairness, I don't think there's anything to do regarding this patch in the default cost function, but it'd nice with a heads-up before committing the final version of this patch for a change though, maybe even with rtx cost tweaking-examples from a target of your choice (in the tree) if I could wish. > Comments, complaints, proposals for alternate fixes, etc? Or OK to > commit? Thank you! Others mentioned benchmarking on some major target, so I'll just add a wish for some PR annotations, any target with ivopts-related PR's. brgds, H-P
[gimplefe] patch that fixes the bug for the failure test case
Hi,
This patch fixes the failure test case that I had submitted the last time.
The changeLog is testsuite/gChangeLog.gimplefe is as follows.
2012-06-09 Sandeep Soni
* gimple.dg/20120605-2.gimple : New.
While the changelog in gimple/ChangeLog is as follows
2012-06-09 Sandeep Soni
* parser.c (gp_parse_expect_return_var) : Modify to have
correct token consumption.
Index: gcc/testsuite/gimple.dg/20120604-2.gimple
===
--- gcc/testsuite/gimple.dg/20120604-2.gimple (revision 0)
+++ gcc/testsuite/gimple.dg/20120604-2.gimple (revision 0)
@@ -0,0 +1 @@
+gimple_cond,> /* { dg-error
"Unsupported gimple_cond expression" } */
Index: gcc/gimple/parser.c
===
--- gcc/gimple/parser.c (revision 188324)
+++ gcc/gimple/parser.c (working copy)
@@ -634,16 +634,11 @@
static void
gp_parse_expect_return_var (gimple_parser *parser)
{
- const gimple_token *next_token;
-
- next_token = gl_consume_token (parser->lexer);
-
- if (next_token->type == CPP_NAME)
-next_token = gl_consume_token (parser->lexer);
-
/* There may be no variable in which the return value is collected.
In that case this field in the tuple will contain NULL. We need
to handle it too. */
+ gl_consume_expected_token (parser->lexer, CPP_NAME);
+
}
@@ -664,7 +659,6 @@
break;
case CPP_MULT:
- next_token = gl_consume_token (parser->lexer);
gl_consume_expected_token (parser->lexer, CPP_NAME);
break;
@@ -692,7 +686,6 @@
break;
else if (next_token->type == CPP_COMMA)
{
- next_token = gl_consume_token (parser->lexer);
gp_parse_expect_argument (parser);
}
}
--
Cheers
Sandy
Re: Wider modes for partial int modes
On Jun 8, 2012, at 4:11 PM, Mike Stump wrote: > On Apr 17, 2012, at 2:08 PM, Bernd Schmidt wrote: >> This patch enables GET_MODE_WIDER_MODE for MODE_PARTIAL_INT (by setting >> the wider mode to the one the partial mode is based on), which is useful >> for the port I'm working on: I can avoid defining operations on the >> partial modes. > > I think this breaks my port, in emit-rtl.c: > > B for (mode = GET_CLASS_NARROWEST_MODE (MODE_PARTIAL_INT); > mode != VOIDmode; > mode = GET_MODE_WIDER_MODE (mode)) > => const_tiny_rtx[i][(int) mode] = GEN_INT (i); > > Doesn't work, as that does expects to step through all partial int modes. > The problem is, we went from P1QI -> P1SI, and now we go from P1QI to QI. > The problem is this, we never initialize P1SI anymore, and later, when > initializing vector constants, things like V2P1SI dies, as P1SI was never > built: > >/* We need to call this function after we set the scalar const_tiny_rtx > > entries. */ >gcc_assert (const_tiny_rtx[constant][(int) inner]); > > So, maybe we want to go through all modes, and just ask, are you a > MODE_PARTIAL_INT, and initialize them that way? Thoughts? The below patch allows my port to at least initialize once more... Thoughts? Ok? diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c index af804df..8ff74c8 100644 --- a/gcc/emit-rtl.c +++ b/gcc/emit-rtl.c @@ -5704,9 +5704,9 @@ init_emit_once (void) mode = GET_MODE_WIDER_MODE (mode)) const_tiny_rtx[i][(int) mode] = GEN_INT (i); - for (mode = GET_CLASS_NARROWEST_MODE (MODE_PARTIAL_INT); - mode != VOIDmode; - mode = GET_MODE_WIDER_MODE (mode)) + for (mode = MIN_MODE_PARTIAL_INT; + mode <= MAX_MODE_PARTIAL_INT; + mode = (enum machine_mode)((int)(mode) + 1)) const_tiny_rtx[i][(int) mode] = GEN_INT (i); } @@ -5717,9 +5717,9 @@ init_emit_once (void) mode = GET_MODE_WIDER_MODE (mode)) const_tiny_rtx[3][(int) mode] = constm1_rtx; - for (mode = GET_CLASS_NARROWEST_MODE (MODE_PARTIAL_INT); - mode != VOIDmode; - mode = GET_MODE_WIDER_MODE (mode)) + for (mode = MIN_MODE_PARTIAL_INT; + mode <= MAX_MODE_PARTIAL_INT; + mode = (enum machine_mode)((int)(mode) + 1)) const_tiny_rtx[3][(int) mode] = constm1_rtx; for (mode = GET_CLASS_NARROWEST_MODE (MODE_COMPLEX_INT);
[PATCH] libgcc: If __GLIBC__ is defined, don't refer to pthread_cancel.
See http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01427.html for the
previous discussion about the motivation for this patch and the choice
of __pthread_key_create (also the comment added in the code by this patch).
This had no effect on testsuite results on x86_64-linux-gnu
(Ubuntu EGLIBC 2.11.1-0ubuntu7.10).
Thanks,
Roland
libgcc/
2012-06-08 Roland McGrath
* gthr-posix.h [neither FreeBSD nor Solaris] (__gthread_active_p):
If __GLIBC__ is defined, refer to __pthread_key_create instead of
pthread_cancel.
diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
index b5b1611..cc4e518 100644
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -212,18 +212,43 @@ __gthread_active_p (void)
#else /* neither FreeBSD nor Solaris */
+/* For a program to be multi-threaded the only thing that it certainly must
+ be using is pthread_create. However, there may be other libraries that
+ intercept pthread_create with their own definitions to wrap pthreads
+ functionality for some purpose. In those cases, pthread_create being
+ defined might not necessarily mean that libpthread is actually linked
+ in.
+
+ For the GNU C library, we can use a known internal name. This is always
+ available in the ABI, but no other library would define it. That is
+ ideal, since any public pthread function might be intercepted just as
+ pthread_create might be. __pthread_key_create is an "internal"
+ implementation symbol, but it is part of the public exported ABI. Also,
+ it's among the symbols that the static libpthread.a always links in
+ whenever pthread_create is used, so there is no danger of a false
+ negative result in any statically-linked, multi-threaded program.
+
+ For others, we choose pthread_cancel as a function that seems unlikely
+ to be redefined by an interceptor library. The bionic (Android) C
+ library does not provide pthread_cancel, so we do use pthread_create
+ there (and interceptor libraries lose). */
+
+#ifdef __GLIBC__
+__gthrw2(__gthrw_(__pthread_key_create),
+__pthread_key_create,
+pthread_key_create)
+# define GTHR_ACTIVE_PROXY __gthrw_(__pthread_key_create)
+#elif defined (__BIONIC__)
+# define GTHR_ACTIVE_PROXY __gthrw_(pthread_create)
+#else
+# define GTHR_ACTIVE_PROXY __gthrw_(pthread_cancel)
+#endif
+
static inline int
__gthread_active_p (void)
{
-/* Android's C library does not provide pthread_cancel, check for
- `pthread_create' instead. */
-#ifndef __BIONIC__
static void *const __gthread_active_ptr
-= __extension__ (void *) &__gthrw_(pthread_cancel);
-#else
- static void *const __gthread_active_ptr
-= __extension__ (void *) &__gthrw_(pthread_create);
-#endif
+= __extension__ (void *) >HR_ACTIVE_PROXY;
return __gthread_active_ptr != 0;
}
Re: Wider modes for partial int modes
On Apr 17, 2012, at 2:08 PM, Bernd Schmidt wrote: > This patch enables GET_MODE_WIDER_MODE for MODE_PARTIAL_INT (by setting > the wider mode to the one the partial mode is based on), which is useful > for the port I'm working on: I can avoid defining operations on the > partial modes. I think this breaks my port, in emit-rtl.c: B for (mode = GET_CLASS_NARROWEST_MODE (MODE_PARTIAL_INT); mode != VOIDmode; mode = GET_MODE_WIDER_MODE (mode)) => const_tiny_rtx[i][(int) mode] = GEN_INT (i); Doesn't work, as that does expects to step through all partial int modes. The problem is, we went from P1QI -> P1SI, and now we go from P1QI to QI. The problem is this, we never initialize P1SI anymore, and later, when initializing vector constants, things like V2P1SI dies, as P1SI was never built: /* We need to call this function after we set the scalar const_tiny_rtx entries. */ gcc_assert (const_tiny_rtx[constant][(int) inner]); So, maybe we want to go through all modes, and just ask, are you a MODE_PARTIAL_INT, and initialize them that way? Thoughts?
[lra] patch to fix some testsuite regressions on ppc
The following patch fixing some LRA crashes (when I tried a new
heuristics in insn alternative selection) on GCC tests on ppc.
The patch was successfully bootstrapped on x86-64 and power7.
Committed as rev. 188350.
2012-06-08 Vladimir Makarov
* emit-rtl.c (validate_subreg): Don't check offset for LRA and
floating point modes.
* lra.c (lra): Call lra_hard_reg_substitution after resetting
lra_in_progress.
* lra-constraints.c (match_reload): Unshare new regs.
Index: lra.c
===
--- lra.c (revision 188341)
+++ lra.c (working copy)
@@ -2217,8 +2217,8 @@ lra (FILE *f)
}
restore_scratches ();
lra_eliminate (true);
- lra_hard_reg_substitution ();
lra_in_progress = 0;
+ lra_hard_reg_substitution ();
lra_clear_live_ranges ();
lra_live_ranges_finish ();
lra_contraints_finish ();
Index: lra-constraints.c
===
--- lra-constraints.c (revision 188341)
+++ lra-constraints.c (working copy)
@@ -872,9 +872,9 @@ match_reload (signed char out, signed ch
= lra_create_new_reg_with_unique_value (outmode, out_rtx,
goal_class, "");
if (SCALAR_INT_MODE_P (outmode))
- new_in_reg = gen_lowpart_SUBREG (inmode, new_out_reg);
+ new_in_reg = gen_lowpart_SUBREG (inmode, reg);
else
- new_in_reg = gen_rtx_SUBREG (inmode, new_out_reg, 0);
+ new_in_reg = gen_rtx_SUBREG (inmode, reg, 0);
}
bitmap_set_bit (&lra_matched_pseudos, REGNO (reg));
bitmap_set_bit (&lra_bound_pseudos, REGNO (reg));
@@ -903,7 +903,7 @@ match_reload (signed char out, signed ch
narrow_reload_pseudo_class (in_rtx, goal_class);
narrow_reload_pseudo_class (out_rtx, goal_class);
push_to_sequence (*before);
- lra_emit_move (new_in_reg, in_rtx);
+ lra_emit_move (copy_rtx (new_in_reg), in_rtx);
*before = get_insns ();
end_sequence ();
for (i = 0; (in = ins[i]) >= 0; i++)
@@ -912,7 +912,7 @@ match_reload (signed char out, signed ch
if (find_reg_note (curr_insn, REG_UNUSED, out_rtx) == NULL_RTX)
{
start_sequence ();
- lra_emit_move (out_rtx, new_out_reg);
+ lra_emit_move (out_rtx, copy_rtx (new_out_reg));
emit_insn (*after);
*after = get_insns ();
end_sequence ();
Index: emit-rtl.c
===
--- emit-rtl.c (revision 188333)
+++ emit-rtl.c (working copy)
@@ -760,7 +760,8 @@ validate_subreg (enum machine_mode omode
of a subword. A subreg does *not* perform arbitrary bit extraction.
Given that we've already checked mode/offset alignment, we only have
to check subword subregs here. */
- if (osize < UNITS_PER_WORD)
+ if (osize < UNITS_PER_WORD
+ && ! (lra_in_progress && (FLOAT_MODE_P (imode) || FLOAT_MODE_P (omode
{
enum machine_mode wmode = isize > UNITS_PER_WORD ? word_mode : imode;
unsigned int low_off = subreg_lowpart_offset (omode, wmode);
Re: [patch] PR29442 - split insn-attrtab.c in three parts
On May 3, 2012, at 9:31 AM, Steven Bosscher wrote: > How does one turn random volunteer GCC hackers into spoiled brats? So, brats aside, your new patch breaks my port... diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 145e8b8..1eeeab9 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3586,7 +3586,7 @@ s-check : build/gencheck$(build_exeext) insn-attrtab.c insn-dfatab.c insn-latencytab.c: s-attrtab ; @true s-attrtab : $(MD_DEPS) build/genattrtab$(build_exeext) \ insn-conditions.md - $(RUN_GEN) build/genattrtab$(build_exeext) $(md_file) insn-conditions.md \ + $(RUN_GEN) build/genattrtab$(build_exeext) $(MD_INCS) $(md_file) insn-conditions.md \ -Atmp-attrtab.c -Dtmp-dfatab.c -Ltmp-latencytab.c $(SHELL) $(srcdir)/../move-if-change tmp-attrtab.cinsn-attrtab.c $(SHELL) $(srcdir)/../move-if-change tmp-dfatab.c insn-dfatab.c Seems to make it get farther... Someone want to check it in?
Re: [PATCH][RFC] Recognize memcpy/memmove - fix PR53081
On Tue, Jun 5, 2012 at 7:36 AM, Richard Guenther wrote: > > This adds memcpy/memmove recognition to loop distribution (and > cleans it up some more). Issues are similar to memset and > not handled (and I just noticed we generate memset/memcpy even > with -fno-builtin ...). > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > Richard. > > 2012-06-05 Richard Guenther > > PR tree-optimization/53081 > * tree-data-ref.h (adjacent_store_dr_p): Rename to ... > (adjacent_dr_p): ... this and make it work for reads, too. > * tree-loop-distribution.c (enum partition_kind): Add PKIND_MEMCPY. > (struct partition_s): Change main_stmt to main_dr, add > secondary_dr member. > (build_size_arg_loc): Change to date data-reference and not > gimplify here. > (build_addr_arg_loc): New function split out from ... > (generate_memset_builtin): ... here. Use it and simplify. > (generate_memcpy_builtin): New function. > (generate_code_for_partition): Adjust. > (classify_partition): Streamline pattern detection. Detect > memcpy. > (ldist_gen): Adjust. > (tree_loop_distribution): Adjust seed statements for memcpy > recognition. > This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53616 -- H.J.
Re: Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)
On Fri, Jun 8, 2012 at 2:22 PM, Cary Coutant wrote: >> Hmm, I thought the convention for this sort of flag was to start with -f, >> that -g flags were only for selecting the type and level of debug info. But >> I see that there are other debug dialect switches that use -g, so I guess >> this is OK. > > I kind of prefer -g, but I did notice that it's -fdebug-types-section, > so I could go with -f[no-]pubnames (or, as Jakub suggests, > -f[no-]debug-pubnames-section). On the other hand, there's > -g[no-]record-gcc-switches. What would you prefer? > > If we change it, should we also change (in a later patch) > -gsplit-dwarf (orig. -gfission) to -fsplit-dwarf? > >>> + if ((TREE_PUBLIC (decl) && !is_class_die (die->die_parent)) >> >> Why not include public class members? Is the theory that you'll need to >> read the type DIE anyway to do anything with the member, so you might as >> well read it to look up the member in the first place? There should be a >> comment about this. > > Yes, that's the theory. We're just trying to do the same thing that > GDB does when it builds .gdb_index. > >>> + VEC_safe_push (pubname_entry, gc, pubtype_table, &e); >> >> Why add enumerators to pubtypes rather than pubnames? They seem more like >> variables than types to me. > > That looks like a typo. It hasn't caused us any trouble because the > linker just throws all the names into the same table in .gdb_index, > but yes, I think it should go in pubnames_table. > > -cary OK, I've updated the patch with all these additional comments. Just waiting on the decision between -f and -g. I'll repost and then commit it when that is settled--hopefully soon. Next up, the big fission patch! Sterling
Re: Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)
> Hmm, I thought the convention for this sort of flag was to start with -f, > that -g flags were only for selecting the type and level of debug info. But > I see that there are other debug dialect switches that use -g, so I guess > this is OK. I kind of prefer -g, but I did notice that it's -fdebug-types-section, so I could go with -f[no-]pubnames (or, as Jakub suggests, -f[no-]debug-pubnames-section). On the other hand, there's -g[no-]record-gcc-switches. What would you prefer? If we change it, should we also change (in a later patch) -gsplit-dwarf (orig. -gfission) to -fsplit-dwarf? >> + if ((TREE_PUBLIC (decl) && !is_class_die (die->die_parent)) > > Why not include public class members? Is the theory that you'll need to > read the type DIE anyway to do anything with the member, so you might as > well read it to look up the member in the first place? There should be a > comment about this. Yes, that's the theory. We're just trying to do the same thing that GDB does when it builds .gdb_index. >> + VEC_safe_push (pubname_entry, gc, pubtype_table, &e); > > Why add enumerators to pubtypes rather than pubnames? They seem more like > variables than types to me. That looks like a typo. It hasn't caused us any trouble because the linker just throws all the names into the same table in .gdb_index, but yes, I think it should go in pubnames_table. -cary
[lra] patch to speed LRA up
The following patch is to speed LRA up a bit. It also adds 2012 to
copyright.
The patch was sucessfully bootstrapped on x86-64.
Committed as rev. 188341.
2012-06-08 Vladimir Makarov
* lra-assigns.c: Add 2012 to copyright header. Use lra_assert
instead of gcc_assert.
* lra-coalesce.c: Ditto.
* lra-eliminations.c: Ditto.
* lra-equivs.c: Ditto.
* lra-lives.c: Ditto.
* lra-spills.c: Ditto.
* lra.c: Ditto.
(insn_recog_data_len): Rename to lra_insn_recog_data_len.
(insn_recog_data): Rename to lra_insn_recog_data.
(lra_get_insn_recog_data): Rename to lra_set_insn_recog_data.
Remove code for accessing cached value.
* lra-constraints.c: Add 2012 to copyright header. Use lra_assert
instead of gcc_assert.
(check_and_process_move): Remove unnecessary side_effects_p call.
* lra-int.h: Ditto.
(lra_assert): Define it.
(lra_insn_recog_data_len, lra_insn_recog_data): New externals.
(lra_get_insn_recog_data): Rename to lra_set_insn_recog_data.
(lra_get_insn_recog_data): New inline function.
* lra.h: Add 2012 to copyright.
Index: lra-assigns.c
===
--- lra-assigns.c (revision 188333)
+++ lra-assigns.c (working copy)
@@ -1,5 +1,5 @@
/* Assign reload pseudos.
- Copyright (C) 2010, 2011
+ Copyright (C) 2010, 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -68,7 +68,7 @@ process_copy_to_form_thread (int regno1,
{
int last, regno1_first, regno2_first;
- gcc_assert (regno1 >= lra_constraint_new_regno_start
+ lra_assert (regno1 >= lra_constraint_new_regno_start
&& regno2 >= lra_constraint_new_regno_start);
regno1_first = regno_assign_info[regno1].first;
regno2_first = regno_assign_info[regno2].first;
@@ -84,7 +84,7 @@ process_copy_to_form_thread (int regno1,
+= regno_assign_info[regno2_first].freq;
}
regno_assign_info[regno1_first].freq -= 2 * copy_freq;
- gcc_assert (regno_assign_info[regno1_first].freq >= 0);
+ lra_assert (regno_assign_info[regno1_first].freq >= 0);
}
/* Initialize REGNO_ASSIGN_INFO and form threads. */
@@ -132,7 +132,7 @@ reload_pseudo_compare_func (const void *
enum reg_class cl2 = regno_allocno_class_array[r2];
int diff;
- gcc_assert (r1 >= lra_constraint_new_regno_start
+ lra_assert (r1 >= lra_constraint_new_regno_start
&& r2 >= lra_constraint_new_regno_start);
/* Prefer to assign reload registers with smaller classes first to
@@ -406,7 +406,7 @@ find_hard_regno_for (int regno, int *cos
conflict_regno)
if (val != lra_reg_info[conflict_regno].val)
{
- gcc_assert (live_pseudos_reg_renumber[conflict_regno] < 0);
+ lra_assert (live_pseudos_reg_renumber[conflict_regno] < 0);
if ((hard_regno
= lra_reg_info[conflict_regno].preferred_hard_regno1) >= 0)
{
@@ -432,7 +432,7 @@ find_hard_regno_for (int regno, int *cos
/* That is important for allocation of multi-word pseudos. */
IOR_COMPL_HARD_REG_SET (conflict_set, reg_class_contents[rclass]);
/* ?!? may be cover class for the old. */
- gcc_assert (rclass != NO_REGS);
+ lra_assert (rclass != NO_REGS);
rclass_size = ira_class_hard_regs_num[rclass];
best_hard_regno = -1;
for (i = 0; i < rclass_size; i++)
@@ -550,7 +550,7 @@ lra_setup_reg_renumber (int regno, int h
if ((hr = hard_regno) < 0)
hr = reg_renumber[regno];
reg_renumber[regno] = hard_regno;
- gcc_assert (hr >= 0);
+ lra_assert (hr >= 0);
for (i = 0; i < hard_regno_nregs[hr][PSEUDO_REGNO_MODE (regno)]; i++)
if (hard_regno < 0)
lra_hard_reg_usage[hr + i] -= lra_reg_info[regno].freq;
@@ -668,7 +668,7 @@ spill_for (int regno, bitmap spilled_pse
bitmap_iterator bi, bi2;
rclass = regno_allocno_class_array[regno];
- gcc_assert (reg_renumber[regno] < 0 && rclass != NO_REGS);
+ lra_assert (reg_renumber[regno] < 0 && rclass != NO_REGS);
bitmap_clear (&ignore_pseudos_bitmap);
bitmap_clear (&best_spill_pseudos_bitmap);
EXECUTE_IF_SET_IN_BITMAP (&lra_reg_info[regno].insn_bitmap, 0, uid, bi)
@@ -696,7 +696,7 @@ spill_for (int regno, bitmap spilled_pse
{
if (try_hard_reg_pseudos_check[hard_regno + j] != curr_pseudo_check)
continue;
- gcc_assert (! bitmap_empty_p (&try_hard_reg_pseudos[hard_regno + j]));
+ lra_assert (! bitmap_empty_p (&try_hard_reg_pseudos[hard_regno + j]));
bitmap_ior_into (&spill_pseudos_bitmap,
&try_hard_reg_pseudos[hard_regno + j]);
}
@@ -836,7 +836,7 @@ assign_hard_regno (int hard_regno, int r
{
int i;
- gcc_assert (hard_regno >= 0);
+ lra_assert (hard_regno >= 0);
lra_setup_reg_renumber (regno, hard_regno, true);
update_lives (regno, false);
for (i = 0;
@@ -887,7 +887,7 @@ setup_live_pseudos_and_spill_after_risky
{
regno = sorted_pseudos[i];
hard_regno = reg_renumber[regno];
- gcc_asser
Re: [PATCH] Add DWZ DWARF multifile extensions to dwarf2.{def,h}
> +/* Extensions for DWZ multifile. > + See http://www.dwarfstd.org/ShowIssue.php?issue=120604.1&type=open . */ I'd suggest repeating this comment below: > --- include/dwarf2.h.jj 2012-05-09 20:15:32.0 +0200 > +++ include/dwarf2.h 2012-05-14 12:16:37.414204203 +0200 > @@ -333,6 +333,9 @@ enum dwarf_macro_record_type > DW_MACRO_GNU_define_indirect = 5, > DW_MACRO_GNU_undef_indirect = 6, > DW_MACRO_GNU_transparent_include = 7, > + DW_MACRO_GNU_define_indirect_alt = 8, > + DW_MACRO_GNU_undef_indirect_alt = 9, > + DW_MACRO_GNU_transparent_include_alt = 10, > DW_MACRO_GNU_lo_user = 0xe0, > DW_MACRO_GNU_hi_user = 0xff > }; -cary
Re: Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)
On Fri, Jun 08, 2012 at 02:45:09PM -0400, Jason Merrill wrote:
> On 06/01/2012 01:58 PM, Sterling Augustine wrote:
> >It also adds and documents a new option "-g[no-]pubtypes" which allows users
> >to generate pubtypes even if the target disables them by default.
>
> Hmm, I thought the convention for this sort of flag was to start
> with -f, that -g flags were only for selecting the type and level of
> debug info. But I see that there are other debug dialect switches
> that use -g, so I guess this is OK.
But we have -f{,no-}debug-types-section, so perhaps consistent with that
would be -f{,no-}debug-pubtypes-section ?
Jakub
Re: [PATCH] Add DWZ DWARF multifile extensions to dwarf2.{def,h}
OK. Jason
Re: Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)
On 06/01/2012 01:58 PM, Sterling Augustine wrote: It also adds and documents a new option "-g[no-]pubtypes" which allows users to generate pubtypes even if the target disables them by default. Hmm, I thought the convention for this sort of flag was to start with -f, that -g flags were only for selecting the type and level of debug info. But I see that there are other debug dialect switches that use -g, so I guess this is OK. + if ((TREE_PUBLIC (decl) && !is_class_die (die->die_parent)) Why not include public class members? Is the theory that you'll need to read the type DIE anyway to do anything with the member, so you might as well read it to look up the member in the first place? There should be a comment about this. + VEC_safe_push (pubname_entry, gc, pubtype_table, &e); Why add enumerators to pubtypes rather than pubnames? They seem more like variables than types to me. + here. This isn't protected by the name conditional because anoymous Missing an 'n' in "anonymous". A C++ opaque enumeration is considered complete, but does not yet have its enumerators, which can be added later. Does this code handle that? + if (use_debug_types && names == pubtype_table) This should check pub->die->comdat_type_p Jason
[AVR,committed]: Set case-values-threshold to 7
http://gcc.gnu.org/viewcvs?view=revision&revision=188336 Revision 179760 changed casesi so that the libgcc code to read from the lookup table by means of __tablejump2__ is used unconditionally, i.e. does no more depend on -mcall-prologues. Consequently, casesi costs no more depend on -mcall-prologues since r179769 and are cheaper. This patch adjusts avr_case_values_threshold and set it to 7. Johann * config/avr/avr.c (avr_case_values_threshold): Return 7.
[PATCH] Add DWZ DWARF multifile extensions to dwarf2.{def,h}
Hi! This patch adds dwz -m DWARF extensions. See http://www.dwarfstd.org/ShowIssue.php?issue=120604.1&type=open for more details and http://sourceware.org/git/?p=dwz.git;a=shortlog;h=refs/heads/multifile for the tool that creates it. Compared to the DWARF5 proposal, this is so far implemented as a GNU extension, using different form values. In the GNU implementation, there is a .gnu_debugaltlink section, which contains a zero terminated filename (should be either absolute filename, or filename relative to the directory in which the file with .gnu_debugaltlink section resides) followed by build-id (SHA1 checksum of the debugging sections). Tom Tromey wrote gdb support for these extensions at http://sources.redhat.com/git/?p=archer.git;a=shortlog;h=refs/heads/archer-tromey-dwz-multifile Ok for trunk? 2012-06-08 Jakub Jelinek * dwarf2.def (DW_FORM_GNU_ref_alt, DW_FORM_GNU_strp_alt): New forms. * dwarf2.h (enum dwarf_macro_record_type): Add DW_MACRO_GNU_define_indirect_alt, DW_MACRO_GNU_undef_indirect_alt and DW_MACRO_GNU_transparent_include_alt. --- include/dwarf2.def.jj 2012-05-02 20:33:43.0 +0200 +++ include/dwarf2.def 2012-05-10 08:23:55.912919813 +0200 @@ -205,6 +205,10 @@ DW_FORM (DW_FORM_ref_sig8, 0x20) /* Extensions for Fission. See http://gcc.gnu.org/wiki/DebugFission. */ DW_FORM (DW_FORM_GNU_addr_index, 0x1f01) DW_FORM (DW_FORM_GNU_str_index, 0x1f02) +/* Extensions for DWZ multifile. + See http://www.dwarfstd.org/ShowIssue.php?issue=120604.1&type=open . */ +DW_FORM (DW_FORM_GNU_ref_alt, 0x1f20) +DW_FORM (DW_FORM_GNU_strp_alt, 0x1f21) DW_END_FORM DW_FIRST_AT (DW_AT_sibling, 0x01) --- include/dwarf2.h.jj 2012-05-09 20:15:32.0 +0200 +++ include/dwarf2.h2012-05-14 12:16:37.414204203 +0200 @@ -333,6 +333,9 @@ enum dwarf_macro_record_type DW_MACRO_GNU_define_indirect = 5, DW_MACRO_GNU_undef_indirect = 6, DW_MACRO_GNU_transparent_include = 7, +DW_MACRO_GNU_define_indirect_alt = 8, +DW_MACRO_GNU_undef_indirect_alt = 9, +DW_MACRO_GNU_transparent_include_alt = 10, DW_MACRO_GNU_lo_user = 0xe0, DW_MACRO_GNU_hi_user = 0xff }; Jakub
Re: divide 64-bit by constant for 32-bit target machines
Hi, Paolo. Here is the new version of patch. I have tested this version with gcc testsuite only on i686 without new regressions, for now. Mips and arm tests are in progress. One strange thing I noticed: > > No need for this gen_reg_rtx, either, by passing a NULL_RTX target below. > >> + carry_result = expand_shift (LSHIFT_EXPR, mode, carry, BITS_PER_WORD, >> carry_result, 1); >> + >> + /* Adding 0x1 as carry here if required. */ > > Oops, a remnant of 32-bit specific code. > that I have to add convert_to_mode () to DImode after emit_store_flag_force (), since emit_store_flag_force () returns "carry" in SImode and without convert_to_mode () call compiler fails with this error: Breakpoint 2, simplify_subreg (outermode=SImode, op=0x756cdf20, innermode=DImode, byte=0) at ../../gcc-20120418-1/gcc/simplify-rtx.c:5423 5423 gcc_assert (GET_MODE (op) == innermode (gdb) bt #0 simplify_subreg (outermode=SImode, op=0x756cdf20, innermode=DImode, byte=0) at ../../gcc-20120418-1/gcc/simplify-rtx.c:5423 #1 0x00aea223 in simplify_gen_subreg (outermode=SImode, op=0x756cdf20, innermode=DImode, byte=0) at ../../gcc-20120418-1/gcc/simplify-rtx.c:5763 #2 0x00733c99 in operand_subword (op=0x756cdf20, offset=0, validate_address=1, mode=DImode) at ../../gcc-20120418-1/gcc/emit-rtl.c:1427 #3 0x00733cc6 in operand_subword_force (op=0x756cdf20, offset=0, mode=DImode) at ../../gcc-20120418-1/gcc/emit-rtl.c:1440 #4 0x00a016b3 in expand_binop (mode=DImode, binoptab=0x195f580, op0=0x756cdf20, op1=0x7583d670, target=0x756cdfa0, unsignedp=1, methods=OPTAB_DIRECT) at ../../gcc-20120418-1/gcc/optabs.c:1779 #5 0x007525af in expand_shift_1 (code=LSHIFT_EXPR, mode=DImode, shifted=0x756cdf20, amount=0x7583d670, target=0x0, unsignedp=1) at ../../gcc-20120418-1/gcc/expmed.c:2273 #6 0x007526b6 in expand_shift (code=LSHIFT_EXPR, mode=DImode, shifted=0x756cdf20, amount=32, target=0x0, unsignedp=1) at ../../gcc-20120418-1/gcc/expmed.c:2318 #7 0x007563e6 in expand_mult_highpart_optab (mode=DImode, op0=0x756cdcc0, op1=0x756b1e00, target=0x0, unsignedp=1, max_cost=188) at ../../gcc-20120418-1/gcc/expmed.c:3581 #8 0x00756747 in expand_mult_highpart (mode=DImode, op0=0x756cdcc0, op1=0x756b1e00, target=0x0, unsignedp=1, max_cost=188) at ../../gcc-20120418-1/gcc/expmed.c:3654 thanks, Dinar. 30.patch Description: Binary data
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
On Fri, Jun 08, 2012 at 07:10:02PM +0200, Janus Weil wrote: > >> [Side note: The piece of code which I'm moving contains a FIXME > >> comment, which I don't quite understand, so I'm not sure whether it is > >> still valid. It was added by Steve in > >> http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone > >> have an opinion on this?] > >> > > > > It's been too long! I believe Tobias is > > right that the FIXME had to do allocatable > > components and a walking one or more > > link list. > > Thanks for the comment, Steve. If your FIXME is supposed to mean what > I think it is, then this is being taken care of already by the part > labeled 'b1': For more complicated expressions (involving components > and/or array elements), the check is deferred to > 'resolve_allocate_expr'. > > Of course it would be nice to unify both checks, but I guess at > parsing stage not everything can be checked, and if we only do it at > resolution stage, then the ICE from the present PR becomes a problem > again, so maybe we just leave the two checks for now. > > Attached is a third version of the patch, which I will commit soon. It > adds at least the relevant standard reference to the resolution-stage > check, too, and fixes the regressions resulting from the changed error > message. I suppose the FIXME comment needs to be updated to explain why the b1, b2, and b3 checks are done. But, it has been too long ago when I last played with allocate(), and the code has gotten much more complicated. > > allocate(a(1)%z(1)%x(42)) ! a(1)%z(1) not allocated, no error > > Detecting this would require some run-time checking, which could > become quite involved, I guess. Runtime checking might be possible. But, for a code that hits a bus error, one can run it under valgrind to find the problem. -- Steve
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
> Attached is a third version of the patch, which I will commit soon. It > adds at least the relevant standard reference to the resolution-stage > check, too, and fixes the regressions resulting from the changed error > message. Committed as r188335. Cheers, Janus
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
>> [Side note: The piece of code which I'm moving contains a FIXME >> comment, which I don't quite understand, so I'm not sure whether it is >> still valid. It was added by Steve in >> http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone >> have an opinion on this?] >> > > It's been too long! I believe Tobias is > right that the FIXME had to do allocatable > components and a walking one or more > link list. Thanks for the comment, Steve. If your FIXME is supposed to mean what I think it is, then this is being taken care of already by the part labeled 'b1': For more complicated expressions (involving components and/or array elements), the check is deferred to 'resolve_allocate_expr'. Of course it would be nice to unify both checks, but I guess at parsing stage not everything can be checked, and if we only do it at resolution stage, then the ICE from the present PR becomes a problem again, so maybe we just leave the two checks for now. Attached is a third version of the patch, which I will commit soon. It adds at least the relevant standard reference to the resolution-stage check, too, and fixes the regressions resulting from the changed error message. > allocate(a(1)%z(1)%x(42)) ! a(1)%z(1) not allocated, no error Detecting this would require some run-time checking, which could become quite involved, I guess. Cheers, Janus pr52552.diff Description: Binary data
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
On Fri, Jun 08, 2012 at 12:40:10PM +0200, Janus Weil wrote: > > [Side note: The piece of code which I'm moving contains a FIXME > comment, which I don't quite understand, so I'm not sure whether it is > still valid. It was added by Steve in > http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone > have an opinion on this?] > It's been too long! I believe Tobias is right that the FIXME had to do allocatable components and a walking one or more link list. troutmask:sgk[207] gfc4x -o z foo.f90 troutmask:sgk[208] ./z Bus error (core dumped) program foo type bah real, allocatable :: x(:) end type bah type bar integer, allocatable :: i(:) type(bah), allocatable :: z(:) end type bar type(bar), allocatable :: a(:) allocate(a(2)) ! Should be ok allocate(a(1)%z(1)%x(42)) ! a(1)%z(1) not allocated, no error end program foo -- Steve
[PATCH] Add vector cost model density heuristic
This patch adds a heuristic to the vectorizer when estimating the
minimum profitable number of iterations. The heuristic is
target-dependent, and is currently disabled for all targets except
PowerPC. However, the intent is to make it general enough to be useful
for other targets that want to opt in.
A previous patch addressed some PowerPC SPEC degradations by modifying
the vector cost model values for vec_perm and vec_promote_demote. The
values were set a little higher than their natural values because the
natural values were not sufficient to prevent a poor vectorization
choice. However, this is not the right long-term solution, since it can
unnecessarily constrain other vectorization choices involving permute
instructions.
Analysis of the badly vectorized loop (in sphinx3) showed that the
problem was overcommitment of vector resources -- too many vector
instructions issued without enough non-vector instructions available to
cover the delays. The vector cost model assumes that instructions
always have a constant cost, and doesn't have a way of judging this kind
of "density" of vector instructions.
The present patch adds a heuristic to recognize when a loop is likely to
overcommit resources, and adds a small penalty to the inside-loop cost
to account for the expected stalls. The heuristic is parameterized with
three target-specific values:
* Density threshold: The heuristic will apply only when the
percentage of inside-loop cost attributable to vectorized
instructions exceeds this value.
* Size threshold: The heuristic will apply only when the
inside-loop cost exceeds this value.
* Penalty: The inside-loop cost will be increased by this
percentage value when the heuristic applies.
Thus only reasonably large loop bodies that are mostly vectorized
instructions will be affected.
By applying only a small percentage bump to the inside-loop cost, the
heuristic will only turn off vectorization for loops that were
considered "barely profitable" to begin with (such as the sphinx3 loop).
So the heuristic is quite conservative and should not affect the vast
majority of vectorization decisions.
Together with the new heuristic, this patch reduces the vec_perm and
vec_promote_demote costs for PowerPC to their natural values.
I've regstrapped this with no regressions on powerpc64-unknown-linux-gnu
and verified that no performance regressions occur on SPEC cpu2006. Is
this ok for trunk?
Thanks,
Bill
2012-06-08 Bill Schmidt
* doc/tm.texi.in: Add vectorization density hooks.
* doc/tm.texi: Regenerate.
* targhooks.c (default_density_pct_threshold): New.
(default_density_size_threshold): New.
(default_density_penalty): New.
* targhooks.h: New decls for new targhooks.c functions.
* target.def (density_pct_threshold): New DEF_HOOK.
(density_size_threshold): Likewise.
(density_penalty): Likewise.
* tree-vect-loop.c (accum_stmt_cost): New.
(vect_estimate_min_profitable_iters): Perform density test.
* config/rs6000/rs6000.c (TARGET_VECTORIZE_DENSITY_PCT_THRESHOLD):
New macro definition.
(TARGET_VECTORIZE_DENSITY_SIZE_THRESHOLD): Likewise.
(TARGET_VECTORIZE_DENSITY_PENALTY): Likewise.
(rs6000_builtin_vectorization_cost): Reduce costs of vec_perm and
vec_promote_demote to correct values.
(rs6000_density_pct_threshold): New.
(rs6000_density_size_threshold): New.
(rs6000_density_penalty): New.
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 188305)
+++ gcc/doc/tm.texi (working copy)
@@ -5798,6 +5798,27 @@ The default is @code{NULL_TREE} which means to not
loads.
@end deftypefn
+@deftypefn {Target Hook} int TARGET_VECTORIZE_DENSITY_PCT_THRESHOLD (void)
+This hook should return the maximum density, expressed in percent, for
+which autovectorization of loops with large bodies should be constrained.
+See also @code{TARGET_VECTORIZE_DENSITY_SIZE_THRESHOLD}. The default
+is to return 100, which disables the density test.
+@end deftypefn
+
+@deftypefn {Target Hook} int TARGET_VECTORIZE_DENSITY_SIZE_THRESHOLD (void)
+This hook should return the minimum estimated size of a vectorized
+loop body for which the density test should apply. See also
+@code{TARGET_VECTORIZE_DENSITY_PCT_THRESHOLD}. The default is set
+to the unreasonable value of 100, which effectively disables
+the density test.
+@end deftypefn
+
+@deftypefn {Target Hook} int TARGET_VECTORIZE_DENSITY_PENALTY (void)
+This hook should return the penalty, expressed in percent, to be applied
+to the inside-of-loop vectorization costs for a loop failing the density
+test. The default is 10.
+@end deftypefn
+
@node Anchored Addresses
@section Anchored Addresses
@cindex anchored addresses
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.te
[PATCH] Fix libgo testsuite
This fixes most of the libgo testsuite failures.
Andreas.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index 1d761bc..7923567 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -1806,6 +1806,7 @@ CHECK = \
LD_LIBRARY_PATH="`${PWD_COMMAND}`/.libs:$${libgccdir}:${LD_LIBRARY_PATH}"; \
LD_LIBRARY_PATH=`echo $${LD_LIBRARY_PATH} | sed
's,::*,:,g;s,^:*,,;s,:*$$,,'`; \
export LD_LIBRARY_PATH; \
+ $(MKDIR_P) $(@D); \
rm -f $@-testsum $@-testlog; \
if test "$(use_dejagnu)" = "yes"; then \
$(SHELL) $(srcdir)/testsuite/gotest --dejagnu=yes --basedir=$(srcdir)
--srcdir=$(srcdir)/go/$(@D) --pkgpath="$(@D)" --pkgfiles="$(go_$(subst
/,_,$(@D))_files)" --testname="$(@D)" --goarch="$(GOARCH)" $(GOTESTFLAGS); \
@@ -2106,7 +2107,6 @@ archive/tar.lo.dep: $(go_archive_tar_files)
archive/tar.lo: $(go_archive_tar_files)
$(BUILDPACKAGE)
archive/tar/check: $(CHECK_DEPS)
- @$(MKDIR_P) archive/tar
@$(CHECK)
.PHONY: archive/tar/check
@@ -2116,7 +2116,6 @@ archive/zip.lo.dep: $(go_archive_zip_files)
archive/zip.lo: $(go_archive_zip_files)
$(BUILDPACKAGE)
archive/zip/check: $(CHECK_DEPS)
- @$(MKDIR_P) archive/zip
@$(CHECK)
.PHONY: archive/zip/check
@@ -2126,7 +2125,6 @@ compress/bzip2.lo.dep: $(go_compress_bzip2_files)
compress/bzip2.lo: $(go_compress_bzip2_files)
$(BUILDPACKAGE)
compress/bzip2/check: $(CHECK_DEPS)
- @$(MKDIR_P) compress/bzip2
@$(CHECK)
.PHONY: compress/bzip2/check
@@ -2136,7 +2134,6 @@ compress/flate.lo.dep: $(go_compress_flate_files)
compress/flate.lo: $(go_compress_flate_files)
$(BUILDPACKAGE)
compress/flate/check: $(CHECK_DEPS)
- @$(MKDIR_P) compress/flate
@$(CHECK)
.PHONY: compress/flate/check
@@ -2146,7 +2143,6 @@ compress/gzip.lo.dep: $(go_compress_gzip_files)
compress/gzip.lo: $(go_compress_gzip_files)
$(BUILDPACKAGE)
compress/gzip/check: $(CHECK_DEPS)
- @$(MKDIR_P) compress/gzip
@$(CHECK)
.PHONY: compress/gzip/check
@@ -2156,7 +2152,6 @@ compress/lzw.lo.dep: $(go_compress_lzw_files)
compress/lzw.lo: $(go_compress_lzw_files)
$(BUILDPACKAGE)
compress/lzw/check: $(CHECK_DEPS)
- @$(MKDIR_P) compress/lzw
@$(CHECK)
.PHONY: compress/lzw/check
@@ -2166,7 +2161,6 @@ compress/zlib.lo.dep: $(go_compress_zlib_files)
compress/zlib.lo: $(go_compress_zlib_files)
$(BUILDPACKAGE)
compress/zlib/check: $(CHECK_DEPS)
- @$(MKDIR_P) compress/zlib
@$(CHECK)
.PHONY: compress/zlib/check
@@ -2176,7 +2170,6 @@ container/heap.lo.dep: $(go_container_heap_files)
container/heap.lo: $(go_container_heap_files)
$(BUILDPACKAGE)
container/heap/check: $(CHECK_DEPS)
- @$(MKDIR_P) container/heap
@$(CHECK)
.PHONY: container/heap/check
@@ -2186,7 +2179,6 @@ container/list.lo.dep: $(go_container_list_files)
container/list.lo: $(go_container_list_files)
$(BUILDPACKAGE)
container/list/check: $(CHECK_DEPS)
- @$(MKDIR_P) container/list
@$(CHECK)
.PHONY: container/list/check
@@ -2196,7 +2188,6 @@ container/ring.lo.dep: $(go_container_ring_files)
container/ring.lo: $(go_container_ring_files)
$(BUILDPACKAGE)
container/ring/check: $(CHECK_DEPS)
- @$(MKDIR_P) container/ring
@$(CHECK)
.PHONY: container/ring/check
@@ -2206,7 +2197,6 @@ crypto/aes.lo.dep: $(go_crypto_aes_files)
crypto/aes.lo: $(go_crypto_aes_files)
$(BUILDPACKAGE)
crypto/aes/check: $(CHECK_DEPS)
- @$(MKDIR_P) crypto/aes
@$(CHECK)
.PHONY: crypto/aes/check
@@ -2216,7 +2206,6 @@ crypto/cipher.lo.dep: $(go_crypto_cipher_files)
crypto/cipher.lo: $(go_crypto_cipher_files)
$(BUILDPACKAGE)
crypto/cipher/check: $(CHECK_DEPS)
- @$(MKDIR_P) crypto/cipher
@$(CHECK)
.PHONY: crypto/cipher/check
@@ -2226,7 +2215,6 @@ crypto/des.lo.dep: $(go_crypto_des_files)
crypto/des.lo: $(go_crypto_des_files)
$(BUILDPACKAGE)
crypto/des/check: $(CHECK_DEPS)
- @$(MKDIR_P) crypto/des
@$(CHECK)
.PHONY: crypto/des/check
@@ -2236,7 +2224,6 @@ crypto/dsa.lo.dep: $(go_crypto_dsa_files)
crypto/dsa.lo: $(go_crypto_dsa_files)
$(BUILDPACKAGE)
crypto/dsa/check: $(CHECK_DEPS)
- @$(MKDIR_P) crypto/dsa
@$(CHECK)
.PHONY: crypto/dsa/check
@@ -2246,7 +2233,6 @@ crypto/ecdsa.lo.dep: $(go_crypto_ecdsa_files)
crypto/ecdsa.lo: $(go_crypto_ecdsa_files)
$(BUILDPACKAGE)
crypto/ecdsa/check: $(CHECK_DEPS)
- @$(MKDIR_P) crypto/ecdsa
@$(CHECK)
.PHONY: crypto/ecdsa/check
@@ -2256,7 +2242,6 @@ crypto/elliptic.lo.dep: $(go_crypto_elliptic_files)
crypto/elliptic.lo: $(go_crypto_elliptic_files)
$(BUILDPACKAGE)
crypto/elliptic/check: $(CHECK_DEPS)
- @$(MKDIR_P) crypto/elliptic
@$(CHECK)
.PHONY: crypto/elliptic/check
@@ -2266,7 +2251,6 @@ crypto/hmac.lo.dep: $(go_crypto_hmac_files)
crypto/hmac.lo: $(go_crypto_hmac_files)
$(BUILDPACKAGE)
crypto/hmac/check:
Re: libgo patch committed: Fix testsuite on PPC
Ian Lance Taylor writes:
> @@ -326,13 +336,18 @@
> }
>
> {
> + text="T"
> + case "$GOARCH" in
> + ppc*) text="D" ;;
This is wrong for ppc.
Andreas.
diff --git a/libgo/testsuite/gotest b/libgo/testsuite/gotest
index da1162e..208cbaf 100755
--- a/libgo/testsuite/gotest
+++ b/libgo/testsuite/gotest
@@ -355,7 +355,7 @@ localname() {
{
text="T"
case "$GOARCH" in
- ppc*) text="D" ;;
+ ppc64) text="D" ;;
esac
symtogo='sed -e s/_test/XXXtest/ -e s/.*_\([^_]*\.\)/\1/ -e
s/XXXtest/_test/'
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
Janus Weil wrote: In any case, for those two, it does not trigger but one gets later (resolve?) the error: Error: Allocate-object at (1) must be ALLOCATABLE or a POINTER Then I guess one can just remove the FIXME. That's fine with me. Regarding the error: Error: Allocate-object at (1) is neither a nonprocedure pointer nor an allocatable variable I wonder whether one should put parentheses around nonprocedure; I tend to misread it; namely: Error: Allocate-object at (1) is neither a (nonprocedure) pointer nor an allocatable variable One could also use "... is neither a data pointer ...", which should have the same meaning I think that's better. By the way, I wonder whether one shouldn't unify the error message between match.c and resolve.c; there is no real reason to have two different strings. A new version of the patch is attached, which removes the FIXME and changes the wording of the error message (will re-check for regressions due to the changed wording). Thanks! Tobias
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
Hi, >> here is a patch for an ICE-on-invalid bug, which concerns the >> allocation of CLASS variables. The ICE is fixed by changing the order >> of the checks which are done in gfc_match_allocate, so that an error >> is triggered before the ICE can occur. >> >> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? > > > Okay. Thanks for the patch! Thanks. Will commit soon. >> [Side note: The piece of code which I'm moving contains a FIXME >> comment, which I don't quite understand, so I'm not sure whether it is >> still valid. It was added by Steve in >> http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone >> have an opinion on this?] > > > Good question. I read the FIXME such that one still needs to add a > diagnostic for a%comp and nonalloc_array(4,4). Though, one can also read it > the other way round. I tend to read it the other way round, but that reading does not really make sense to me. > In any case, for those two, it does not trigger but one > gets later (resolve?) the error: > > Error: Allocate-object at (1) must be ALLOCATABLE or a POINTER Then I guess one can just remove the FIXME. > Regarding the error: > > Error: Allocate-object at (1) is neither a nonprocedure pointer nor an > allocatable variable > > I wonder whether one should put parentheses around nonprocedure; I tend to > misread it; namely: > > Error: Allocate-object at (1) is neither a (nonprocedure) pointer nor an > allocatable variable One could also use "... is neither a data pointer ...", which should have the same meaning (there are two kinds of pointers in the Fortran standard: data pointers and procedure pointers). This also fits better the wording in the F08 standard: C628 (R632) Each allocate-object shall be a data pointer or an allocatable variable. A new version of the patch is attached, which removes the FIXME and changes the wording of the error message (will re-check for regressions due to the changed wording). Cheers, Janus pr52552.diff Description: Binary data
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
Hi, Janus Weil wrote: here is a patch for an ICE-on-invalid bug, which concerns the allocation of CLASS variables. The ICE is fixed by changing the order of the checks which are done in gfc_match_allocate, so that an error is triggered before the ICE can occur. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Okay. Thanks for the patch! [Side note: The piece of code which I'm moving contains a FIXME comment, which I don't quite understand, so I'm not sure whether it is still valid. It was added by Steve in http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone have an opinion on this?] Good question. I read the FIXME such that one still needs to add a diagnostic for a%comp and nonalloc_array(4,4). Though, one can also read it the other way round. In any case, for those two, it does not trigger but one gets later (resolve?) the error: Error: Allocate-object at (1) must be ALLOCATABLE or a POINTER Regarding the error: Error: Allocate-object at (1) is neither a nonprocedure pointer nor an allocatable variable I wonder whether one should put parentheses around nonprocedure; I tend to misread it; namely: Error: Allocate-object at (1) is neither a (nonprocedure) pointer nor an allocatable variable Tobias 2012-06-08 Janus Weil PR fortran/52552 * match.c (gfc_match_allocate): Modify order of checks. 2012-06-08 Janus Weil PR fortran/52552 * gfortran.dg/allocate_with_typespec_7.f90: New test case.
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
> [Side note: The piece of code which I'm moving contains a FIXME > comment, which I don't quite understand, so I'm not sure whether it is > still valid. It was added by Steve in > http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone > have an opinion on this?] Possibly the comment refers to the problems raised in http://gcc.gnu.org/ml/fortran/2008-12/msg00167.html However, both of the code snippets given there are correctly treated by the current trunk, so I guess these issues have been taken care of by now and one can remove the FIXME (anyway, it does not really seem to apply directly to the check it precedes, or maybe I just fail to see how). Cheers, Janus
Re: [PATCH, WWWDOCS] Document AArch64 branch.
On 06/06/12 21:45, Gerald Pfeifer wrote: Looks good to me. (Note, that as someone with write access to the GCC repository you don't need approval for changes like this, though I am always happy to look at changes.) Ok, thank you, I hadn't realized approval was not required. Change committed. /Marcus
[Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
Hi all, here is a patch for an ICE-on-invalid bug, which concerns the allocation of CLASS variables. The ICE is fixed by changing the order of the checks which are done in gfc_match_allocate, so that an error is triggered before the ICE can occur. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? [Side note: The piece of code which I'm moving contains a FIXME comment, which I don't quite understand, so I'm not sure whether it is still valid. It was added by Steve in http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone have an opinion on this?] Cheers, Janus 2012-06-08 Janus Weil PR fortran/52552 * match.c (gfc_match_allocate): Modify order of checks. 2012-06-08 Janus Weil PR fortran/52552 * gfortran.dg/allocate_with_typespec_7.f90: New test case. pr52552.diff Description: Binary data allocate_with_typespec_7.f90 Description: Binary data
Re: [PATCH] libatomic, v2
Richard Henderson writes:
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index 1a25324..b93dc5c 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -3795,6 +3795,8 @@ proc check_effective_target_sync_long_long_runtime { } {
>&& [check_effective_target_lp64]
>&& [check_effective_target_ultrasparc_hw]) } {
> return 1
> +} elseif { [check_effective_target_powerpc64] } {
> + return 1
This is wrong. check_effective_target_powerpc64 tests whether the
target can execute 64-bit insns, but that doesn't say anything about
whether the compiler can make use of them (-mno-powerpc64 can't, which
is the default for -m32 on linux).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [ARM Patch 1/n] PR53447: optimizations of 64bit ALU operation with constant
Hi
In rtl expression, substract a constant c is expressed as add a value -c, so it
is alse processed by adddi3, and I extend it more to handle a subtraction of
64bit constant. I created an insn pattern arm_subdi3_immediate to specifically
represent substraction with 64bit constant while continue keeping the add rtl
expression.
Tested on arm qemu with both arm/thumb modes. OK for trunk?
thanks
Carrot
2012-06-08 Wei Guozhi
PR target/53447
* gcc.target/arm/pr53447-1.c: New testcase.
* gcc.target/arm/pr53447-5.c: New testcase.
2012-06-08 Wei Guozhi
PR target/53447
* config/arm/constraints.md (Dd): New constraint.
* config/arm/predicates.md (arm_neg_immediate_di_operand): New
predicate.
* config/arm/arm.md (adddi3): Extend it to handle constants.
(arm_subdi3_immediate): New insn pattern.
(arm_adddi3): Extend it to handle constants.
* config/arm/neon.md (adddi3_neon): Likewise.
Index: testsuite/gcc.target/arm/pr53447-1.c
===
--- testsuite/gcc.target/arm/pr53447-1.c(revision 0)
+++ testsuite/gcc.target/arm/pr53447-1.c(revision 0)
@@ -0,0 +1,8 @@
+/* { dg-options "-O2" } */
+/* { dg-require-effective-target arm32 } */
+/* { dg-final { scan-assembler-not "mov" } } */
+
+void t0p(long long * p)
+{
+ *p += 0x10001;
+}
Index: testsuite/gcc.target/arm/pr53447-5.c
===
--- testsuite/gcc.target/arm/pr53447-5.c(revision 0)
+++ testsuite/gcc.target/arm/pr53447-5.c(revision 0)
@@ -0,0 +1,8 @@
+/* { dg-options "-O2" } */
+/* { dg-require-effective-target arm32 } */
+/* { dg-final { scan-assembler-not "mov" } } */
+
+void t0p(long long * p)
+{
+ *p -= 0x10008;
+}
Index: config/arm/neon.md
===
--- config/arm/neon.md (revision 187751)
+++ config/arm/neon.md (working copy)
@@ -588,9 +588,9 @@
)
(define_insn "adddi3_neon"
- [(set (match_operand:DI 0 "s_register_operand" "=w,?&r,?&r,?w")
-(plus:DI (match_operand:DI 1 "s_register_operand" "%w,0,0,w")
- (match_operand:DI 2 "s_register_operand" "w,r,0,w")))
+ [(set (match_operand:DI 0 "s_register_operand" "=w,?&r,?&r,?w,?&r,?&r,?&r")
+(plus:DI (match_operand:DI 1 "s_register_operand" "%w,0,0,w,r,0,r")
+ (match_operand:DI 2 "arm_di_operand" "w,r,0,w,r,Di,Di")))
(clobber (reg:CC CC_REGNUM))]
"TARGET_NEON"
{
@@ -600,13 +600,16 @@
case 3: return "vadd.i64\t%P0, %P1, %P2";
case 1: return "#";
case 2: return "#";
+case 4: return "#";
+case 5: return "#";
+case 6: return "#";
default: gcc_unreachable ();
}
}
- [(set_attr "neon_type" "neon_int_1,*,*,neon_int_1")
- (set_attr "conds" "*,clob,clob,*")
- (set_attr "length" "*,8,8,*")
- (set_attr "arch" "nota8,*,*,onlya8")]
+ [(set_attr "neon_type" "neon_int_1,*,*,neon_int_1,*,*,*")
+ (set_attr "conds" "*,clob,clob,*,clob,clob,clob")
+ (set_attr "length" "*,8,8,*,8,8,8")
+ (set_attr "arch" "nota8,*,*,onlya8,*,*,*")]
)
(define_insn "*sub3_neon"
Index: config/arm/constraints.md
===
--- config/arm/constraints.md (revision 187751)
+++ config/arm/constraints.md (working copy)
@@ -29,7 +29,7 @@
;; in Thumb-1 state: I, J, K, L, M, N, O
;; The following multi-letter normal constraints have been used:
-;; in ARM/Thumb-2 state: Da, Db, Dc, Dn, Dl, DL, Dv, Dy, Di, Dt, Dz
+;; in ARM/Thumb-2 state: Da, Db, Dc, Dd, Dn, Dl, DL, Dv, Dy, Di, Dt, Dz
;; in Thumb-1 state: Pa, Pb, Pc, Pd, Pe
;; in Thumb-2 state: Pj, PJ, Ps, Pt, Pu, Pv, Pw, Px, Py
@@ -251,6 +251,13 @@
(match_test "TARGET_32BIT && arm_const_double_inline_cost (op) == 4
&& !(optimize_size || arm_ld_sched)")))
+(define_constraint "Dd"
+ "@internal
+ In ARM/Thumb-2 state a const_int whose negative value satisfy constraint
+ Di."
+ (and (match_code "const_int")
+ (match_test "TARGET_32BIT && arm_const_double_by_immediates
(GEN_INT (-ival))")))
+
(define_constraint "Di"
"@internal
In ARM/Thumb-2 state a const_int or const_double where both the high
Index: config/arm/predicates.md
===
--- config/arm/predicates.md(revision 187751)
+++ config/arm/predicates.md(working copy)
@@ -117,6 +117,10 @@
(and (match_code "const_int,const_double")
(match_test "arm_const_double_by_immediates (op)")))
+(define_predicate "arm_neg_immediate_di_operand"
+ (and (match_code "const_int")
+ (match_test "arm_const_double_by_immediates (GEN_INT (-INTVAL (op)))")))
+
(define_predicate "arm_neg_immediate_operand"
(and (match_code "const_int")
(match_test "const_ok_for_arm (-INTVAL (op))")))
Index: config/arm/arm.md
=
[arm-embedded] Backport mainline r182621, r182628, r183095, r183349, r183756, r184442
Committed to ARM/embedded-4_6-branch 2012-06-08 Joey Ye Backport r184442 from mainline 2012-02-21 Richard Earnshaw PR target/52294 * thumb2.md (thumb2_shiftsi3_short): Split register and immediate shifts. For register shifts tie operands 0 and 1. (peephole2 for above): Check that register-controlled shifts have suitably tied operands. Backport r183756 from mainline 2012-01-31 Matthew Gretton-Dann * config/arm/thumb2.md (thumb2_mov_notscc): Use MVN for true condition. Backport r183349 from mainline 2012-01-20 Jakub Jelinek PR target/51915 * config/arm/arm.c (arm_count_output_move_double_insns): Call output_move_double on a copy of operands array. Backport r183095 from mainline 2012-01-11 Matthew Gretton-Dann * config/arm/arm.md (mov_notscc): Use MVN for false condition. Backport r182628 from mainline 2011-12-21 Richard Earnshaw PR target/51643 * arm.c (arm_function_ok_for_sibcall): Use DECL_WEAK in previous change. Backport r182621 from mainline 2011-12-21 Richard Earnshaw PR target/51643 * arm.c (arm_function_ok_for_sibcall): Don't try to tailcall a weak function on bare-metal EABI targets. Testsuite: Backport r183349 from mainline 2012-01-20 Jakub Jelinek PR target/51915 * gcc.target/arm/pr51915.c: New test. Backport r183095 from mainline 2012-01-11 Matthew Gretton-Dann * gcc.c-torture/execute/20120110-1.c: New testcase. Backport r182621 from mainline 2011-12-21 Richard Earnshaw PR target/51643 * gcc.target/arm/sibcall-2.c: New test.
Re: [AArch64] Use snprintf instead sprintf
On 01/06/12 09:53, Sofiane Naci wrote: Hi, This patch replaces instances of sprintf with snprintf with sizeof(..) in the AArch64 port. It also fixes layout issues in the code it touches. Thanks Sofiane - ChangeLog 2012-06-01 Sofiane Naci [AArch64] Replace sprintf with snprintf. * config/aarch64/aarch64.c (aarch64_elf_asm_constructor): Replace sprintf with snprintf. (aarch64_elf_asm_destructor): Likewise. (aarch64_output_casesi): Likewise. (aarch64_output_asm_insn): Likewise. * config/aarch64/aarch64-builtins.c (init_aarch64_simd_builtins): Likewise. * config/aarch64/aarch64-simd.md (*aarch64_simd_mov): Replace sprintf with snprintf, and fix code layout. OK for aarch64 branch. /Marcus
Re: [PATCH, GCC][AArch64] Use Enums for TLS dialect option selection
On 01/06/12 09:56, Sofiane Naci wrote: Hi, This patch re-factors TLS dialect option selection in the AArch64 port to use the generic support for enumerated option arguments. Thanks Sofiane - 2012-06-01 Sofiane Naci [AArch64] Use Enums for TLS option selection. * config/aarch64/aarch64-opts.h (enum aarch64_tls_type): New. * config/aarch64/aarch64.c (aarch64_tls_dialect): Remove. (tls_symbolic_operand_type): Update comment. (aarch64_override_options): Remove TLS option setup code. * config/aarch64/aarch64.h (TARGET_TLS_TRADITIONAL): Remove. (TARGET_TLS_DESC): Update definition. (enum tls_dialect): Remove. (enum tls_dialect aarch64_tls_dialect) Remove. * config/aarch64/aarch64.opt (tls_type): New. (mtls-dialect): Update. OK for aarch64 branch. /Marcus
Re: [PATCH][AARCH64][libgcc] Remove t-softfp-sfdf and t-softfp-excl from aarch64 configuration
On 01/06/12 14:29, Jim MacArthur wrote: In response to a comment from http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01721.html, this patch removes t-softfp-sfdf and t-softfp-excl from the aarch64 entries in libgcc/config.host. Every setting in these files is overridden by t-softfp. Addition to libgcc/ChangeLog: 2012-06-01 Jim MacArthur * config.host (aarch64*-*-elf): Remove references to t-softfp-sfdf and t-softfp-excl. (aarch64*-*-linux*): Likewise. Committed to aarch64 branch. /Marcus
Merge from gcc 4.7 branch to gccgo branch
I've merged revision 188326 from the gcc 4.7 branch to the gccgo branch. I also included the two patches I sent out and have committed to mainline but have not yet committed to 4.7 branch. Ian
Re: [AARCH64][libgcc] Add __aarch64_sync_cache_range as lib2func
On 31/05/12 16:33, Jim MacArthur wrote: * config/aarch64/sync-cache.S: New file. Corrected to sync-cache.c and committed to aarch64 branch. /Marcus
Re: [PATCH][AARCH64] Remove t-aarch64 from libgcc
On 29/05/12 09:31, Jim MacArthur wrote: 2012-05-28 Jim MacArthur * config/aarch64/t-aarch64: Delete. * config.host (aarch64*-*-elf): Remove reference to t-aarch64. I've committed this patch to the aarch64 branch. /Marcus
