[Committed] S/390: Define TARGET_FLT_EVAL_METHOD
I've committed the attached patch. 2013-03-27 Andreas Krebbel * config/s390/s390.h (TARGET_FLT_EVAL_METHOD): Define. --- gcc/config/s390/s390.h |5 + 1 file changed, 5 insertions(+) Index: gcc/config/s390/s390.h === *** gcc/config/s390/s390.h.orig --- gcc/config/s390/s390.h *** enum processor_flags *** 164,169 --- 164,174 #define S390_TDC_INFINITY (S390_TDC_POSITIVE_INFINITY \ | S390_TDC_NEGATIVE_INFINITY ) + /* This is used by float.h to define the float_t and double_t data +types. For historical reasons both are double on s390 what cannot +be changed anymore. */ + #define TARGET_FLT_EVAL_METHOD 1 + /* Target machine storage layout. */ /* Everything is big-endian. */
RE: [PATCH GCC/ARM]Fix rtx cost for Thumb1
> -Original Message-
> From: Richard Earnshaw
> Sent: Tuesday, March 26, 2013 6:57 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH GCC/ARM]Fix rtx cost for Thumb1
>
> On 26/03/13 08:34, Bin Cheng wrote:
> > Hi,
> > As reported in PR56102, arm back end returns wrong rtx cost for
> > pattern SET/ASHIFT/ASHIFTRT/LSHIFTRT/ROTATERT with multi-word mode.
> > This causes GCC skipping the split process in lower-subreg.c, and
> > generating bigger constant pool.
> >
> > This patch fixes the issue. Tested on arm-none-eabi/thumb1/O2/Os, ok
> > for trunk?
> >
> > Thanks.
> >
> > 2013-03-26 Bin Cheng
> >
> > PR target/56102
> > * config/arm/arm.c (thumb1_rtx_costs, thumb1_size_rtx_costs): Fix
> > rtx costs for SET/ASHIFT/ASHIFTRT/LSHIFTRT/ROTATERT patterns with
> > mult-word mode.
> >
>
Sorry that I mis-sent the old version patch. The right one is attached now.
Since the difference is obvious and was approved before this thread, I
committed it directly as revision 197155.
Thanks.Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 197154)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2013-03-27 Bin Cheng
+
+ PR target/56102
+ * config/arm/arm.c (thumb1_rtx_costs, thumb1_size_rtx_costs): Fix
+ rtx costs for SET/ASHIFT/ASHIFTRT/LSHIFTRT/ROTATERT patterns with
+ mult-word mode.
+
2013-03-27 Andreas Krebbel
* config/s390/s390.h (TARGET_FLT_EVAL_METHOD): Define.
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 197154)
+++ gcc/config/arm/arm.c(working copy)
@@ -7116,7 +7116,7 @@ static inline int
thumb1_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer)
{
enum machine_mode mode = GET_MODE (x);
- int total;
+ int total, words;
switch (code)
{
@@ -7124,6 +7124,8 @@ thumb1_rtx_costs (rtx x, enum rtx_code code, enum
case ASHIFTRT:
case LSHIFTRT:
case ROTATERT:
+ return (mode == SImode) ? COSTS_N_INSNS (1) : COSTS_N_INSNS (2);
+
case PLUS:
case MINUS:
case COMPARE:
@@ -7147,7 +7149,10 @@ thumb1_rtx_costs (rtx x, enum rtx_code code, enum
return COSTS_N_INSNS (1) + 16;
case SET:
- return (COSTS_N_INSNS (1)
+ /* A SET doesn't have a mode, so let's look at the SET_DEST to get
+the mode. */
+ words = ARM_NUM_INTS (GET_MODE_SIZE (GET_MODE (SET_DEST (x;
+ return (COSTS_N_INSNS (words)
+ 4 * ((MEM_P (SET_SRC (x)))
+ MEM_P (SET_DEST (x;
@@ -7844,6 +7849,7 @@ static inline int
thumb1_size_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer)
{
enum machine_mode mode = GET_MODE (x);
+ int words;
switch (code)
{
@@ -7851,6 +7857,8 @@ thumb1_size_rtx_costs (rtx x, enum rtx_code code,
case ASHIFTRT:
case LSHIFTRT:
case ROTATERT:
+ return (mode == SImode) ? COSTS_N_INSNS (1) : COSTS_N_INSNS (2);
+
case PLUS:
case MINUS:
case COMPARE:
@@ -7869,7 +7877,10 @@ thumb1_size_rtx_costs (rtx x, enum rtx_code code,
return COSTS_N_INSNS (1);
case SET:
- return (COSTS_N_INSNS (1)
+ /* A SET doesn't have a mode, so let's look at the SET_DEST to get
+the mode. */
+ words = ARM_NUM_INTS (GET_MODE_SIZE (GET_MODE (SET_DEST (x;
+ return (COSTS_N_INSNS (words)
+ 4 * ((MEM_P (SET_SRC (x)))
+ MEM_P (SET_DEST (x;
[Patch, fortran] optimize string comparison
Hi,
as I looked to compare_string I discovered that it could be
optimized. This speeds up case when strings are equal but we must check
padding where checking it byte by byte is suboptimal.
Ondra
2013-03-27 Ondřej Bílka
* libgfortran/intrinsics/string_intrinsics_inc.c (compare_string):
Optimize.
diff --git a/libgfortran/intrinsics/string_intrinsics_inc.c
b/libgfortran/intrinsics/string_intrinsics_inc.c
index a1f86b5..9eb0613 100644
--- a/libgfortran/intrinsics/string_intrinsics_inc.c
+++ b/libgfortran/intrinsics/string_intrinsics_inc.c
@@ -107,16 +107,15 @@ compare_string (gfc_charlen_type len1, const CHARTYPE *s1,
res = 1;
}
- while (len--)
+ s = memchr (s, ' ', len);
+ if (!s)
+ return 0;
+ if (*s != ' ')
{
- if (*s != ' ')
-{
- if (*s > ' ')
-return res;
- else
-return -res;
-}
- s++;
+ if (*s > ' ')
+return res;
+ else
+return -res;
}
return 0;
Re: [patch, fortran] Use memcmp() for string comparison for constant-length kind=1 strings
On Tue, Mar 26, 2013 at 11:53:27PM +0200, Janne Blomqvist wrote: > On Mon, Mar 25, 2013 at 7:00 PM, Thomas Koenig wrote: > > Hello world, > > > > this patch uses memcpy() directly when comparing two kind=1 strings of > > equal and constant lengths. The test case modification depends > > on the previous patch at > > Could you omit of equal lengths part? Do memcmp with minimum of lengths and if not equal call compare_string for suffixes. > > http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00996.html > > > > for setting the string lengths for substrings. > > > > Regression-tested. No extra test case because the original test > > cases have to be modified to avoid failure, and test the new > > feature. OK for trunk after committing the patch above? > > > > 2013-03-25 Thomas Koenig > > > > * trans-expr.c (build_memcmp_call): New function. > > (gfc_build_compare_string): If the kind=1 strings to be > > compared have constant and equal lengths, use > > memcmp(). > > > > 2013-03-25 Thomas Koenig > > > > * gfortran.dg/character_comparison_3.f90: Adjust for use of memcmp > > for constant and equal string lengths. > > * gfortran.dg/character_comparison_5.f90: Likewise. > > Ok. I think the same optimization could be done for kind=4 strings as > well, but nobody probably uses those anyway.. > > > -- > Janne Blomqvist
Re: BUILD PATCH: Support source file with .cc extension
Il 26/03/2013 21:48, Gabriel Dos Reis ha scritto: > > Hi Paolo, > > The patchlet below allows uses of source file with .cc extension. > > This comes out of work being done on the C++ front-end and has merit of > its own. OK to apply? > > Thanks, > > -- Gaby > > 2013-03-26 Gabriel Dos Reis > > * Makefile.in (.SUFFIXES): Add .cc. > (.c.o): Apply same recipe for implicit rule .cc.o. > > Index: Makefile.in > === > --- Makefile.in (revision 196984) > +++ Makefile.in (working copy) > @@ -48,7 +48,7 @@ > # This must come before the language makefile fragments to allow them to > # add suffixes and rules of their own. > .SUFFIXES: > -.SUFFIXES: .c .o .po .pox .gmo > +.SUFFIXES: .c .cc .o .po .pox .gmo > > # --- > # Standard autoconf-set variables > @@ -1054,7 +1054,7 @@ > $(CPPINC) $(GMPINC) $(DECNUMINC) $(BACKTRACEINC) \ > $(CLOOGINC) $(ISLINC) > > -.c.o: > +.cc.o .c.o: > $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $< $(OUTPUT_OPTION) > > # > Ok. Paolo
Re: [ARM] Fix ICE in minipool handling at -Os
> Having half-word accesses into the minipool is generally a bad idea. > The limited offset range that's supported by these instructions means > it's much more likely that we'll end up with a pool after a conditional > branch or, worse, in the middle of a linear code sequence. That means > we have to jump around the pool, which costs performance. Note that this is -Os so performance considerations might come second. > We really need to find out why the compiler keeps trying to create these > and fix that problem rather than work around the issue. > > I'm not sure why the v6 variants allow this; I thought that had been > taken out. Apparently not. -- Eric Botcazou
Fwd: [Patch, fortran] optimize string comparison
(The email below was only sent to gcc-patches@; I now also CC fortran@ -
sorry for the full quote)
Regarding the below patch: I think it does not work as-is for Unicode
strings (UCS4, character(kind=4)), where each character is 4 bytes wide
and a space does not consist of sequences of four ' '.
Regarding Thomas' patch:* I would also think that memcmp should work for
kind=4 characters; one then needs to multiply the length by the
byte-size. (Actually, for kind==1, one could check the excess characters
in the generated code via memchr as done in Ondřej's patch.)
However, looking at intrinsics/string_intrinsics{,_inc}.c, I see that we
don't use MEMCMP for UCS4 either - but some a hand-written function. I
think that could also be replaced by the normal memcmp (or did I miss
some fine print?). A possible patch would be to replace
#define MEMCMP memcmp_char4
by
#define MEMCMP(a,b,c) memcmp(a,b,4*(c))
and delete the memcmp_char4 function.
Tobias
* http://gcc.gnu.org/ml/fortran/2013-03/msg00142.html
Original Message
Subject: [Patch, fortran] optimize string comparison
Date: Wed, 27 Mar 2013 09:35:57 +0100
From: Ondřej Bílka
To: gcc-patches@gcc.gnu.org
Hi,
as I looked to compare_string I discovered that it could be
optimized. This speeds up case when strings are equal but we must check
padding where checking it byte by byte is suboptimal.
Ondra
2013-03-27 Ondřej Bílka
* libgfortran/intrinsics/string_intrinsics_inc.c (compare_string):
Optimize.
diff --git a/libgfortran/intrinsics/string_intrinsics_inc.c
b/libgfortran/intrinsics/string_intrinsics_inc.c
index a1f86b5..9eb0613 100644
--- a/libgfortran/intrinsics/string_intrinsics_inc.c
+++ b/libgfortran/intrinsics/string_intrinsics_inc.c
@@ -107,16 +107,15 @@ compare_string (gfc_charlen_type len1, const
CHARTYPE *s1,
res = 1;
}
- while (len--)
+ s = memchr (s, ' ', len);
+ if (!s)
+ return 0;
+ if (*s != ' ')
{
- if (*s != ' ')
-{
- if (*s > ' ')
-return res;
- else
-return -res;
-}
- s++;
+ if (*s > ' ')
+return res;
+ else
+return -res;
}
return 0;
Re: [patch] Unified debug dump function names.
On Wed, Mar 27, 2013 at 12:50 AM, Lawrence Crowl wrote: > On 3/26/13, Lawrence Crowl wrote: >> On 3/26/13, Richard Biener wrote: >>> On Mar 25, 2013 Lawrence Crowl wrote: >>> > On 3/25/13, Richard Biener wrote: >>> > > You add a not used new interface. What for? >>> > >>> > So that people can use it. >>> > >>> > > For use from gdb only? >>> > >>> > No, for use from both gdb and internally. It is often that >>> > folks add dumps in various places while developing/debugging. >>> > These functions support that effort without having to hunt down >>> > the name. >>> >>> But having both interfaces is bad. As you are unconditionally >>> "dumping" to stderr using debug () is correct. Sorry that I >>> don't follow each and every proposal - nobody follows up my >>> proposals either. >>> >>> The dump_ namespace is claimed by dumping to dumpfiles and >>> diagnostics. >>> >>> > > In which case it should be debug (), not dump (). >>> > >>> > I will use whatever name you wish, but I would have preferred >>> > that we addressed naming issues when we published the plan, >>> > not after I've done the implementation. What name do you wish? >>> >>> debug (). >> >> Okay. >> >>> And I'd like you to remove the alternate debug_ interface that >>> is obsoleted by the overloads. >> >> I'm sure that folks have the old interfaces baked into scripts and >> dot files. I think it would should not remove the old interface >> until they have had some time to migrate. >> >>> Btw, the overloading will provide extra headache to one of the >>> most used ways to the debug_ routines: >>> >>> (gdb) call debug_tree (fndecl) >>> >>type >>type >>size >>>unit size >>>align 32 symtab 0 alias set -1 canonical type >>> 0x76d175e8 precision 32 min >> -2147483648> max >>> ... >>> (gdb) call debug_tree (0x76d175e8) >>> Cannot resolve function debug_tree to any overloaded instance >>> (gdb) call debug_tree >>> debug_tree(tree_node*) >>> debug_tree_chain(tree_node*) >>> debug_tree_chain(tree_node*)::__FUNCTION__ >>> debug_tree_ssa() >>> debug_tree_ssa_stats() >>> >>> (gdb) call debug_tree ((tree_node*)0x76d175e8) >>> >>size >> bitsizetype> constant 32> >>>unit size >> 0x76d17000 sizetype> constant 4> >>>align 32 symtab 0 alias set -1 canonical type 0x76d175e8 >>> precision 32 min max >>> >>>pointer_to_this > >>> >>> but with debug () having overloads to each and every thing we'd >>> ever want to debug the list of possible types I have to cast that >>> literal address I cut&pasted will be endless. >>> >>> Any suggestion on how to improve this situation? Yes, it's already >>> bad as with typing debug_tree I know it's a tree I am interested >>> in and >>> >>> (gdb) call debug_ >>> ... endless list of functions and overloads ... >>> >>> is probably as useless as >>> >>> (gdb) call debug >>> >>> is after your patch. >> >> I have three suggestions, in increasing order of difficulty. >> >> First, modify the dumpers to print the type cast in front of >> the hex value. The cut and paste is just a bit wider. >> >> Second, modify the dumpers to print the access expression (which >> would then not require the hex value). I'm not actually sure how >> well this would work in practice. It's a thought. >> >> Third, modify gdb to have an interactive data explorer. As a >> straw man, "explorer foo" would open up a window with all of >> foo's elements. Each pointer is clickable and changes your view to >> its referrent. I've used such a tool, and while it was sometimes >> at too low a level of abstraction, it was generally quite handy >> for exploring the data. In retrospect, it would be nice to fold >> sub-objects (in the editor sense). > > Patch with rename to debug attached. > Tested on x86_64. > > > Add uniform debug dump function names. > > > Add some overloaded functions that provide uniform debug dump > function names. These names are: > > debug: the general debug dumper > debug_verbose: for more details > debug_raw: for the gory details > debug_head: for the heads of declarations, e.g. function heads > debug_body: for the bodies of declarations, e.g. function bodies > > Not all types have the last four versions. > > The debug functions come in two flavors, those that take pointers > to the type, and those that take references to the type. The first > handles printing of '' for null pointers. The second assumes > a valid reference, and prints the content. > > > Example uses are as follows: > > cp_token t, *p; > debug (t); > debug (p); > > From the debugger, use > > call debug (t) > > > The functions sets implemented are: > > debug (only) > > basic_block_def, const bitmap_head_def, cp_binding_level, > cp_parser, cp_token, data_reference, die_struct, edge_def, > gimple_statement_d, ira_allocno, ira_allocno_copy, live_range, > lra_live_range, omega_pb_d, pt_solution, const rtx_def, sreal, > tree_live_info_d, _var_map, > >
Re: [patch] Hash table changes from cxx-conversion branch
On Sat, Mar 23, 2013 at 11:36 PM, Lawrence Crowl wrote: > This patch is a consolodation of the hash_table patches to the > cxx-conversion branch. > > Update various hash tables from htab_t to hash_table. > Modify types and calls to match. Ugh. Can you split it up somewhat ... like split target bits away at least? Targets may prefer to keep the old hashes for ease of branch maintainance. > * config/arm/arm.c'arm_libcall_uses_aapcs_base::libcall_htab > > Fold libcall_eq and libcall_hash into new struct libcall_hasher. > > * config/ia64/ia64.c'bundle_state_table > > Fold bundle_state_hash and bundle_state_eq_p into new struct > bundle_state_hasher. > > * config/mips/mips.c'mips_offset_table > > Fold mips_lo_sum_offset_hash and mips_lo_sum_offset_eq into new > struct mips_lo_sum_offset_hasher. > > In mips_reorg_process_insns, change call to for_each_rtx to pass > a pointer to the hash_table rather than a htab_t. This change > requires then dereferencing that pointer in mips_record_lo_sum to > obtain the hash_table. > > * config/sol2.c'solaris_comdat_htab > > Fold comdat_hash and comdat_eq into new struct comdat_entry_hasher. > > * config/i386/winnt.c'i386_pe_section_type_flags::htab > > * config/i386/winnt.c'i386_find_on_wrapper_list::wrappers > > Fold wrapper_strcmp into new struct wrapped_symbol_hasher. > > * tree-ssa-coalesce.c'coalesce_list_d.list > > Fold coalesce_pair_map_hash and coalesce_pair_map_eq into new > struct coalesce_pair_hasher. > > Removed struct coalesce_pair_iterator, as did not meet the hash_table > iterator interface and it provided no significant code reduction. > This leads to a change in the implementation of FOR_EACH_PARTITION_PAIR. Individual bits I looked at follow: > * tree-ssa-coalesce.c'coalesce_list_d.list from htab_t to hash_table. > > Fold coalesce_pair_map_hash and coalesce_pair_map_eq into new > struct coalesce_pair_hasher. > > Removed struct coalesce_pair_iterator, as did not meet the hash_table > iterator interface and it provided no significant code reduction. > This leads to a change in the implementation of FOR_EACH_PARTITION_PAIR. Ok. > * statistics.c'statistics_hashes > > Fold hash_statistics_eq into new struct stats_counter_hasher. Ok. > * hash-table.h'hash_table > > Add documentation. > Add nested class iterator and methods to hash_table. > Add FOR_EACH_HASH_TABLE_ELEMENT implemented with those iterators. > Change uses of FOR_EACH_HTAB_ELEMENT to FOR_EACH_HASH_TABLE_ELEMENT. Ok. > * tree-ssa-sccvn.c'vn_tables_s.nary > > Fold vn_nary_op_hash, vn_nary_op_eq into new struct vn_nary_op_hasher. > Add typedef vn_nary_op_table_type. > Add typedef vn_nary_op_iterator_type. > > * tree-ssa-sccvn.c'vn_tables_s.phis > > Fold vn_phi_hash, free_phi into new struct vn_phi_hasher. > Add typedef vn_phi_table_type. > Add typedef vn_phi_iterator_type. > > * tree-ssa-sccvn.c'vn_tables_s.references > > Fold vn_reference_hash, vn_reference_op_eq, free_reference > into new struct vn_reference_hasher. > Add typedef vn_reference_table_type. > Add typedef vn_reference_iterator_type. > > * tree-ssa-sccvn.c'constant_value_ids > > Fold vn_constant_hash, vn_constant_eq into new struct vn_constant_hasher. Ok. > * tree-into-ssa.c'var_infos > > Fold var_info_hash, var_info_eq into new struct var_info_hasher. Ok. > * tree-vectorizer.h'_loop_vec_info::peeling_htab > > * tree-vectorizer.h > > New struct peel_info_hasher. > > * tree-vect-loop.c > > Update dependent calls and types to match. > > * tree-vect-data-refs.c > > Fold vect_peeling_hash and vect_peeling_hash_eq into struct peel_info_hasher. Ok. > * tree-ssa-structalias.c'pointer_equiv_class_table > * tree-ssa-structalias.c'location_equiv_class_table > > Fold equiv_class_label_hash and equiv_class_label_eq into new > struct equiv_class_hasher. > > * tree-ssa-structalias.c'shared_bitmap_table > > Fold shared_bitmap_hash and shared_bitmap_eq into new struct > shared_bitmap_hasher. Ok. > * tree-ssa-live.c'var_map_base_init::tree_to_index > > New struct tree_int_map_hasher. I think this wants to be generalized - we have the common tree_map/tree_decl_map and tree_int_map maps in tree.h - those (and its users) should be tackled in a separate patch by providing common hashtable trails implementations. > * tree-ssa-reassoc.c'undistribute_ops_list::ctable > > Fold oecount_hash and oecount_eq into new struct oecount_hasher. Ok. > * tree-ssa-loop-im.c'memory_accesses.refs > > Fold memref_hash and memref_eq into new struct mem_ref_hasher. Ok. > Remove unused: > > htab_t scop::original_pddrs > SCOP_ORIGINAL_PDDRS > > Remove unused: > > insert_loop_close_phis > insert_guard_phis > debug_ivtype_map > ivtype_map_elt_info > new_ivtype_map_elt Unused function/type removal are obvious changes. > Remove unused: > dse.c bitmap clear_alias_sets > dse.c bitmap disqualified_clear_alias_sets > dse.c alloc_pool clear_alias_mode_pool > dse.c dse_step2_spill > dse.c dse_step5_spill > graphds.h htab_t graph::indices See above. Thanks, Rich
Re: [Patch, Fortran] PR56650/36437 - Add compile-time simplification for (c_)sizeof, storage_size
Hi Tobias,
I think you need to deallocate array_size in gfc_simplify_sizeof
unconditionally.
+ if (x->rank && x->expr_type != EXPR_ARRAY
+ && gfc_array_size (x, &array_size) == FAILURE)
+return NULL;
Here, it is allocated on success of gfc_array_size.
[...]
And here, it is freed only if expr_type != EXPR_ARRAY.
+ if (x->rank && x->expr_type != EXPR_ARRAY)
+{
+ mpz_mul (result->value.integer, result->value.integer, array_size);
+ mpz_clear (array_size);
+}
Otherwise, the patch looks OK for me.
Thomas
Re: [rtl, i386] vec_merge simplification
> int is getting small to store one bit per vector element (V32QI...) so I > switched to hwint after checking that Zadeck's patches don't touch this. unsigned HOST_WIDE_INT is indeed the correct type to use for mask manipulation but please use UINTVAL instead of INTVAL with it. And: + unsigned HOST_WIDE_INT mask = (HOST_WIDE_INT_1 << n_elts) - 1; can be flagged as relying on undefined behavior (we fixed a bunch of cases a couple of years ago) so use: unsigned HOST_WIDE_INT mask = ((unsigned HOST_WIDE_INT) 1 << n_elts) - 1; > Bootstrap + testsuite on x86_64-linux-gnu. > > 2013-03-17 Marc Glisse > > gcc/ > * simplify-rtx.c (simplify_binary_operation_1) : > Handle VEC_MERGE. > (simplify_ternary_operation) : Handle nested VEC_MERGE. > Handle equal arguments. OK, modulo a few nits: - in simplify_binary_operation_1, the notion of left and right is a bit elusive, so I'd use all_operand0 and all_operand1 instead. And I'd use the same idiom as in simplify_ternary_operation: (sel & (1 << UINTVAL (j)). - in simplify_ternary_operation, we probably need to test that op0 doesn't have side-effects too before dropping one of the copies, as VEC_MERGE is supposed to evaluate its 2 arguments I think. -- Eric Botcazou
Re: [Patch, Fortran, 4.9] Minor FINAL preparation patch
** PING ** And an updated patch. Changes: - Updated isym handling due to the ISO_C_BINDING patch - Fixed some bugs in the generated code for finalizing arrays (mainly missing gfc_copy_expr) Build and tested on x86-64-gnu-linux. OK for the trunk? Tobias PS: Regarding true FINAL support: The current draft patch* mostly works, except for: Polymorphic arrays aren't deallocated at the end of the scope (old bug), allocatables are wrongly finalized at the end of the main program, and for allocatable,intent(out), no finalization is done. After those issues are fixed and some code cleanup has be done, the patch should be ready. *https://userpage.physik.fu-berlin.de/~tburnus/final/ On March 13, 2013 11:26 a.m., Tobias Burnus wrote: Dear all, this small patch fixes some small issues with the current FINAL implementation, which is still disabled. Namely: (a) class.c: TRANSFER has an optional size= argument; if one doesn't has an actual-argument (which can be expr == NULL), it segfaults. (b) class.c: SIZE needs to return an index-size-kind integer not a default-kind integer (tree checking error, but potentially also wrong code) (c) trans.c: Scalar coarrays (with -fcoarray=lib) were mishandled - they also use an array descriptor Build and regtested on x86-64-gnu-linux. OK? (I target 4.9 with this patch; in principle, it could also be applied to 4.8: The code is not used, yet, and thus it shouldn't harm on 4.8 but there is also no benefit.) The full patch, which enables finalization and regtests is available at: https://userpage.physik.fu-berlin.de/~tburnus/final/ – The patch still requires some clean up. In addition, finalization (with a user FINAL subroutine) is mishandled for allocatable INTENT(OUT) as gfortran handles it (at least partially) in the caller (trans-expr.c's gfc_conv_procedure_call) and not in the callee (trans-decl.c). That will lead to not finalizing and segfaults at run time. There are more issues, but for an experimental implementation, fixing this issue should be enough. (Note: the .mod version should be bumped to force recompilation, which is required due to the ABI change of the vtable.) Tobias 2013-03-27 Tobias Burnus * class.c (finalization_scalarizer, finalizer_insert_packed_call, generate_finalization_wrapper): Avoid segfault with absent SIZE= argment to TRANSFER and use correct result kind for SIZE. * intrinsic.c (gfc_isym_id_by_intmod): Also handle ids of nonmodules. * trans.c (gfc_build_final_call): Handle coarrays. /fortran/class.c b/gcc/fortran/class.c index d8e7b6d..564b4c7 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -956,8 +956,10 @@ finalization_scalarizer (gfc_symbol *array, gfc_symbol *ptr, block->resolved_sym = block->symtree->n.sym; block->resolved_sym->attr.flavor = FL_PROCEDURE; block->resolved_sym->attr.intrinsic = 1; + block->resolved_sym->attr.subroutine = 1; block->resolved_sym->from_intmod = INTMOD_ISO_C_BINDING; block->resolved_sym->intmod_sym_id = ISOCBINDING_F_POINTER; + block->resolved_isym = gfc_intrinsic_subroutine_by_id (GFC_ISYM_C_F_POINTER); gfc_commit_symbol (block->resolved_sym); /* C_F_POINTER's first argument: TRANSFER ( , c_intptr_t). */ @@ -965,6 +967,7 @@ finalization_scalarizer (gfc_symbol *array, gfc_symbol *ptr, block->ext.actual->next = gfc_get_actual_arglist (); block->ext.actual->next->expr = gfc_get_int_expr (gfc_index_integer_kind, NULL, 0); + block->ext.actual->next->next = gfc_get_actual_arglist (); /* SIZE. */ /* The part: TRANSFER (C_LOC (array), c_intptr_t). */ @@ -976,7 +979,7 @@ finalization_scalarizer (gfc_symbol *array, gfc_symbol *ptr, expr->symtree->n.sym->intmod_sym_id = ISOCBINDING_LOC; expr->symtree->n.sym->attr.intrinsic = 1; expr->symtree->n.sym->from_intmod = INTMOD_ISO_C_BINDING; - expr->value.function.esym = expr->symtree->n.sym; + expr->value.function.isym = gfc_intrinsic_function_by_id (GFC_ISYM_C_LOC); expr->value.function.actual = gfc_get_actual_arglist (); expr->value.function.actual->expr = gfc_lval_expr_from_sym (array); @@ -987,9 +990,9 @@ finalization_scalarizer (gfc_symbol *array, gfc_symbol *ptr, /* TRANSFER. */ expr2 = gfc_build_intrinsic_call (sub_ns, GFC_ISYM_TRANSFER, "transfer", -gfc_current_locus, 2, expr, +gfc_current_locus, 3, expr, gfc_get_int_expr (gfc_index_integer_kind, - NULL, 0)); + NULL, 0), NULL); expr2->ts.type = BT_INTEGER; expr2->ts.kind = gfc_index_integer_kind; @@ -1200,9 +1203,9 @@ finalizer_insert_packed_call (gfc_code *block, gfc_finalizer *fini, size_expr->value.op.op1 = gfc_build_intrinsic_call (sub_ns, GFC_ISYM_STORAGE_SIZE, "storage_size", gfc_current_locus, 2, -gfc_lval_expr_from_sym (array)); +gfc_lval_expr_from_sym (array), gfc_get_int_expr (gfc_index_integer_kind, - NULL, 0); + NULL, 0)); /* NUMERIC_STORAGE_SIZE. */
Re: [RFC PATCH] Implementing ifunc target hook
> > Otherwise OK. > > Thanks, Hi, chacked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00785.html Thanks, K
Re: [RTL] Canonicalize commutative operations more
> This patch passes bootstrap+testsuite on x86_64-linux-gnu. Using the > opposite arbitrary order in compare_commutative_operands_precedence > (exchange x and y in the line with GET_CODE) passes as well. The > simplify-rtx bit is because I get an infinite recursion otherwise. > Surprisingly, that infinite recursion occurs only in var-tracking, and > only for a single file in bootstrap+testsuite (not the same one depending > on the arbitrary order). I am not sure that is the best place to break the > recursion, but it seems to work. > > I don't really expect the patch to be accepted as is, but it seems good > enough to start the conversation. I'm rather with Jakub here, I think that arbitrary canonicalization as the one proposed here will probably be worse than no canonicalization in practice, because it will generate much shuffling. If you need more canonicalization, then why not propose new, precise canonicalization rules? -- Eric Botcazou
Re: [testsuite] Adding -fno-pic to certain tests
> Ok with that change. Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00786.html Thanks, K
New template for 'cpplib' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'cpplib' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/cpplib-4.8.0.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: http://ftp.gnu.org/gnu/gcc/gcc-4.8.0/gcc-4.8.0.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New template for 'gcc' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/gcc-4.8.0.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: http://ftp.gnu.org/gnu/gcc/gcc-4.8.0/gcc-4.8.0.tar.bz2 Translated PO files will later be automatically e-mailed to you. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [testsuite] Adding -fno-pic to certain tests
Hi, Thank you for your review. Since the patch was aimed to fix tests and it is pretty small, is it posible to backport it to 4.8 branch? So we would not have those testfails on Android with new release. Alexander 2013/3/27 Kirill Yukhin : >> Ok with that change. > > Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00786.html > > Thanks, K
[PATCH, i386, AVX2] Fix intrinsic name for _mm256_broadcastsi128_si256
Hello, According to recent Spec, we have intrinsic _mm256_broadcastsi128_si256, not _mm_broadcastsi128_si256. Attached patch makes avx2intrin.h consistent with Spec in that way. ChangeLog: 2013-03-27 Kirill Yukhin * gcc/config/i386/avx2intrin.h (_mm256_broadcastsi128_si256): Fix declaration name. testsuite/ChangeLog: 2013-03-27 Kirill Yukhin * gcc.target/i386/avx2-vbroadcastsi128-1.c: Fix intrinsic name. * gcc.target/i386/avx2-vbroadcastsi128-1.c: Ditto. Patch attached. Ok for trunk, for 4.8? Thanks, K avx2-bcst-intrin-1.patch Description: Binary data
Re: [Patch, Fortran] PR56650/36437 - Add compile-time simplification for (c_)sizeof, storage_size
Am 27.03.2013 10:47, schrieb Thomas Koenig: I think you need to deallocate array_size in gfc_simplify_sizeof unconditionally. Actually, when I applied the more than two years old draft patch, I thought likewise - but that leads to segfaults. If one reads the code more carefully, one sees that the condition is required: + if (x->rank && x->expr_type != EXPR_ARRAY + && gfc_array_size (x, &array_size) == FAILURE) +return NULL; Here, it is allocated on success of gfc_array_size. But only if "x->rank && x->expr_type != EXPR_ARRAY" is true. And here, it is freed only if expr_type != EXPR_ARRAY. + if (x->rank && x->expr_type != EXPR_ARRAY) Which is the same condition. I have now applied the (unmodified) patch as Rev. 197159. Thanks for the review! Tobias
Re: [PATCH, i386, AVX2] Fix intrinsic name for _mm256_broadcastsi128_si256
On Wed, Mar 27, 2013 at 12:22 PM, Kirill Yukhin wrote: > According to recent Spec, we have intrinsic > _mm256_broadcastsi128_si256, not _mm_broadcastsi128_si256. > > Attached patch makes avx2intrin.h consistent with Spec in that way. > > ChangeLog: > 2013-03-27 Kirill Yukhin > > * gcc/config/i386/avx2intrin.h (_mm256_broadcastsi128_si256): > Fix declaration name. > > testsuite/ChangeLog: > 2013-03-27 Kirill Yukhin > > * gcc.target/i386/avx2-vbroadcastsi128-1.c: Fix intrinsic name. > * gcc.target/i386/avx2-vbroadcastsi128-1.c: Ditto. > > Patch attached. Ok for trunk, for 4.8? OK. Thanks, Uros.
[PATCH] Handle SLP group loads with trailing gaps
This makes the vectorizer handle loads of SLP groups with
"trailing gaps". That is, a (for now know) gap between
the groups between loop iterations as in the testcase
+ double self[1024];
+ double a[1024][1024];
+ double b[1024];
+
+ void __attribute__((noinline,noclone))
+ foo (void)
+ {
+ int i, j;
+ for (i = 0; i < 1024; i+=6)
+ for (j = 0; j < 1024; j+=6)
+ {
+ self[i] = self[i] + a[i][j]*b[j];
+ self[i+1] = self[i+1] + a[i][j+1]*b[j+1];
+ }
+ }
reduced to this issue from the complex multiplication vectorization
issue in PR37021.
A next step will eventually be to allow an unknown gap between
the groups between iterations (including possible overlap).
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Richard.
2013-03-27 Richard Biener
PR tree-optimization/37021
* tree-vect-slp.c (vect_build_slp_tree): When not unrolling
do not restrict gaps between groups.
* tree-vect-stmts.c (vectorizable_load): Properly account for
a gap between groups.
* gcc.dg/vect/fast-math-slp-38.c: New testcase.
* gcc.dg/vect/O3-pr36098.c: Un-XFAIL.
Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c.orig2013-03-26 13:09:18.0 +0100
--- gcc/tree-vect-slp.c 2013-03-26 14:27:14.135697847 +0100
*** vect_build_slp_tree (loop_vec_info loop_
*** 740,750
else
{
/* Load. */
! /* FORNOW: Check that there is no gap between the loads. */
! if ((GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) == stmt
!&& GROUP_GAP (vinfo_for_stmt (stmt)) != 0)
! || (GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) != stmt
! && GROUP_GAP (vinfo_for_stmt (stmt)) != 1))
{
if (dump_enabled_p ())
{
--- 750,765
else
{
/* Load. */
! /* FORNOW: Check that there is no gap between the loads
!and no gap between the groups when we need to load
!multiple groups at once.
!??? We should enhance this to only disallow gaps
!inside vectors. */
! if ((ncopies > 1
! && GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) == stmt
! && GROUP_GAP (vinfo_for_stmt (stmt)) != 0)
! || (GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) != stmt
! && GROUP_GAP (vinfo_for_stmt (stmt)) != 1))
{
if (dump_enabled_p ())
{
*** vect_build_slp_tree (loop_vec_info loop_
*** 762,768
/* Check that the size of interleaved loads group is not
greater than the SLP group size. */
if (loop_vinfo
! && GROUP_SIZE (vinfo_for_stmt (stmt)) > ncopies *
group_size)
{
if (dump_enabled_p ())
{
--- 777,786
/* Check that the size of interleaved loads group is not
greater than the SLP group size. */
if (loop_vinfo
! && GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) == stmt
! && ((GROUP_SIZE (vinfo_for_stmt (stmt))
! - GROUP_GAP (vinfo_for_stmt (stmt)))
! > ncopies * group_size))
{
if (dump_enabled_p ())
{
Index: gcc/testsuite/gcc.dg/vect/fast-math-slp-38.c
===
*** /dev/null 1970-01-01 00:00:00.0 +
--- gcc/testsuite/gcc.dg/vect/fast-math-slp-38.c2013-03-26
13:09:20.860002059 +0100
***
*** 0
--- 1,22
+ /* { dg-do compile } */
+ /* { dg-require-effective-target vect_double } */
+
+ double self[1024];
+ double a[1024][1024];
+ double b[1024];
+
+ void __attribute__((noinline,noclone))
+ foo (void)
+ {
+ int i, j;
+ for (i = 0; i < 1024; i+=6)
+ for (j = 0; j < 1024; j+=6)
+ {
+ self[i] = self[i] + a[i][j]*b[j];
+ self[i+1] = self[i+1] + a[i][j+1]*b[j+1];
+ }
+ }
+
+ /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
+ /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" }
} */
+ /* { dg-final { cleanup-tree-dump "vect" } } */
Index: gcc/testsuite/gcc.dg/vect/O3-pr36098.c
===
*** gcc/testsuite/gcc.dg/vect/O3-pr36098.c.orig 2013-03-26 13:02:00.0
+0100
--- gcc/testsuite/gcc.dg/vect/O3-pr36098.c 2013-03-26 13:09:20.860002059
+0100
*** void foo (int ncons, t_sortblock *sb, in
*** 17,22
iatom[m]=sb[i].iatom[m];
}
! /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "ve
Re: [patch] Hash table changes from cxx-conversion branch
Hi, On Sat, Mar 23, 2013 at 03:36:35PM -0700, Lawrence Crowl wrote: > This patch is a consolodation of the hash_table patches to the > cxx-conversion branch. > I can't approve anything but I am fine with > * tree-sra.c (candidates): > Change type to hash_table. Update dependent calls and types. > > * tree-ssa.c (int_tree_map_eq): Moved into struct int_tree_hasher > in tree-flow.h. > (int_tree_map_hash): Likewise. Thanks, Martin
[PATCH] Fix PTA dumping ICEs
This fixes ICEs when dumping PTA pass details (I'm pretty sure
it will not fix PR56716, but this issue is reported there, too).
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-03-27 Richard Biener
PR tree-optimization/56716
* tree-ssa-structalias.c (perform_var_substitution): Adjust
dumping for ref nodes.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 197158)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -2292,18 +2292,37 @@ perform_var_substitution (constraint_gra
{
unsigned j = si->node_mapping[i];
if (j != i)
- fprintf (dump_file, "%s node id %d (%s) mapped to SCC leader "
- "node id %d (%s)\n",
- bitmap_bit_p (graph->direct_nodes, i)
- ? "Direct" : "Indirect", i, get_varinfo (i)->name,
- j, get_varinfo (j)->name);
+ {
+ fprintf (dump_file, "%s node id %d ",
+bitmap_bit_p (graph->direct_nodes, i)
+? "Direct" : "Indirect", i);
+ if (i < FIRST_REF_NODE)
+ fprintf (dump_file, "\"%s\"", get_varinfo (i)->name);
+ else
+ fprintf (dump_file, "\"*%s\"",
+ get_varinfo (i - FIRST_REF_NODE)->name);
+ fprintf (dump_file, " mapped to SCC leader node id %d ", j);
+ if (j < FIRST_REF_NODE)
+ fprintf (dump_file, "\"%s\"\n", get_varinfo (j)->name);
+ else
+ fprintf (dump_file, "\"*%s\"\n",
+ get_varinfo (j - FIRST_REF_NODE)->name);
+ }
else
- fprintf (dump_file,
- "Equivalence classes for %s node id %d (%s): pointer %d"
- ", location %d\n",
- bitmap_bit_p (graph->direct_nodes, i)
- ? "direct" : "indirect", i, get_varinfo (i)->name,
- graph->pointer_label[i], graph->loc_label[i]);
+ {
+ fprintf (dump_file,
+"Equivalence classes for %s node id %d ",
+bitmap_bit_p (graph->direct_nodes, i)
+? "direct" : "indirect", i);
+ if (i < FIRST_REF_NODE)
+ fprintf (dump_file, "\"%s\"", get_varinfo (i)->name);
+ else
+ fprintf (dump_file, "\"*%s\"",
+ get_varinfo (i - FIRST_REF_NODE)->name);
+ fprintf (dump_file,
+": pointer %d, location %d\n",
+graph->pointer_label[i], graph->loc_label[i]);
+ }
}
/* Quickly eliminate our non-pointer variables. */
Re: patch to fix constant math - first small patch - patch ping for the next stage 1
On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
wrote:
> Here is the first of my wide int patches with joseph's comments and the
> patch rot removed.
>
> I would like to get these pre approved for the next stage 1.
+ int shift = HOST_BITS_PER_WIDE_INT - (prec &
(HOST_BITS_PER_WIDE_INT - 1));
I think this should gcc_checking_assert that prec is not out of range
(any reason why prec is signed int and not unsigned int?) rather than
ignore bits in prec.
+static inline HOST_WIDE_INT
+zext_hwi (HOST_WIDE_INT src, int prec)
+{
+ if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+ else
+return src & (((HOST_WIDE_INT)1
+ << (prec & (HOST_BITS_PER_WIDE_INT - 1))) - 1);
+}
likewise. Also I'm not sure I agree about the signedness of the result / src.
zext_hwi (-1, HOST_BITS_PER_WIDE_INT) < 0 is true which is odd.
The patch misses context of uses, so I'm not sure what the above functions
are intended to do.
Richard.
> On 10/05/2012 08:14 PM, Joseph S. Myers wrote:
>>
>> On Fri, 5 Oct 2012, Kenneth Zadeck wrote:
>>
>>> +# define HOST_HALF_WIDE_INT_PRINT "h"
>>
>> This may cause problems on hosts not supporting %hd (MinGW?), and there's
>> no real need for using "h" here given the promotion of short to int; you
>> can just use "" (rather than e.g. needing special handling in xm-mingw32.h
>> like is done for HOST_LONG_LONG_FORMAT).
>>
>
Re: patch to fix constant math - second small patch -patch ping for next stage 1
On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck wrote: > Here is the second of my wide int patches with the patch rot removed. > > I would like to get these pre approved for the next stage 1. > On 10/05/2012 06:48 PM, Kenneth Zadeck wrote: >> >> This patch adds machinery to genmodes.c so that largest possible sizes of >> various data structures can be determined at gcc build time. These functions >> create 3 symbols that are available in insn-modes.h: >> MAX_BITSIZE_MODE_INT - the bitsize of the largest int. >> MAX_BITSIZE_MODE_PARTIAL_INT - the bitsize of the largest partial int. >> MAX_BITSIZE_MODE_ANY_INT - the largest bitsize of any kind of int. I remember we have discussed about the need to special-case/handle partial integer modes. Do further patches use the _INT and _PARTIAL_INT sizes at all? I'm fine with providing MAX_BITSIZE_MODE_ANY_INT. Richard.
Re: patch to fix constant math - third patch - what is left for next stage 1
On Wed, Feb 27, 2013 at 1:37 AM, Kenneth Zadeck wrote: > the original patch 3 was accepted and committed. These were subsequent > comments. This could likely be just checked in the next stage 1 without > approval. Ok. Thanks, Richard. > >
Re: patch to fix constant math - second small patch -patch ping for next stage 1
On 03/27/2013 10:18 AM, Richard Biener wrote: On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck wrote: Here is the second of my wide int patches with the patch rot removed. I would like to get these pre approved for the next stage 1. On 10/05/2012 06:48 PM, Kenneth Zadeck wrote: This patch adds machinery to genmodes.c so that largest possible sizes of various data structures can be determined at gcc build time. These functions create 3 symbols that are available in insn-modes.h: MAX_BITSIZE_MODE_INT - the bitsize of the largest int. MAX_BITSIZE_MODE_PARTIAL_INT - the bitsize of the largest partial int. MAX_BITSIZE_MODE_ANY_INT - the largest bitsize of any kind of int. I remember we have discussed about the need to special-case/handle partial integer modes. Do further patches use the _INT and _PARTIAL_INT sizes at all? I'm fine with providing MAX_BITSIZE_MODE_ANY_INT. i do not believe that in the end, those two ended up getting used.i can remove them if you want. kenny Richard.
C++ PATCH for c++/56749 (wrongly treating scoped enums as dependent)
My change to treat SCOPE_REFs in a template as instantiation-dependent
due to access issues incorrectly affected scoped enums; we don't need to
worry about access for them, since there are no access-specifiers in an
enum.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 279da5952b411af833810a644ed650a566515a5e
Author: Jason Merrill
Date: Wed Mar 27 09:35:35 2013 -0400
PR c++/56749
* semantics.c (finish_qualified_id_expr): Return early
for enum scope.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index fd77725..72b884e 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -1762,6 +1762,10 @@ finish_qualified_id_expr (tree qualifying_class,
return expr;
}
+ /* No need to check access within an enum. */
+ if (TREE_CODE (qualifying_class) == ENUMERAL_TYPE)
+return expr;
+
/* Within the scope of a class, turn references to non-static
members into expression of the form "this->...". */
if (template_arg_p)
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum24.C b/gcc/testsuite/g++.dg/cpp0x/enum24.C
new file mode 100644
index 000..6099656
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum24.C
@@ -0,0 +1,57 @@
+// PR c++/56749
+// { dg-require-effective-target c++11 }
+
+enum normal_enum
+{
+not_scoped1,
+not_scoped2
+};
+
+enum class scoped_enum
+{
+scoped1,
+scoped2
+};
+
+template
+class A
+{
+public:
+template
+void fun ()
+{
+}
+};
+
+template
+class B
+{
+public:
+template
+void fun ()
+{
+}
+};
+
+
+template
+void tfun ()
+{
+A<> a;
+a.fun(); //< THIS IS FINE
+
+B<> b_defaulted;
+B b_explicited;
+
+b_defaulted.fun(); //< UNEXPECTED: THIS FAILS
+b_defaulted.template fun(); //< THIS IS FINE
+
+b_explicited.fun(); //< UNEXPECTED: THIS FAILS
+b_explicited.template fun();//< THIS IS FINE
+}
+
+int main(int argc, char const *argv[])
+{
+tfun();
+return 0;
+}
Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
wrote:
> This patch contains a large number of the changes requested by Richi. It
> does not contain any of the changes that he requested to abstract the
> storage layer. That suggestion appears to be quite unworkable.
>
> I believe that the wide-int class addresses the needs of gcc for performing
> math on any size integer irregardless of the platform that hosts the
> compiler. The interface is admittedly large, but it is large for a reason:
> these are the operations that are commonly performed by the client
> optimizations in the compiler.
>
> I would like to get this patch preapproved for the next stage 1.
Please clean from dead code like
+// using wide_int::;
and
+#ifdef DEBUG_WIDE_INT
+ if (dump_file)
+debug_wh ("wide_int::from_shwi %s " HOST_WIDE_INT_PRINT_HEX ")\n",
+ result, op0);
+#endif
and
+#ifdef NEW_REP_FOR_INT_CST
+ /* This is the code once the tree level is converted. */
+ wide_int result;
+ int i;
+
+ tree type = TREE_TYPE (tcst);
+
+ result.bitsize = GET_MODE_BITSIZE (TYPE_MODE (type));
+ result.precision = TYPE_PRECISION (type);
+ result.len = TREE_INT_CST_LEN (tcst);
+ for (i = 0; i < result.len; i++)
+result.val[i] = TREE_INT_CST_ELT (tcst, i);
+
+ return result;
+#else
this also shows the main reason I was asking for storage abstraction.
The initialization from tree is way too expensive.
+/* Convert a integer cst into a wide int expanded to BITSIZE and
+ PRECISION. This call is used by tree passes like vrp that expect
+ that the math is done in an infinite precision style. BITSIZE and
+ PRECISION are generally determined to be twice the largest type
+ seen in the function. */
+
+wide_int
+wide_int::from_tree_as_infinite_precision (const_tree tcst,
+ unsigned int bitsize,
+ unsigned int precision)
+{
I know you have converted everything, but to make this patch reviewable
I'd like you to strip the initial wide_int down to a bare minimum.
Only then people will have a reasonable chance to play with interface
changes (such as providing a storage abstraction).
+/* Check the upper HOST_WIDE_INTs of src to see if the length can be
+ shortened. An upper HOST_WIDE_INT is unnecessary if it is all ones
+ or zeros and the top bit of the next lower word matches.
+
+ This function may change the representation of THIS, but does not
+ change the value that THIS represents. It does not sign extend in
+ the case that the size of the mode is less than
+ HOST_BITS_PER_WIDE_INT. */
+
+void
+wide_int::canonize ()
this shouldn't be necessary - it's an optimization - and due to value
semantics (yes - I know you have a weird mix of value semantics
and modify-in-place in wide_int) the new length should be computed
transparently when creating a new value.
Well. Leaving wide-int.c for now.
+class wide_int {
+ /* Internal representation. */
+
+ /* VAL is set to a size that is capable of computing a full
+ multiplication on the largest mode that is represented on the
+ target. The full multiplication is use by tree-vrp. tree-vpn
+ currently does a 2x largest mode by 2x largest mode yielding a 4x
+ largest mode result. If operations are added that require larger
+ buffers, then VAL needs to be changed. */
+ HOST_WIDE_INT val[4 * MAX_BITSIZE_MODE_ANY_INT / HOST_BITS_PER_WIDE_INT];
as you conver partial int modes in MAX_BITSIZE_MODE_ANY_INT the
above may come too short. Please properly round up.
+ unsigned short len;
+ unsigned int bitsize;
+ unsigned int precision;
I see we didn't get away with this mix of bitsize and precision. I'm probably
going to try revisit the past discussions - but can you point me to a single
place in the RTL conversion where they make a difference? Bits beyond
precision are either undefined or properly zero-/sign-extended. Implicit
extension beyond len val members should then provide in "valid" bits
up to bitsize (if anyone cares). That's how double-ints work on tree
INTGER_CSTs
which only care for precision, even with partial integer mode types
(ok, I never came along one of these beasts - testcase / target?).
[abstraction possibility - have both wide_ints with actual mode and
wide_ints with arbitrary bitsize/precision]
+ enum ShiftOp {
+NONE,
+/* There are two uses for the wide-int shifting functions. The
+ first use is as an emulation of the target hardware. The
+ second use is as service routines for other optimizations. The
+ first case needs to be identified by passing TRUNC as the value
+ of ShiftOp so that shift amount is properly handled according to the
+ SHIFT_COUNT_TRUNCATED flag. For the second case, the shift
+ amount is always truncated by the bytesize of the mode of
+ THIS. */
+TRUNC
+ };
I think I have expressed my opinion on this. (and SHIFT_COUNT_TRUNCATED
should va
Re: patch to fix constant math - second small patch -patch ping for next stage 1
On Wed, Mar 27, 2013 at 3:23 PM, Kenneth Zadeck wrote: > > On 03/27/2013 10:18 AM, Richard Biener wrote: >> >> On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck >> wrote: >>> >>> Here is the second of my wide int patches with the patch rot removed. >>> >>> I would like to get these pre approved for the next stage 1. >>> On 10/05/2012 06:48 PM, Kenneth Zadeck wrote: This patch adds machinery to genmodes.c so that largest possible sizes of various data structures can be determined at gcc build time. These functions create 3 symbols that are available in insn-modes.h: MAX_BITSIZE_MODE_INT - the bitsize of the largest int. MAX_BITSIZE_MODE_PARTIAL_INT - the bitsize of the largest partial int. MAX_BITSIZE_MODE_ANY_INT - the largest bitsize of any kind of int. >> >> I remember we have discussed about the need to special-case/handle partial >> integer modes. Do further patches use the _INT and _PARTIAL_INT sizes >> at all? I'm fine with providing MAX_BITSIZE_MODE_ANY_INT. > > i do not believe that in the end, those two ended up getting used.i can > remove them if you want. Yes please. Ok with that change. Richard. > kenny >> >> >> Richard. > >
Re: Do not disable -fomit-frame-pointer on !ACCUMULATE_OUTGOING_ARGS targets
On 03/26/2013 03:29 PM, Eric Botcazou wrote: >> Heh. We've actually fixed this now -- unwind info generation aware of >> the cfg is exactly what pass_dwarf2_frame does. So I guess this comment >> has been out of date since gcc 4.7. > > I see, thanks. So what do you suggest doing at this point? Entirely remove > the block of code? But AFAICS pass_dwarf2_frame isn't always enabled. Apply > the patch anyway with the appropriate additional conditions? > Isn't pass_dwarf2_frame enabled whenever we're generating any unwind info? r~
[c++concepts] Reducing requirements
Implements reduction of requirements into the constraints language: logical formulas comprised of atomic propositions. Calls to constraint predicates are recursively inlined in the resulting expression. All other calls are treated as atoms. 2013-03-01 Andrew Sutton * gcc/cp/Makefile.lang.in: Add constraints.o target. * gcc/cp/cp-tree.h (substitute_template_parameters): Declare. (instantiate_requirements): Declare. (conjoin_requirements): Declare. (disjoin_requirements): Declare. (reduce_requirements): Declare. * gcc/cp/pt.c (substitute_template_parameters): Define. (instantiate_requirements): Define. * gcc/cp/pt.c (finish_template_requirements): Call reduce_requirements to get constraints. * gcc/cp/parser.c (cp_parser_type_parameter): Restore saved constraints after parsing template template parameter decl. * gcc/cp/constraints.cc: New. Andrew reduce-req.patch Description: Binary data
[patch][cilkplus-merge] Fix a bug in one of the test cases
Not sure if this went out or not...
> -Original Message-
> From: Iyer, Balaji V
> Sent: Wednesday, March 27, 2013 11:25 AM
> To: 'GCC Patches (gcc-patches@gcc.gnu.org)'
> Subject: [patch][cilkplus-merge] Fix a bug in one of the test cases
>
> Hello Everyone,
> This patch will fix a bug in one of the test cases. Is it OK for
> pushing?
>
> Thanks,4
>
> Balaji V. Iyer.
diff --git gcc/testsuite/gcc.dg/cilk-plus/array_notation/compile/array_test2.c
gcc/testsuite/gcc.dg/cilk-plus/array_notation/compile/array_test2.c
index 5fb3680..fd128b1 100644
--- gcc/testsuite/gcc.dg/cilk-plus/array_notation/compile/array_test2.c
+++ gcc/testsuite/gcc.dg/cilk-plus/array_notation/compile/array_test2.c
@@ -26,7 +26,7 @@ int main(int argc, char **argv)
array[ii] = 10;
array2[ii] = 500;
}
- array2[0:10:2] = array[0:10:2];
+ array2[0:5:2] = array[0:5:2];
printf("==\n");
for (ii = 0; ii<10; ii++)
[PATCH] Fix PR56695 + adjust verify_gimple_comparison
This fixes PR56695 where we ICEd because expand_vec_cond_expr
doesn't expect that the result of a vector comparison is of
TYPE_UNSIGNED type. So we unconditionally build a signed type now.
We know that the result of vec comparison is e.g. { -1, 0, -1}
and that all elements have to be SI types.
This patch does one more thing - in verify_gimple_comparison we now
explicitly check whether the result of a vec comparison is signed.
Regtested/bootstrapped on x86_64-unknown-linux-gnu, ok for trunk?
2013-03-27 Marek Polacek
Richard Biener
PR tree-optimization/56695
* tree-vect-stmts.c (vectorizable_condition): Unconditionally
build signed result of a vector comparison.
* tree-cfg.c (verify_gimple_comparison): Check that a result
of a vector comparison has signed type.
* gcc.dg/vect/pr56695.c: New test.
--- gcc/tree-vect-stmts.c.mp2013-03-27 15:19:43.928738801 +0100
+++ gcc/tree-vect-stmts.c 2013-03-27 15:20:12.485832946 +0100
@@ -5265,7 +5265,7 @@ vectorizable_condition (gimple stmt, gim
vec vec_oprnds1 = vNULL;
vec vec_oprnds2 = vNULL;
vec vec_oprnds3 = vNULL;
- tree vec_cmp_type = vectype;
+ tree vec_cmp_type;
if (slp_node || PURE_SLP_STMT (stmt_info))
ncopies = 1;
@@ -5338,14 +5338,12 @@ vectorizable_condition (gimple stmt, gim
&& TREE_CODE (else_clause) != FIXED_CST)
return false;
- if (!INTEGRAL_TYPE_P (TREE_TYPE (vectype)))
-{
- unsigned int prec = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vectype)));
- tree cmp_type = build_nonstandard_integer_type (prec, 1);
- vec_cmp_type = get_same_sized_vectype (cmp_type, vectype);
- if (vec_cmp_type == NULL_TREE)
- return false;
-}
+ unsigned int prec = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vectype)));
+ /* The result of a vector comparison should be signed type. */
+ tree cmp_type = build_nonstandard_integer_type (prec, 0);
+ vec_cmp_type = get_same_sized_vectype (cmp_type, vectype);
+ if (vec_cmp_type == NULL_TREE)
+return false;
if (!vec_stmt)
{
--- gcc/tree-cfg.c.mp 2013-03-27 15:19:59.144788303 +0100
+++ gcc/tree-cfg.c 2013-03-27 15:20:12.475832906 +0100
@@ -3191,7 +3191,10 @@ verify_gimple_comparison (tree type, tre
if (TYPE_VECTOR_SUBPARTS (type) != TYPE_VECTOR_SUBPARTS (op0_type)
|| (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (type)))
- != GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (op0_type)
+ != GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (op0_type
+ /* The result of a vector comparison is of signed
+integral type. */
+ || TYPE_UNSIGNED (TREE_TYPE (type)))
{
error ("invalid vector comparison resulting type");
debug_generic_expr (type);
--- gcc/testsuite/gcc.dg/vect/pr56695.c.mp 2013-03-27 15:19:06.901618407
+0100
+++ gcc/testsuite/gcc.dg/vect/pr56695.c 2013-03-27 15:19:00.13259 +0100
@@ -0,0 +1,14 @@
+/* PR tree-optimization/56695 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize" } */
+
+int a, b, i;
+
+void
+f (void)
+{
+ for (i = 0; i < 8; ++i)
+a |= !(i |= b %= 1);
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */
Marek
Re: [PATCH, generic] Support printing of escaped curly braces and vertical bar in assembler output
I'd suggest rewriting this expression in some easier way: p += (*p == '%' && *(p + 1)) ? 2 : 1; I'd prefer if (*p == '%') p++; p++; However, that could be only my taste:) On 26 March 2013 15:10, Maksim Kuznetsov wrote: >> Thanks for the explanation, now I understand it. I fixed the patch >> according to your remarks. I removed %| support since we don't >> actually need it in i386 right now, it was added for the purpose of >> possible generalization. >> >> Updated patch is attached. > > Ping > > -- > Maxim Kuznetsov -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
Re: [patch][cilkplus-merge] Fix a bug in one of the test cases
"Iyer, Balaji V" writes: > Not sure if this went out or not... > >> -Original Message- >> From: Iyer, Balaji V >> Sent: Wednesday, March 27, 2013 11:25 AM >> To: 'GCC Patches (gcc-patches@gcc.gnu.org)' >> Subject: [patch][cilkplus-merge] Fix a bug in one of the test cases >> >> Hello Everyone, >> This patch will fix a bug in one of the test cases. Is it OK >> for pushing? Yes, you mentioned this was to silence a warning so the test would pass. OK. Thanks.
Re: [PATCH, generic] Support printing of escaped curly braces and vertical bar in assembler output
On Tue, Mar 26, 2013 at 4:10 AM, Maksim Kuznetsov
wrote:
>> Thanks for the explanation, now I understand it. I fixed the patch
>> according to your remarks. I removed %| support since we don't
>> actually need it in i386 right now, it was added for the purpose of
>> possible generalization.
>>
>> Updated patch is attached.
>
> Ping
>
For '}' case, can you simply just add
/* Skip over any character after a percent sign. */
if (*p == '%' && *(p + 1))
{
p += 2;
continue;
}
without changing the do-while loop to the while loop?
--
H.J.
Re: [patch] Unified debug dump function names.
On 3/27/13, Richard Biener wrote:
> On Mar 27, 2013, Lawrence Crowl wrote:
>> Patch with rename to debug attached.
>> Tested on x86_64.
>>
>>
>> Add uniform debug dump function names.
>>
>>
>> Add some overloaded functions that provide uniform debug dump
>> function names. These names are:
>>
>> debug: the general debug dumper
>> debug_verbose: for more details
>> debug_raw: for the gory details
>> debug_head: for the heads of declarations, e.g. function heads
>> debug_body: for the bodies of declarations, e.g. function bodies
>>
>> Not all types have the last four versions.
>>
>> The debug functions come in two flavors, those that take pointers
>> to the type, and those that take references to the type. The first
>> handles printing of '' for null pointers. The second assumes
>> a valid reference, and prints the content.
>>
>>
>> Example uses are as follows:
>>
>> cp_token t, *p;
>> debug (t);
>> debug (p);
>>
>> From the debugger, use
>>
>> call debug (t)
>>
>>
>> The functions sets implemented are:
>>
>> debug (only)
>>
>> basic_block_def, const bitmap_head_def, cp_binding_level,
>> cp_parser, cp_token, data_reference, die_struct, edge_def,
>> gimple_statement_d, ira_allocno, ira_allocno_copy, live_range,
>> lra_live_range, omega_pb_d, pt_solution, const rtx_def, sreal,
>> tree_live_info_d, _var_map,
>>
>> vec, vec, vec,
>> vec, vec,
>>
>> debug and debug_raw
>>
>> simple_bitmap_def
>>
>> debug and debug_verbose
>>
>> expr_def, struct loop, vinsn_def
>>
>> debug, debug_raw, debug_verbose, debug_head, debug_body
>>
>> const tree_node
>>
>>
>> This patch is somewhat different from the original plan at
>> gcc.gnu.org/wiki/cxx-conversion/debugging-dumps. The reason
>> is that gdb has an incomplete implementation of C++ call syntax;
>> requiring explicit specification of template arguments and explicit
>> specification of function arguments even when they have default
>> values. So, the original plan would have required typing
>>
>> call dump (t, 0, 0, stderr)
>>
>> which is undesireable. Instead instead of templates, we overload
>> plain functions. This adds a small burden of manually adding
>> the pointer version of dump for each type. Instead of default
>> function arguments, we simply assume the default values. Most of
>> the underlying dump functions did not use the options and indent
>> parameters anyway. Several provide FILE* parameters, but we expect
>> debugging to use stderr anyway. So, the explicit specification of
>> arguments was not as valuable as we thought initially.
>
> Note that generally modules should provide a
>
> print_FOO (FILE *, FOO *...)
>
> interface which should be the worker for the dump_* interface
> which prints to dumpfiles (and stdout/stderr with -fopt-info) and
> the debug_* interface (which just prints to stderr).
I'm not sure what you're saying here. I haven't been adding new
underlying functionality. If there are missing print_FOO functions,
shouldn't they be a separate work item?
>> Finally, a change of name from dump to debug reflect the implicit
>> output to stderr.
>
> A few more questions. As we are now using C++ and these
> functions are not called by GCC itself - do we really need
> all the extern declarations in the header files? We don't have
> -Wstrict-prototypes issues with C++ and I do not consider the debug
> () interface part of the public API of a module. This avoids
> people ending up calling debug () from inside GCC.
We don't need the extern declarations for gdb, but I've written
temporary calls to debug into the source code while I was developing.
It would be handy to not have to add declarations simultaneously.
Your call.
> + if (ptr)
> +debug (*ptr);
> + else
> +fprintf (stderr, "\n");
>
> can we avoid repeating this using a common helper? I'd use a simple
> #define like
>
> #define DO_DEBUG_PTR(p) do { if (p) debug (*(p)) else fprintf (stderr,
> "\n"); } while (0)
>
> but I suppose you can come up with something more clever using C++?
I had a template that did this for us in my earlier code. I removed
the template when I discovered the gdb issue. One advantage to
removing the template was that I no longer needed a common header and
its inclusion in various files. Adding the macro would reintroduce
the header.
My personal preference is to avoid the macros and just live with the
repeated pattern.
--
Lawrence Crowl
[cilkplus-merge] Handle generic pretty printing of ARRAY_NOTATION_REF
While debugging some code I noticed that dump_generic_stmt() does not work on ARRAY_NOTATION_REFs. Attached is a patch adding the smarts to tree-pretty-print. There is no testcase because ARRAY_NOTATION_REFs are expanded by the parser, so by the time the tree dumps happen, there are no more ARRAY_NOTATION_REFs to look at. I am using TREE_OPERAND instead of the preferred ARRAY_NOTATION_* accessors, because these accessors are defined in c-family/c-common.h. Perhaps when both the C and C++ array notations are contributed, we could move the accessors to tree.h or something. Balaji, are you ok with these changes? If you are ok, I will commit this as a fairly trivial and obvious change. commit 6a865bd29f24f94039c9017766d82d05085f320f Author: Aldy Hernandez Date: Wed Mar 27 11:19:56 2013 -0500 Handle generic pretty printing of ARRAY_NOTATION_REF. diff --git a/gcc/ChangeLog.cilkplus b/gcc/ChangeLog.cilkplus index 7c0834d..a0ecc76 100644 --- a/gcc/ChangeLog.cilkplus +++ b/gcc/ChangeLog.cilkplus @@ -8,3 +8,5 @@ ARRAY_NOTATION_REF storage. * Makefile.in (C_COMMON_OBJS): Added c-family/array-notation-common.o. + * tree-pretty-print.c (dump_generic_node): Add case for + ARRAY_NOTATION_REF. diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c index 1613142..36a9f5a 100644 --- a/gcc/tree-pretty-print.c +++ b/gcc/tree-pretty-print.c @@ -1266,6 +1266,17 @@ dump_generic_node (pretty_printer *buffer, tree node, int spc, int flags, pp_string (buffer, ">"); break; +case ARRAY_NOTATION_REF: + dump_generic_node (buffer, TREE_OPERAND (node, 0), spc, flags, false); + pp_character (buffer, '['); + dump_generic_node (buffer, TREE_OPERAND (node, 1), spc, flags, false); + pp_character (buffer, ':'); + dump_generic_node (buffer, TREE_OPERAND (node, 2), spc, flags, false); + pp_character (buffer, ':'); + dump_generic_node (buffer, TREE_OPERAND (node, 3), spc, flags, false); + pp_character (buffer, ']'); + break; + case ARRAY_REF: case ARRAY_RANGE_REF: op0 = TREE_OPERAND (node, 0);
Re: [patch] Hash table changes from cxx-conversion branch
On 3/27/13, Richard Biener wrote: > On Mar 23, 2013 Lawrence Crowl wrote: > > This patch is a consolodation of the hash_table patches to the > > cxx-conversion branch. > > > > Update various hash tables from htab_t to hash_table. > > Modify types and calls to match. > > Ugh. Can you split it up somewhat ... like split target bits > away at least? Targets may prefer to keep the old hashes for > ease of branch maintainance. I will do that. > > * tree-ssa-live.c'var_map_base_init::tree_to_index > > > > New struct tree_int_map_hasher. > > I think this wants to be generalized - we have the common > tree_map/tree_decl_map and tree_int_map maps in tree.h - those > (and its users) should be tackled in a separate patch by providing > common hashtable trails implementations. I will investigate for a separate patch. > > Remove unused: > > > > htab_t scop::original_pddrs > > SCOP_ORIGINAL_PDDRS > > > > Remove unused: > > > > insert_loop_close_phis > > insert_guard_phis > > debug_ivtype_map > > ivtype_map_elt_info > > new_ivtype_map_elt > > Unused function/type removal are obvious changes. > > > Remove unused: > > dse.c bitmap clear_alias_sets > > dse.c bitmap disqualified_clear_alias_sets > > dse.c alloc_pool clear_alias_mode_pool > > dse.c dse_step2_spill > > dse.c dse_step5_spill > > graphds.h htab_t graph::indices > > See above. It wasn't obvious that the functions could be removed. :-) Are you saying you don't want these notations in the description? -- Lawrence Crowl
RE: [cilkplus-merge] Handle generic pretty printing of ARRAY_NOTATION_REF
Yes, it looks OK. Thanks, Balaji V. Iyer. > -Original Message- > From: Aldy Hernandez [mailto:al...@redhat.com] > Sent: Wednesday, March 27, 2013 12:32 PM > To: gcc-patches; Iyer, Balaji V > Subject: [cilkplus-merge] Handle generic pretty printing of > ARRAY_NOTATION_REF > > While debugging some code I noticed that dump_generic_stmt() does not work > on ARRAY_NOTATION_REFs. Attached is a patch adding the smarts to tree- > pretty-print. > > There is no testcase because ARRAY_NOTATION_REFs are expanded by the > parser, so by the time the tree dumps happen, there are no more > ARRAY_NOTATION_REFs to look at. > > I am using TREE_OPERAND instead of the preferred ARRAY_NOTATION_* > accessors, because these accessors are defined in c-family/c-common.h. > Perhaps when both the C and C++ array notations are contributed, we could > move the accessors to tree.h or something. > > Balaji, are you ok with these changes? If you are ok, I will commit this as > a fairly > trivial and obvious change.
[patch] Fix node weight updates during ipa-cp (issue7812053)
I found that the node weight updates on cloned nodes during ipa-cp were
leading to incorrect/insane weights. Both the original and new node weight
computations used truncating divides, leading to a loss of total node weight.
I have fixed this by making both rounding integer divides.
Bootstrapped and tested on x86-64-unknown-linux-gnu. Ok for trunk?
2013-03-27 Teresa Johnson
* ipa-cp.c (update_profiling_info): Perform rounding integer
division when updating weights instead of truncating.
(update_specialized_profile): Ditto.
Index: ipa-cp.c
===
--- ipa-cp.c(revision 197118)
+++ ipa-cp.c(working copy)
@@ -2588,14 +2588,18 @@ update_profiling_info (struct cgraph_node *orig_no
for (cs = new_node->callees; cs ; cs = cs->next_callee)
if (cs->frequency)
- cs->count = cs->count * (new_sum * REG_BR_PROB_BASE
- / orig_node_count) / REG_BR_PROB_BASE;
+ cs->count = (cs->count
+ * ((new_sum * REG_BR_PROB_BASE + orig_node_count/2)
+ / orig_node_count)
+ + REG_BR_PROB_BASE/2) / REG_BR_PROB_BASE;
else
cs->count = 0;
for (cs = orig_node->callees; cs ; cs = cs->next_callee)
-cs->count = cs->count * (remainder * REG_BR_PROB_BASE
-/ orig_node_count) / REG_BR_PROB_BASE;
+cs->count = (cs->count
+ * ((remainder * REG_BR_PROB_BASE + orig_node_count/2)
+/ orig_node_count)
+ + REG_BR_PROB_BASE/2) / REG_BR_PROB_BASE;
if (dump_file)
dump_profile_updates (orig_node, new_node);
@@ -2627,14 +2631,19 @@ update_specialized_profile (struct cgraph_node *ne
for (cs = new_node->callees; cs ; cs = cs->next_callee)
if (cs->frequency)
- cs->count += cs->count * redirected_sum / new_node_count;
+ cs->count += (cs->count
+* ((redirected_sum * REG_BR_PROB_BASE
++ new_node_count/2) / new_node_count)
++ REG_BR_PROB_BASE/2) / REG_BR_PROB_BASE;
else
cs->count = 0;
for (cs = orig_node->callees; cs ; cs = cs->next_callee)
{
- gcov_type dec = cs->count * (redirected_sum * REG_BR_PROB_BASE
- / orig_node_count) / REG_BR_PROB_BASE;
+ gcov_type dec = (cs->count
+ * ((redirected_sum * REG_BR_PROB_BASE
+ + orig_node_count/2) / orig_node_count)
+ + REG_BR_PROB_BASE/2) / REG_BR_PROB_BASE;
if (dec < cs->count)
cs->count -= dec;
else
--
This patch is available for review at http://codereview.appspot.com/7812053
Re: Do not disable -fomit-frame-pointer on !ACCUMULATE_OUTGOING_ARGS targets
> Isn't pass_dwarf2_frame enabled whenever we're generating any unwind info?
Essentially, yes:
static bool
gate_dwarf2_frame (void)
{
#ifndef HAVE_prologue
/* Targets which still implement the prologue in assembler text
cannot use the generic dwarf2 unwinding. */
return false;
#endif
/* ??? What to do for UI_TARGET unwinding? They might be able to benefit
from the optimized shrink-wrapping annotations that we will compute.
For now, only produce the CFI notes for dwarf2. */
return dwarf2out_do_frame ();
}
--
Eric Botcazou
Contents of PO file 'cpplib-4.8.0.zh_TW.po'
cpplib-4.8.0.zh_TW.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
New Chinese (traditional) PO file for 'cpplib' (version 4.8.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Chinese (traditional) team of translators. The file is available at: http://translationproject.org/latest/cpplib/zh_TW.po (This file, 'cpplib-4.8.0.zh_TW.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] Compute and emit working set information from gcov-dump (issue6940061)
Ping. Thanks, Teresa
On Fri, Dec 14, 2012 at 6:11 PM, Teresa Johnson wrote:
> This patch enables the gcov-dump tool to optionally compute and dump
> the working set information from the counter histogram, via a new -w option.
> This is useful to help understand and tune how the compiler will use
> the counter histogram, since it first computes the working set and selects
> thresholds based on that.
>
> This required moving the bulk of the compute_working_sets functionality
> into gcov-io.c so that it was accessible by gcov-dump.c.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, and tested with various
> gcda files. Ok for trunk?
>
> 2012-12-14 Teresa Johnson
>
> * lto-cgraph.c (input_symtab): Replace call to compute_working_sets
> to get_working_sets.
> * gcov-io.c (compute_working_sets): Moved most of body of old
> compute_working_sets here from profile.c.
> * gcov-io.h (NUM_GCOV_WORKING_SETS): Moved here from profile.c.
> (gcov_working_set_t): Moved typedef here from basic-block.h
> (compute_working_set): Declare.
> * profile.c (NUM_GCOV_WORKING_SETS): Moved to gcov-io.h.
> (get_working_sets): Renamed from compute_working_set,
> replace most of body with call to new compute_working_sets.
> (get_exec_counts): Replace call to compute_working_sets
> to get_working_sets.
> * profile.h (get_working_sets): Renamed from
> compute_working_set.
> * basic-block.h (gcov_working_set_t): Moved to gcov-io.h.
> * gcov-dump.c (dump_working_sets): New function.
>
> Index: lto-cgraph.c
> ===
> --- lto-cgraph.c(revision 194502)
> +++ lto-cgraph.c(working copy)
> @@ -1457,7 +1457,7 @@ input_symtab (void)
> }
>
>merge_profile_summaries (file_data_vec);
> - compute_working_sets ();
> + get_working_sets ();
>
>
>/* Clear out the aux field that was used to store enough state to
> Index: gcov-io.c
> ===
> --- gcov-io.c (revision 194502)
> +++ gcov-io.c (working copy)
> @@ -806,3 +806,110 @@ static void gcov_histogram_merge (gcov_bucket_type
>memcpy(tgt_histo, tmp_histo, sizeof (gcov_bucket_type) *
> GCOV_HISTOGRAM_SIZE);
> }
> #endif /* !IN_GCOV */
> +
> +/* This is used by gcov-dump (IN_GCOV == -1) and in the compiler
> + (!IN_GCOV && !IN_LIBGCOV). */
> +#if IN_GCOV <= 0 && !IN_LIBGCOV
> +/* Compute the working set information from the counter histogram in
> + the profile summary. This is an array of information corresponding to a
> + range of percentages of the total execution count (sum_all), and includes
> + the number of counters required to cover that working set percentage and
> + the minimum counter value in that working set. */
> +
> +GCOV_LINKAGE void
> +compute_working_sets (const struct gcov_ctr_summary *summary,
> + gcov_working_set_t *gcov_working_sets)
> +{
> + gcov_type working_set_cum_values[NUM_GCOV_WORKING_SETS];
> + gcov_type ws_cum_hotness_incr;
> + gcov_type cum, tmp_cum;
> + const gcov_bucket_type *histo_bucket;
> + unsigned ws_ix, c_num, count;
> + int h_ix;
> +
> + /* Compute the amount of sum_all that the cumulative hotness grows
> + by in each successive working set entry, which depends on the
> + number of working set entries. */
> + ws_cum_hotness_incr = summary->sum_all / NUM_GCOV_WORKING_SETS;
> +
> + /* Next fill in an array of the cumulative hotness values corresponding
> + to each working set summary entry we are going to compute below.
> + Skip 0% statistics, which can be extrapolated from the
> + rest of the summary data. */
> + cum = ws_cum_hotness_incr;
> + for (ws_ix = 0; ws_ix < NUM_GCOV_WORKING_SETS;
> + ws_ix++, cum += ws_cum_hotness_incr)
> +working_set_cum_values[ws_ix] = cum;
> + /* The last summary entry is reserved for (roughly) 99.9% of the
> + working set. Divide by 1024 so it becomes a shift, which gives
> + almost exactly 99.9%. */
> + working_set_cum_values[NUM_GCOV_WORKING_SETS-1]
> + = summary->sum_all - summary->sum_all/1024;
> +
> + /* Next, walk through the histogram in decending order of hotness
> + and compute the statistics for the working set summary array.
> + As histogram entries are accumulated, we check to see which
> + working set entries have had their expected cum_value reached
> + and fill them in, walking the working set entries in increasing
> + size of cum_value. */
> + ws_ix = 0; /* The current entry into the working set array. */
> + cum = 0; /* The current accumulated counter sum. */
> + count = 0; /* The current accumulated count of block counters. */
> + for (h_ix = GCOV_HISTOGRAM_SIZE - 1;
> + h_ix >= 0 && ws_ix < NUM_GCOV_WORKING_SETS; h_ix--)
> +{
> + histo_bucket = &summary->histogram[h_ix];
> +
> + /* If
Re: Fwd: [Patch, fortran] optimize string comparison
On Wed, Mar 27, 2013 at 10:20:59AM +0100, Tobias Burnus wrote:
> (The email below was only sent to gcc-patches@; I now also CC
> fortran@ - sorry for the full quote)
>
> Regarding the below patch: I think it does not work as-is for
> Unicode strings (UCS4, character(kind=4)), where each character is 4
> bytes wide and a space does not consist of sequences of four ' '.
>
I did not know about that. We could use wmemchr when sizeof(wchar_t)==4.
where should I put that?
>
> Regarding Thomas' patch:* I would also think that memcmp should work
> for kind=4 characters; one then needs to multiply the length by the
> byte-size. (Actually, for kind==1, one could check the excess
> characters in the generated code via memchr as done in Ondřej's
> patch.)
>
>
> However, looking at intrinsics/string_intrinsics{,_inc}.c, I see
> that we don't use MEMCMP for UCS4 either - but some a hand-written
> function. I think that could also be replaced by the normal memcmp
> (or did I miss some fine print?). A possible patch would be to
> replace
> #define MEMCMP memcmp_char4
> by
> #define MEMCMP(a,b,c) memcmp(a,b,4*(c))
> and delete the memcmp_char4 function.
>
Or use wmemcmp.
>
> Tobias
>
> * http://gcc.gnu.org/ml/fortran/2013-03/msg00142.html
>
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
So I committed the patch with two modifications at revision 197168 as * config/i386/cygwin-stdint.h: Add support for cygwin x64 target. * config/i386/t-cygwin-w64: New file. * config/i386/cygwin-w64.h: New file. * config/i386/cygwin.h (EXTRA_OS_CPP_BUILTINS): Extend and add support for x64-cygwin target. (CPP_SPEC): Likewise. (CXX_WRAP_SPEC_LIST): Undefine before define. (LIBGCJ_SONAME): Use 15 as version. First I removed useless undef in cygwin.h header. Also I removed this version-number calculation and changed version to use 15 for libjava's DLL. Regards, Kai
Re: [cilkplus-merge] Handle generic pretty printing of ARRAY_NOTATION_REF
On 03/27/13 12:01, Iyer, Balaji V wrote: Yes, it looks OK. Thanks, Balaji V. Iyer. Ok, thanks. Committed to branch.
[wwwdocs] gcc-3.1/criteria.html links maintenance
Adjust kernel.org link to use https. Applied. Gerald Index: criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/criteria.html,v retrieving revision 1.35 diff -u -3 -p -r1.35 criteria.html --- criteria.html 29 Mar 2009 22:40:07 - 1.35 +++ criteria.html 27 Mar 2013 21:36:40 - @@ -239,7 +239,7 @@ shown here are used for GCC 3.1 integrat build and test guide -http://www.kernel.org";>Linux kernel +https://www.kernel.org";>Linux kernel C 2.4.18
[wwwdocs] Fix projects/cxx-reflection/index.html link to our SVN page
Applied. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-reflection/index.html,v retrieving revision 1.5 diff -u -3 -p -r1.5 index.html --- index.html 29 Dec 2012 00:24:56 - 1.5 +++ index.html 27 Mar 2013 21:40:30 - @@ -22,7 +22,7 @@ constrained genericity in C++. Contributing Checkout the cxx-reflection-branch branch -in our respository. +in our respository. When posting to the development lists, please mark messages and patches with [cxx-reflection] in the subject. As this is a branch, and not
[wwwdocs] Update for two entries in frontends.html
Both of these are currently getting a permanent redirect. Applied. Index: frontends.html === RCS file: /cvs/gcc/wwwdocs/htdocs/frontends.html,v retrieving revision 1.37 diff -u -3 -p -r1.37 frontends.html --- frontends.html 28 Jan 2011 19:33:38 - 1.37 +++ frontends.html 27 Mar 2013 21:50:18 - @@ -27,10 +27,10 @@ are very mature. -http://www.gnu-pascal.de/";>GNU Pascal Compiler (GPC). +http://www.gnu-pascal.de/gpc/h-index.html";>GNU Pascal Compiler (GPC). http://www.mercury.cs.mu.oz.au/download/gcc-backend.html";>Mercury, +href="http://www.mercurylang.org/download/gcc-backend.html";>Mercury, a declarative logic/functional language. The University of Melbourne Mercury compiler is written in Mercury; originally it compiled via C but now it also has a backend that generates assembler directly, using the GCC backend.
[cilkplus-merge] rewrite __sec_reduce* builtin handling to use <.def> infrastructure
Hi Joseph. As you have requested, I have rewritten the __sec_reduce* builtins to use the built-in <.def> infrastructure. You mentioned that the __sec_implicit_index built-in may have to be rewritten as a keyword, provided that relevant changes are made to the specification. For now, I have left this as a builtin, but as soon as the spec is resolved, I can rewrite this particular one as a keyword. I have cleaned up a lot of the __sec_reduce* handling as well and I even got rid of the REDUCE_* enums since we can just use the BUILT_IN_* enums. Is this OK for the branch? I'd like to get a nod of approval before committing to the branch, as to aid in review, but if you prefer that I just commit at will, and then post a big "cilk plus array notation" patch to the list, I can do this instead. It just seems easier to fix stuff incrementally, as suggestions and fixes are piling up for both Balaji and myself. Thanks. Aldy commit 76d3fa024e2d4fdc0f295f7ccc567455ac022a60 Author: Aldy Hernandez Date: Wed Mar 27 09:43:38 2013 -0500 Rewrite __sec_reduce* built-in handling to use the .def infrastructure. diff --git a/gcc/ChangeLog.cilkplus b/gcc/ChangeLog.cilkplus index a0ecc76..bf08713 100644 --- a/gcc/ChangeLog.cilkplus +++ b/gcc/ChangeLog.cilkplus @@ -10,3 +10,8 @@ c-family/array-notation-common.o. * tree-pretty-print.c (dump_generic_node): Add case for ARRAY_NOTATION_REF. + (BUILTINS_DEF): Depend on cilkplus.def. + * builtins.def: Include cilkplus.def. + Define DEF_CILKPLUS_BUILTIN. + * builtin-types.def: Define BT_FN_INT_PTR_PTR_PTR. + * cilkplus.def: New file. diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 11ef491..74a4136 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -861,7 +861,7 @@ RTL_ERROR_H = rtl-error.h $(RTL_H) $(DIAGNOSTIC_CORE_H) READ_MD_H = $(OBSTACK_H) $(HASHTAB_H) read-md.h PARAMS_H = params.h params.def BUILTINS_DEF = builtins.def sync-builtins.def omp-builtins.def \ - gtm-builtins.def sanitizer.def + gtm-builtins.def sanitizer.def cilkplus.def INTERNAL_FN_DEF = internal-fn.def INTERNAL_FN_H = internal-fn.h $(INTERNAL_FN_DEF) TREE_H = coretypes.h tree.h all-tree.def tree.def c-family/c-common.def \ diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def index 3ef2d1b..2634ecc 100644 --- a/gcc/builtin-types.def +++ b/gcc/builtin-types.def @@ -368,6 +368,8 @@ DEF_FUNCTION_TYPE_3 (BT_FN_INT_CONST_STRING_CONST_STRING_VALIST_ARG, BT_INT, BT_CONST_STRING, BT_CONST_STRING, BT_VALIST_ARG) DEF_FUNCTION_TYPE_3 (BT_FN_INT_FILEPTR_CONST_STRING_VALIST_ARG, BT_INT, BT_FILEPTR, BT_CONST_STRING, BT_VALIST_ARG) +DEF_FUNCTION_TYPE_3 (BT_FN_INT_PTR_PTR_PTR, +BT_INT, BT_PTR, BT_PTR, BT_PTR) DEF_FUNCTION_TYPE_3 (BT_FN_STRING_CONST_STRING_CONST_STRING_INT, BT_STRING, BT_CONST_STRING, BT_CONST_STRING, BT_INT) DEF_FUNCTION_TYPE_3 (BT_FN_FLOAT_FLOAT_FLOAT_FLOAT, diff --git a/gcc/builtins.def b/gcc/builtins.def index 4f378fa..09303bc 100644 --- a/gcc/builtins.def +++ b/gcc/builtins.def @@ -157,6 +157,11 @@ along with GCC; see the file COPYING3. If not see true, true, true, ATTRS, true, \ (flag_asan || flag_tsan)) +#undef DEF_CILKPLUS_BUILTIN +#define DEF_CILKPLUS_BUILTIN(ENUM, NAME, TYPE, ATTRS) \ + DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, TYPE, TYPE, \ + false, false, true, ATTRS, false, flag_enable_cilkplus) + /* Define an attribute list for math functions that are normally "impure" because some of them may write into global memory for `errno'. If !flag_errno_math they are instead "const". */ @@ -837,3 +842,5 @@ DEF_GCC_BUILTIN (BUILT_IN_LINE, "LINE", BT_FN_INT, ATTR_NOTHROW_LEAF_LIST) /* Sanitizer builtins. */ #include "sanitizer.def" +/* Cilk Plus builtins. */ +#include "cilkplus.def" diff --git a/gcc/c-family/ChangeLog.cilkplus b/gcc/c-family/ChangeLog.cilkplus index 6591fd1..25f5ec5 100644 --- a/gcc/c-family/ChangeLog.cilkplus +++ b/gcc/c-family/ChangeLog.cilkplus @@ -1,21 +1,17 @@ 2013-03-20 Balaji V. Iyer - * c-common.c (c_define_builtins): When cilkplus is enabled, the - function array_notation_init_builtins() is called. - (c_common_init_ts): Added ARRAY_NOTATION_REF as typed. + * c-common.c (c_common_init_ts): Added ARRAY_NOTATION_REF as typed. * c-common.def (ARRAY_NOTATION_REF): New tree. * c-common.h (build_array_notation_expr): New function declaration. (build_array_notation_ref): Likewise. (extract_sec_implicit_index_arg): New extern declaration. (is_sec_implicit_index_fn): Likewise. - (array_notation_init_builtins): Likewise. (ARRAY_NOTATION_CHECK): New define. (ARRAY_NOTATION_ARRAY): Likewise. (ARRAY_NOTATION_START): Likewise. (ARRAY_NOTATION_LENGTH): Likewise. (ARRAY_NOTATION_STRIDE): Likewise. (ARRAY_NOTATION_TYPE): Lik
[Patch, ARM] Enable libsanitizer
Hi,
This small patch enables libsanitizer on ARM.
It has been tested successfully on cortex-a9 hardware (via the GCC testsuite).
I have chosen to bundle -funwind-table with -fsanitize=* so that a
useful backtrace can be printed to the user in case of error,
otherwise the reporting is limited to one line belonging to
libsanitizer.so.
Note that the testsuite currently fails when executing under qemu:
- support of /proc/self/maps does not conform to the kernel format.
One extra space is missing from some lines, which confuses libsanitizer.
Patch proposed to upstream qemu:
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg03051.html
- qemu reserves some memory space by default, conflicting with
libsanitizer needs.
Workaround: invoke qemu with -R 0
- libsanitizer detects if its output is a tty, and when GCC testsuite
is executed under qemu, libsanitizer concludes that it is actually
running under a tty, and adds beautyfying characters which confuse
dejanu.
OK?
Christophe.
2013-03-27 Christophe Lyon
gcc/
* config/arm/arm.c (arm_asan_shadow_offset): New function.
(TARGET_ASAN_SHADOW_OFFSET): Define.
* config/arm/linux-eabi.h (ASAN_CC1_SPEC): Define.
(LINUX_OR_ANDROID_CC): Add ASAN_CC1_SPEC.
libsanitizer/
* configure.tgt: Add ARM pattern.
=== modified file 'gcc/config/arm/arm.c'
--- gcc/config/arm/arm.c2013-02-28 10:26:41 +
+++ gcc/config/arm/arm.c2013-03-04 08:39:02 +
@@ -280,6 +280,8 @@
static void arm_canonicalize_comparison (int *code, rtx *op0, rtx *op1,
bool op0_preserve_value);
+static unsigned HOST_WIDE_INT arm_asan_shadow_offset (void);
+
/* Table of machine attributes. */
static const struct attribute_spec arm_attribute_table[] =
@@ -649,6 +651,9 @@
#define TARGET_CANONICALIZE_COMPARISON \
arm_canonicalize_comparison
+#undef TARGET_ASAN_SHADOW_OFFSET
+#define TARGET_ASAN_SHADOW_OFFSET arm_asan_shadow_offset
+
struct gcc_target targetm = TARGET_INITIALIZER;
/* Obstack for minipool constant handling. */
@@ -27393,4 +27398,12 @@
}
+/* Implement the TARGET_ASAN_SHADOW_OFFSET hook. */
+
+static unsigned HOST_WIDE_INT
+arm_asan_shadow_offset (void)
+{
+ return (unsigned HOST_WIDE_INT) 1 << 29;
+}
+
#include "gt-arm.h"
=== modified file 'gcc/config/arm/linux-eabi.h'
--- gcc/config/arm/linux-eabi.h 2013-01-10 20:38:27 +
+++ gcc/config/arm/linux-eabi.h 2013-03-26 09:59:11 +
@@ -84,10 +84,14 @@
LINUX_OR_ANDROID_LD (LINUX_TARGET_LINK_SPEC, \
LINUX_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC)
+#undef ASAN_CC1_SPEC
+#define ASAN_CC1_SPEC "%{fsanitize=*:-funwind-tables}"
+
#undef CC1_SPEC
#define CC1_SPEC \
- LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \
- GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC)
+ LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC " " ASAN_CC1_SPEC, \
+ GNU_USER_TARGET_CC1_SPEC " " ASAN_CC1_SPEC " " \
+ ANDROID_CC1_SPEC)
#define CC1PLUS_SPEC \
LINUX_OR_ANDROID_CC ("", ANDROID_CC1PLUS_SPEC)
=== modified file 'libsanitizer/configure.tgt'
--- libsanitizer/configure.tgt 2013-02-11 23:13:37 +
+++ libsanitizer/configure.tgt 2013-03-04 08:39:02 +
@@ -29,6 +29,8 @@
;;
sparc*-*-linux*)
;;
+ arm*-*-linux*)
+ ;;
x86_64-*-darwin[1]* | i?86-*-darwin[1]*)
TSAN_SUPPORTED=no
;;
[wwwdocs] readings.html: update link to AVR documentation
Applied Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.221 diff -u -3 -p -r1.221 readings.html --- readings.html 1 Nov 2012 23:41:38 - 1.221 +++ readings.html 27 Mar 2013 22:09:25 - @@ -80,7 +80,7 @@ names. AVR Manufacturer: Atmel - http://www.atmel.com/products/AVR/";>AVR Documentation + http://www.atmel.com/products/microcontrollers/avr/";>AVR Documentation Blackfin
Re: [cilkplus-merge] rewrite __sec_reduce* builtin handling to use <.def> infrastructure
On Wed, 27 Mar 2013, Aldy Hernandez wrote: > Is this OK for the branch? I'd like to get a nod of approval before > committing to the branch, as to aid in review, but if you prefer that I just > commit at will, and then post a big "cilk plus array notation" patch to the > list, I can do this instead. It just seems easier to fix stuff incrementally, > as suggestions and fixes are piling up for both Balaji and myself. I'm expecting the two of you to deal with reviews for the branch and then repost a big patch against trunk once you think all the comments have been addressed. But this looks like the sort of thing I was expecting for cleaning up the built-in function handling. -- Joseph S. Myers jos...@codesourcery.com
[doc] Tweak link for AVR-LibC user manual
2013-03-27 Gerald Pfeifer
* doc/invoke.texi (AVR Options): Tweak link for AVR-LibC user manual.
* doc/extend.texi (Named Address Spaces): Ditto.
(Variable Attributes): Ditto.
Installed on HEAD; will also apply to GCC 4.8 in a day or two.
Gerald
Index: doc/extend.texi
===
--- doc/extend.texi (revision 197179)
+++ doc/extend.texi (working copy)
@@ -1339,7 +1339,7 @@
accesses to these data read from generic address space, i.e.@:
from RAM,
so that you need special accessors like @code{pgm_read_byte}
-from @w{@uref{http://nongnu.org/avr-libc/user-manual,AVR-LibC}}
+from @w{@uref{http://nongnu.org/avr-libc/user-manual/,AVR-LibC}}
together with attribute @code{progmem}.
@noindent
@@ -4940,7 +4940,7 @@
In order to read data located with the @code{progmem} attribute
(inline) assembler must be used.
@smallexample
-/* Use custom macros from
@w{@uref{http://nongnu.org/avr-libc/user-manual,AVR-LibC}} */
+/* Use custom macros from
@w{@uref{http://nongnu.org/avr-libc/user-manual/,AVR-LibC}} */
#include
/* Locate var in flash memory */
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 197179)
+++ doc/invoke.texi (working copy)
@@ -11708,7 +11708,7 @@
The startup code from libgcc never sets @code{EIND}.
Notice that startup code is a blend of code from libgcc and AVR-LibC.
For the impact of AVR-LibC on @code{EIND}, see the
-@w{@uref{http://nongnu.org/avr-libc/user-manual,AVR-LibC user manual}}.
+@w{@uref{http://nongnu.org/avr-libc/user-manual/,AVR-LibC user manual}}.
@item
It is legitimate for user-specific startup code to set up @code{EIND}
Re: [cilkplus-merge] rewrite __sec_reduce* builtin handling to use <.def> infrastructure
On 03/27/13 17:10, Joseph S. Myers wrote: On Wed, 27 Mar 2013, Aldy Hernandez wrote: Is this OK for the branch? I'd like to get a nod of approval before committing to the branch, as to aid in review, but if you prefer that I just commit at will, and then post a big "cilk plus array notation" patch to the list, I can do this instead. It just seems easier to fix stuff incrementally, as suggestions and fixes are piling up for both Balaji and myself. I'm expecting the two of you to deal with reviews for the branch and then repost a big patch against trunk once you think all the comments have been addressed. But this looks like the sort of thing I was expecting for cleaning up the built-in function handling. Ah, ok. Will do. Thanks.
Re: [patch] Use JUMP_TABLE_DATA_P instead of JUMP_P and GET_CODE tests
*Ping* On Sat, Mar 23, 2013 at 5:15 PM, Steven Bosscher wrote: > Hello, > > This patch replaces all tests I could find, where the code is looking > for jump table data with GET_CODE(..)=ADDR_VEC and similar with > JUMP_TABLE_DATA_P tests. > > Most replacements are mechanical, but a few are not: > > * The code in s390.c looked odd, I think the replacement code is > easier to follow. > > * The changed in bfin.c and a few other places assume that ADDR_VEC > and ADDR_DIFF_VEC can only appear as tablejump data. This appears to > be assumed in many other places in the compiler (although AFAICT it's > not documented as such) and it looks like the authors of the changed > code simply omitted the JUMP_P test before looking at the pattern for > an ADDR_VEC/ADDR_DIFF_VEC. > > BTW if ADDR_VEC/ADDR_DIFF_VEC really only appear in JUMP_TABLE_DATA_P > insns then tests for these codes can be removed in all places where > the insn being looked at must be in a basic block. That's almost all > places in the middle-end proper (especially as case labels) and I > intend to clean that up in a follow-up patch. > > But first... > > Bootstrapped&tested on powerpc64-unknown-linux-gnu and on > ia64-unknown-linux-gnu. > OK for trunk? > > Ciao! > Steven
[C++ Patch] Fix some informs following permerror
Hi,
this is almost obvious, I guess: Manuel kindly explained in the audit
trail of c++/56725 that if a permerror returns false no diagnostic was
actually emitted thus any accompanying inform should not be called,
otherwise with -fpermissive -w only the latter are wrongly emitted.
Tested x86_64-linux.
Thanks,
Paolo.
///
2013-03-27 Paolo Carlini
* call.c (joust): Don't call inform for a permerror returning false.
* parser.c (cp_parser_check_class_key): Likewise.
* pt.c (tsubst_copy_and_build): Likewise.
Index: call.c
===
--- call.c (revision 197184)
+++ call.c (working copy)
@@ -8650,13 +8650,15 @@ joust (struct z_candidate *cand1, struct z_candida
{
if (complain & tf_error)
{
- permerror (input_location,
-"default argument mismatch in "
-"overload resolution");
- inform (input_location,
- " candidate 1: %q+#F", cand1->fn);
- inform (input_location,
- " candidate 2: %q+#F", cand2->fn);
+ if (permerror (input_location,
+"default argument mismatch in "
+"overload resolution"))
+ {
+ inform (input_location,
+ " candidate 1: %q+#F", cand1->fn);
+ inform (input_location,
+ " candidate 2: %q+#F", cand2->fn);
+ }
}
else
return 0;
Index: parser.c
===
--- parser.c(revision 197184)
+++ parser.c(working copy)
@@ -23363,12 +23363,12 @@ cp_parser_check_class_key (enum tag_types class_ke
return;
if ((TREE_CODE (type) == UNION_TYPE) != (class_key == union_type))
{
- permerror (input_location, "%qs tag used in naming %q#T",
-class_key == union_type ? "union"
-: class_key == record_type ? "struct" : "class",
-type);
- inform (DECL_SOURCE_LOCATION (TYPE_NAME (type)),
- "%q#T was previously declared here", type);
+ if (permerror (input_location, "%qs tag used in naming %q#T",
+class_key == union_type ? "union"
+: class_key == record_type ? "struct" : "class",
+type))
+ inform (DECL_SOURCE_LOCATION (TYPE_NAME (type)),
+ "%q#T was previously declared here", type);
}
}
Index: pt.c
===
--- pt.c(revision 197184)
+++ pt.c(working copy)
@@ -14019,30 +14019,32 @@ tsubst_copy_and_build (tree t,
fn = TREE_OPERAND (fn, 1);
if (is_overloaded_fn (fn))
fn = get_first_fn (fn);
- permerror (EXPR_LOC_OR_HERE (t),
- "%qD was not declared in this scope, "
- "and no declarations were found by "
- "argument-dependent lookup at the point "
- "of instantiation", function);
- if (!DECL_P (fn))
- /* Can't say anything more. */;
- else if (DECL_CLASS_SCOPE_P (fn))
+ if (permerror (EXPR_LOC_OR_HERE (t),
+ "%qD was not declared in this scope, "
+ "and no declarations were found by "
+ "argument-dependent lookup at the point "
+ "of instantiation", function))
{
- inform (EXPR_LOC_OR_HERE (t),
- "declarations in dependent base %qT are "
- "not found by unqualified lookup",
- DECL_CLASS_CONTEXT (fn));
- if (current_class_ptr)
- inform (EXPR_LOC_OR_HERE (t),
- "use %%D%> instead", function);
+ if (!DECL_P (fn))
+ /* Can't say anything more. */;
+ else if (DECL_CLASS_SCOPE_P (fn))
+ {
+ inform (EXPR_LOC_OR_HERE (t),
+ "declarations in dependent base %qT are "
+ "not found by unqualified lookup",
+ DECL_CLASS_CONTEXT (fn));
+ if (current_class_ptr)
+ inform (EXPR_LOC_OR_HERE (t),
+
Re: [C++ Patch] Fix some informs following permerror
OK. Jason
Re: extend fwprop optimization
I am not familiar how to use define_subst, so I write a patch that
changes define_insn_and_split to define_insn. bootstrapped and
regression tested on x86_64-unknown-linux-gnu.
A question is: after that change, Is there anyway I can make
targetm.rtx_costs() aware about the truncation, .i.e the cost is only
a "shift" instead of "shift + and".
Thanks,
Wei.
On Tue, Mar 26, 2013 at 11:23 AM, Uros Bizjak wrote:
> On Tue, Mar 26, 2013 at 10:14 AM, Richard Biener
> wrote:
I am trying to figure out a way not to lose the opportunity when shift
truncation is not combined in a bit test pattern. Can we keep the
explicit truncation in RTL, but generate truncation code in assembly?
Then only shift truncation which not combined in a bit test
pattershift truncationn will happen.
(define_insn "*"
[(set (match_operand:SWI48 0 "nonimmediate_operand" "=rm")
(any_shiftrt:SWI48
(match_operand:SWI48 1 "nonimmediate_operand" "0")
(subreg:QI
(and:SI
(match_operand:SI 2 "nonimmediate_operand" "c")
(match_operand:SI 3 "const_int_operand" "n")) 0)))
(clobber (reg:CC FLAGS_REG))]
"ix86_binary_operator_ok (, mode, operands)"
{
if ((INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode)-1))
== GET_MODE_BITSIZE (mode)-1)
return "and\t{%3, %2|%2, %3}\n\r shift\t{%b2, %0|%0, %b2}";
else
"shift\t{%2, %0|%0, %2}";
}
>>>
>>> Sorry, rectify a mistake:
>>>
>>> {
>>>if ((INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode)-1))
>>> == GET_MODE_BITSIZE (mode)-1)
>>> return "shift\t{%2, %0|%0, %2}";
>>>else
>>> return "and\t{%3, %2|%2, %3}\n\r shift\t{%b2, %0|%0, %b2}";
>>> }
>>
>> I'm not sure the existing patterns are wrong because SHIFT_COUNT_TRUNCATED
>> is false for x86 AFAIK, exactly because of the bit-test vs. shift instruction
>> differences. So there is no inconsistency. The i386 backend seems to
>> try to follow my suggestion as if SHIFT_COUNT_TRUNCATED didn't exist
>> (well, it's false, so it technically doesn't exist for i386) and recognizes
>> the shift with truncate with the *3_mask splitter.
>> But I'm not sure why it bothers to do it with a splitter instead of just
>> with a define_insn? Because the split code,
>>
>> [(parallel [(set (match_dup 0)
>>(any_shiftrt:SWI48 (match_dup 1) (match_dup 2)))
>> (clobber (reg:CC FLAGS_REG))])]
>>
>> is wrong and could be combined into a bit-test instruction. No?
>>
>> That is, why not have define_insn variants for shift instructions with
>> explicit truncation?
>
> You are right, the split is harmful in this case.
>
> It looks to me, that explicit truncation can be added to split
> patterns in the most elegant way using proposed "define_subst"
> infrastructure.
>
> Uros.
changelog
Description: Binary data
patch
Description: Binary data
