Re: Interaction between first stage build with g++ and $PATH
On Wed, Aug 15, 2012 at 10:17:18PM -0700, Gary Funck wrote: I can file a bug reported if necessary, but am wondering if it is a known requirement not to have . on $PATH or to explicitly set CC and CXX? Having . in $PATH is a serious bug (especially from security POV). Just never do that. Jakub
Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)
On Wed, 15 Aug 2012, Lawrence Crowl wrote:
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T T;
? Given that this name is scoped anyway...
I do not much like _t names either.
The following is what I'm testing now, it also integrates the
hashtable support functions and typedef within the existing local
data types which is IMHO cleaner. (it also shows we can do with
a janitorial cleanup replacing typedef struct foo_d {} foo; with
struct foo {}; and the likes)
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu, ok?
Thanks,
Richard.
2012-08-16 Richard Guenther rguent...@suse.de
* hash-table.h (class hash_table): Use a descriptor template
argument instead of decomposed element type and support
functions.
(struct pointer_hash): New generic typed pointer-hash.
(struct typed_free_remove, struct typed_noop_remove): Generic
hash_table support pieces.
* coverage.c (struct counts_entry): Add hash_table support
members.
* tree-ssa-ccp.c (gimple_htab): Use pointer_hash.
* tree-ssa-coalesce.c (struct ssa_name_var_hash): New generic
SSA name by SSA_NAME_VAR hash.
(coalesce_ssa_name): Use it.
* tree-ssa-pre.c (struct pre_expr_d): Add hash_table support.
(expression_to_id): Adjust.
(struct expr_pred_trans_d): Add hash_table support.
(phi_translate_table): Adjust.
(phi_trans_lookup): Likewise.
(phi_trans_add): Likewise.
(do_regular_insertion): Likewise.
* tree-ssa-tail-merge.c (struct same_succ_def): Add hash_table
support.
(same_succ_htab): Adjust.
(find_same_succ_bb): Likewise.
(find_same_succ): Likewise.
(update_worklist): Likewise.
* tree-ssa-threadupdate.c (struct redirection_data): Add hash_table
support.
(redirection_data): Adjust.
Index: gcc/hash-table.h
===
*** gcc/hash-table.h.orig 2012-08-16 10:33:59.0 +0200
--- gcc/hash-table.h2012-08-16 11:08:36.311277498 +0200
*** xcallocator Type::data_free (Type *mem
*** 83,127
}
! /* A common function for hashing a CANDIDATE typed pointer. */
template typename Element
! inline hashval_t
! typed_pointer_hash (const Element *candidate)
{
! /* This is a really poor hash function, but it is what the current code
uses,
! so I am reusing it to avoid an additional axis in testing. */
! return (hashval_t) ((intptr_t)candidate 3);
! }
!
! /* A common function for comparing an EXISTING and CANDIDATE typed pointers
!for equality. */
template typename Element
! inline int
! typed_pointer_equal (const Element *existing, const Element * candidate)
{
! return existing == candidate;
! }
! /* A common function for doing nothing on removing a RETIRED slot. */
template typename Element
! inline void
! typed_null_remove (Element *retired ATTRIBUTE_UNUSED)
{
! }
! /* A common function for using free on removing a RETIRED slot. */
template typename Element
! inline void
! typed_free_remove (Element *retired)
{
! free (retired);
}
--- 83,134
}
! /* Remove method dispatching to free. */
template typename Element
! struct typed_free_remove
{
! static inline void remove (Element *p) { free (p); }
! };
! /* No-op remove method. */
template typename Element
! struct typed_noop_remove
{
! static inline void remove (Element *) {}
! };
! /* Pointer hash with a no-op remove method. */
template typename Element
! struct pointer_hash : typed_noop_remove Element
{
! typedef Element T;
+ static inline hashval_t
+ hash (const T *);
! static inline int
! equal (const T *existing, const T * candidate);
! };
template typename Element
! inline hashval_t
! pointer_hashElement::hash (const T *candidate)
{
! /* This is a really poor hash function, but it is what the current code
uses,
! so I am reusing it to avoid an additional axis in testing. */
! return (hashval_t) ((intptr_t)candidate 3);
! }
!
! template typename Element
! inline int
! pointer_hashElement::equal (const T *existing,
! const T *candidate)
! {
! return existing == candidate;
}
*** extern hashval_t hash_table_mod2 (hashva
*** 147,157
/* Internal implementation type. */
! template typename Element
struct hash_table_control
{
/* Table itself. */
! Element **entries;
/* Current size (in entries) of the hash table. */
size_t size;
--- 154,164
/* Internal implementation type. */
! template typename T
struct hash_table_control
{
/* Table itself.
Re: [PATCH] Set current_function_decl in {push,pop}_cfun and push_struct_function
On Wed, Aug 15, 2012 at 5:21 PM, Martin Jambor mjam...@suse.cz wrote: Hi, On Fri, Aug 10, 2012 at 04:57:41PM +0200, Eric Botcazou wrote: - ada/gcc-interface/utils.c:rest_of_subprog_body_compilation calls dump_function which in turns calls dump_function_to_file which calls push_cfun. But Ada front end has its idea of the current_function_decl and there is no cfun which is an inconsistency which makes push_cfun assert fail. I solved it by temporarily setting current_function_decl to NULL_TREE. It's just dumping and I thought that dump_function should be considered middle-end and thus middle-end invariants should apply. If you think that calling dump_function from rest_of_subprog_body_compilation is a layering violation, I don't have a problem with replacing it with a more manual scheme like the one in c-family/c-gimplify.c:c_genericize, provided that this yields roughly the same output. Richi suggested on IRC that I remove the push/pop_cfun calls from dump_function_to_file. The only problem seems to be dump_histograms_for_stmt (buried in a dump_bb call) which needs a function to get the value histograms. Richi suggested to replace the per function hash with one global one. I tried that and bumped into two problems: First, I did not really know when to deallocate the global hash and all the histograms. More importantly, the current gimple verifier (verify_gimple_in_cfg) checks that there are no dead histograms in the hash corresponding to statements no longer in the function. With one global hash, it would be very cumbersome to do this check (add cfun to each histogram? only when checking is enabled?). Hash tables are now in flux anyway so I postponed that work until the interface settles down. Nevertheless, I guess I need a confirmation from maintainers that I can remove the checking if I continue this way. When I looked at what would need to be changed if I added a function parameter to dump_bb, the work list grew very large very quickly. It is probably doable, but the change will be quite big, so if anyone thinks it is a bad idea, please email me to stop. If I manage to change the dumping in one of the two ways, the call will not be a layering problem any more as it probably should not be. At the moment, it probably is. We'll see. If dumping a statement needs the containing function then we need to either pass that down, provide a way to get from statement to function, or stop requiring the function. Making the hash global is choice three (deallocating the hash would be when compilation is finished, in which case you can double-check that it is empty and preserve above checking). Option one is ok as well, option two is probably either unreliable (going from gimple_block to function from function scope - but maybe who cares for dumping?) or expensive (add a pointer from basic_block to struct function). I'm fine with both option three (would even save a pointer in struct function!) or one. Other opinions? Thanks, Richard. Thanks, Martin
Re: [patch] PR54146 - rewrite rewrite_into_loop_closed_ssa
On Wed, Aug 15, 2012 at 6:26 PM, Steven Bosscher stevenb@gmail.com wrote: Hello, This patch rewrites the rewriting part of rewrite_into_loop_closed_ssa. This function took ~300s on the simplified test case for PR54146, walking around the many thousands of loops in the 400,000 basic blocks in the CFG, in compute_global_livein. For rewriting into LC-SSA, we can do better than that if we use the knowledge that we're actually computing livein for an SSA name DEF, therefore its uses must all be dominated by the basic block where DEF is assigned a value. But walking up the dominator tree doesn't work here because we want to traverse and mark the edges in the CFG where DEF is live, and we may not see those edges if we walk up the dominator tree from a USE to DEF. We do know, however, that when we walk up the CFG then: 1. if we enter any loop nested in the same loop as the basic block containing DEF (let's call it DEF_LOOP) then we can stop walking because the only way in is through one of the edges we're interested in. 2. if we enter a loop is not in the nesting stack of DEF_LOOP, then we can skin straight to the header of the loop and continue looking up from there. 3. if we reach a basic block X as a predecessor of Y and Y dominates X then we don't have to look at X or any of its predecessors. Putting this all together, you end up with what looks like a poor man's form of structural analysis where the control tree only contains loop nodes, non-loop basic blocks, and irreducible regions. (Honza: maybe re-surrect http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html? Now that we can maintain the loop tree, perhaps it's also feasible to maintain the complete control tree and use it in places where we want to analyze only a sub-CFG?) The effect is that the time spent in rewrite_into_loop_closed_ssa drops to less than one second. Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk? Ok! It recently occured to me that the only reason we do not have virtual operands in loop-closed-SSA form (and thus jump through hoops dealing with them in cfgloopmainp and elsewhere) was that we'd have so many of them. Today we just have a single one, so maybe we can simplify things here (the into-lc-SSA code just skips vops, not doing that should provide lc-SSA form even for virtuals). Many thanks for all these speed-ups! Richard. Ciao! Steven
Commit: Fixes for building avr-elf with g++.
Hi Denis, Hi Anatoly, Hi Eric,
I am applying the patch below as an obvious fix for building the
avr-elf port of gcc with a C++ compiler.
There were two problems:
* t-avr was using $(CC) instead of $(COMPILER) which meant the
targets failed to build because they included C++ style headers
(eg vec.h).
* avr.c was using integer values in places where a specific enum was
required.
The patch below fixes these problems and allows avr-elf-gcc to be
built.
Cheers
Nick
gcc/ChangeLog
2012-08-16 Nick Clifton ni...@redhat.com
* config/avr/t-avr: Replace occurrences of $(CC) with $(COMPILER).
* config/avr/avr.c (avr_legitimize_reload_address): Add casts
for reload_type enums.
(DEF_BUILTIN): Cast the icode to enum insn_code.
Index: gcc/config/avr/avr.c
===
--- gcc/config/avr/avr.c(revision 190438)
+++ gcc/config/avr/avr.c(working copy)
@@ -1741,7 +1741,7 @@
push_reload (XEXP (mem, 0), NULL_RTX, XEXP (mem, 0), NULL,
POINTER_REGS, Pmode, VOIDmode, 0, 0,
- 1, addr_type);
+ 1, (enum reload_type) addr_type);
if (avr_log.legitimize_reload_address)
avr_edump ( RCLASS.2 = %R\n IN = %r\n OUT = %r\n,
@@ -1749,7 +1749,7 @@
push_reload (mem, NULL_RTX, XEXP (x, 0), NULL,
BASE_POINTER_REGS, GET_MODE (x), VOIDmode, 0, 0,
- opnum, type);
+ opnum, (enum reload_type) type);
if (avr_log.legitimize_reload_address)
avr_edump ( RCLASS.2 = %R\n IN = %r\n OUT = %r\n,
@@ -1763,7 +1763,7 @@
{
push_reload (x, NULL_RTX, px, NULL,
POINTER_REGS, GET_MODE (x), VOIDmode, 0, 0,
- opnum, type);
+ opnum, (enum reload_type) type);
if (avr_log.legitimize_reload_address)
avr_edump ( RCLASS.3 = %R\n IN = %r\n OUT = %r\n,
@@ -10338,7 +10338,7 @@
{
#define DEF_BUILTIN(NAME, N_ARGS, ID, TYPE, ICODE) \
-{ ICODE, NAME, N_ARGS, NULL_TREE },
+{ (enum insn_code) ICODE, NAME, N_ARGS, NULL_TREE },
#include builtins.def
#undef DEF_BUILTIN
};
Index: gcc/config/avr/t-avr
===
--- gcc/config/avr/t-avr(revision 190438)
+++ gcc/config/avr/t-avr(working copy)
@@ -19,20 +19,20 @@
driver-avr.o: $(srcdir)/config/avr/driver-avr.c \
$(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H)
- $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $
+ $(COMPILER) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $
avr-devices.o: $(srcdir)/config/avr/avr-devices.c \
$(srcdir)/config/avr/avr-mcus.def \
$(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H)
- $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $
+ $(COMPILER) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $
avr-c.o: $(srcdir)/config/avr/avr-c.c \
$(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) $(C_COMMON_H)
- $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $
+ $(COMPILER) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $
avr-log.o: $(srcdir)/config/avr/avr-log.c \
$(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) $(INPUT_H) dumpfile.h
- $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $
+ $(COMPILER) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $
avr.o avr-c.o: $(srcdir)/config/avr/builtins.def
@@ -45,7 +45,7 @@
gen-avr-mmcu-texi$(build_exeext): $(srcdir)/config/avr/gen-avr-mmcu-texi.c \
$(TM_H) $(AVR_MCUS) $(srcdir)/config/avr/avr-devices.c
- $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $ -o $@
+ $(COMPILER) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $ -o $@
# Make sure that the -mmcu= documentation is in sync with the compiler.
$(srcdir)/doc/avr-mmcu.texi: s-avr-mmcu-texi; @true
Commit: BFIN: Fix use of VEC_last macro in bfin.c
Hi Bernd, Hi Jie,
I am applying the patch below as an obvious fix for this problem
whilst compiling the BFIN port of GCC:
gcc/config/bfin/bfin.c: In function 'bool hwloop_optimize(hwloop_info)':
gcc/config/bfin/bfin.c:3481:41: error: request for member 'flags' in
'VEC_last_1edge_def*(loop-hwloop_info_d::incoming, ((const
char*)/work/sources/gcc/current/gcc/config/bfin/bfin.c), 3481u, ((const
char*)( __FUNCTION__)))', which is of pointer type 'edge_def*' (maybe you
meant to use '-' ?)
gcc/config/bfin/bfin.c:3750:41: error: request for member 'flags' in
'VEC_last_1edge_def*(loop-hwloop_info_d::incoming, ((const
char*)/work/sources/gcc/current/gcc/config/bfin/bfin.c), 3750u, ((const
char*)( __FUNCTION__)))', which is of pointer type 'edge_def*' (maybe you
meant to use '-' ?)
With this patch applied the bfin port now compiles correctly.
Cheers
Nick
gcc/ChangeLog
2012-08-16 Nick Clifton ni...@redhat.com
* config/bfin/bfin.c (hwloop_optimize): Fix use of VEC_last macro.
Index: gcc/config/bfin/bfin.c
===
--- gcc/config/bfin/bfin.c (revision 190438)
+++ gcc/config/bfin/bfin.c (working copy)
@@ -3478,7 +3478,7 @@
/* If we have to insert the LSETUP before a jump, count that jump in the
length. */
if (VEC_length (edge, loop-incoming) 1
- || !(VEC_last (edge, loop-incoming).flags EDGE_FALLTHRU))
+ || !(VEC_last (edge, loop-incoming)-flags EDGE_FALLTHRU))
{
gcc_assert (JUMP_P (insn));
insn = PREV_INSN (insn);
@@ -3747,7 +3747,7 @@
{
rtx prev = BB_END (loop-incoming_src);
if (VEC_length (edge, loop-incoming) 1
- || !(VEC_last (edge, loop-incoming).flags EDGE_FALLTHRU))
+ || !(VEC_last (edge, loop-incoming)-flags EDGE_FALLTHRU))
{
gcc_assert (JUMP_P (prev));
prev = PREV_INSN (prev);
Re: [patch] speed up ifcvt:cond_move_convert_if_block
On Thu, Aug 16, 2012 at 1:11 AM, Steven Bosscher stevenb@gmail.com wrote: On Mon, Aug 6, 2012 at 1:27 PM, Paolo Bonzini bonz...@gnu.org wrote: 2. sparseset has the same problem of memory clearing (for valgrind, see sparseset_alloc). ... only the sparse array needs this clearing, but currently we do it for both. And according to the fat comment before the xcalloc, it's not even really needed. Why can't we just tell valgrind to treat the memory as defined, like in this patchlet: Indeed ... I suppose ok if it bootstraps / tests w/o valgrind checking and if a cc1 builds with valgrind checking. Thanks, Richard. Index: sparseset.c === --- sparseset.c (revision 190418) +++ sparseset.c (working copy) @@ -30,12 +30,14 @@ sparseset_alloc (SPARSESET_ELT_TYPE n_elms) unsigned int n_bytes = sizeof (struct sparseset_def) + ((n_elms - 1) * 2 * sizeof (SPARSESET_ELT_TYPE)); - /* We use xcalloc rather than xmalloc to silence some valgrind uninitialized + sparseset set = XNEWVAR(sparseset, n_bytes); + + /* Mark the sparseset as defined to silence some valgrind uninitialized read errors when accessing set-sparse[n] when n is not, and never has been, in the set. These uninitialized reads are expected, by design and - harmless. If this turns into a performance problem due to some future - additional users of sparseset, we can revisit this decision. */ - sparseset set = (sparseset) xcalloc (1, n_bytes); + harmless. */ + VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (set, n_bytes)); + set-dense = (set-elms[0]); set-sparse = (set-elms[n_elms]); set-size = n_elms; I have never built GCC with valgrind checking, so I don't know if this is correct. But there has to be a better solution than calling xcalloc... Ciao! Steven
Re: PATCH: Replace target MEMBER_TYPE_FORCES_BLK macro with a target hook
On Thu, Aug 16, 2012 at 1:50 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
This patch replaces MEMBER_TYPE_FORCES_BLK with a target hook. I
also pass the type to the target hook in addition to field, which will
be used by i386 backend for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
This patch doesn't change code generation. Tested on Linux/x86-64. I
also tested cross compilers to ia64-hpux, powerpc-linux and xtensa-linux
up to cc1. OK to install?
Isn't the type just always DECL_FIELD_CONTEXT (field)?
Btw, with C++ you no longer need ATTRIBUTE_UNUSED, just give the
parameter no name.
Richard.
Thanks.
H.J.
---
2012-08-15 H.J. Lu hongjiu...@intel.com
* stor-layout.c (compute_record_mode): Replace
MEMBER_TYPE_FORCES_BLK with targetm.member_type_forces_blk.
(layout_type): Likewise.
* system.h: Poison MEMBER_TYPE_FORCES_BLK.
* target.def (member_type_forces_blk): New target hook.
* targhooks.c (default_member_type_forces_blk): New.
* targhooks.h (default_member_type_forces_blk): Likewise.
* doc/tm.texi.in (MEMBER_TYPE_FORCES_BLK): Renamed to ...
(TARGET_MEMBER_TYPE_FORCES_BLK): This.
* doc/tm.texi: Regenerated.
* config/ia64/hpux.h (MEMBER_TYPE_FORCES_BLK): Removed.
* config/ia64/ia64.c (ia64_member_type_forces_blk): New
function.
(TARGET_MEMBER_TYPE_FORCES_BLK): New macro.
* config/rs6000/rs6000.c (TARGET_MEMBER_TYPE_FORCES_BLK): New
macro.
(rs6000_member_type_forces_blk): New function.
* config/rs6000/rs6000.h (MEMBER_TYPE_FORCES_BLK): Removed.
* config/xtensa/xtensa.c (xtensa_member_type_forces_blk): New
function.
(TARGET_MEMBER_TYPE_FORCES_BLK): New macro.
* config/xtensa/xtensa.h (MEMBER_TYPE_FORCES_BLK): Removed.
diff --git a/gcc/config/ia64/hpux.h b/gcc/config/ia64/hpux.h
index ad106b4..d9ae109 100644
--- a/gcc/config/ia64/hpux.h
+++ b/gcc/config/ia64/hpux.h
@@ -115,9 +115,6 @@ do {
\
#define TARGET_DEFAULT \
(MASK_DWARF2_ASM | MASK_BIG_ENDIAN | MASK_ILP32)
-/* ??? Might not be needed anymore. */
-#define MEMBER_TYPE_FORCES_BLK(FIELD, MODE) ((MODE) == TFmode)
-
/* ASM_OUTPUT_EXTERNAL_LIBCALL defaults to just a globalize_label call,
but that doesn't put out the @function type information which causes
shared library problems. */
diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index c7fb559..f3585b1 100644
--- a/gcc/config/ia64/ia64.c
+++ b/gcc/config/ia64/ia64.c
@@ -319,6 +319,8 @@ static const char *ia64_invalid_binary_op (int,
const_tree, const_tree);
static enum machine_mode ia64_c_mode_for_suffix (char);
static void ia64_trampoline_init (rtx, tree, rtx);
static void ia64_override_options_after_change (void);
+static bool ia64_member_type_forces_blk (const_tree, const_tree,
+enum machine_mode);
static tree ia64_builtin_decl (unsigned, bool);
@@ -570,6 +572,9 @@ static const struct attribute_spec ia64_attribute_table[]
=
#undef TARGET_GET_RAW_ARG_MODE
#define TARGET_GET_RAW_ARG_MODE ia64_get_reg_raw_mode
+#undef TARGET_MEMBER_TYPE_FORCES_BLK
+#define TARGET_MEMBER_TYPE_FORCES_BLK ia64_member_type_forces_blk
+
#undef TARGET_GIMPLIFY_VA_ARG_EXPR
#define TARGET_GIMPLIFY_VA_ARG_EXPR ia64_gimplify_va_arg
@@ -11153,6 +11158,17 @@ ia64_get_reg_raw_mode (int regno)
return default_get_reg_raw_mode(regno);
}
+/* Implement TARGET_MEMBER_TYPE_FORCES_BLK. ??? Might not be needed
+ anymore. */
+
+bool
+ia64_member_type_forces_blk (const_tree type ATTRIBUTE_UNUSED,
+const_tree field ATTRIBUTE_UNUSED,
+enum machine_mode mode)
+{
+ return TARGET_HPUX mode == TFmode;
+}
+
/* Always default to .text section until HP-UX linker is fixed. */
ATTRIBUTE_UNUSED static section *
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 34948fb..5b2d9f0 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1302,6 +1302,9 @@ static const struct attribute_spec
rs6000_attribute_table[] =
#undef TARGET_INIT_DWARF_REG_SIZES_EXTRA
#define TARGET_INIT_DWARF_REG_SIZES_EXTRA rs6000_init_dwarf_reg_sizes_extra
+#undef TARGET_MEMBER_TYPE_FORCES_BLK
+#define TARGET_MEMBER_TYPE_FORCES_BLK rs6000_member_type_forces_blk
+
/* On rs6000, function arguments are promoted, as are function return
values. */
#undef TARGET_PROMOTE_FUNCTION_MODE
@@ -7287,6 +7290,27 @@ rs6000_emit_move (rtx dest, rtx source, enum
machine_mode mode)
emit_set:
emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
}
+
+/* Return true if TYPE containing FIELD should be accessed using
+ `BLKMODE'.
+
+ For the SPE, simd types are V2SI, and gcc can be tempted to put the
+ entire thing in a DI
Commit: Fix i386 ASM_OUTPUT_ASCII macro for C++ compilation.
Hi Richard, Hi Jan, Hi Uros,
I am applying the patch below as an obvious fix for this problem when
building an i386-elf targeted toolchain:
gcc/dwarf2asm.c: In function 'void dw2_asm_output_nstring(const char*,
size_t, const char*, ...)':
gcc/dwarf2asm.c:334:7: error: invalid conversion from 'const unsigned
char*' to 'const char*' [-fpermissive]
With the patch applied the compiler now builds correctly.
Cheers
Nick
gcc/ChangeLog
2012-08-16 Nick Clifton ni...@redhat.com
* config/i386/i386elf.h (ASM_OUTPUT_ASCII): Cast _ascii_bytes
before passing it to ASM_OUTPUT_LIMITED_STRING.
Index: gcc/config/i386/i386elf.h
===
--- gcc/config/i386/i386elf.h (revision 190438)
+++ gcc/config/i386/i386elf.h (working copy)
@@ -73,7 +73,7 @@
fputc ('\n', (FILE)); \
bytes_in_chunk = 0; \
} \
- ASM_OUTPUT_LIMITED_STRING ((FILE), _ascii_bytes); \
+ ASM_OUTPUT_LIMITED_STRING ((FILE), (const char *) _ascii_bytes); \
_ascii_bytes = p; \
} \
else \
RE: [PATCH,i386] fma,fma4 and xop flags
This won't work, since we have to prefer FMA3 also in case when only -mfma -mfma4 without -mtune=XX is used. We can add TARGET_FMA_BOTH though, but I doubt there will ever be target that implements both insn sets without preferences. Preferring FMA3 over FMA4 might not do good always. For instance, with increased register pressure FMA3 can be used. But, when we have more registers at our disposal, fma4 if used might do good by avoiding extra reload. IMO, when preference of FMA instructions is adjudged by register pressure, we may need some functionality to support that. So, ideally for bdver2, we like to have both fma and fma4 getting generated with options -mfma -mfma4. Regards Ganesh -Original Message- From: Uros Bizjak [mailto:ubiz...@gmail.com] Sent: Tuesday, August 14, 2012 9:12 PM To: Richard Henderson Cc: Gopalasubramanian, Ganesh; gcc-patches@gcc.gnu.org Subject: Re: [PATCH,i386] fma,fma4 and xop flags On Mon, Aug 13, 2012 at 9:50 PM, Richard Henderson r...@redhat.com wrote: On 08/13/2012 12:33 PM, Uros Bizjak wrote: AFAIU fma3 is better than fma4 for bdver2 (the only CPU that implements both FMA sets). Current description of bdver2 doesn't even enable fma4 in processor_alias_table due to this fact. The change you are referring to adds preference for fma3 insn set for generic code (not FMA4 builtins!), even when fma4 is enabled. So, no matter which combination and sequence of -mfmfa -mfma4 or -mxop user passes to the compiler, only fma3 instructions will be generated. This rationale needs to appear as a comment above + (eq_attr isa fma4) +(symbol_ref TARGET_FMA4 !TARGET_FMA) I plan to commit following patch: --cut here-- Index: i386.md === --- i386.md (revision 190362) +++ i386.md (working copy) @@ -659,6 +659,9 @@ (eq_attr isa noavx2) (symbol_ref !TARGET_AVX2) (eq_attr isa bmi2) (symbol_ref TARGET_BMI2) (eq_attr isa fma) (symbol_ref TARGET_FMA) +;; Disable generation of FMA4 instructions for generic code +;; since FMA3 is preferred for targets that implement both +;; instruction sets. (eq_attr isa fma4) (symbol_ref TARGET_FMA4 !TARGET_FMA) ] --cut here-- Longer term we may well require some sort of (TARGET_FMA4 !(TARGET_FMA TARGET_PREFER_FMA3)) with an appropriate entry in ix86_tune_features to match. This won't work, since we have to prefer FMA3 also in case when only -mfma -mfma4 without -mtune=XX is used. We can add TARGET_FMA_BOTH though, but I doubt there will ever be target that implements both insn sets without preferences. Uros.
[bootstrap] Tentative fix for PR 54281
Richi, this implements your idea for fixing PR 54281. I don't
have an old enough compiler. Could you please test it in your
system?
I debated whether to remove the GENERATOR_FILE predicate from the
inclusion (some files include gmp.h unconditionally). I think it
could be removed, but only a minority of files build with
GENERATOR_FILE set, so it didn't seem harmful.
OK if tests pass?
Diego.
2012-08-16 Diego Novillo dnovi...@google.com
Richard Guenther rguent...@suse.de
PR bootstrap/54281
* double-int.h: Move including of gmp.h ...
* system.h: ... here.
* realmpfr.h: Do not include gmp.h.
* tree-ssa-loop-niter.c: Do not include gmp.h.
fortran/ChangeLog
* gfortran.h: Do not include gmp.h.
diff --git a/gcc/double-int.h b/gcc/double-int.h
index 3d9aa2c..7ea0528 100644
--- a/gcc/double-int.h
+++ b/gcc/double-int.h
@@ -20,10 +20,6 @@ along with GCC; see the file COPYING3. If not see
#ifndef DOUBLE_INT_H
#define DOUBLE_INT_H
-#ifndef GENERATOR_FILE
-#include gmp.h
-#endif
-
/* A large integer is currently represented as a pair of HOST_WIDE_INTs.
It therefore represents a number with precision of
2 * HOST_BITS_PER_WIDE_INT bits (it is however possible that the
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 7c4c0a4..611d16d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1681,7 +1681,6 @@ gfc_intrinsic_sym;
EXPR_COMPCALL Function (or subroutine) call of a procedure pointer
component or type-bound procedure. */
-#include gmp.h
#include mpfr.h
#include mpc.h
#define GFC_RND_MODE GMP_RNDN
diff --git a/gcc/realmpfr.h b/gcc/realmpfr.h
index ab234e9..ada876e 100644
--- a/gcc/realmpfr.h
+++ b/gcc/realmpfr.h
@@ -22,7 +22,10 @@
#ifndef GCC_REALGMP_H
#define GCC_REALGMP_H
-#include gmp.h
+/* Note that we do not include gmp.h. It is included in system.h
+ because it wrecks intl.h when compiling in C++ mode.
+ See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 for details. */
+
#include mpfr.h
#include mpc.h
#include real.h
diff --git a/gcc/system.h b/gcc/system.h
index 9e7d503..0ccd991 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1037,4 +1037,8 @@ helper_const_non_const_cast (const char *p)
#define DEBUG_VARIABLE
#endif
+#ifndef GENERATOR_FILE
+#include gmp.h
+#endif
+
#endif /* ! GCC_SYSTEM_H */
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index c719a74..4c67c26 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -38,7 +38,6 @@ along with GCC; see the file COPYING3. If not see
#include flags.h
#include diagnostic-core.h
#include tree-inline.h
-#include gmp.h
#define SWAP(X, Y) do { affine_iv *tmp = (X); (X) = (Y); (Y) = tmp; } while (0)
Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c
On 12-08-16 05:49 , Nick Clifton wrote: gcc/ChangeLog 2012-08-16 Nick Clifton ni...@redhat.com * config/bfin/bfin.c (hwloop_optimize): Fix use of VEC_last macro. Thanks Nick. I made the wrong fix here, sorry about that. I will be making more changes to VEC_ shortly. What's a good way for me to test them? Diego.
Re: [PATCH,i386] fma,fma4 and xop flags
On Thu, Aug 16, 2012 at 1:43 PM, Gopalasubramanian, Ganesh ganesh.gopalasubraman...@amd.com wrote: This won't work, since we have to prefer FMA3 also in case when only -mfma -mfma4 without -mtune=XX is used. We can add TARGET_FMA_BOTH though, but I doubt there will ever be target that implements both insn sets without preferences. Preferring FMA3 over FMA4 might not do good always. For instance, with increased register pressure FMA3 can be used. But, when we have more registers at our disposal, fma4 if used might do good by avoiding extra reload. IMO, when preference of FMA instructions is adjudged by register pressure, we may need some functionality to support that. So, ideally for bdver2, we like to have both fma and fma4 getting generated with options -mfma -mfma4. Yes, now it can also work that way. Current insn generation can be trivially changed now, just change fma4 condition for enabled attribute in i386.md. I will wait for your recommendation. Uros.
Re: [PATCH] Set current_function_decl in {push,pop}_cfun and push_struct_function
Hi, On Thu, 16 Aug 2012, Richard Guenther wrote: If dumping a statement needs the containing function then we need to either pass that down, provide a way to get from statement to function, or stop requiring the function. Making the hash global is choice three (deallocating the hash would be when compilation is finished, in which case you can double-check that it is empty and preserve above checking). Option one is ok as well, option two is probably either unreliable (going from gimple_block to function from function scope - but maybe who cares for dumping?) or expensive (add a pointer from basic_block to struct function). I'm fine with both option three (would even save a pointer in struct function!) or one. Other opinions? Actually I must say, that none of the above three options appeal to me very much, and that the current solution (passing cfun via a global variable) is better than any of these: 1) passing it down in arguments: uglifies interface for a very special situation. 3) making the hash global is a layering violation in its own, and for instance would complicate a scheme where the memory for instructions (and their histograms) comes from per-function pools. 2) that's actually the most appealing one from a user interface, i.e. if there's a generic way of mapping gimple - FUNCTION_DECL. Certainly not at the cost of an additional pointer in each bb, but there are other schemes that we could use, for instance: Every function has an ENTRY and EXIT block. That one for certain is reachable via going bb-prev_bb until you hit the end. The entry block doesn't contain much interesting things, so we for instance can reuse, I don't know, the loop_father pointer to actually point to the function_decl containing it. Looking up the function from a bb would hence be a fairly expensive operation (walking the block chain), so it requires some care to use it, but I think that's okay. Ciao, Michael.
Re: [patch] PR54146 - rewrite rewrite_into_loop_closed_ssa
Hi,
On Wed, 15 Aug 2012, Steven Bosscher wrote:
Please convince me that this :
+/* Return the outermost superloop LOOP of USE_LOOP that is a superloop of
+ both DEF_LOOP and USE_LOOP. */
+static inline struct loop *
+find_sibling_superloop (struct loop *use_loop, struct loop *def_loop)
+{
+ unsigned ud = loop_depth (use_loop);
+ unsigned dd = loop_depth (def_loop);
+ gcc_assert (ud 0 dd 0);
+ if (ud dd)
+use_loop = superloop_at_depth (use_loop, dd);
+ if (ud dd)
+def_loop = superloop_at_depth (def_loop, ud);
+ while (loop_outer (use_loop) != loop_outer (def_loop))
+{
+ use_loop = loop_outer (use_loop);
+ def_loop = loop_outer (def_loop);
+ gcc_assert (use_loop def_loop);
+}
+ return use_loop;
doesn't have the usual problem of advancing two iterators at the same time
and expecting they'll eventually meet (which they generally don't have
to).
Also the block comment indicates that could should just as well return the
outermost loop of the function, because it's the outermost superloop LOOP
of USE_LOOP that is a superloop of both DEF_LOOP and USE_LOOP.
The implementation seems to want to return the _innermost_ superloop that
still covers both DEF_LOOP and USE_LOOP, and in that case my concern about
them never meeting stands.
Ciao,
Michael.
[PATCH] Fix memleaks obvious from PR54146
This fixes some memleaks which look obvious when looking at
-fmem-report of PR54146. Most important the tree-ssa-loop-im.c leak.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.
Richard.
2012-08-16 Richard Guenther rguent...@suse.de
PR middle-end/54146
* tree-ssa-loop-niter.c (find_loop_niter_by_eval): Free the
exit vector.
* ipa-pure-const.c (analyze_function): Use FOR_EACH_LOOP_BREAK.
* cfgloop.h (FOR_EACH_LOOP_BREAK): Fix.
* tree-ssa-structalias.c (handle_lhs_call): Properly free rhsc.
* tree-into-ssa.c (get_ssa_name_ann): Allocate info only when
needed.
* tree-ssa-loop-im.c (analyze_memory_references): Adjust.
(tree_ssa_lim_finalize): Free all mem_refs.
* tree-ssa-sccvn.c (extract_and_process_scc_for_name): Free
scc when bailing out.
* modulo-sched.c (sms_schedule): Use FOR_EACH_LOOP_BREAK.
* ira-build.c (loop_with_complex_edge_p): Free loop exit vector.
* graphite-sese-to-poly.c (scop_ivs_can_be_represented): Use
FOR_EACH_LOOP_BREAK.
Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c (revision 190442)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -2287,7 +2287,10 @@ find_loop_niter_by_eval (struct loop *lo
/* Loops with multiple exits are expensive to handle and less important. */
if (!flag_expensive_optimizations
VEC_length (edge, exits) 1)
-return chrec_dont_know;
+{
+ VEC_free (edge, heap, exits);
+ return chrec_dont_know;
+}
FOR_EACH_VEC_ELT (edge, exits, i, ex)
{
Index: gcc/ipa-pure-const.c
===
--- gcc/ipa-pure-const.c(revision 190442)
+++ gcc/ipa-pure-const.c(working copy)
@@ -802,7 +802,7 @@ end:
if (dump_file)
fprintf (dump_file, can not prove finiteness of loop
%i\n, loop-num);
l-looping =true;
- break;
+ FOR_EACH_LOOP_BREAK (li);
}
scev_finalize ();
}
Index: gcc/cfgloop.h
===
--- gcc/cfgloop.h (revision 190442)
+++ gcc/cfgloop.h (working copy)
@@ -649,7 +649,7 @@ fel_init (loop_iterator *li, loop_p *loo
#define FOR_EACH_LOOP_BREAK(LI) \
{ \
-VEC_free (int, heap, (LI)-to_visit); \
+VEC_free (int, heap, (LI).to_visit); \
break; \
}
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 190442)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -3868,9 +3868,11 @@ handle_lhs_call (gimple stmt, tree lhs,
tmpc.offset = 0;
tmpc.type = ADDRESSOF;
VEC_safe_push (ce_s, heap, rhsc, tmpc);
+ process_all_all_constraints (lhsc, rhsc);
+ VEC_free (ce_s, heap, rhsc);
}
-
- process_all_all_constraints (lhsc, rhsc);
+ else
+process_all_all_constraints (lhsc, rhsc);
VEC_free (ce_s, heap, lhsc);
}
Index: gcc/tree-into-ssa.c
===
--- gcc/tree-into-ssa.c (revision 190442)
+++ gcc/tree-into-ssa.c (working copy)
@@ -312,22 +312,21 @@ get_ssa_name_ann (tree name)
unsigned len = VEC_length (ssa_name_info_p, info_for_ssa_name);
struct ssa_name_info *info;
+ /* Re-allocate the vector at most once per update/into-SSA. */
if (ver = len)
-{
- unsigned old_len = VEC_length (ssa_name_info_p, info_for_ssa_name);
- unsigned new_len = num_ssa_names;
+VEC_safe_grow_cleared (ssa_name_info_p, heap,
+ info_for_ssa_name, num_ssa_names);
- VEC_reserve (ssa_name_info_p, heap, info_for_ssa_name,
- new_len - old_len);
- while (len++ new_len)
- {
- struct ssa_name_info *info = XCNEW (struct ssa_name_info);
- info-age = current_info_for_ssa_name_age;
- VEC_quick_push (ssa_name_info_p, info_for_ssa_name, info);
- }
+ /* But allocate infos lazily. */
+ info = VEC_index (ssa_name_info_p, info_for_ssa_name, ver);
+ if (!info)
+{
+ info = XCNEW (struct ssa_name_info);
+ info-age = current_info_for_ssa_name_age;
+ info-info.need_phi_state = NEED_PHI_STATE_UNKNOWN;
+ VEC_replace (ssa_name_info_p, info_for_ssa_name, ver, info);
}
- info = VEC_index (ssa_name_info_p, info_for_ssa_name, ver);
if (info-age current_info_for_ssa_name_age)
{
info-age = current_info_for_ssa_name_age;
Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c (revision 190442)
+++ gcc/tree-ssa-loop-im.c (working copy)
@@ -1486,9 +1486,8 @@ free_mem_ref_locs (mem_ref_locs_p accs)
/* A function to free the mem_ref object OBJ. */
Re: [PATCH] Set current_function_decl in {push,pop}_cfun and push_struct_function
On Thu, Aug 16, 2012 at 8:40 AM, Michael Matz m...@suse.de wrote: Hi, On Thu, 16 Aug 2012, Richard Guenther wrote: If dumping a statement needs the containing function then we need to either pass that down, provide a way to get from statement to function, or stop requiring the function. Making the hash global is choice three (deallocating the hash would be when compilation is finished, in which case you can double-check that it is empty and preserve above checking). Option one is ok as well, option two is probably either unreliable (going from gimple_block to function from function scope - but maybe who cares for dumping?) or expensive (add a pointer from basic_block to struct function). I'm fine with both option three (would even save a pointer in struct function!) or one. Other opinions? Actually I must say, that none of the above three options appeal to me very much, and that the current solution (passing cfun via a global variable) is better than any of these: 1) passing it down in arguments: uglifies interface for a very special situation. 3) making the hash global is a layering violation in its own, and for instance would complicate a scheme where the memory for instructions (and their histograms) comes from per-function pools. 2) that's actually the most appealing one from a user interface, i.e. if there's a generic way of mapping gimple - FUNCTION_DECL. Certainly not at the cost of an additional pointer in each bb, but there are other schemes that we could use, for instance: Every function has an ENTRY and EXIT block. That one for certain is reachable via going bb-prev_bb until you hit the end. The entry block doesn't contain much interesting things, so we for instance can reuse, I don't know, the loop_father pointer to actually point to the function_decl containing it. Looking up the function from a bb would hence be a fairly expensive operation (walking the block chain), so it requires some care to use it, but I think that's okay. I like this approach, particularly since it would be used in contexts where there is no simpler scheme. I'm not crazy about overloading unused fields, but it's fine if we wrap it around a special accessor. I suppose we could also make ENTRY/EXIT be a base class for basic_block and use a real field (but that can wait). There are other pieces of data that are global but context-dependent. I wonder if it wouldn't make sense to encapsulate them in some class that is controlled by the pass manager and gets updated as it moves from function to function (it would contain things like cfun, current_function_decl, etc). Diego.
Re: [bootstrap] Tentative fix for PR 54281
On 12-08-16 09:08 , Richard Guenther wrote: It fixes it. Thus, ok from my side (if your testing succeeds). Worked here too. Committed to trunk. Diego.
[4.6] Add /lib to Solaris default library search path
On recent Solaris 11 Update 1 builds, the 4.6 branch failed to bootstrap
in libjava: the configure test for connect failed since libsocket.so
indirectly depends on libcryptoutil.so which only lives in /lib, not
/usr/lib:
configure:20311: checking for connect in -lsocket
configure:20339: /var/gcc/regression/gcc-4.6-branch/11-gcc/build/./gcc/xgcc
-B/var/gcc/regression/gcc-4.6-branch/11-gcc/build/./gcc/
-B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/
-isystem /vol/gcc/i386-pc-solaris2.11/include -isystem
/vol/gcc/i386-pc-solaris2.11/sys-include-o conftest -g -O2 conftest.c
-lsocket 5
ld: warning: file libcryptoutil.so.1: required by /usr/lib/libmd.so.1, not found
Undefined first referenced
symbol in file
get_fips_mode /usr/lib/libmd.so.1
ld: fatal: symbol referencing errors. No output written to conftest
The Solaris 2 gcc configuration overrides the Sun linker default (which
includes /lib, of course) with -Y P, so we need to explicitly add it
ourselves. The following patch does exactly that.
Bootstrapped without regressions on i386-pc-solaris2.1[01] and
sparc-sun-solaris2.1[01], installed on 4.6 branch.
The 4.7 branch and mainline are not affected since /lib has been added
there during the complete rework of the Solaris configurations.
Rainer
2012-08-06 Rainer Orth r...@cebitec.uni-bielefeld.de
* config/sol2.h (LINK_ARCH32_SPEC_BASE): Add /lib to default
linker search path.
* config/sparc/sol2-bi.h (LINK_ARCH64_SPEC_BASE): Likewise for
/lib/sparcv9.
# HG changeset patch
# Parent 7415e4cf7479d1f8e0a66d3db9bd03d3b17964cf
Add /lib to Solaris default library search path
diff --git a/gcc/config/sol2.h b/gcc/config/sol2.h
--- a/gcc/config/sol2.h
+++ b/gcc/config/sol2.h
@@ -1,6 +1,6 @@
/* Operating system specific defines to be used when targeting GCC for any
Solaris 2 system.
- Copyright 2002, 2003, 2004, 2007, 2008, 2009, 2010, 2011
+ Copyright 2002, 2003, 2004, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -163,12 +163,12 @@ along with GCC; see the file COPYING3.
%{YP,*} \
%{R*} \
%{compat-bsd: \
- %{!YP,*:%{p|pg:-Y P,%R/usr/ucblib:%R/usr/ccs/lib/libp:%R/usr/lib/libp:%R/usr/ccs/lib:%R/usr/lib} \
- %{!p:%{!pg:-Y P,%R/usr/ucblib:%R/usr/ccs/lib:%R/usr/lib}}} \
+ %{!YP,*:%{p|pg:-Y P,%R/usr/ucblib:%R/usr/ccs/lib/libp:%R/usr/lib/libp:%R/usr/ccs/lib:%R/usr/lib:%R/lib} \
+ %{!p:%{!pg:-Y P,%R/usr/ucblib:%R/usr/ccs/lib:%R/usr/lib:%R/lib}}} \
-R %R/usr/ucblib} \
%{!compat-bsd: \
- %{!YP,*:%{p|pg:-Y P,%R/usr/ccs/lib/libp:%R/usr/lib/libp:%R/usr/ccs/lib:%R/usr/lib} \
- %{!p:%{!pg:-Y P,%R/usr/ccs/lib:%R/usr/lib
+ %{!YP,*:%{p|pg:-Y P,%R/usr/ccs/lib/libp:%R/usr/lib/libp:%R/usr/ccs/lib:%R/usr/lib:%R/lib} \
+ %{!p:%{!pg:-Y P,%R/usr/ccs/lib:%R/usr/lib:%R/lib
#undef LINK_ARCH32_SPEC
#define LINK_ARCH32_SPEC LINK_ARCH32_SPEC_BASE
diff --git a/gcc/config/sparc/sol2-bi.h b/gcc/config/sparc/sol2-bi.h
--- a/gcc/config/sparc/sol2-bi.h
+++ b/gcc/config/sparc/sol2-bi.h
@@ -1,6 +1,6 @@
/* Definitions of target machine for GCC, for bi-arch SPARC
running Solaris 2 using the system assembler and linker.
- Copyright (C) 2002, 2003, 2004, 2006, 2007, 2009, 2010, 2011
+ Copyright (C) 2002, 2003, 2004, 2006, 2007, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -191,12 +191,12 @@ see the files COPYING3 and COPYING.RUNTI
%{YP,*} \
%{R*} \
%{compat-bsd: \
- %{!YP,*:%{p|pg:-Y P,%R/usr/ucblib/sparcv9:%R/usr/lib/libp/sparcv9:%R/usr/lib/sparcv9} \
- %{!p:%{!pg:-Y P,%R/usr/ucblib/sparcv9:%R/usr/lib/sparcv9}}} \
+ %{!YP,*:%{p|pg:-Y P,%R/usr/ucblib/sparcv9:%R/usr/lib/libp/sparcv9:%R/usr/lib/sparcv9:%R/lib/sparcv9} \
+ %{!p:%{!pg:-Y P,%R/usr/ucblib/sparcv9:%R/usr/lib/sparcv9:%R/lib/sparcv9}}} \
-R %R/usr/ucblib/sparcv9} \
%{!compat-bsd: \
- %{!YP,*:%{p|pg:-Y P,%R/usr/lib/libp/sparcv9:%R/usr/lib/sparcv9} \
- %{!p:%{!pg:-Y P,%R/usr/lib/sparcv9
+ %{!YP,*:%{p|pg:-Y P,%R/usr/lib/libp/sparcv9:%R/usr/lib/sparcv9:%R/lib/sparcv9} \
+ %{!p:%{!pg:-Y P,%R/usr/lib/sparcv9:%R/lib/sparcv9
#define LINK_ARCH64_SPEC LINK_ARCH64_SPEC_BASE
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH 6/7] rs6000: Remove -mabi=ieeelongdouble.
On Wed, Aug 15, 2012 at 6:29 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: There are some problems with it: - On at least 4.6 and later, it crashes the compiler together with -m64; - On older versions, it generates incorrect code together with -m64; - Supposedly it doesn't actually work on 32-bit either, on the glibc side; - It isn't listed in --target-help, because the option file says undocumented, but the manual does in fact list it; - The Darwin header claims it is for POWER. In the spirit of the rest of this patch series, I solve these problems by ripping it all out. Segher, As we discussed on IRC, this should work but is broken. It should not be ripped out. Would you please open a Bugzilla PR and include me, Meissner and Peter Bergner on the CC list? Thanks, David
[PATCH] Decrease integer-share-limit
This decreases the integer-share-limit to make sure the TREE_VEC we
allocate for the small cached integers has a reasonable size for
our GC memory allocator. With the current value (256) and a reduced
testcase from PR54146 we see
tree.c:1224 (build_int_cst_wide) 40: 0.0%
0: 0.0% 35443680: 8.7% 11635920:39.0% 9305
thus 39% overhead (oops, that TREE_VEC has size 2080). Reducing
this to 251 yields
tree.c:1224 (build_int_cst_wide) 40: 0.0%
0: 0.0% 11698864: 3.0% 33696: 0.2% 9154
which is much nicer (size 2048 for signed ints, 1020 bytes on
32bit hosts if I counted correctly).
I'm queueing this for a bootstrap regtest run.
Richard.
2012-08-16 Richard Guenther rguent...@suse.de
* params.def (integer-share-limit): Decrease from 256 to 251,
add rationale.
Index: gcc/params.def
===
*** gcc/params.def (revision 190442)
--- gcc/params.def (working copy)
*** DEFPARAM(PARAM_MAX_LAST_VALUE_RTL,
*** 638,648
/* INTEGER_CST nodes are shared for values [{-1,0} .. N) for
{signed,unsigned} integral types. This determines N.
!Experimentation shows 256 to be a good value. */
DEFPARAM (PARAM_INTEGER_SHARE_LIMIT,
integer-share-limit,
The upper bound for sharing integer constants,
! 256, 2, 2)
DEFPARAM (PARAM_SSP_BUFFER_SIZE,
ssp-buffer-size,
--- 638,649
/* INTEGER_CST nodes are shared for values [{-1,0} .. N) for
{signed,unsigned} integral types. This determines N.
!Experimentation shows 251 to be a good value that generates the
!least amount of garbage for allocating the TREE_VEC storage. */
DEFPARAM (PARAM_INTEGER_SHARE_LIMIT,
integer-share-limit,
The upper bound for sharing integer constants,
! 251, 2, 2)
DEFPARAM (PARAM_SSP_BUFFER_SIZE,
ssp-buffer-size,
Re: [bootstrap] Tentative fix for PR 54281
On 12-08-16 09:08 , Richard Guenther wrote:
On Thu, 16 Aug 2012, Diego Novillo wrote:
Richi, this implements your idea for fixing PR 54281. I don't
have an old enough compiler. Could you please test it in your
system?
I debated whether to remove the GENERATOR_FILE predicate from the
inclusion (some files include gmp.h unconditionally). I think it
could be removed, but only a minority of files build with
GENERATOR_FILE set, so it didn't seem harmful.
OK if tests pass?
It fixes it.
Thus, ok from my side (if your testing succeeds).
So, I had failed to include Ada in my testing and my patch breaks it.
In several ada/*.c files, we forcefully include system.h as a C header:
#ifdef __cplusplus
extern C {
#endif
...
#include system.h
...
#ifdef __cplusplus
}
#endif
Eric, is this really needed now? We are including gmp.h from system.h
due to PR 54281. This is causing Ada builds to fail.
Would it be OK to remove all the '#ifdef __cplusplus' conditionals from
ada/*.c or is there something I'm missing?
Thanks. Diego.
[PATCH] Free redirect_callers vector in tree-sra.c
I noticed we leak the redirect_callers vector in SRA and also noticed
we compute it and then immediately re-compute cgraph edges which
looks weird to me.
Thus the following patch which frees the vector and makes its lifetime
more obvious.
Queued for testing.
Richard.
2012-08-16 Richard Guenther rguent...@suse.de
* tree-sra.c (modify_function): Collect callers after rebuilding
cgraph edges. Free caller vector.
Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c (revision 190442)
+++ gcc/tree-sra.c (working copy)
@@ -4689,15 +4689,18 @@ modify_function (struct cgraph_node *nod
{
struct cgraph_node *new_node;
bool cfg_changed;
- VEC (cgraph_edge_p, heap) * redirect_callers = collect_callers_of_node
(node);
+ VEC (cgraph_edge_p, heap) * redirect_callers;
rebuild_cgraph_edges ();
free_dominance_info (CDI_DOMINATORS);
pop_cfun ();
current_function_decl = NULL_TREE;
+ redirect_callers = collect_callers_of_node (node);
new_node = cgraph_function_versioning (node, redirect_callers, NULL, NULL,
false, NULL, NULL, isra);
+ VEC_free (cgraph_edge_p, heap, redirect_callers);
+
current_function_decl = new_node-symbol.decl;
push_cfun (DECL_STRUCT_FUNCTION (new_node-symbol.decl));
Re: [PATCH] Set current_function_decl in {push,pop}_cfun and push_struct_function
Hi, On Thu, 16 Aug 2012, Diego Novillo wrote: I like this approach, particularly since it would be used in contexts where there is no simpler scheme. I'm not crazy about overloading unused fields, but it's fine if we wrap it around a special accessor. I suppose we could also make ENTRY/EXIT be a base class for basic_block and use a real field (but that can wait). Actually the other way around (ENTRY/EXIT be a subclass), as it would be an additional field to the normal basic blocks. But for central data structures I'm usually of the opinion that jumping through hoops just to not enlarge them is quite acceptable :) There are other pieces of data that are global but context-dependent. I wonder if it wouldn't make sense to encapsulate them in some class that is controlled by the pass manager and gets updated as it moves from function to function (it would contain things like cfun, current_function_decl, etc). And on that topic: I think it makes sense to eventually get rid of one or the other, current_function_decl is always (well, mostly) cfun-decl, if cfun happens to be set. I know there are some roadblocks in front of that goal, but still. Ciao, Michael.
Re: [patch] PR54146 - rewrite rewrite_into_loop_closed_ssa
Hi, On Thu, 16 Aug 2012, Steven Bosscher wrote: 2. In find_sibling_superloop the first step is to align the loop depth: ... 3. Now that USE_LOOP and DEF_LOOP are at the same nesting depth, Ah, that's the crucial point I missed, the while loops starts out with loops at the same depth; yes then the loop works. Thanks for having a walk with me :) This must meet at some point, because the outermost loop of all loops is current_loops-tree_root at depth 0, and we count down from the same loop depth. Btw, then the comment is still wrong. You're returning the innermost common outer loop, not the outermost (which would be trivial). Ciao, Michael.
Re: [patch] PR54146 - rewrite rewrite_into_loop_closed_ssa
On Thu, Aug 16, 2012 at 4:24 PM, Michael Matz m...@suse.de wrote: Btw, then the comment is still wrong. You're returning the innermost common outer loop, not the outermost (which would be trivial). I'll fix the comment. Ciao! Steven
Re: [PATCH] Set current_function_decl in {push,pop}_cfun and push_struct_function
On Thu, Aug 16, 2012 at 10:21 AM, Michael Matz m...@suse.de wrote: Hi, On Thu, 16 Aug 2012, Diego Novillo wrote: I like this approach, particularly since it would be used in contexts where there is no simpler scheme. I'm not crazy about overloading unused fields, but it's fine if we wrap it around a special accessor. I suppose we could also make ENTRY/EXIT be a base class for basic_block and use a real field (but that can wait). Actually the other way around (ENTRY/EXIT be a subclass), as it would be Yeah, sorry. an additional field to the normal basic blocks. But for central data structures I'm usually of the opinion that jumping through hoops just to not enlarge them is quite acceptable :) Yeah, adding a full word when it's only used in a few places does not seem like a good tradeoff. There are other pieces of data that are global but context-dependent. I wonder if it wouldn't make sense to encapsulate them in some class that is controlled by the pass manager and gets updated as it moves from function to function (it would contain things like cfun, current_function_decl, etc). And on that topic: I think it makes sense to eventually get rid of one or the other, current_function_decl is always (well, mostly) cfun-decl, if cfun happens to be set. I know there are some roadblocks in front of that goal, but still. Agreed. Diego.
Re: [PATCH] Decrease integer-share-limit
Hi, On 08/16/2012 03:39 PM, Richard Guenther wrote: This decreases the integer-share-limit to make sure the TREE_VEC we allocate for the small cached integers has a reasonable size for our GC memory allocator. Out of curiosity (just in case you hav two spare minutes) do you have any idea why this is so? I mean, naively one would think that allowing for any 8 bit constant would be a nice idea; puzzlingly, however the comment in the code says just experimentation. I'm wondering if tweaking a bit the memory allocator itself could allow for the full 8 bit range without a big memory waste... Paolo.
Re: PATCH: Replace target MEMBER_TYPE_FORCES_BLK macro with a target hook
On Thu, Aug 16, 2012 at 3:09 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Aug 16, 2012 at 1:50 AM, H.J. Lu hongjiu...@intel.com wrote:
Hi,
This patch replaces MEMBER_TYPE_FORCES_BLK with a target hook. I
also pass the type to the target hook in addition to field, which will
be used by i386 backend for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
This patch doesn't change code generation. Tested on Linux/x86-64. I
also tested cross compilers to ia64-hpux, powerpc-linux and xtensa-linux
up to cc1. OK to install?
Isn't the type just always DECL_FIELD_CONTEXT (field)?
Btw, with C++ you no longer need ATTRIBUTE_UNUSED, just give the
parameter no name.
You are right. Now I don't need to replace MEMBER_TYPE_FORCES_BLK
with a target hook for PR 20020. Since I already made the change, here is
the updated patch. OK to install?
If we don't want to convert MEMBER_TYPE_FORCES_BLK, I can submit a
patch to use MEMBER_TYPE_FORCES_BLK in i386 backend.
Thanks.
--
H.J.
---
2012-08-16 H.J. Lu hongjiu...@intel.com
* stor-layout.c (compute_record_mode): Replace
MEMBER_TYPE_FORCES_BLK with targetm.member_type_forces_blk.
(layout_type): Likewise.
* system.h: Poison MEMBER_TYPE_FORCES_BLK.
* target.def (member_type_forces_blk): New target hook.
* targhooks.c (default_member_type_forces_blk): New.
* targhooks.h (default_member_type_forces_blk): Likewise.
* doc/tm.texi.in (MEMBER_TYPE_FORCES_BLK): Renamed to ...
(TARGET_MEMBER_TYPE_FORCES_BLK): This.
* doc/tm.texi: Regenerated.
* config/ia64/hpux.h (MEMBER_TYPE_FORCES_BLK): Removed.
* config/ia64/ia64.c (ia64_member_type_forces_blk): New
function.
(TARGET_MEMBER_TYPE_FORCES_BLK): New macro.
* config/rs6000/rs6000.c (TARGET_MEMBER_TYPE_FORCES_BLK): New
macro.
(rs6000_member_type_forces_blk): New function.
* config/rs6000/rs6000.h (MEMBER_TYPE_FORCES_BLK): Removed.
* config/xtensa/xtensa.c (xtensa_member_type_forces_blk): New
function.
(TARGET_MEMBER_TYPE_FORCES_BLK): New macro.
* config/xtensa/xtensa.h (MEMBER_TYPE_FORCES_BLK): Removed.
diff --git a/gcc/config/ia64/hpux.h b/gcc/config/ia64/hpux.h
index ad106b4..d9ae109 100644
--- a/gcc/config/ia64/hpux.h
+++ b/gcc/config/ia64/hpux.h
@@ -115,9 +115,6 @@ do {
\
#define TARGET_DEFAULT \
(MASK_DWARF2_ASM | MASK_BIG_ENDIAN | MASK_ILP32)
-/* ??? Might not be needed anymore. */
-#define MEMBER_TYPE_FORCES_BLK(FIELD, MODE) ((MODE) == TFmode)
-
/* ASM_OUTPUT_EXTERNAL_LIBCALL defaults to just a globalize_label call,
but that doesn't put out the @function type information which causes
shared library problems. */
diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index c7fb559..f2f02c8 100644
--- a/gcc/config/ia64/ia64.c
+++ b/gcc/config/ia64/ia64.c
@@ -319,6 +319,7 @@ static const char *ia64_invalid_binary_op (int,
const_tree, const_tree);
static enum machine_mode ia64_c_mode_for_suffix (char);
static void ia64_trampoline_init (rtx, tree, rtx);
static void ia64_override_options_after_change (void);
+static bool ia64_member_type_forces_blk (const_tree, enum machine_mode);
static tree ia64_builtin_decl (unsigned, bool);
@@ -570,6 +571,9 @@ static const struct attribute_spec ia64_attribute_table[] =
#undef TARGET_GET_RAW_ARG_MODE
#define TARGET_GET_RAW_ARG_MODE ia64_get_reg_raw_mode
+#undef TARGET_MEMBER_TYPE_FORCES_BLK
+#define TARGET_MEMBER_TYPE_FORCES_BLK ia64_member_type_forces_blk
+
#undef TARGET_GIMPLIFY_VA_ARG_EXPR
#define TARGET_GIMPLIFY_VA_ARG_EXPR ia64_gimplify_va_arg
@@ -11153,6 +11157,15 @@ ia64_get_reg_raw_mode (int regno)
return default_get_reg_raw_mode(regno);
}
+/* Implement TARGET_MEMBER_TYPE_FORCES_BLK. ??? Might not be needed
+ anymore. */
+
+bool
+ia64_member_type_forces_blk (const_tree, enum machine_mode mode)
+{
+ return TARGET_HPUX mode == TFmode;
+}
+
/* Always default to .text section until HP-UX linker is fixed. */
ATTRIBUTE_UNUSED static section *
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 34948fb..57c4823 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1302,6 +1302,9 @@ static const struct attribute_spec
rs6000_attribute_table[] =
#undef TARGET_INIT_DWARF_REG_SIZES_EXTRA
#define TARGET_INIT_DWARF_REG_SIZES_EXTRA rs6000_init_dwarf_reg_sizes_extra
+#undef TARGET_MEMBER_TYPE_FORCES_BLK
+#define TARGET_MEMBER_TYPE_FORCES_BLK rs6000_member_type_forces_blk
+
/* On rs6000, function arguments are promoted, as are function return
values. */
#undef TARGET_PROMOTE_FUNCTION_MODE
@@ -7287,6 +7290,26 @@ rs6000_emit_move (rtx dest, rtx source, enum
machine_mode mode)
emit_set:
emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
}
+
+/* Return true if a structure, union or array containing FIELD should
Re: [PATCH 6/7] rs6000: Remove -mabi=ieeelongdouble.
There are some problems with it: - On at least 4.6 and later, it crashes the compiler together with -m64; - On older versions, it generates incorrect code together with -m64; - Supposedly it doesn't actually work on 32-bit either, on the glibc side; - It isn't listed in --target-help, because the option file says undocumented, but the manual does in fact list it; - The Darwin header claims it is for POWER. In the spirit of the rest of this patch series, I solve these problems by ripping it all out. As we discussed on IRC, this should work but is broken. It should not be ripped out. I figured as much :-) Would you please open a Bugzilla PR and include me, Meissner and Peter Bergner on the CC list? Done, PR54284. Also committed the attached as obvious, to fix the issue that made me do this patch in the first place. Cheers, Segher 2012-08-16 Segher Boessenkool seg...@kernel.crashing.org * config/rs6000/darwin.h (TARGET_IEEE_QUAD): Fix comment. --- gcc/config/rs6000/darwin.h (revision 190445) +++ gcc/config/rs6000/darwin.h (working copy) @@ -282,7 +282,7 @@ #undef TARGET_DEFAULT #define TARGET_DEFAULT (MASK_MULTIPLE | MASK_PPC_GFXOPT) -/* Darwin only runs on PowerPC, so short-circuit POWER patterns. */ +/* Darwin always uses IBM long double, never IEEE long double. */ #undef TARGET_IEEEQUAD #define TARGET_IEEEQUAD 0
Re: [PATCH] Decrease integer-share-limit
On Thu, 16 Aug 2012, Paolo Carlini wrote: Hi, On 08/16/2012 03:39 PM, Richard Guenther wrote: This decreases the integer-share-limit to make sure the TREE_VEC we allocate for the small cached integers has a reasonable size for our GC memory allocator. Out of curiosity (just in case you hav two spare minutes) do you have any idea why this is so? I mean, naively one would think that allowing for any 8 bit constant would be a nice idea; puzzlingly, however the comment in the code says just experimentation. I'm wondering if tweaking a bit the memory allocator itself could allow for the full 8 bit range without a big memory waste... The GC memory allocator works on pages, there are not pages of arbitrary size but only power-of-two sizes. It's hard to improve the allocator here. Richard.
Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)
Hi,
I have another out of curiosity-type question ;)
On 08/16/2012 11:19 AM, Richard Guenther wrote:
!
! template typename Element
! inline int
! pointer_hashElement::equal (const T *existing,
! const T *candidate)
! {
! return existing == candidate;
}
are these uses in the new code of int instead of bool intended or
historical? Seem weird, definitely from the C++ (but even from the C)
point of view.
Paolo.
Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)
On Thu, 16 Aug 2012, Paolo Carlini wrote:
Hi,
I have another out of curiosity-type question ;)
On 08/16/2012 11:19 AM, Richard Guenther wrote:
!
! template typename Element
! inline int
! pointer_hashElement::equal (const T *existing,
! const T *candidate)
! {
! return existing == candidate;
}
are these uses in the new code of int instead of bool intended or
historical? Seem weird, definitely from the C++ (but even from the C) point
of view.
Historical, copying what libiberty htab did.
Richard.
Re: [PATCH] Decrease integer-share-limit
On Thu, Aug 16, 2012 at 04:44:03PM +0200, Richard Guenther wrote: On Thu, 16 Aug 2012, Paolo Carlini wrote: On 08/16/2012 03:39 PM, Richard Guenther wrote: This decreases the integer-share-limit to make sure the TREE_VEC we allocate for the small cached integers has a reasonable size for our GC memory allocator. Out of curiosity (just in case you hav two spare minutes) do you have any idea why this is so? I mean, naively one would think that allowing for any 8 bit constant would be a nice idea; puzzlingly, however the comment in the code says just experimentation. I'm wondering if tweaking a bit the memory allocator itself could allow for the full 8 bit range without a big memory waste... The GC memory allocator works on pages, there are not pages of arbitrary size but only power-of-two sizes. It's hard to improve the allocator here. The allocations are either power-of-two, or a couple of extra listed sizes. So, the alternative would be to add an extra size for the default integer share limit vector. See extra_order_size_table in ggc-page.c. Of course only provided there are many of those vectors. Jakub
Re: [PATCH] Free redirect_callers vector in tree-sra.c
On Thu, 16 Aug 2012, Richard Guenther wrote:
I noticed we leak the redirect_callers vector in SRA and also noticed
we compute it and then immediately re-compute cgraph edges which
looks weird to me.
Thus the following patch which frees the vector and makes its lifetime
more obvious.
Queued for testing.
The re-ordering fails gcc.dg/ipa/ipa-sra-6.c, I'll re-do without that.
Richard.
Richard.
2012-08-16 Richard Guenther rguent...@suse.de
* tree-sra.c (modify_function): Collect callers after rebuilding
cgraph edges. Free caller vector.
Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c(revision 190442)
+++ gcc/tree-sra.c(working copy)
@@ -4689,15 +4689,18 @@ modify_function (struct cgraph_node *nod
{
struct cgraph_node *new_node;
bool cfg_changed;
- VEC (cgraph_edge_p, heap) * redirect_callers = collect_callers_of_node
(node);
+ VEC (cgraph_edge_p, heap) * redirect_callers;
rebuild_cgraph_edges ();
free_dominance_info (CDI_DOMINATORS);
pop_cfun ();
current_function_decl = NULL_TREE;
+ redirect_callers = collect_callers_of_node (node);
new_node = cgraph_function_versioning (node, redirect_callers, NULL, NULL,
false, NULL, NULL, isra);
+ VEC_free (cgraph_edge_p, heap, redirect_callers);
+
current_function_decl = new_node-symbol.decl;
push_cfun (DECL_STRUCT_FUNCTION (new_node-symbol.decl));
--
Richard Guenther rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend
Re: RFA: Support infinity, NaN, and denormalized numbers in floatformat.c
Ian Lance Taylor i...@wasabisystems.com writes:
@@ -306,8 +359,18 @@ floatformat_to_double (fmt, from, to)
mant = get_field (ufrom, fmt-byteorder, fmt-totalsize,
mant_off, mant_bits);
- dto += ldexp ((double)mant, exponent - mant_bits);
- exponent -= mant_bits;
+ /* Handle denormalized numbers. FIXME: What should we do for
+ non-IEEE formats? */
+ if (exponent == 0 mant != 0)
+ dto += ldexp ((double)mant,
+ (- fmt-exp_bias
+- mant_bits
+- (mant_off - fmt-man_start)
++ 1));
+ else
+ dto += ldexp ((double)mant, exponent - mant_bits);
+ if (exponent != 0)
+ exponent -= mant_bits;
That mishandles numbers between 1 and 2 (ie. where the unbiased exponent
is zero) with floating-point formats with more than 32 mantissa bits.
Also, the handling of denormal numbers can be simplified by just setting
exponent appropriately.
Andreas.
* floatformat.c (floatformat_to_double): Correctly handle numbers
between 1 and 2. Simplify handling of denormal number.
(main): Test with 1.1.
---
libiberty/floatformat.c | 38 ++
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/libiberty/floatformat.c b/libiberty/floatformat.c
index 1116c63..c58ab01 100644
--- a/libiberty/floatformat.c
+++ b/libiberty/floatformat.c
@@ -1,5 +1,5 @@
/* IEEE floating point support routines, for GDB, the GNU Debugger.
- Copyright 1991, 1994, 1999, 2000, 2003, 2005, 2006, 2010
+ Copyright 1991, 1994, 1999, 2000, 2003, 2005, 2006, 2010, 2012
Free Software Foundation, Inc.
This file is part of GDB.
@@ -463,7 +463,6 @@ floatformat_to_double (const struct floatformat *fmt,
unsigned long mant;
unsigned int mant_bits, mant_off;
int mant_bits_left;
- int special_exponent;/* It's a NaN, denorm or zero */
/* Split values are not handled specially, since the top half has
the correctly rounded double value (in the only supported case of
@@ -503,20 +502,20 @@ floatformat_to_double (const struct floatformat *fmt,
mant_off = fmt-man_start;
dto = 0.0;
- special_exponent = exponent == 0 || (unsigned long) exponent == fmt-exp_nan;
-
- /* Don't bias zero's, denorms or NaNs. */
- if (!special_exponent)
-exponent -= fmt-exp_bias;
-
/* Build the result algebraically. Might go infinite, underflow, etc;
who cares. */
- /* If this format uses a hidden bit, explicitly add it in now. Otherwise,
- increment the exponent by one to account for the integer bit. */
-
- if (!special_exponent)
+ /* For denorms use minimum exponent. */
+ if (exponent == 0)
+exponent = 1 - fmt-exp_bias;
+ else
{
+ exponent -= fmt-exp_bias;
+
+ /* If this format uses a hidden bit, explicitly add it in now.
+Otherwise, increment the exponent by one to account for the
+integer bit. */
+
if (fmt-intbit == floatformat_intbit_no)
dto = ldexp (1.0, exponent);
else
@@ -530,18 +529,8 @@ floatformat_to_double (const struct floatformat *fmt,
mant = get_field (ufrom, fmt-byteorder, fmt-totalsize,
mant_off, mant_bits);
- /* Handle denormalized numbers. FIXME: What should we do for
-non-IEEE formats? */
- if (special_exponent exponent == 0 mant != 0)
- dto += ldexp ((double)mant,
- (- fmt-exp_bias
- - mant_bits
- - (mant_off - fmt-man_start)
- + 1));
- else
- dto += ldexp ((double)mant, exponent - mant_bits);
- if (exponent != 0)
- exponent -= mant_bits;
+ dto += ldexp ((double) mant, exponent - mant_bits);
+ exponent -= mant_bits;
mant_off += mant_bits;
mant_bits_left -= mant_bits;
}
@@ -756,6 +745,7 @@ main (void)
{
ieee_test (0.0);
ieee_test (0.5);
+ ieee_test (1.1);
ieee_test (256.0);
ieee_test (0.12345);
ieee_test (234235.78907234);
--
1.7.11.5
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: Merge C++ conversion into trunk
On 12-08-16 12:50 , Iain Sandoe wrote: On 14 Aug 2012, at 19:59, Diego Novillo wrote: After the merge is in, I will send an announcement and request major branch merges to wait for another 24 hrs to allow testers the chance to pick up this merge. The following patch (mimicking what has been done elsewhere at r190402) restores bootstrap for powerpc-darwin. OK for trunk? Iain gcc/ * config/rs6000/rs6000.c (macho_branch_islands): Adjust for changes to vec.h. OK, thanks. Diego.
Re: C++ PR 54197: lifetime of reference not properly extended
On Wed, Aug 15, 2012 at 10:52 AM, Ollie Wild a...@google.com wrote: (Adding other C++ maintainers in case someone else wants to have a stab.) Ping? Ollie I wonder if it wouldn't make more sense to iterate until we find the rightmost element in a compound_expr chain, but I don't think they are neither common nor long enough to matter. It looks like a good fix, but I would rather have a C++ maintainer give final approval for gcc-4_7-branch and trunk. In the meantime, should we install it in google/gcc-4_7? I can deal with any merge conflicts, in case the patch needs more work for the upstream branches. Thanks. Diego.
PATCH: Add x32 support to config.guess
Hi,
GCC on Linux/x86-64 may be configured for x32:
https://sites.google.com/site/x32abi/
by default and the Linux/x32 target should be x86_64-VENDOR-linux-gnux32.
This patch adds x32 support to config.guess. OK to install?
Thanks.
H.J.
---
2012-08-16 H.J. Lu hongjiu...@intel.com
* config.guess (x86_64:Linux:*:*): Append x32 if compiler is
configured for 32-bit objects.
diff --git a/config.guess b/config.guess
index b02565c..4b0f7c2 100755
--- a/config.guess
+++ b/config.guess
@@ -984,7 +984,18 @@ EOF
echo ${UNAME_MACHINE}-dec-linux-gnu
exit ;;
x86_64:Linux:*:*)
- echo x86_64-unknown-linux-gnu
+ eval $set_cc_for_build
+ X86_64_ABI=
+ # If there is a compiler, see if it is configured for 32-bit objects.
+ if [ $CC_FOR_BUILD != 'no_compiler_found' ]; then
+ if (echo '#ifdef __ILP32__'; echo IS_X32; echo '#endif') | \
+ (CCOPTS= $CC_FOR_BUILD -E - 2/dev/null) | \
+ grep IS_X32 /dev/null
+ then
+ X86_64_ABI=x32
+ fi
+ fi
+ echo x86_64-unknown-linux-gnu${X86_64_ABI}
exit ;;
xtensa*:Linux:*:*)
echo ${UNAME_MACHINE}-unknown-linux-gnu
PATCH: PR target/20020: 128 bit structs not targeted to TImode
Hi,
My email sent to gcc-patches@gcc.gnu.org was bounced as spam. I am
resending it. This patch defines both MAX_FIXED_MODE_SIZE and
MEMBER_TYPE_FORCES_BLK for i386. MEMBER_TYPE_FORCES_BLK is needed so
that we always put union with XFmode field in BLKmode. This patch
doesn't change any ABI since both MAX_FIXED_MODE_SIZE and
MEMBER_TYPE_FORCES_BLK aren't ABI macros. They only change code
quality. Tested on Linux/x86-64. OK to install?
Thanks.
H.J.
---
gcc/
2012-08-16 H.J. Lu hongjiu...@intel.com
Gary Funck g...@intrepid.com
PR target/20020
* config/i386/i386.h (MAX_FIXED_MODE_SIZE): New macro.
(MEMBER_TYPE_FORCES_BLK): Likewise.
gcc/testsuite/
2012-08-16 H.J. Lu hongjiu...@intel.com
Gary Funck g...@intrepid.com
PR target/20020
* gcc.target/i386/pr20020-1.c: New test.
* gcc.target/i386/pr20020-2.c: Likewise.
* gcc.target/i386/pr20020-3.c: Likewise.
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 5ff82ab..4046a9a 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1816,6 +1816,16 @@ do {
\
#define BRANCH_COST(speed_p, predictable_p) \
(!(speed_p) ? 2 : (predictable_p) ? 0 : ix86_branch_cost)
+/* An integer expression for the size in bits of the largest integer machine
+ mode that should actually be used. We allow pairs of registers. */
+#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (TARGET_64BIT ? TImode : DImode)
+
+/* Union with XFmode must be in BLKmode. */
+#define MEMBER_TYPE_FORCES_BLK(FIELD, MODE)\
+ ((MODE) == XFmode\
+(TREE_CODE (DECL_FIELD_CONTEXT (FIELD)) == UNION_TYPE\
+ || TREE_CODE (DECL_FIELD_CONTEXT (FIELD)) == QUAL_UNION_TYPE))
+
/* Define this macro as a C expression which is nonzero if accessing
less than a word of memory (i.e. a `char' or a `short') is no
faster than accessing a word of memory, i.e., if such access
diff --git a/gcc/testsuite/gcc.target/i386/pr20020-1.c
b/gcc/testsuite/gcc.target/i386/pr20020-1.c
new file mode 100644
index 000..3f10970
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr20020-1.c
@@ -0,0 +1,26 @@
+/* Check that 128-bit struct's are represented as TImode values. */
+/* { dg-do compile { target int128 } } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ union
+{
+ void *addr;
+ unsigned long long pad;
+};
+};
+typedef struct shared_ptr_struct sptr_t;
+
+sptr_t S;
+
+sptr_t
+sptr_result (void)
+{
+ return S;
+}
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* \\\[ retval
\\\]\\\) expand } } */
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg/i:TI 0 ax\\\) expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr20020-2.c
b/gcc/testsuite/gcc.target/i386/pr20020-2.c
new file mode 100644
index 000..e8c5b3d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr20020-2.c
@@ -0,0 +1,24 @@
+/* Check that 128-bit struct's are represented as TImode values. */
+/* { dg-do compile { target int128 } } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ union
+{
+ void *addr;
+ unsigned long long pad;
+};
+};
+typedef struct shared_ptr_struct sptr_t;
+
+void
+copy_sptr (sptr_t *dest, sptr_t src)
+{
+ *dest = src;
+}
+
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr20020-3.c
b/gcc/testsuite/gcc.target/i386/pr20020-3.c
new file mode 100644
index 000..b1cc926
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr20020-3.c
@@ -0,0 +1,27 @@
+/* Check that 128-bit struct's are represented as TImode values. */
+/* { dg-do compile { target int128 } } */
+/* { dg-options -O2 -fdump-rtl-expand } */
+
+struct shared_ptr_struct
+{
+ unsigned long long phase:48;
+ unsigned short thread:16;
+ union
+{
+ void *addr;
+ unsigned long long pad;
+};
+};
+typedef struct shared_ptr_struct sptr_t;
+
+sptr_t sptr_1, sptr_2;
+
+void
+copy_sptr (void)
+{
+ sptr_1 = sptr_2;
+}
+
+/* { dg-final { scan-rtl-dump \\\(set \\\(reg:TI \[0-9\]* expand } } */
+/* { dg-final { scan-rtl-dump \\\(set \\\(mem/c:TI expand } } */
+/* { dg-final { cleanup-rtl-dump expand } } */
Re: [bootstrap] Tentative fix for PR 54281
On Thu, Aug 16, 2012 at 07:55:51AM -0400, Diego Novillo wrote: Richi, this implements your idea for fixing PR 54281. I don't have an old enough compiler. Could you please test it in your system? I debated whether to remove the GENERATOR_FILE predicate from the inclusion (some files include gmp.h unconditionally). I think it could be removed, but only a minority of files build with GENERATOR_FILE set, so it didn't seem harmful. OK if tests pass? This patch breaks building with gmp, cloog and isl in subdirectories of the source tree. echo timestamp s-options gawk -f ../../trunk/gcc/opt-functions.awk -f ../../trunk/gcc/opt-read.awk \ -f ../../trunk/gcc/opth-gen.awk \ optionlist tmp-options.h /bin/sh ../../trunk/gcc/../move-if-change tmp-options.h options.h echo timestamp s-options-h TARGET_CPU_DEFAULT= \ HEADERS=auto-host.h ansidecl.h DEFINES= \ /bin/sh ../../trunk/gcc/mkconfig.sh bconfig.h g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/home/magfr/src/gcc/build/./gmp -I/home/magfr/src/gcc/trunk/gmp -I/home/magfr/src/gcc/build/./mpfr -I/home/magfr/src/gcc/trunk/mpfr -I/home/magfr/src/gcc/trunk/mpc/src -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_INT_GMP -I/home/magfr/src/gcc/build/./cloog/include -I/home/magfr/src/gcc/trunk/cloog/include -I../trunk/cloog/include -I/home/magfr/src/gcc/build/./isl/include -I/home/magfr/src/gcc/trunk/isl/include \ -o build/genconstants.o ../../trunk/gcc/genconstants.c In file included from /usr/include/sys/resource.h:25:0, from /usr/include/sys/wait.h:32, from ../../trunk/gcc/system.h:351, from ../../trunk/gcc/genconstants.c:29: /usr/include/bits/resource.h:133:18: error: declaration does not declare anything [-fpermissive] In file included from ../../trunk/gcc/genconstants.c:29:0: ../../trunk/gcc/system.h:443:23: error: declaration of C function `void* sbrk(int)' conflicts with In file included from ../../trunk/gcc/system.h:253:0, from ../../trunk/gcc/genconstants.c:29: /usr/include/unistd.h:1067:14: error: previous declaration `void* sbrk(intptr_t)' here In file included from ../../trunk/gcc/genconstants.c:29:0: ../../trunk/gcc/system.h:447:48: error: new declaration `char* strstr(const char*, const char*)' In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cstring:44:0, from ../../trunk/gcc/system.h:207, from ../../trunk/gcc/genconstants.c:29: /usr/include/string.h:323:22: error: ambiguates old declaration `const char* strstr(const char*, const char*)' In file included from ../../trunk/gcc/genconstants.c:29:0: ../../trunk/gcc/system.h:499:34: error: declaration of C function `const char* strsignal(int)' conflicts with In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cstring:44:0, from ../../trunk/gcc/system.h:207, from ../../trunk/gcc/genconstants.c:29: /usr/include/string.h:566:14: error: previous declaration `char* strsignal(int)' here In file included from ../../trunk/gcc/system.h:639:0, from ../../trunk/gcc/genconstants.c:29: ../../trunk/gcc/../include/libiberty.h:110:36: error: new declaration `char* basename(const char*)' In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/cstring:44:0, from ../../trunk/gcc/system.h:207, from ../../trunk/gcc/genconstants.c:29: /usr/include/string.h:603:28: error: ambiguates old declaration `const char* basename(const char*)' make[3]: *** [build/genconstants.o] Error 1 make[3]: Leaving directory `/home/magfr/src/gcc/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/magfr/src/gcc/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/magfr/src/gcc/build' make: *** [all] Error 2 The problem seems to be that during configure time the test scripts include system.h, but it fails to add the gmp include directory to the compiler flags so the checks for sbrk, strstr and so on fails with configure:10294: checking whether sbrk is declared configure:10317: gcc -c -g -I../../trunk/gcc -I../../trunk/gcc/../include conftest.c 5 In file included from conftest.c:125:0: ../../trunk/gcc/system.h:1041:17: fatal error: gmp.h: No such file or directory compilation terminated. configure:10317: $? = 1 Reverting this patch makes the compiler build. /MF
Re: [bootstrap] Tentative fix for PR 54281
On Thu, Aug 16, 2012 at 1:50 PM, Magnus Fromreide ma...@lysator.liu.se wrote: On Thu, Aug 16, 2012 at 07:55:51AM -0400, Diego Novillo wrote: Richi, this implements your idea for fixing PR 54281. I don't have an old enough compiler. Could you please test it in your system? I debated whether to remove the GENERATOR_FILE predicate from the inclusion (some files include gmp.h unconditionally). I think it could be removed, but only a minority of files build with GENERATOR_FILE set, so it didn't seem harmful. OK if tests pass? This patch breaks building with gmp, cloog and isl in subdirectories of the source tree. Working on a fix. It also exposed problems in Ada. Diego.
[SH] PR 54089
Hello,
This fixes the case where a dynamic shift would expand into a P27 shift
sequence that clobbers T_REG, which would result in wrong code.
Tested on rev 190396 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
OK?
Cheers,
Oleg
ChangeLog:
PR target/54089
* config/gcc/sh/sh.md (ashlsi3_d): Do not split if it would
result in a T_REG clobber. Correct comment.
(ashlsi3_n): Correct comment.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 190396)
+++ gcc/config/sh/sh.md (working copy)
@@ -3746,7 +3746,8 @@
(match_operand:SI 2 shift_count_operand r)))]
TARGET_DYNSHIFT
shld %2,%0
- (CONST_INT_P (operands[2]) ! sh_dynamicalize_shift_p (operands[2]))
+ CONST_INT_P (operands[2]) ! sh_dynamicalize_shift_p (operands[2])
+! sh_ashlsi_clobbers_t_reg_p (operands[2])
[(const_int 0)]
{
if (satisfies_constraint_P27 (operands[2]))
@@ -3759,7 +3760,9 @@
/* This must happen before reload, otherwise the constant will be moved
into a register due to the r constraint, after which this split
cannot be done anymore.
- Unfortunately the move insn will not always be eliminated. */
+ Unfortunately the move insn will not always be eliminated.
+ Also, here we must not create a shift sequence that clobbers the
+ T_REG. */
emit_move_insn (operands[0], operands[1]);
gen_shifty_op (ASHIFT, operands);
DONE;
@@ -3782,8 +3785,7 @@
if (sh_dynamicalize_shift_p (operands[2]) can_create_pseudo_p ())
{
/* If this pattern was picked and dynamic shifts are supported, switch
- to dynamic shift pattern before reload. However, we must not
- create a shift sequence that clobbers the T_REG. */
+ to dynamic shift pattern before reload. */
operands[2] = force_reg (SImode, operands[2]);
emit_insn (gen_ashlsi3_d (operands[0], operands[1], operands[2]));
}
Re: C++ PR 54197: lifetime of reference not properly extended
On Thu, Aug 16, 2012 at 12:12 PM, Diego Novillo dnovi...@google.com wrote: I wonder if it wouldn't make more sense to iterate until we find the rightmost element in a compound_expr chain, but I don't think they are neither common nor long enough to matter. Yeah, that was my thinking. I can certainly do whatever the maintainers want. It looks like a good fix, but I would rather have a C++ maintainer give final approval for gcc-4_7-branch and trunk. In the meantime, should we install it in google/gcc-4_7? I can deal with any merge conflicts, in case the patch needs more work for the upstream branches. I'll go ahead and submit to google/gcc-4_7, then. Thanks, Ollie
[lra] patch to remove lra-equivs.c
File lra-equivs.c was removed as not used anymore. The patch was committed as rev. 190448. 2012-08-16 Vladimir Makarov vmaka...@redhat.com * lra-equivs.c: Remove.
Re: [bootstrap] Tentative fix for PR 54281
I have reverted my original fix and propose this one. My fix caused build failures in Ada (which includes system.h inside 'extern C' blocks) and it also breaks in-tree isl/cloog. Richi, I've tried building my own 4.1, but it doesn't build on my system. Could you try this patch? It includes libintl.h before undefining the names, this way the inclusion done from gmp.h turns into a nop. Thanks. Diego. commit 96e3d8108901c6f94fa3b0f2de769370688836cb Author: Diego Novillo dnovi...@google.com Date: Thu Aug 16 14:27:49 2012 -0400 2012-08-16 Diego Novillo dnovi...@google.com PR bootstrap/54281 * intl.h: Always include libintl.h. diff --git a/gcc/ChangeLog b/gcc/ChangeLog index a8ff00d..5252122 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,5 +1,10 @@ 2012-08-16 Diego Novillo dnovi...@google.com + PR bootstrap/54281 + * intl.h: Always include libintl.h. + +2012-08-16 Diego Novillo dnovi...@google.com + Revert PR bootstrap/54281 diff --git a/gcc/intl.h b/gcc/intl.h index c4db354..745fefd 100644 --- a/gcc/intl.h +++ b/gcc/intl.h @@ -27,8 +27,8 @@ # define setlocale(category, locale) (locale) #endif -#ifdef ENABLE_NLS #include libintl.h +#ifdef ENABLE_NLS extern void gcc_init_libintl (void); extern size_t gcc_gettext_width (const char *); #else
[SH] PR 39423
Hello,
This fixes the issue mentioned in the PR's comment #29.
Tested on rev 190396 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
OK?
Cheers,
Oleg
ChangeLog:
PR target/39423
* config/sh/sh.md (*movsi_index_disp, *movhi_index_disp):
Handle potential T_REG clobber. Convert zero extending split
to insn_and_split.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 190396)
+++ gcc/config/sh/sh.md (working copy)
@@ -5455,16 +5455,22 @@
;; mov.l @(4,r5),r0
;;
;; See also PR 39423.
+;; Notice that these patterns have a T_REG clobber, because the shift
+;; sequence that will be split out might clobber the T_REG. Ideally, the
+;; clobber would be added conditionally, depending on the result of
+;; sh_ashlsi_clobbers_t_reg_p. When splitting out the shifts we must go
+;; through the ashlsi3 expander in order to get the right shift insn --
+;; a T_REG clobbering or non-clobbering shift sequence or dynamic shift.
;; FIXME: Fold copy pasted patterns somehow.
;; FIXME: Combine never tries this kind of patterns for DImode.
(define_insn_and_split *movsi_index_disp
[(set (match_operand:SI 0 arith_reg_dest =r)
- (match_operand:SI 1 mem_index_disp_operand m))]
+ (match_operand:SI 1 mem_index_disp_operand m))
+ (clobber (reg:SI T_REG))]
TARGET_SH1
#
can_create_pseudo_p ()
- [(set (match_dup 5) (ashift:SI (match_dup 1) (match_dup 2)))
- (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
+ [(set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
(set (match_dup 0) (match_dup 7))]
{
rtx mem = operands[1];
@@ -5481,16 +5487,18 @@
operands[7] =
replace_equiv_address (mem,
gen_rtx_PLUS (SImode, operands[6], operands[4]));
+
+ emit_insn (gen_ashlsi3 (operands[5], operands[1], operands[2]));
})
(define_insn_and_split *movhi_index_disp
[(set (match_operand:SI 0 arith_reg_dest =r)
- (sign_extend:SI (match_operand:HI 1 mem_index_disp_operand m)))]
+ (sign_extend:SI (match_operand:HI 1 mem_index_disp_operand m)))
+ (clobber (reg:SI T_REG))]
TARGET_SH1
#
can_create_pseudo_p ()
- [(set (match_dup 5) (ashift:SI (match_dup 1) (match_dup 2)))
- (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
+ [(set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
(set (match_dup 0) (sign_extend:SI (match_dup 7)))]
{
rtx mem = operands[1];
@@ -5507,13 +5515,19 @@
operands[7] =
replace_equiv_address (mem,
gen_rtx_PLUS (SImode, operands[6], operands[4]));
+
+ emit_insn (gen_ashlsi3 (operands[5], operands[1], operands[2]));
})
-(define_split
+(define_insn_and_split *movhi_index_disp
[(set (match_operand:SI 0 arith_reg_dest)
- (zero_extend:SI (match_operand:HI 1 mem_index_disp_operand)))]
+ (zero_extend:SI (match_operand:HI 1 mem_index_disp_operand)))
+ (clobber (reg:SI T_REG))]
TARGET_SH1
- [(set (match_dup 0) (sign_extend:SI (match_dup 1)))
+ #
+ 1
+ [(parallel [(set (match_dup 0) (sign_extend:SI (match_dup 1)))
+ (clobber (reg:SI T_REG))])
(set (match_dup 0) (zero_extend:SI (match_dup 2)))]
{
operands[2] = gen_lowpart (HImode, operands[0]);
@@ -5521,12 +5535,12 @@
(define_insn_and_split *movsi_index_disp
[(set (match_operand:SI 0 mem_index_disp_operand =m)
- (match_operand:SI 1 arith_reg_operand r))]
+ (match_operand:SI 1 arith_reg_operand r))
+ (clobber (reg:SI T_REG))]
TARGET_SH1
#
can_create_pseudo_p ()
- [(set (match_dup 5) (ashift:SI (match_dup 0) (match_dup 2)))
- (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
+ [(set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
(set (match_dup 7) (match_dup 1))]
{
rtx mem = operands[0];
@@ -5543,16 +5557,18 @@
operands[7] =
replace_equiv_address (mem,
gen_rtx_PLUS (SImode, operands[6], operands[4]));
+
+ emit_insn (gen_ashlsi3 (operands[5], operands[0], operands[2]));
})
(define_insn_and_split *movsi_index_disp
[(set (match_operand:HI 0 mem_index_disp_operand =m)
- (match_operand:HI 1 arith_reg_operand r))]
+ (match_operand:HI 1 arith_reg_operand r))
+ (clobber (reg:SI T_REG))]
TARGET_SH1
#
can_create_pseudo_p ()
- [(set (match_dup 5) (ashift:SI (match_dup 0) (match_dup 2)))
- (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
+ [(set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
(set (match_dup 7) (match_dup 1))]
{
rtx mem = operands[0];
@@ -5569,6 +5585,8 @@
operands[7] =
replace_equiv_address (mem,
gen_rtx_PLUS (SImode, operands[6], operands[4]));
+
+ emit_insn (gen_ashlsi3 (operands[5], operands[0], operands[2]));
})
;; Define additional pop for SH1 and SH2 so it does not get
Re: [bootstrap] Tentative fix for PR 54281
On Thu, 16 Aug 2012, Diego Novillo wrote: diff --git a/gcc/intl.h b/gcc/intl.h index c4db354..745fefd 100644 --- a/gcc/intl.h +++ b/gcc/intl.h @@ -27,8 +27,8 @@ # define setlocale(category, locale) (locale) #endif -#ifdef ENABLE_NLS #include libintl.h +#ifdef ENABLE_NLS I'm not sure it's safe to assume libintl.h exists on all hosts (e.g. MinGW) unless ENABLE_NLS. (If ENABLE_NLS, the intl/ directory will have built that header if the host didn't have it.) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH, ARM] Don't pull in unwinder for 64-bit division routines
On 07/24/12 13:27, Julian Brown wrote: On Fri, 20 Jul 2012 11:15:27 +0100 Julian Brown jul...@codesourcery.com wrote: Anyway: this revised version of the patch removes the strange libgcc Makefile-fragment changes, the equivalent of which have since been incorporated into mainline GCC now anyway, so the patch is somewhat more straightforward than it was previously. Joey Ye contacted me offlist and suggested that the t-divmod-ef fragment might be better integrated into t-bpabi instead. Doing that makes the patch somewhat smaller/cleaner. Minimally re-tested, looks OK. The original submission makes no mention of testing ? The ARM specific portions look OK to me modulo no regressions. Ian, can also take a quick look. regards, Ramana
Re: [bootstrap] Tentative fix for PR 54281
On 12-08-16 14:46 , Joseph S. Myers wrote: On Thu, 16 Aug 2012, Diego Novillo wrote: diff --git a/gcc/intl.h b/gcc/intl.h index c4db354..745fefd 100644 --- a/gcc/intl.h +++ b/gcc/intl.h @@ -27,8 +27,8 @@ # define setlocale(category, locale) (locale) #endif -#ifdef ENABLE_NLS #include libintl.h +#ifdef ENABLE_NLS I'm not sure it's safe to assume libintl.h exists on all hosts (e.g. MinGW) unless ENABLE_NLS. (If ENABLE_NLS, the intl/ directory will have built that header if the host didn't have it.) I wonder if we couldn't simply '#define _LIBINTL_H 1' in the #else branch then. Something like this (though it seems a bit hacky to me): diff --git a/gcc/intl.h b/gcc/intl.h index c4db354..3da4738 100644 --- a/gcc/intl.h +++ b/gcc/intl.h @@ -32,6 +32,9 @@ extern void gcc_init_libintl (void); extern size_t gcc_gettext_width (const char *); #else +/* Prevent libintl.h from being included, since we are truncating + some functions (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281). */ +# define _LIBINTL_H 1 /* Stubs. */ # undef textdomain # define textdomain(domain) (domain)
Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)
On 8/16/12, Richard Guenther rguent...@suse.de wrote:
On Wed, 15 Aug 2012, Lawrence Crowl wrote:
On 8/15/12, Richard Henderson r...@redhat.com wrote:
On 2012-08-15 07:29, Richard Guenther wrote:
+ typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T T;
? Given that this name is scoped anyway...
I do not much like _t names either.
The following is what I'm testing now, it also integrates the
hashtable support functions and typedef within the existing local
data types which is IMHO cleaner. (it also shows we can do with
a janitorial cleanup replacing typedef struct foo_d {} foo; with
struct foo {}; and the likes)
Yes.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu, ok?
Looks good to me.
I would have prefered the Element-T rename in a separate patch
so that it is easier to see the core difference.
--
Lawrence Crowl
[SH] PR 54236 - Improve addc/subc utilization
Hello,
The attached patch improves the utilization of the addc and subc
instructions as mentioned in the PR.
Tested on rev 190396 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
I've also briefly checked the CSiBE result-size for 'm4-single -ml -O2
-mpretend-cmove'. There is a little bit of noise here and there due to
differences in insn scheduling/ordering. Looking at some parts of
mpeg2dec, the new insn sequences seem to be beneficial for a couple of
functions.
OK?
Cheers,
Oleg
ChangeLog:
PR target/54236
* config/sh/sh.md (addc): Add commutative modifier.
(*addc, *minus_plus_one, *subc, *negc): New insns and splits.
testsuite/ChangeLog:
PR target/54236
* gcc.target/sh/pr54236-1.c: New.
Index: gcc/testsuite/gcc.target/sh/pr54236-1.c
===
--- gcc/testsuite/gcc.target/sh/pr54236-1.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr54236-1.c (revision 0)
@@ -0,0 +1,76 @@
+/* Tests to check the utilization of addc, subc and negc instructions in
+ special cases. If everything works as expected we won't see any
+ movt instructions in these cases. */
+/* { dg-do compile { target sh*-*-* } } */
+/* { dg-options -O1 } */
+/* { dg-skip-if { sh*-*-* } { -m5*} { } } */
+/* { dg-final { scan-assembler-times addc 3 } } */
+/* { dg-final { scan-assembler-times subc 3 } } */
+/* { dg-final { scan-assembler-times sett 4 } } */
+/* { dg-final { scan-assembler-times negc 1 } } */
+/* { dg-final { scan-assembler-not movt } } */
+
+int
+test_00 (int a, int b, int c, int d)
+{
+ /* 1x addc, 1x sett */
+ return a + b + 1;
+}
+
+int
+test_01 (int a, int b, int c, int d)
+{
+ /* 1x addc */
+ return a + (c == d);
+}
+
+int
+test_02 (int a, int b, int c, int d)
+{
+ /* 1x subc, 1x sett */
+ return a - b - 1;
+}
+
+int
+test_03 (int a, int b, int c, int d)
+{
+ /* 1x subc */
+ return a - (c == d);
+}
+
+int
+test_04 (int a, int b, int c, int d)
+{
+ /* 1x addc, 1x sett */
+ return a + b + c + 1;
+}
+
+int
+test_05 (int a, int b, int c, int d)
+{
+ /* 1x subc, 1x sett */
+ return a - b - c - 1;
+}
+
+int
+test_06 (int a, int b, int c, int d)
+{
+ /* 1x negc */
+ return 0 - a - (b == c);
+}
+
+int
+test_07 (int *vec)
+{
+ /* Must not see a 'sett' or 'addc' here.
+ This is a case where combine tries to produce
+ 'a + (0 - b) + 1' out of 'a - b + 1'. */
+ int z = vec[0];
+ int vi = vec[1];
+ int zi = vec[2];
+
+ if (zi != 0 z -1)
+vi -= (((vi 7) 0x01) 1) - 1;
+
+ return vi;
+}
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 190396)
+++ gcc/config/sh/sh.md (working copy)
@@ -1686,7 +1686,7 @@
(define_insn addc
[(set (match_operand:SI 0 arith_reg_dest =r)
- (plus:SI (plus:SI (match_operand:SI 1 arith_reg_operand 0)
+ (plus:SI (plus:SI (match_operand:SI 1 arith_reg_operand %0)
(match_operand:SI 2 arith_reg_operand r))
(reg:SI T_REG)))
(set (reg:SI T_REG)
@@ -1695,6 +1695,76 @@
addc %2,%0
[(set_attr type arith)])
+;; A simplified version of the addc insn, where the exact value of the
+;; T bit doesn't matter. This is easier for combine to pick up.
+;; We allow a reg or 0 for one of the operands in order to be able to
+;; do 'reg + T' sequences. Reload will load the constant 0 into the reg
+;; as needed.
+(define_insn *addc
+ [(set (match_operand:SI 0 arith_reg_dest =r)
+ (plus:SI (plus:SI (match_operand:SI 1 arith_reg_operand %0)
+ (match_operand:SI 2 arith_reg_or_0_operand r))
+ (match_operand:SI 3 t_reg_operand )))
+ (clobber (reg:SI T_REG))]
+ TARGET_SH1
+ addc %2,%0
+ [(set_attr type arith)])
+
+;; Split 'reg + reg + 1' into a sett addc sequence, as it can be scheduled
+;; better, if the sett insn can be done early.
+(define_insn_and_split *addc
+ [(set (match_operand:SI 0 arith_reg_dest )
+ (plus:SI (plus:SI (match_operand:SI 1 arith_reg_operand )
+ (match_operand:SI 2 arith_reg_operand ))
+ (const_int 1)))
+ (clobber (reg:SI T_REG))]
+ TARGET_SH1
+ #
+ 1
+ [(set (reg:SI T_REG) (const_int 1))
+ (parallel [(set (match_dup 0) (plus:SI (plus:SI (match_dup 1) (match_dup 2))
+ (reg:SI T_REG)))
+ (clobber (reg:SI T_REG))])])
+
+;; Sometimes combine will try to do 'reg + (0-reg) + 1' if the *addc pattern
+;; matched. Split this up into a simple sub add sequence, as this will save
+;; us one sett insn.
+(define_insn_and_split *minus_plus_one
+ [(set (match_operand:SI 0 arith_reg_dest )
+ (plus:SI (minus:SI (match_operand:SI 1 arith_reg_operand )
+ (match_operand:SI 2 arith_reg_operand ))
+ (const_int 1)))]
+ TARGET_SH1
+ #
+ 1
+ [(set (match_dup 0) (minus:SI (match_dup 1) (match_dup 2)))
+ (set (match_dup 0) (plus:SI (match_dup 0) (const_int 1)))])
+
+;; Split 'reg + T' into 'reg + 0 + T' to utilize the addc insn.
+;; If the
Re: C++ PR 54197: lifetime of reference not properly extended
On Wed, Aug 15, 2012 at 9:52 AM, Ollie Wild a...@google.com wrote: (Adding other C++ maintainers in case someone else wants to have a stab.) Ping? I consider Jason to be the expert on this; so let see what he says. -- Gaby Ollie On Mon, Aug 13, 2012 at 4:01 PM, Ollie Wild a...@google.com wrote: On Mon, Aug 13, 2012 at 3:50 PM, Jakub Jelinek ja...@redhat.com wrote: The formatting doesn't match GCC coding conventions in several ways. You don't have spaces before (, and ( shouldn't be at the end of line if possible. Updated patch attached. Ollie
Re: [PATCH, ARM] Don't pull in unwinder for 64-bit division routines
On Thu, 16 Aug 2012 19:56:52 +0100 Ramana Radhakrishnan ramra...@arm.com wrote: On 07/24/12 13:27, Julian Brown wrote: On Fri, 20 Jul 2012 11:15:27 +0100 Julian Brown jul...@codesourcery.com wrote: Anyway: this revised version of the patch removes the strange libgcc Makefile-fragment changes, the equivalent of which have since been incorporated into mainline GCC now anyway, so the patch is somewhat more straightforward than it was previously. Joey Ye contacted me offlist and suggested that the t-divmod-ef fragment might be better integrated into t-bpabi instead. Doing that makes the patch somewhat smaller/cleaner. Minimally re-tested, looks OK. The original submission makes no mention of testing ? The ARM specific portions look OK to me modulo no regressions. Thanks -- I'm sure I did test the patch, but just omitted to mention that fact in the mail :-O. We've also been carrying a version of this patch in our local source base for many years now. Ian, can also take a quick look. Cheers, Julian
Re: Reproducible gcc builds, gfortran, and -grecord-gcc-switches
On Thu, Aug 16, 2012 at 06:59:09PM +0200, Simon Baldwin wrote: On 16 August 2012 16:40, Michael Matz m...@suse.de wrote: ,,, Do you have considered to use a new option flag (usable in the .opt files) instead of a langhook? I.e. add a flag cl_dont_record to cl_option, a string Norecord for the .opt files, some handling for it in opt-functions.awk and the like? Adding lang-hooks used by debug producers make me twitch :) Okay. Below is an alternative approach. I've moved discussion to gcc-patches, since it's now more concrete than abstract. You could have just added case OPT_cpp_: to the switch in gen_producer_string, instead of all this. --- gcc/dwarf2out.c (revision 190442) +++ gcc/dwarf2out.c (working copy) @@ -18101,6 +18101,9 @@ gen_producer_string (void) /* Ignore these. */ continue; default: +if (cl_options[save_decoded_options[j].opt_index].flags + CL_NO_DWARF_RECORD) + continue; gcc_checking_assert (save_decoded_options[j].canonical_option[0][0] == '-'); switch (save_decoded_options[j].canonical_option[0][1]) Jakub
Re: LEA-splitting improvement patch.
On Wed, Aug 15, 2012 at 12:58 PM, Yuri Rumyantsev ysrum...@gmail.com wrote: I send you new patch with fixed space/tab alignments. About your comment. It is more optimal to put adding of constant before adding of the register only for case when 3 instructions must be generated to split lea. In all other cases it does not matter and I left code unchangeable. I have cleaned patch a bit and committed the patch to mainline SVN. Thanks, Uros.
[committed] TILE-Gx/TILEPro: add stub header file
This patch adds a stub header file feedback.h, needed to compile
glibc and linux.
Walter
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 190448)
+++ gcc/config.gcc (working copy)
@@ -2440,6 +2440,7 @@ tilegx-*-linux*)
extra_objs=mul-tables.o
c_target_objs=tilegx-c.o
cxx_target_objs=tilegx-c.o
+ extra_headers=feedback.h
;;
tilepro-*-linux*)
tm_file=elfos.h gnu-user.h linux.h glibc-stdint.h tilepro/linux.h
${tm_file}
@@ -2447,6 +2448,7 @@ tilepro-*-linux*)
extra_objs=mul-tables.o
c_target_objs=tilepro-c.o
cxx_target_objs=tilepro-c.o
+ extra_headers=feedback.h
;;
v850-*-rtems*)
target_cpu_default=TARGET_CPU_generic
Index: gcc/config/tilegx/feedback.h
===
--- gcc/config/tilegx/feedback.h(revision 0)
+++ gcc/config/tilegx/feedback.h(revision 0)
@@ -0,0 +1 @@
+/* This file is currently empty and serves as a placeholder. */
Index: gcc/config/tilepro/feedback.h
===
--- gcc/config/tilepro/feedback.h (revision 0)
+++ gcc/config/tilepro/feedback.h (revision 0)
@@ -0,0 +1 @@
+/* This file is currently empty and serves as a placeholder. */
Re: [C PATCH] -Wsizeof-pointer-memaccess warning
On Thu, 16 Aug 2012, Jakub Jelinek wrote: Hi! On Wed, Aug 15, 2012 at 04:29:55PM +, Joseph S. Myers wrote: On Wed, 15 Aug 2012, Jakub Jelinek wrote: I was mainly interested in whether such an approach is acceptable, or whether I need to stop evaluating sizeof right away, create SIZEOF_EXPR and only fold it during fully_fold*. I've briefly looked at that today, The approach is fine. Delaying evaluating sizeof is hard simply because of the expectation that integer constant expressions in general are evaluated early. Ok, thanks. Here is an updated patch, which gets away just with one global variable (location_t computed from token after sizeof keyword in the caller). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? This version is OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFA:] fix PR54261, reverse operator emitted for compare_and_swap-libfunc targets
From: Hans-Peter Nilsson h...@axis.com
Date: Wed, 15 Aug 2012 02:20:37 +0200
I looked around and it seems only cris{v32,}-axis-linux-gnu is
affected. Still, besides that target, for a 4.7/r189762 import
and c/c++ testing, boot+regtest in progress for x86_64-linux and
cross-test for cris-axis-elf. The test-case is spot-checked to
pass for a target not implementing any atomics whatsoever,
i.e. mmix-knuth-mmixware.
(clean test-results)
Ok for trunk, assuming clean test-results? Maybe 4.7 too, it
being somewhat trivial?
gcc:
PR middle-end/54261
* optabs.c (expand_atomic_fetch_op): Save and restore code when
retrying after failed attempt.
gcc/testsuite:
PR middle-end/54261
* gcc.dg/torture/pr54261-1.c: New test.
Approved on IRC by dnovillo, committed. A backport to 4.7 is
trivial but AFAIK not affecting any FSF target so I'll drop
that; affected private ports have to have maintainers skilled
enough to find this post.
brgds, H-P
Re: [SH] PR 39423
Oleg Endo oleg.e...@t-online.de wrote:
This fixes the issue mentioned in the PR's comment #29.
Tested on rev 190396 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures.
OK?
OK.
Regards,
kaz
[PATCH] PR c++/53540 - using fails to be equivalent to typedef
Hello,
In the example of this problem report, during the substituting of int
into 'function', tsubst_aggr_type fails for the alias ctxt1. This is
because TYPE_TEMPLATE_INFO looks for the TEMPLATE_INFO of the ctxt1
alias at the wrong place and was wrongly finding it to be NULL.
Namely, it was looking for it in the DECL_TEMPLATE_INFO of the
declaration of the type -- as if ctxt1 was an alias template
specialization -- rather than looking of it in its
CLASSTYPE_TEMPLATE_INFO.
Fixed thus. The second hunk of the patch is just to prevent the
compiler from crashing when primary_template_instantiation_p is passed
an alias of a class template instantiation.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp
* cp-tree.h (TYPE_TEMPLATE_INFO): For an alias that is not an
instance of alias template, don't look for its TEMPLATE_INFO in
its declaration.
* pt.c (primary_template_instantiation_p): Don't crash on an alias
that is not an instance of a template.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-21.C: New test.
---
gcc/cp/cp-tree.h |4 ++--
gcc/cp/pt.c|1 +
gcc/testsuite/g++.dg/cpp0x/alias-decl-21.C | 24
3 files changed, 27 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-21.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 44f3ac1..64a8830 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -2634,8 +2634,8 @@ extern void decl_shadowed_for_var_insert (tree, tree);
template info for the alias template, not the one (if any) for the
template of the underlying type. */
#define TYPE_TEMPLATE_INFO(NODE) \
- (TYPE_ALIAS_P (NODE) \
- ? ((TYPE_NAME (NODE) DECL_LANG_SPECIFIC (TYPE_NAME (NODE))) \
+ ((TYPE_ALIAS_P (NODE) DECL_LANG_SPECIFIC (TYPE_NAME (NODE))) \
+ ? (DECL_LANG_SPECIFIC (TYPE_NAME (NODE))\
? DECL_TEMPLATE_INFO (TYPE_NAME (NODE)) \
: NULL_TREE) \
: ((TREE_CODE (NODE) == ENUMERAL_TYPE) \
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ad81bab..3163bd4 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -2854,6 +2854,7 @@ primary_template_instantiation_p (const_tree t)
else if (TYPE_P (t)
TYPE_TEMPLATE_INFO (t)
PRIMARY_TEMPLATE_P (TYPE_TI_TEMPLATE (t))
+ DECL_LANG_SPECIFIC (TYPE_NAME (t))
DECL_TEMPLATE_INSTANTIATION (TYPE_NAME (t)))
return true;
return false;
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-21.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-21.C
new file mode 100644
index 000..b68fa93
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-21.C
@@ -0,0 +1,24 @@
+// Origin: PR c++/53540
+// { dg-do compile { target c++11 } }
+
+template typename T
+struct context
+{
+ typedef int type;
+};
+
+template typename T
+void function()
+{
+ using ctx1 = contextT;
+ typename ctx1::type f1;
+
+ typedef contextT ctx2;
+ typename ctx2::type f2;
+}
+
+int main()
+{
+ functionint();
+}
+
--
Dodji
Re: [PATCH] Set correct source location for deallocator calls
ping.
Thanks,
Dehao
On Fri, Aug 10, 2012 at 8:38 PM, Dehao Chen de...@google.com wrote:
New patch attached.
Bootstrapped and passed GCC regression tests.
Ok for trunk?
Thanks,
Dehao
gcc/ChangeLog
2012-08-07 Dehao Chen de...@google.com
* tree-eh.c (goto_queue_node): New field.
(record_in_goto_queue): New parameter.
(record_in_goto_queue_label): New parameter.
(lower_try_finally_dup_block): New parameter.
(maybe_record_in_goto_queue): Update source location.
(lower_try_finally_copy): Likewise.
(honor_protect_cleanup_actions): Likewise.
* gimplify.c (gimplify_expr): Reset the location to unknown.
gcc/testsuite/ChangeLog
2012-08-07 Dehao Chen de...@google.com
* g++.dg/guality/deallocator.C: New test.
Index: gcc/testsuite/g++.dg/guality/deallocator.C
===
*** gcc/testsuite/g++.dg/guality/deallocator.C (revision 0)
--- gcc/testsuite/g++.dg/guality/deallocator.C (revision 0)
***
*** 0
--- 1,33
+ // Test that debug info generated for auto-inserted deallocator is
+ // correctly attributed.
+ // This patch scans for the lineno directly from assembly, which may
+ // differ between different architectures. Because it mainly tests
+ // FE generated debug info, without losing generality, only x86
+ // assembly is scanned in this test.
+ // { dg-do compile { target { i?86-*-* x86_64-*-* } } }
+ // { dg-options -O2 -fno-exceptions -g }
+
+ struct t {
+ t ();
+ ~t ();
+ void foo();
+ void bar();
+ };
+
+ int bar();
+
+ void foo(int i)
+ {
+ for (int j = 0; j 10; j++)
+ {
+ t test;
+ test.foo();
+ if (i + j)
+ {
+ test.bar();
+ return;
+ }
+ }
+ return;
+ }
+ // { dg-final { scan-assembler 1 28 0 } }
Index: gcc/tree-eh.c
===
*** gcc/tree-eh.c (revision 190209)
--- gcc/tree-eh.c (working copy)
*** static bitmap eh_region_may_contain_thro
*** 321,326
--- 321,327
struct goto_queue_node
{
treemple stmt;
+ location_t location;
gimple_seq repl_stmt;
gimple cont_stmt;
int index;
*** static void
*** 560,566
record_in_goto_queue (struct leh_tf_state *tf,
treemple new_stmt,
int index,
! bool is_label)
{
size_t active, size;
struct goto_queue_node *q;
--- 561,568
record_in_goto_queue (struct leh_tf_state *tf,
treemple new_stmt,
int index,
! bool is_label,
! location_t location)
{
size_t active, size;
struct goto_queue_node *q;
*** record_in_goto_queue (struct leh_tf_stat
*** 583,588
--- 585,591
memset (q, 0, sizeof (*q));
q-stmt = new_stmt;
q-index = index;
+ q-location = location;
q-is_label = is_label;
}
*** record_in_goto_queue (struct leh_tf_stat
*** 590,596
TF is not null. */
static void
! record_in_goto_queue_label (struct leh_tf_state *tf, treemple stmt,
tree label)
{
int index;
treemple temp, new_stmt;
--- 593,600
TF is not null. */
static void
! record_in_goto_queue_label (struct leh_tf_state *tf, treemple stmt,
tree label,
! location_t location)
{
int index;
treemple temp, new_stmt;
*** record_in_goto_queue_label (struct leh_t
*** 629,635
since with a GIMPLE_COND we have an easy access to the then/else
labels. */
new_stmt = stmt;
! record_in_goto_queue (tf, new_stmt, index, true);
}
/* For any GIMPLE_GOTO or GIMPLE_RETURN, decide whether it leaves a
try_finally
--- 633,639
since with a GIMPLE_COND we have an easy access to the then/else
labels. */
new_stmt = stmt;
! record_in_goto_queue (tf, new_stmt, index, true, location);
}
/* For any GIMPLE_GOTO or GIMPLE_RETURN, decide whether it leaves a
try_finally
*** maybe_record_in_goto_queue (struct leh_s
*** 649,667
{
case GIMPLE_COND:
new_stmt.tp = gimple_op_ptr (stmt, 2);
! record_in_goto_queue_label (tf, new_stmt,
gimple_cond_true_label (stmt));
new_stmt.tp = gimple_op_ptr (stmt, 3);
! record_in_goto_queue_label (tf, new_stmt,
gimple_cond_false_label (stmt));
break;
case GIMPLE_GOTO:
new_stmt.g = stmt;
! record_in_goto_queue_label (tf, new_stmt, gimple_goto_dest (stmt));
break;
case GIMPLE_RETURN:
tf-may_return = true;
new_stmt.g = stmt;
! record_in_goto_queue (tf, new_stmt, -1, false);
break;
default:
--- 653,674
{
Re: [bootstrap] Tentative fix for PR 54281
On Thu, Aug 16, 2012 at 12:12 PM, Diego Novillo dnovi...@google.com wrote: This is the patch I'm currently testing. I need someone with a very old toolchain (4.1 or earlier) to also give this a try (the original problem does not occur in g++ more recent than 4.1). Thanks. Diego. diff --git a/gcc/ChangeLog b/gcc/ChangeLog index a8ff00d..8798b8f 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,5 +1,11 @@ 2012-08-16 Diego Novillo dnovi...@google.com + PR bootstrap/54281 + * intl.h: Prevent libintl.h from being included when + ENABLE_NLS is not set. It's hard to convince myself that this patch is portable. I don't think we can assume that every system that provides libintl.h uses _LIBINTL_H as the preprocessor guard. The issue is that we must not #include libintl.h after #defining those macros. So the fix is to #include libintl.h in all cases before #defining those macros. Your proposal of unconditionally doing #include libintl.h is not a good idea, because libintl.h is not available on every system. But we are compiling host files here, so we can just use autoconf. I recommend that you add libintl.h to the AC_CHECK_HEADERS list in gcc/configure.ac, and then change intl.h to do #ifdef HAVE_LIBINTL_H #include libintl.h #endif before the #ifdef ENABLE_NLS test. Ian
Re: [Google 4.7] Generate pubnames compatible with gdb-index version 7. (issue6459099)
+/* Output a single entry in the pubnames table. */ + +static void +output_pubname (dw_offset die_offset, pubname_entry *entry) For this function, I'd suggest a comment to the effect that the logic is lifted from GDB. @@ -2424,6 +2424,10 @@ gpubnames Common RejectNegative Var(debug_generate_pub_sections, 1) Generate DWARF pubnames and pubtypes sections. +ggnu-pubnames +Common RejectNegative Var(debug_generate_pub_sections, 2) +Generate DWARF pubnames and pubtypes sections. Instead of RejectNegative, I think these three options should now use Negative(...) flags (each one naming the next, circularly). Not sure about that, though. (See the treatment of -gdwarf-, -gstabs, etc.) OK for google/gcc-4_7 branch. -cary
Re: [PATCH, MIPS] DSP ALU scheduling
On 08/16/2012 01:27 PM, Richard Sandiford wrote: Sandra Loosemoresan...@codesourcery.com writes: @@ -569,7 +569,7 @@ UNSPEC_DPAU_H_QBL))] ISA_HAS_DSP !TARGET_64BIT dpau.h.qbl\t%q0,%2,%3 - [(set_attr type imadd) + [(set_attr type dspmac) (set_attr mode SI)]) (define_insn mips_dpau_h_qbr [etc] I think all these want (set_attr accum_in 1) too. Eeek, you are right. I have checked in the obvious patch to correct this. -Sandra 2012-08-16 Sandra Loosemore san...@codesourcery.com gcc/ * config/mips/mips-dsp.md (mips_dpau_h_qbl, mips_dpau_h_qbr) (mips_dpsu_h_qbl, mips_dpsu_h_qbr, mips_dpaq_s_w_ph) (mips_dpsq_s_w_ph, mips_mulsaq_s_w_ph, mips_dpaq_sa_l_w) (mips_dpsq_sa_l_w, mips_maq_s_w_phl, mips_maq_s_w_phr) (mips_maq_sa_w_phl, mips_maq_sa_w_phr): Add accum_in attribute. Index: gcc/config/mips/mips-dsp.md === --- gcc/config/mips/mips-dsp.md (revision 190453) +++ gcc/config/mips/mips-dsp.md (working copy) @@ -570,6 +570,7 @@ ISA_HAS_DSP !TARGET_64BIT dpau.h.qbl\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) (define_insn mips_dpau_h_qbr @@ -581,6 +582,7 @@ ISA_HAS_DSP !TARGET_64BIT dpau.h.qbr\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) ;; DPSU* @@ -593,6 +595,7 @@ ISA_HAS_DSP !TARGET_64BIT dpsu.h.qbl\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) (define_insn mips_dpsu_h_qbr @@ -604,6 +607,7 @@ ISA_HAS_DSP !TARGET_64BIT dpsu.h.qbr\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) ;; DPAQ* @@ -620,6 +624,7 @@ ISA_HAS_DSP !TARGET_64BIT dpaq_s.w.ph\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) ;; DPSQ* @@ -636,6 +641,7 @@ ISA_HAS_DSP !TARGET_64BIT dpsq_s.w.ph\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) ;; MULSAQ* @@ -652,6 +658,7 @@ ISA_HAS_DSP !TARGET_64BIT mulsaq_s.w.ph\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) ;; DPAQ* @@ -668,6 +675,7 @@ ISA_HAS_DSP !TARGET_64BIT dpaq_sa.l.w\t%q0,%2,%3 [(set_attr type dspmacsat) + (set_attr accum_in 1) (set_attr mode SI)]) ;; DPSQ* @@ -684,6 +692,7 @@ ISA_HAS_DSP !TARGET_64BIT dpsq_sa.l.w\t%q0,%2,%3 [(set_attr type dspmacsat) + (set_attr accum_in 1) (set_attr mode SI)]) ;; MAQ* @@ -700,6 +709,7 @@ ISA_HAS_DSP !TARGET_64BIT maq_s.w.phl\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) (define_insn mips_maq_s_w_phr @@ -715,6 +725,7 @@ ISA_HAS_DSP !TARGET_64BIT maq_s.w.phr\t%q0,%2,%3 [(set_attr type dspmac) + (set_attr accum_in 1) (set_attr mode SI)]) ;; MAQ_SA* @@ -731,6 +742,7 @@ ISA_HAS_DSP !TARGET_64BIT maq_sa.w.phl\t%q0,%2,%3 [(set_attr type dspmacsat) + (set_attr accum_in 1) (set_attr mode SI)]) (define_insn mips_maq_sa_w_phr @@ -746,6 +758,7 @@ ISA_HAS_DSP !TARGET_64BIT maq_sa.w.phr\t%q0,%2,%3 [(set_attr type dspmacsat) + (set_attr accum_in 1) (set_attr mode SI)]) ;; Table 2-4. MIPS DSP ASE Instructions: General Bit/Manipulation
Re: [PATCH, ARM] Don't pull in unwinder for 64-bit division routines
On Thu, Aug 16, 2012 at 11:56 AM, Ramana Radhakrishnan ramra...@arm.com wrote: On 07/24/12 13:27, Julian Brown wrote: On Fri, 20 Jul 2012 11:15:27 +0100 Julian Brown jul...@codesourcery.com wrote: Anyway: this revised version of the patch removes the strange libgcc Makefile-fragment changes, the equivalent of which have since been incorporated into mainline GCC now anyway, so the patch is somewhat more straightforward than it was previously. Joey Ye contacted me offlist and suggested that the t-divmod-ef fragment might be better integrated into t-bpabi instead. Doing that makes the patch somewhat smaller/cleaner. Minimally re-tested, looks OK. The original submission makes no mention of testing ? The ARM specific portions look OK to me modulo no regressions. Ian, can also take a quick look. Looks fine to me. Ian
[PATCH] AIX libgcc.map missing symbols
When libgcc was moved to its own directory, reorganized and refactored, the tmakefile fragment for AIX was broken. t-ibm-ldouble must come after t-slibgcc-aix because t-ibm-ldouble appends to SHLIB_MAPFILES Makefile variable and t-slibgcc-aix. This omitted ibm-ldouble support symbols from the libgcc.map and export file. Bootstrapped and regression tested on powerpc-ibm-aix5.3.0.0. Committed. This also will be back-ported to GCC 4.7. Thanks, David * config.host (*-*-aix*): Move rs6000/t-ibm-ldouble after rs6000/t-slibgcc-aix. Index: config.host === --- config.host (revision 190464) +++ config.host (working copy) @@ -898,15 +898,15 @@ ;; rs6000-ibm-aix4.[3456789]* | powerpc-ibm-aix4.[3456789]*) md_unwind_header=rs6000/aix-unwind.h - tmake_file=t-fdpbit rs6000/t-ppc64-fp rs6000/t-ibm-ldouble rs6000/t-slibgcc-aix + tmake_file=t-fdpbit rs6000/t-ppc64-fp rs6000/t-slibgcc-aix rs6000/t-ibm-ldouble ;; rs6000-ibm-aix5.1.* | powerpc-ibm-aix5.1.*) md_unwind_header=rs6000/aix-unwind.h - tmake_file=t-fdpbit rs6000/t-ppc64-fp rs6000/t-ibm-ldouble rs6000/t-slibgcc-aix + tmake_file=t-fdpbit rs6000/t-ppc64-fp rs6000/t-slibgcc-aix rs6000/t-ibm-ldouble ;; rs6000-ibm-aix[56789].* | powerpc-ibm-aix[56789].*) md_unwind_header=rs6000/aix-unwind.h - tmake_file=t-fdpbit rs6000/t-ppc64-fp rs6000/t-ibm-ldouble rs6000/t-slibgcc-aix + tmake_file=t-fdpbit rs6000/t-ppc64-fp rs6000/t-slibgcc-aix rs6000/t-ibm-ldouble ;; rl78-*-elf) tmake_file=$tm_file t-fdpbit rl78/t-rl78
Re: combine permutations in gimple
On Wed, 15 Aug 2012, Richard Guenther wrote: On Wed, Aug 15, 2012 at 1:56 PM, Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote: Of-course, the problem here is this change of semantics with the hook TARGET_VEC_PERM_CONST_OK. Targets were expanding to generic permutes with constants in the *absence* of being able to deal with them with the specialized permutes. fwprop will now leave us at a point where each target has to now grow more knowledge with respect to how best to expand a generic constant permute with a sequence of permutes rather than just using the generic permute. Generating a sequence of permutes from a single constant permute will be a harder problem than (say) dealing with immediate expansions so you are pushing more complexity into the target but in the short term target maintainers should definitely have a heads up that folks using vector permute intrinsics could actually have performance regressions on their targets. It's of course the same with the user input containing such a non-optimal handled constant permute. So I'm less convinced that it's too much burden on the target side. OTOH if there is a generic kind of shuffles that targets do not implement directly but can be simulated by two that are directly implemented pushing the logic to the expander (and adjusting the target hook semantic) would be ok. There's a wonderful knapsack-class problem in there, something for next year's GSoC? (Given a constant permutation, synthesize it with a set of simpler operations with total cost constant_shuffle, where the simpler operation and costs are target-specific (query for presence by TARGET_VEC_PERM_CONST_OK and cost hooks; decompose to simpler operation by generic heuristics). A similar but simpler problem is to synthesize a constant vector instead of loading it from memory (though a load may be cheap enough for most SIMD targets that this may be uninteresting to generalize). brgds, H-P
